April 2025 Update

It’s been an eventful, if not altogether enjoyable, month for the project. The security report on OpenSAML came in just after the last blog entry and it’s taken several weeks for all of the work on that to get completed (and it’s technically still not quite done, we plan to issue an OpenSAML-specific advisory as a courtesy to the (very small) number of members that are funding us specifically for the library.

The issues centered around the non-XML signing features in SAML, which we made worse 20 years ago by creating a rather sloppy extension specification called POST-SimpleSign, which seemed like a good idea at the time (it…was not). Its subtle differences from the HTTP-Redirect binding made our code somewhat “odd” in both C++ and Java and it took a while to really understand the full scope of the vulnerabilities. If not for POST-SImpleSign, the SP implications would have been minimal but they were not as it turned out. These kinds of issues with the SP are significantly more expensive nowadays because so much of our focus is on Java and on redesigning the SP, so it’s a costly exercise to crack open that code and figure out the most expedient fixes to apply.

The fix I would like to have made to OpenSAML-C++ (and that the reporter urged me to make) would have required API changes that would have necessitated version bumps to it and the SP, and updates to triple the number of packages. I simply didn’t have the time or inclination to do that and my existing APIs made some simpler mitigations workable enough for now, but it is possible I’ll eventually implement the better fixes later.

The process of getting that patch out was bumpy for reasons I’ve noted exhaustively; suffice to say we’ve take some steps to clarify how information about these kinds of issues should be embargoed going forward, but we don’t control what other projects do.

We took more time with the Java fixes simply because we could. While we did identify a larger concern in the IdP than initially thought, it still wasn’t critical. The extra time allowed for more comprehensive changes, including a more robust fix that should address the issues for other projects that might be using our code without additional steps or changes by them. Security fixes that require changes to clients of a library are not generally all that successful.

In the midst of all the chaos, the business of the project continued with the release of several plugin updates (WebAuthn, OpenID RP, JDBC, TOTP). The Duo plugin will get an update “soon”, we have to track down at least one signing key for a dependency before we can ship that. We’re also hoping to get a first release of the Thymeleaf view technology plugin done this summer. If there are deployers who use Thymeleaf and would be interested in helping produce some examples for that, please get in touch.

The IdP V5.2 update is targeted for early Summer as well and will of course be a drop-in upgrade. Much of the urgency there was lessened since a number of bug fixes got backported to V5.1.4 anyway.

I have been slowly returning to working on the SP V4 redesign, and several key milestones have been crossed this year, including a successful (and secure?) end to end test of a SAML exchange with the information from the assertion dumped to the browser for now, pending the creation of a new session cache layer. There’s a ton of work left, but that’s a major proof of the design and should put us on track to deliver an alpha release this year, and I think shipping something in 2026 feels realistic. Probably the biggest barrier to that is documentation in fact, and it has to at least be a point of discussion whether to continue producing our documentation with Confluence or not.