August 2024 Update
A short update on various tasks in progress…
Firstly, a reminder that IdP V4 will be EOL as of September 1, just a couple of weeks off. There likely will not be another V4 patch at this point, barring something serious.
We discovered a fairly serious bug warranting an IdP V5 patch release, so that was completed. It was not a security issue, but deployments that do not use the shipping defaults for managing client sessions via HTML Storage would have been prone to more frequent re-authentication due to cookie issues, which some had been reporting anecdotally. A decent backlog of other small issues had been accumulating as well.
After identifying some last minute issues, the WebAuthn plugin will be in a “release candidate” state after today, for testing. The final release of 1.0 will be at the end of this month.
A new version of the OIDC OP plugin should be coming soonish, most of the major tasks are nearing completion. Tha major features are advanced capabilities like PAR and DPoP support. Work on OpenID Federation support will commence once that’s complete.
We pushed out a fix (after several aborted attempts) for the SP packages on Amazon 2023 Linux.
A reminder that while we will continue to build packages for CentOS 7 if we can, official support for RHEL 7 is now over as it has reached the public EOL stage. I know a lot of campuses have a lot of existing RHEL 7, including my own, but I’m just being up front here: Red Hat has made CentOS very hard to continue to build for, and building on native Red Hat is “complex” for me at least, and officially we have no obligation to do so, so if you are on that platform, you need to recognize that you’re on an unsupported platform and packaging may cease at any time.
On the Jetty and Windows packaging front, a number of irons are in the fire. The latest IdP patch was the first time for us building the Windows installation package with a new Maven-driven process that is more automatable and repeatable. It should be feature-identical to the earlier versions, it’s just built somewhat differently.
We have a working installer for Jetty 12 at this time, but have run into a handful of serious bugs in Jetty, and the latest version has a fatal regression that makes it unsafe to use, so we are still waiting on a fixed version we can ship and then we will be officially making that the Windows baseline. I’m now running an older version of 12 myself in production. If nothing else, I did observe that its defaults now meet SSL Labs “A” grade for TLS configuration without customization.
In parallel, we have been working internally on the approach I mentioned last month, an IdP plugin that essentially installs Jetty “inside” the IdP configuration tree. We’re still working out the implications for customizing Jetty and for upgrades, but it should be a promising direction for simplfying initial setup and should be quite Docker-friendly, as I mentioned, but in a “use a staged instalation to produce a Docker image to deploy” way, not a “deliver the IdP via Docker” way. We have to adjust some APIs to support this plugin, but I believe it may be possible to ship a version of it prior to work on IdP V6 (which has not started at all at this point).
Finally, I have continued to make progress on the SP redesign and have successfully built code producing SAML AuthnRequests on behalf of agents, essentially the “front half” of implementing SAML for the SP. That portion required more new code than the back half is likely to require. Some work remains but nothing show-stopping has emerged in the design so far, and I’m happy with the way the split in responsibility between the agents and the hub is shaping up, which is to say “as little as possible in the agents”. The next phase of work is to wrap up some RelayState handling code, and then I will be moving the drafted SAML logic into a new plugin so that the SP will be protocol-independent. We will be producing SAML and OpenID plugins for the SP plugin, essentially sub-modules that add the desired protocol(s). It is an explicit goal for agents to be entirely protocol-agnostic and not require modifications to add or remove protocols in Java.