October 2023 Update
The IdP (and OpenSAML) V5 release was completed on schedule last month ahead of TechExchange, though with a fair number of bumps due to the refactoring work and the increased number of projects to release, including all of the plugins. Some glitches aside, the software release went fine (with a notable exception) and we have not gotten much in the way of bug reports so far. One did come in today, indicating a regression handling some kinds of SAML metadata extensions in conjunction with the new “strict parsing” implemented in OpenSAML. It has been reported, triaged, and documented on the ReleaseNotes page as a known bug with the workaround for now. It’s serious enough to probably warrant a patch relatively soon.
As previously announced, the EOL for V4 will be September 2024.
At this point, we don’t have much queued up for V4, but there are feature branches under development (or will be soon) for IdP V5.1 and minor updates to the major plugins still getting new features, and we are hoping for December releases for that work. These will not be be significant/huge updates, nothing on par with V4.1, which was very much an outlier.
The notable exception to the release being “fine” was that our Javadoc generation process turned out to have atrophied and wasn’t correct at the time of the release. A lot of time has been spent (during TechEx and since then) to get that cleaned up, design new approaches to managing the links between projects, and ultimately re-publish new copies of the Javadocs under a new home at https://shibboleth.net/api. We had a long-standing desire to dump the Maven site feature and stop using that to generate the Javadocs, but it has turned into a substantial project to get Maven to do it some other way, and we’re still working that out. These are the times “dump Maven” starts to sound very attractive, but we’re not quite there yet given the time that would take.
The other notable event was an avalanche of security advisories all dropping last Wednesday. They all turned out to be relatively unimportant to us, but we released Jetty and libcurl updates anyway. The Jetty update allowed us to reorganize the way we will be publishing those since they are decoupled from the V5 IdP releases now, and needed to be housed separately.
I feel the need, out of personal frustration, to note that the total amount of time spent on the fact that Red Hat foolishly and needlessly chose to rebase curl on NSS in Red Hat 7 has cost the project well over a hundred hours of time to deal with. All for no reason, for a change that had no chance of suceeding, and that they inevitably reverted in the next version. Incredibly frustrating and we’re still paying the cost of that, because Amazon Linux 2 inherited the same bug and isn’t going away any time soon. If I seem grouchy a lot, this is the kind of thing that causes it.
TechExchange itself was a good event, well attended, and I know I attended a lot of good sessions throughout the week (and missed many more I’m sure). A lot of good discussion was had about the project’s next steps, particularly in areas like WebAuthn support and personal data and profile management for end users (a GEANT project that we are eager to see mature and eventually turn into a supported plugin). As I noted last month, we’re going to be doing a lot of project planning before diving into some of the major work items on our list, but one clear task we know has demand will be prototyping a WebAuthn plugin, so that work will certainly start this fall.
Another non-trivial but hopefully not huge work item will be to finally incorporate CSP support into the views we ship, to provide some hardening against XSS threats by locking down the Javascript the pages can run. These will not be changes forced on anybody since upgrades don’t replace the views in general, but for new installs and as a sample to work from, it’s a necessary bit of work that’s been neglected for a while. While I don’t think a lot of the major threat models can be addressed with this change, it’s still good practice to do it.
One of those threat models is that mobile apps that use captive login windows have carte blanche to attack the user’s session because naturally they have access to the cookies. That’s one reason the IdP continues to default to binding sessions to IP addresses. Ultimately, nothing we do on the server or with CSP can prevent a malicious client from sniffing passwords or stealing cookies. And SSO will always inherently depend on bearer cookies because Google killed the Token Binding initiative that could have shored that up.
Members should expect to start seeing some communication from the Board fairly soon as we work through the budget issues we’re facing. A formal announcement of the planned rate increases for individual academic and commercial members in 2025 will be coming as soon as it can be drafted. After the low hanging fruit, the harder work of crafting different costing proposals for different sets of work items will be underway this fall.