Shibboleth Developer's Meeting, 2024-04-05

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-04-19. Any reason to deviate from this?

60 to 90 minute call window.

Call Details

This week's call will use the Zoom system at OSU:

http://shibboleth.net/pipermail/dev/2024-April/011171.html

AGENDA

1. FYI, we did not get approved for the GEANT grant

2. Releases postmortem, if anything

3. API/IdP baseline for next round of OIDC/Duo plugins

4. (PS) OIDC Stack (other than Duo) release schedule

   1. Thursday 11th April full OIDC stack; commons, config, OP, and RP.

5. Succession planning

Attendees:

Brent

Daniel

Henri

• Null cleanup

• OP testing, documentation

  • Last-minute bug: JOIDC-199: UserInfo JWT access token issued by the implicit authorize flow is not signedClosed

• Initial drafting for PAR and DPoP support

Ian

John

• Helped Scott setup and test DKIM and DMARC for shibboleth.net

• Documented https://shibboleth.atlassian.net/wiki/spaces/DEV/pages/3517317124 for shibboleth.net and tested on a temporary domain

• cpp-linbuild image bumps for AZL 2 & 2023, RHEL 7, 8, & 9

Marvin

Phil

• Some null cleanup on commons crypto and metadata

• Making sure the RP is working with the new stack

Rod

• Heavily engaged elsewhere

• ‘We need to talk about the Windows Installers’

  • I’ll send mail around in the next two weeks with status and proposed actions

Scott

• Jetty 12 testing – think this is worked through for basic use, bug Paul found (see list) supposedly already patched

  • Debating eventual port of removed CGI servlet in our libraries

  • Proposing we drop the back-channel plugin, but to be fair I didn’t test it on 12, maybe it just works?

• Working through a redesign of Duo Passwordless support

  • Eliminating use of Admin API as an eligibility check due to DOS concerns

  • Developing a new design allowing user to opt-in after second factor use

  • More understandable to users (I think) and more flexible but also simpler to deploy

    • Allows user/group-based criteria for eligibility, allowing gradual adoption a la many MFA rollouts now

Tom

• working through Jenkins integration tests post releases

• started work on running integration tests with Jetty 12

• then get back to OIDC and browser integration tests using CA-signed certificates (instead of self-signed, to support testing Safari and testing on Rocky versions which disable insecure algorithms)

• as a deployer :

  • working on upgrades (both V4 and V5)

  • are entity attributes (such as requesting REFEDS MFA) supported for MD-driven OIDC SSO + SAML proxy authn flow ? I’m thinking I’m missing an authn context comparison somewhere - works fine for MD-driven SAML browser SSO

  • would like to override a relying party’s security configuration (to use a different signing key with a shorter lifetime) via metadata (i.e. MD-driven) - not sure how

Other