2019-06-21

Owned by Ian Young
Last updated: 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