April 2024 Update

Created by Scott Cantor
Last updated: Apr 10, 2024
3 min read

Since the previous update, we have shipped the IdP V5.1 update, and a V5.1.1 patch to address a Spring issue announced the day after and a couple of regressions. Regressions are never fun, but they were pretty minor and the update has been otherwise a non-event, which is always the goal.

Because of the Spring issue, we were forced to go ahead and issue a V4 patch update as well, which is likely to be the “if we have to, we will” final rollup release of that branch. Barring another security issue in the next 4 months, that will be it for V4.

Updating our plugin development status, we are on track to release updates to the OIDC plugins this week. Those plugins will be compatible with V5.0, not withstanding that support for that ended with the V5.1 release. We will likely be dropping an updated alpha release of the WebAuthn plugin relatively soon.

The Duo Passwordless update is coming, but (somewhat unusually for us) we have been able to get a significant amount of feedback from testers and I have been substantially rethinking things to take a fresh approach that should be easier to configure, and allows for more gradual adoption, which I think is a critical requirement for something like this to be successful. We have a new snapshot being tested, but there’s a bit more to do and unit tests to finish, so May is probably a more realistic guess for a release. It will also require V5.1 in order to leverage some newer cookie-related APIs. There aren’t any important “fixes” in this update to those using the current plugin, so we do not anticipate a major amount of pressure to update to it independently of the passwordless feature.

A note (and something of a warning?) about Jetty 12: in response to some early testing issues reported on the mailing list, we did the initial work to prepare a Jetty confguration suitable to it and created a page for that. One issue encountered by testers was isolated and reported as a bug in Jetty and that’s already been fixed upstream, so we believe the current 12.x release is now usable in production. There are a couple of notes about it that I would highlight, one particularly significant.

Likely a minor issue is that Jetty 12 does not include CGI support for reasons that are not clear to me. Those using Jetty by itself rather than behind Apache, for example, could be impacted by this limitation (I personally use CGI scripts extensively for various things, I don’t know how common that is).

The more signifiant warning I hope affects very few people at this point, and if not, well, it’s time: we do not know of a way to allow for the “accept any TLS client certificate for authentication” support on a second port that was part of the oldest Shibboleth deployments prior to SAML 2.0 adoption, i.e. the so-called “back-channel port” for SOAP traffic that often runs on port 8443 or a similar alternative port. So given that Jetty 11’s official EOL may not be that far off, anybody still relying on and supporting a second port in that fashion needs to pay off that technical debt and move on. It has been easily over a decade since that approach was even suggested, let alone advised.

We will put together a new page outlining more of the concrete considerations around migrating away from that approach, mostly for use by federations needing help crafting advice for their members. In a nutshell, you need to know what profiles your IdP supports, which ones are in use, and what services relying on that port might support or not support in terms of SAML metadata to allow a smooth migration away from it. In the meantime, the topic contains good information about why the additional port is largely a historical footnote at this point.