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.

https://shibboleth.atlassian.net/browse/JOIDC-223
- 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
https://shibboleth.atlassian.net/browse/JOIDC-222
- 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.
https://shibboleth.atlassian.net/browse/SSPCPP-991
- Looks valid
Currently wrestling with Red Hat Developer Program renewal nonsense

- Think that is done (manually) across the ‘core’ code base.
- Not sure why this is working differently than other file resources in the IdP. Need to look at it
- Need to store the AAGUI (authenticator GUID) if present to attach metadata retrospectively.
and
- 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.