January 2026 Update

Welcome to 2026. Just returning from an extended break after getting back from Tech Exchange, where I managed a successful demo of the new SP.

Just prior to stopping for the year, I managed to get the first release done of the new Jetty plugin for the IdP, which will also serve as a facilitator for deploying the SP Hub plugins more easily (which typically will not be colocated with a “real” operational IdP). Early feedback is very positive on the ease of use this provides.

At the time I released the 1.0 plugin, the expectation was that it would nominally be supporting either Jetty 12.0 or 12.1, but we subsequently found out just before the holiday that the new version of Spring Web Flow (V4) was released and turns out to require Jakarta EE 11 and Servlet 6.1, which are only supported by Jetty 12.1. So for all intents and purposes, we’re essentially fully onto Jetty 12.1 now, which is a very trivial upgrade from 12.0.

To emphasize that point: the upcoming IdP V5.2 release will require Jetty 12.1 (or in Tomcat’s case, apparently 11.0) because of the imposed requirement for the latest Jakarta version. I have added this to the release notes and the implication is basically that it makes sense to move any existing IdP 5.x deployment over to a compatible container using Jakarta EE 11 now (which we support, but didn’t require), prior to later upgrading the IdP itself. Normally we don’t move that aggressively in terms of those server API versions, but Spring has moved more aggressively than we expected so we have to follow suit. This is a good example of the challenges we face with versioning our software in light of Spring’s increasingly aggressive pace. We probably might have just gone right to V6 if we’d had all the facts at the time, but we also know that perception matters, and apart from the container change, this is not a major or API-breaking release for us.

The Jetty plugin is also the eventual replacement on the V6 timeline (likely 2027) for the current pair of Windows installers for the IdP and Jetty. Microsoft has gone through yet more iterations of creating yet more installation APIs in Windows (all of which are very complex), and reliance on MSI as a tool at this point is technical debt we have to mitigate. For the time being, we still intend to ship the SP V4 Agents for Windows using that approach, but that probably will change at some point. In the meantime, the priority is to reduce our exposure to MSI and eliminating the “special” packages for the IdP and Jetty will help with that goal. It also means eliminating a lot of extra work alongside every new Jetty or IdP version for the project, so we are set on this course. We have no intention of reducing our support for Windows in any technical sense; only the form is changing.

The next major milestone will be getting IdP V5.2 out the door, which is needed for its own sake, but is also a prerequisite to getting the SP alpha out, as the Hub plugins do depend on IdP V5.2 and will not install into older versions.

While we are not exactly code-frozen, we are not making a ton of changes at this point and testing is underway. I was able to apply it to the QA environment at Ohio State and it has been working fine once I mitigated an issue due to my own use of implementation class in my configuration. I had to immediately make some adjustments to take advantage of the new features added for control of subject canonicalization which are outlined in PostLoginCanonicalizationConfigurationPreview, a new page I developed to articulate the differences. My use of an implementation class was actually a means of handling overlap between my use of c14n features between my password support and my proxying-to-Entra support, and the changes in V5.2 are about solving that problem in a simpler way. I hope and expect my issues are going to be rare and that most configurations will be forwardly compatible wth 5.2, as my trickery was the sort of thing only somebody knowing the code might try.

The rest of this week and some of next wll be spent on testing and addressing any remaining critical path issues, and we would expect a release by the end of this month. The SP alpha will follow shord some of next wll be spent on testing and addressing any remaining critical path issues, and we would expect a release by the end of this month. The SP alpha should follow shortly afterwards after a bit of further testing there, but will likely happen in February.

Finally, I’ll just note we released a minor SP patch to address a memcache issue that works around a bug in the underlyinig memcache client library we used for the build. In practice, this is mainly just a source patch for the benefit of certain organizations using that feature. The only platforms remaining that include the client library as a native package we can build against are older, EOL Red Hat versions, and all the more current packaging does not generally include memcache support in binary form.