Shibboleth Developer's Meeting, 2023-03-17

Call Administrivia

09:00 Central US / 10:00 Eastern US / 14:00 UK / 16:00 FI (note unusual time in UK, FI due to DST change in US)

Calls are normally the 1st and 3rd Fridays of each month. Next call would be Friday 2023-04-07. Any reason to deviate from this?

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

1. FedCM Update

Attendees:

Brent

• Any more questions etc on HC 5 update?

Daniel

• Nothing to report.

Henri

• https://shibboleth.atlassian.net/browse/JCOMOIDC-67

• JCOMOIDC-41: Move OIDC Signature Validation resolvers and parameter classes to commonsClosed

  • Flow tests for authorize, token and userinfo flows now cover signed and encrypted JWTs with all supported algorithms

  • Algorithm exclusion also covered for signing and key transport algorithms, one bug found for exclusion of data encryption algorithm

• JOIDC-142: Improve Request Object handling and configurationClosed

  • Next up

Ian

• Spring Framework 6.0.5 and 6.0.6 are out, but not integrated. We expect their new signing key to be published on their web site soon, now.

John

• Unable to attend today

• Almost done with SSPCPP-968: "make clean" target and friendsIn Progress. A little bogged down in naming cats.

• Updated Amazon Linux images to latest, including newly-GA AL2023. Completed smoke test builds on x86_64 and aarch64.

Marvin

Phil

• RP tinkering.

  • allow login_hint function in the profile configuration

  • Allow UserInfo request by POST as well as GET

  • Cleanup the IDToken and UserInfo request decoders

• https://shibboleth.atlassian.net/browse/JCOMOIDC-66

  • Creating interfaces, throwing them away, creating more interfaces, and making some diagrams to avoid more confusion.

Rod

• null cleanup

• Some Jira backlog

Scott

• Started null cleanup on OpenSAML

• Reviewing HttpClient changes

• Working on SP configuration “framework” based around Application interface

  • Instead of reusing RelyingParty resolver, Application will do its own resolution of default or overridden RP config

  • Moved “default” SecurityConfiguration into RelyingPartyConfiguration

    • More sensible than the old approach of the resolver exposing it

    • Obviates the need for profile-specific security configs in most cases but still an option

  • Deployer declares Application beans that can reference shared or contain specific RelyingParty/Profile configurations

  • All the beans typically inside RelyingPartyResolver service will be in the “ServiceProviderService” (no idea what to call it yet) that exposes the Applications and other Remoted endpoints that do work

  • With Spring magic, no need for the current idea of a “default” Application and nested overrides. Just map requests to an Application, and share beans as needed to have defaults and special settings

Tom

Other