...
This week's call will use the Zoom system at GU, see ZoomGU for access info.
AGENDA
...
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-attributeandjava-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.
Oracle are now indicating 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.
They have talked about this changed cadence before in the “future hopeful” so this is not a complete surprise. I expect this to be confirmed at JavaOne, which is October 17–20.
The One interesting question is whether things like 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
- merged in the feature branch (dev/JCOMOIDC-41)Jira Legacy server System JIRA serverId f52c7d31-6eab-3f0e-93c3-231b5754d506 key JCOMOIDC-49 Took a bit of time, a thank you to Henri for testing the OP against it before the merge.
- 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.Jira Legacy server System JIRA serverId f52c7d31-6eab-3f0e-93c3-231b5754d506 key JCOMOIDC-48 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