Shibboleth Developer's Meeting, 2024-09-06

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 would be Friday 2024-09-20. Any reason to deviate from this?

60 to 90 minute call window.

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

JOIDC-223: IDP Session (cookies) not created after OIDC Login in IDP Version 5.1.3 Resolved
- Now uses HttpServletResponse.sendRedirect(..) whenever Location-header has a value
- The bug is also reported to Nimbus
Finalising OP 4.2
- The two major features (PAR and dPoP) are reported to be working as expected
JOIDC-222: Support for OpenID FederationIn Progress
- Working on fetching and validation of trust chains (RP → superior authorities → trust anchors)
- DynamicMetadataCache seems to be a good building block

Generated several pages of thoughts about how a cpp-linbuild/ECR integration should work. Almost have a plan that seems sane and implementable.
SSPCPP-991: RPM's for systemd based RHEL/clone distros include unnecessary deps on legacy sysv initscript packagesOpen
- Looks valid
Currently wrestling with Red Hat Developer Program renewal nonsense

GEN-337: Analyse code base for boxed primitive comparisons using reference operatorsOpen
- Think that is done (manually) across the ‘core’ code base.
JWEBAUTHN-21: IdP does not start with a non-existing fido metadata cache fileClosed
- Not sure why this is working differently than other file resources in the IdP. Need to look at it
JWEBAUTHN-23: user.displayName is not usedClosed
JWEBAUTHN-26: Allow metadata to be attached to registrations retroactivelyClosed
- Need to store the AAGUI (authenticator GUID) if present to attach metadata retrospectively.
JWEBAUTHN-24: Make user.name configurableClosed and JWEBAUTHN-25: Have username/password login during registration pre-fill the username fieldOpen
- Critical to a v1. I think I need to:
  - Integrate c14n into the username collection steps. Otherwise the credential is registered against a principal name and the user can enter a different username into the view which will not match to a credential (and it will fail).
  - De-couple the internal username/principalName used for registration v what is sent to the authenticator (although less sure about this atm)

Turning around a very small TOTP plugin update
- Identified a bug in the attribute library targeted at IdP 5.2
Work ongoing on SAML assertion consumer service flow based on back-half of proxy flow
- Per Slack, all but the very final bits have been reused or very lightly adapted/adjusted code from the IdP, I’m up to the “what do I do with the data and what do I send back to the agent” step, which is all new design work.
- Working assumption is a series of configured subflows that get a shot at handling a request and first one to activate wins and either succeeds or the response fails
- Each supported binding is its own subflow, and the master flow provides a single response endpoint for all protocols
Split off the SAML flows in progress into a new plugin project so base plugin is now protocol-less
- Creates some hassle in the new agents config file for controlling protocols to enable since we can’t default in any, but the alternative would be to assume SAML or OpenID in the base plugin
Some discussion about accepting our Velocity/Spring changes, but not sure it’s going to be worth the bother at this point.