March Update

The last few weeks have been dominated by the recent cross-industry SAML vulnerability discovered by a Duo Security researcher, a lot of research into the impact of Java 9, 10, and 11 on our dependencies and build process, and continued work on the SP 3.0 features and documentation.

The vulnerability has dominated a lot of conversation of late. It was embargoed for about a month and I've been dropping various hints about it, mostly by alluding to the previous vulnerability that we fixed in January because it's actually almost an identical bug, at least in our SP. Once the new issue came to light, the importance of XML Encryption became very evident, since it mitigated both the original and the new class of vulnerabilities, and the fallout in pure Shibboleth deployments was much less as a result.

The real fallout from this is with cloud integrations, both because they are the most likely to forgo encryption, but also because there are so many different, and often substandard, SAML implementations in use. This is the reason we're so vocal as a project in advising people not to even consider building their own code on top of OpenSAML. We don't have the resources to document it adequately, and there are very few developers with the skills necessary. I say that with full self-awareness of the fact that we were vulnerable; that reinforces the point rather than weakens it.

Anyway, a lot of the time on this has been the fallout and considering how to approach the problem of finding and reporting all these vulnerable systems to  companies who simply don't have the resources to be supporting the SAML stacks they now have to fix. We'll be cleaning this up for months, if not years.

Since people seem to take blogs so seriously, I'll say a couple of things that might help with some vendor conversations: This is an SP bug, period, and there is no justification whatsoever to point fingers at the IdP or claim that the IdP can fix this. There are some obscure things an IdP can do to make the bug hard or impossible to exploit, but that's a workaround, just like XML Encryption is. It's a bug. Fix the bug. Secondly, do not think that because your SAML code doesn't use one of the libraries that was explicitly noted as being vulnerable that you're safe. That is not a list of the affected libraries, it's a list of lbraries known to be affected. Others are affected. Other libraries are not broken per se, but have been misused by developers so as to create a vulnerability (this is particularly true of the Java version of OpenSAML).

A beneficial side effect of this has been to force us to invest the time necessary to come up with a package distribution mechanism that bypasses the broken opensuse.org mirroring infrastructure. Simply put, they allow sites to mirror without valldating the mirrors actually work, and keep serving up broken links using a server-side redirector that makes bypassing the mirrors impossible. Things were bad enough this time that we were forced to sort of insist that one of our members with the necessary infrastructure step up to deal with this, and Jisc agreed to put a long term solution into place this summer. In the meantime, we have put out a call for volunteers to host the files, and we have a "final" Yum repository builder in place that will de-reference the mirrors to choose from properly, on the client side, so these repo files should keep working in the future as we add new mirrors. Please update your servers to use these fresh repository files.

On a lighter note...

The impending release of Java 10, and soon 11, has managed to break a ton of Maven plugins and we've been spending significant time ramping up full matrix testing, identifying incompatibilities, and waiting for new versions of the plugins so the build and deploy process can be tested again. The expected pace of Java releases that introduce breaking changes is going to be a major problem for a lot of projects, and we have a lot of dependencies that, unlike Spring, are less well-maintained. We're going to have to divert even more time than in the past to keeping things working, and it's likely that there will be less of a guarantee that our major releases will continue to work on the non-LTS (long term support) versions of Java. We can only do so much, and as an "enterprise" platform, we need to focus our time on making sure the LTS releases work and that we have versions released to support those Java platforms in time. That means, practically speaking, that Java 9 and 10 matter a lot less than Java 8 and Java 11, and that we have to make sure V3.4 works on Java 11 since it supersedes Java 8 this fall. Expect some kind of official policy about this when we have more time to study the issues.

On the SP front, we should be in the home-stretch in getting the SP out the door within the next couple of months at most. The build process on Windows is now fairly streamlined and scriptable, even down to our dependencies. Repeatable processes are always nice. We have a basically "final" plan for the configuration, which is that we have built support for a new V3 configuration schema that is essentially identical to the V2 schema with some deprecated features removed, but the SP will load either one. This guarantees safe upgrades but provides the right warnings to get old settings cleaned up in case we ever do a V4. We have renamed the default file to shibboleth3.xml but will fall back to the old filename, so the whole thing is pretty seamless.

I also completed work on a cookie-based session recovery feature that allows most of the important data in a session to migrate between server nodes or across restarts using a shared key. It should alleviate most of the need for back-end session store sharing, and the cookie sizes don't seem too risky in most cases.

Finally, another highlighting of the OIDC work, which has reached alpha 2 and needs testing and feedback: https://marc.info/?l=shibboleth-dev&m=152111752828021&w=2