Shibboleth Developer's Meeting, 2019-06-21
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.
This week's call will use the Zoom system at GU, see ZoomGU for access info.
- Next meeting: 5th of July. Push? (decision: yes, so next is the 2019-07-19, in four weeks)
Add items for discussion here
- Back from vacation. Apologies for not setting up the Zoom meeting for last time.
- - Velocity devs supportive of this proposal, will work on soon.
- On Holiday.
- Finished two of the three CSRF defence PoCs.
- Implementations are for showcasing ideas, and not tested thoroughly across different flows etc.(yet).
I may be slightly late to the meeting (but I'll be there) don't wait for me
Generakl Tidy in the IdP
- Testing 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?
- Completed without any changes to apis
- Requires systematic API change (
@Nullable Boolean )
- Also flushed (which may be artefact of testing, not of the code)
- 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