Page Comparison

...

This week's call will use the Zoom system at GU, see ZoomGU for access info.

AGENDA

...

1. Duo Passwordless review

Attendees:

Brent

• HttpClient v5: Reviewing docs, evaluating changes. Looks not as bad as I earlier thought.

Daniel

Henri

• Jira Legacy
  server System JIRA serverId f52c7d31-6eab-3f0e-93c3-231b5754d506 key JOIDC-127

  • Should be finished, I’ll close it once I get a confirmation from a customer

• Jira Legacy
  server System JIRA serverId f52c7d31-6eab-3f0e-93c3-231b5754d506 key JOIDC-128

  • Authorize-flow now supports OAuth authorization requests in addition to OIDC authentication requests

    • Separation is done via the presence of scope-parameter and openid value

    • For OAuth requests: resource parameter is required if OAuth RP’s metadata doesn’t contain audience

  • UserInfo-flow verifies that the incoming access token contains openid -scope

Ian

• Completed pruning of java-shib-attribute and java-shib-metadata, down to 28M and 17M from 85M each.

  • Anachronistic history largely achieved.

• Java 19 is now GA. Mostly feature previews: record patterns, virtual threads, structured concurrency.

• It is now confirmed by Oracle that Java 21 (September 2023) will be the next LTS release.

  • Note that this is only two years after Java 17, not the three-year gap between 11 and 17 they initially claimed would be the pattern going forward.

  • One interesting question is whether virtual threads make it into Java 21. Probably largely a concern for the containers (Jetty 10/11 already has some support), but we will want to be compatible.

  • I think we more or less have to say we’ll support Java 21 for IdP v5, and that would mean adding it to the Java 17 platform description. We don’t have to make that promise now, but I don’t think it’s in doubt.

  • I think we probably want to say the same for IdP v4, unless v4 is already unsupported by next September (which seems unlikely). Again, we don’t have to say this now.

  • The rule of thumb looks like it will end up being that we support the most recent LTS at the time of a major release, and two subsequent ones. (11, 17, 21 for v4; 17, 21, 25 for v5).

• In passing: Debian 11 “buster” shipped with a Java 17 EA release only, but now has an up-to-date 17.0.4. I’ve updated the Java Distributions page to add that to the “partially supported” category.

• I’m now aiming to make an MDA 0.10 release by early 2023, as UKf and InCommon appear able to adopt around then.

  • This will now target the same stack as IdP v5: Java 17, Spring Framework 6 (and java-shib-shared).

• I’ve started thinking about getting more formal about the Java 17 platform, specifically supported distributions.

  • Proposal for a new section in Java Distributions:

    • Corretto 17 for Linux as primary distribution.

    • Fully supported: Corretto 17 for Linux, Corretto 17 for Windows, RH OpenJDK 17 as shipped in RHEL/Rocky 8, RH OpenJDK 17 as shipped in RHEL/Rocky 9.

    • We don’t yet know what Amazon and Red Hat are going to do about Java 21, so we can’t add that yet.

    • Partial support: Debian’s OpenJDK 17 on Debian 11 “buster”.

• Spring Framework 6 is nearly here:

  • 6.0.0-RC1 on 2022-10-12 (next week)

  • 6.0.0-RC2 on 2022-10-20 (Spring Boot 3.0.0-RC1 on this date too).

John

• Jira Legacy
  server System JIRA serverId f52c7d31-6eab-3f0e-93c3-231b5754d506 key SSPCPP-954

Marvin

Phil

• Jira Legacy
  server System JIRA serverId f52c7d31-6eab-3f0e-93c3-231b5754d506 key JCOMOIDC-49

  - merged in the feature branch (dev/JCOMOIDC-41)

  • Took a bit of time, a thank you to Henri for testing the OP against it before the merge.

• Jira Legacy
  server System JIRA serverId f52c7d31-6eab-3f0e-93c3-231b5754d506 key JCOMOIDC-48

  - moved the RP profile and security config over locally, which obviously works fine for just the RP, but a much bigger job when considering the OP profile and relying party config.

• More wiki docs and more RP flow bean cleanup.

• Was mistakenly worried about an old JWT key confusion attack (CVE-2016-10555). In the end, the vulnerability is from a particular library that is just bizarrely coded.

Rod

• Cleanup - Notably

  Jira Legacy
  server System JIRA serverId f52c7d31-6eab-3f0e-93c3-231b5754d506 key JSSH-5

• Now looking at

  Jira Legacy
  server System JIRA serverId f52c7d31-6eab-3f0e-93c3-231b5754d506 key IDP-1927

  • Engaging with JISC and Canarie Support Team on requirements

  • Nature study under way

Scott

• Started on getting a Xerces patch out the door, to pick up some memory leak patches and other fuzzing issues. No immediate plans for an SP release, just getting it done in case.

• Finished? the refactor/rename in the support classes.

  • Have some remaining ideas for improvement but since everything has been rehomed, the breakage can’t get worse.

• Redesigned the use of web.xml to deal with the prevelance of class names (

  Jira Legacy
  server System JIRA serverId f52c7d31-6eab-3f0e-93c3-231b5754d506 key IDP-2015

  )

  • Old filter references are stubs for the V5 release, will be removed in V6

  • 3 new context initializers are exposed via idp-conf-impl

    • One installs the Spring listener and context-init parameters (enabled via a new context parameter)

    • One installs the filters via a new “chaining” filter that calls other filters, defined via Spring (filters.xml)

      • The new filters can influence relative order Apache style

      • Enabled by default, old filters are no-ops or harmless, can be disabled via a context parameter for testbed

    • One installs the servlets (individual context parameters to enable/disable each)

      • The RemoteUser/X509 servlets (which should have been controllers, alas) are now Spring beans with property-based config, called by a new delegating servlet copied from Spring’s delegating filter class

    • Subject to testing, should be backward compatible with V4 web.xml

...