Shibboleth Developer's Meeting, 2024-10-18

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-11-01. 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.

Nexus Coordinates for the jetty and SP plugins
- Subquestion: Where does the “legacy jetty base” live
Plugin documentation proposal to move “most” of them into IdP doc space
(Lack of) timeout for HttpClient – any appetite to try to fix?
Plugin use of impl classes

Finalising and documenting the OP 4.2.0 release
- https://shibboleth.atlassian.net/browse/JOIDC-201
  - Final adjustments regarding nonces and some other details
- Release (common 3.2, OP 4.2) scheduled for Wednesday

No progress worth mentioning on ECR integration
Tested SP upgrade (3.4.1-6 → 3.5.0-1) on all supported platforms (x86-64 and aarch64) except CentOS 7 & 8
Rocky 9.4 aarch64 bug on EC2

https://shibboleth.atlassian.net/browse/JWEBAUTHN-27
- Pretty much done testing, will merge than into main today.
- Need to fix the newly structured wiki docs.
https://shibboleth.atlassian.net/browse/IDP-2339
- Will look to add more options for token generation and look to only enforce on POST requests.
https://shibboleth.atlassian.net/browse/JCOMOIDC-115
- Will retest the RP and Duo, given there might be a release of this soon.
New tester of the RC.

Proposals for IdP doc improvement
SP 3.5 release
- Waiting on final testing of RPMs before publishing
- Xerces 3.3.0 and xml-security 3.0.0 tagged and released
Reviewing existing SP design notes to align to running code
- Prep for beginning to work on agent development plan expecting possible external contribution to that work
- Current state of things is to allow agents to act as any URLs because determination of entityID is entirely Java-side
  - Could still supply an unused callout for validation
  - SP’s auto-vhosting feature would be handled by moving generation of entityID to hub, so the entityID “pattern” remains controlled
  - Need to see if that assumption holds for OpenID

Seems like global.xml should be reloaded when any service is reloaded, since it’s … global ? or maybe it is
MFA : trying to use the authn/MFA flow as mechanism for failover - should step-up authn work ?
- use case : want to failover to a backup authn flow (External) if the primary (SAML) is not available (e.g. disaster scenario)
  - MFA strategy is simple = always return primary authn flow unless a certain file exists, then return the backup authn flow
- step-up MFA is not working > NoAuthnContext - what to do ?