June 2026 Update

Bit of a longer update this month, as I neglected to provide an update in May due to the Board not meeting, but we have been working steadily nevertheless.

The major task last month was wrapping up work on a security fix for the IdP and shipping the patch release, which was a little more complex than usual because as an OpenSAML vulnerability we were and are aware that many other software packages and services would be impacted by it and many of them are very unlikely to every upgrade to a supported release. While we are certainly withiin our rights to ignore those, we did want to provide a thorough enough advisory to provide some mitigations for those cases. We also needed to take more time than expected because of the discovery that some of the eduGAIN metadata was pretty messy with respect to XML namespace normalization (or lack of) and was going to immediately cause issues with the default settings we planned on using. We did additional work to sidestep that problem for people running current versions, but it would be best for federations to clean that XML up for people, and many already do.

We also had the additional complication of the Jakarta Mail vulnerability (which is entirely on us, we should have been aware of it a long time ago), and it took time to work out whether fixing or removing it was the best course of action. It was pretty close to unanimous that removal was the right thing to do.

Anyway, that all took some weeks to sort out, along with identifying and remediating a few other open, if not impactful, library vulnerabilities, and getting a few other bugs patched.

Where we are now is at the stage of determining what the next planned IdP release is likely to be. While we have a lot of technical debt that we’d love to attack in a V6.0, realistically we have too much else going on this year to make that happen, so more than likely we will have to make the next upgrade a V5.3 release to pick up Spring 7.1 this winter, and probaby look at V6 in 2027. As such, the SP4 Hub is likely to be based on V5.2 or V5.3 of the IdP (it’s currently pinned to V5.2). At this point, the OID Federation work remains pinned to V5.0 along with all the other OIDC plugins we have, and that seems likely to remain the case.

Work on the SP has continued over the last couple of months, though balanced by other priorities. The most recent phase of work there involved completing the redesign of the state management layer used for CSRF protection to better cover both SAML and OpenID, and the implementation of logout support “inbound”, meaning processing logout messages issued by IdPs/OPs, both requests and responses. This was fairly complex for a couple of reasons. Keeping the Agent totally “unaware” of the details of the protocols was much more challenging with logout than it was for authentication. And in particular, the SP support for notifying applications of a logout through a series of redirections is something I know people make use of, so retaining that functionality was necessary but hard to pull off. I cobbled together a solution and it’s finally working at least for SAML under initial testing. We believe the model should adapt to OpenID’s logout protocol, as they unfortunately repeated a lot of the mistakes we made designing SAML logout (though not everything, SAML’s is still much worse).

Anyway, a number of additions to the Agent were required to complete the logout work, so we are pretty close to shipping a second alpha of the Agent, probably later this month.

In addition to that development work, we have most of the work done to replace the MSI-based Agent installation process for Windows with a simpler approach using batch files. The registry will still be updated with the information needed to report the Agent version installed to inventory tools (something I recognize is very important), and to uninstall the Agent. Most likely the second alpha will use that approach.

In parallel, we did some build testing of the older SP on the latest LTS release of OpenSSL to ensure that we can get the release refreshed with a supported version of all the libraries, which may be necessary as soon as this week, as OpenSSL is releasing its latest set of advisories tomorrow as I write this. That OpenSSL version (3.6) should be supported for the remaining life of the older SP code base, so that buys us the time needed to get it retired in a few years. I’m still trying to hold off releasing V3.6 of the SP so I can get additional deprecation warnings in place for that “final” release, and that ideally won’t show up until close to the SP4 release.

Other updates:

The OID Federation work has reached a refactoring stage to allow us to produce another shared library plugin we will need to enable federation support in both the OP plugin and the SP Hub plugin. This is a precondition for getting the SP part of that work going, though I don’t know what we expect it to ship with the first Hub releases (though regular OpenID support alone certainly will). This is also provides opportunities for simplifying configuration and then getting it documented, which need to happen before we ship any of this work. We’re also developing a command line tool that will exercise trust chain resolution, sort of an AACLI for OID Federation if you will, which we think will be pretty crucial in making this deployable.

Finally, the first of possibly a few webinars for Consortium Members will be held in a couple of weeks to provide an update on the SP4 work, demos of both SAML and OpenID using commercial tools with it such as Entra and Google’s IdP, and discussion of deployment/migration, along with general Q/A. We distributed an invitation to this webinar to the member contacts we have on file and have to rely on them to circulate the invitation internally. If you work for a member organization, and would like to attend, you can reach out to us at contact@shibboleth.net and we can put you in contact with the right person to get the information from. We will be uploading some demo videos before or after that will be public, but the actual webinar recording will of course be restricted to members).

While I plan to be at TechExchange in October for another update session, it’s quite possible I won’t be doing that every year now (or even most). I don’t really care to travel for work much now that I’m retired, and honestly we get much more bang for the buck doing this kind of webinar, as more of our members can attend, and its our members that we owe these opportunities to, not the general public.