December 2025 Update

This update is being written a week before Tech Exchange in Denver, where I will be presenting the usual update on 2025 work and future project plans, along with a bit of an update on the planning happening around the future of the Consortium. For those not attending, we are planning to record the session and make it available. We probably will also be looking at scheduling both Consortium and Project-focused webinars in the new year.

Aside from the major updates below, work has continued to build out OpenID Federation support in the form of an additional plugin for the OP and with that draft apparently soon to be final we will be making changes to align it to the final version of the specification prior to it being officially released.

Our migration of source code to Codeberg is now completed. All repositories have been moved and are mastered there now, with the active/non-frozen ones mirrored back for internal use. I sent an announcement of this yesterday and we have updated some wiki and web site links to reflect the change, though I’m sure there are other links to clean up. With this change, we have informally begun to discontinue support for the legacy GitWeb site, though it remains active for the moment because of some internal requirements. We are on track to eventually be able to shut it down but with the code now publically browseable again, there’s no major rush.

With this addressed, we can cross off the need to worry about GitHub, but there remain legal barriers to supporting Maven Central. Addressing those is a goal of the planning work happening around the Consortium, though by no means the most critical.

With the increased visibility, it’s a good time to note that while we welcome pull requests, the most practical way to do so is to license them using the Apache 2.0 license. The formal policy on contrbutions remains unchanged.

On the IdP front…

Spring 7 was finally released (as was 7.0.1) so a more formal determination of compatibility and any required changes has started. Spring Web Flow 3 “mostly” works, but there are some compatibility issues that don’t appear to impact us; we are thus in a slight holding pattern officially until SWF 4 is released, but have contingencies in the event that gets delayed too long for our purposes.

The most significant issue is sort of a less important one, which is a change to the Nullability annotations in Spring to JSpecify, which are not exactly compatible with our existing use of JSR 305 annotations. Eclipse is struggling with combining them, so we have to turn some of our checking off again for the moment, but we likely will have to consider migrating to JSpecify for a future release. This is more a problem for us, not for deployers.

We’re now in the stage of testing the idP with some snapshots of key dependencies updated along with the Spring changes so we can identify any show stopping issues for 5.2. Right now, it appears likely that December isn’t happening, but if SWF 4 drags past early January, I would expect we will need to activate our contingency plans and ship as is or with a forked version. We do not want to provide less than a 12-18 month lifecycle for 5.2 so we can’t afford to wait too long before shipping it.

In the interest of facilitating any testing of a 5.2 snapshot by anybody, I have updated the Release Notes and made the WIP notes for this release publically visible. There’s really only one significant regression risk in this upgrade (aside from Spring itself), the changes made to the Subject Canonicalization design, so that will be the focus of my testing.

I don’t know at this point whether the SP alpha will make it out by year’s end, simply because of the time available to finish off the installation story and produce something that’s suitable for testing, but it should come in January at the latest, and I remain pretty confident we can ship a 4.0 Agent (with a 1.0 Hub plugin set) by the end of 2026. I will definitely be able to demo something next week, with an emphasis on what the out of the box defaults look like and what it takes to go from zero to a working SAML SP.

Hub documentation still needs a fair amount of work before a real release, but it’s in a usable state for alpha testing. I have had some time to work on one of the additional session cache implementations for the Agent, so given the schedule, the new one may end up as the default at least for an alpha. There has been significant progress on the OIDC Hub plugin; it’s not clear yet if that will be close to alpha level by the time we make a formal announcement; the most likely outcome is probably a second alpha with some small Agent changes needed to allow OpenID to work properly, but we’ll see.

A big precondition to announcing an alpha is completing work on the Jetty plugin. We are quite close on that and I hope it’s available before the end of the year. I probably will demo that a bit as part of showing how to install the Hub next week.