Shibboleth Developer's Meeting, 2022-01-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 2023-01-20. 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

• Apropos the 4.3 release, Spring Framework 5.3.25 is due in less than a week on 2023-01-11: https://github.com/spring-projects/spring-framework/milestone/308?closed=1 has 17 closed issues, none open, nothing that immediately stands out as relevant to us. Do we want to delay and pick it up anyway?

• Plugin implications of 4.3?

  • oidc-commons base opensaml and idp versions?

  • Set max version to 4.3 (exclusive) for plugin versions that would warn on the HttpServlet* work.

• Naming convention for JSON security classes?

Add items for discussion here

Attendees:

Brent

• Out for last 2.5 weeks.

• Will begin impl of proposed OpenSAML decryption remediation immediately. Expect to be done by mid-next week at latest.

Daniel

• Nothing today.

Henri

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

  • OP starts to be in fairly good shape with the new security configuration style: all the existing flow tests pass

    • Algorithm-setup via client information (metadata) still not complete though

  • Incoming JWT signature validation now harmonised

    • TrustEngine used for client authentication (OAuth2Client) and request object validation

    • Previously via JWTSignatureValidationUtil inside SWF actions

Ian

• https://shibboleth.atlassian.net/browse/IDP-2055

• https://shibboleth.atlassian.net/browse/JPAR-205

• https://shibboleth.atlassian.net/browse/JPAR-215

John

Marvin

Phil

• Not much. Helping Henri with the commons changes — Henri doing most of the work.

  • Although I now need to update the RP to use anything we moved into commons.

• Name changes in commons, on the agenda

• Centralising the Profile beans … still not tackled that properly

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

Rod

• https://shibboleth.atlassian.net/browse/IDP-1793 (again and again and again)

• I’ll probably build an enforcer-data and windows jetty-base this week in prep for 4.3.

Scott

• Nothing over break

• Worked through some small 4.3 backlog this week and started testing snapshot at OSU, expect to complete bulk of testing this week

• Did initial analysis of SP exposure to the XML Encryption issue through experimental testing and analysis of xml-sec-c code

  • SP does honor CipherReference as expected

  • SP would attempt XSLT and XPath transforms if Santuario were built againt Xalan, though I obviously do not in my packages

    • Even so, it doesn’t follow that the issues in Java could apply, but I don’t know how generic the “external callout” hook in XSLT is

  • SP seems NOT to be able to resolve remote references in the encryption code, and my belief from code review is that by some weird coincidence, Santuario “accidentally” doesn’t install the default URL resolver code into the Cipher objects the way it does for Signature objects. I don’t know why and am not 100% sure yet that I’m correct, need to debug it.

    • I can trigger a particular exception message failing to deref the URI that appears to be a product of the resolver being null.

Tom

• Some module and plugin tests

  • verify that the IdP starts with all modules enabled and plugins installed

Other