/
2019-06-21

2019-06-21

Jul 29, 2021

Shibboleth Developer's Meeting, 2019-06-21

Call Administrivia

09:00 Central US / 10:00 Eastern US / 15:00 UK / 17:00 FI

Calls are normally the 1st and 3rd Fridays of each month. Next call will be Friday 2019-07-19.

60 to 90 minute call window.

 

Call Details

This week's call will use the Zoom system at GU, see ZoomGU for access info.

 

AGENDA

  • Next meeting: 5th of July. Push? (decision: yes, so next is the 2019-07-19, in four weeks)

Add items for discussion here

Attendees:

 

Brent

  • Back from vacation.  Apologies for not setting up the Zoom meeting for last time.

  • IDP-1461 - Getting issue details... STATUS
    - Velocity devs supportive of this proposal, will work on soon.

 

Daniel

 

Henri

 

Phil (absent)

  • On Holiday.

  • Finished two of the three CSRF defence PoCs.

    • Implementations are for showcasing ideas, and not tested thoroughly across different flows etc.(yet).

    • Updated document CSRF Mitigation Options

    • Added implementations to my personal git repo git@git.shibboleth.net:philsmart/java-identity-provider (see doc for branches)

    • Will finish the third next week or the week after, then announce on dev list for comments.

    • Will add to agenda of next meeting.

Ian

 

Marvin

 

Rod

I may be slightly late to the meeting (but I'll be there) don't wait for me

Generakl Tidy in the IdP

  • Testing 

    IDP-1418 - Getting issue details... STATUS
    led me into the world gauges (which I think we have bottomed out)

    • Do we have any thoughts about doing a deferred load for non fail-fast services?

  • IDP-1464 - Getting issue details... STATUS

    • Completed without any changes to apis

  • IDP-1457 - Getting issue details... STATUS

    • Requires systematic API change (boolean  to @Nullable Boolean )

    • Also flushed

      IDP-1470 - Getting issue details... STATUS
      (which may be artefact of testing, not of the code)

 

 

Scott

  • JSPT-87 - Getting issue details... STATUS

  • Mostly docs, support, revving brain up for proxy flows

    • Envisioning three login flows for proxy auth (CAS, SAML, OIDC)

    • Base flow for all three will optionally invoke discovery

      • Disco protocol explicitly requires ignoring query string so flowExecutionKey won't break it

    • Create new ProfileRequestContext tree under AuthenticationContext (PRC → AC → PRC)

    • Concrete flows would do varied forms of metadata lookup specific to each protocol based on discovery result

    • MFA flow can script each type to allow for prioritization of protocols (try CAS, then SAML, etc.)

    • Response locations for protocols will have to implemented outside of core flow to allow for endpoint validation

      • Flows will essentially produce outbound messages but inbound will have to be caught by a servlet or JSP and probably use relay state / target data to recovery flowExecutionKey for resumption

Tom

 

Other