July 2024 Update

In between various summer vacations, work has continued on a number of fronts this summer.

The Duo plugin upgrade adding dedicated single-factor passwordless support is now available.

The WebAuthn plugin has reached beta status while work continues on a few final additions such as better auditing support. With the plugin largely stable now, testing can be conducted using nightly snapshots, allowing any bug fixes to be immediately available. As I mentioned in May, we have built a new page to improve project transparency regarding the state of our Java projects and links to the stable and in-development distributions at https://shibboleth.net/cgi-bin/projstatus.cgi. See my note for more on this. We will work on finding ways to expose a pointer to this page wherever it makes sense to do so.

Work has progressed on OAuth PAR and DPOP features in the OP plugin along with other minor improvements. Documentation of the new features is in progress and a release is expected later this summer. That should clear the decks for work to start on the OpenID Federation implementation this fall.

We are close to shipping an upgrading Windows installer for Jetty 12 to replace the Jetty 11 version; testing is underway. We are also starting to explore the possibility of migrating to a plugin-based approach that adds Jetty to an existing IdP.

I am considering a minor SP update this fall to pick up a small number of fixes and substantially freshen the WIndows library set, which is getting increasingly out of date, OpenSSL in particular. Part of this release may include a new release of the xml-security library that has now formally been forked by the Shibboleth Project with the original library retired at Apache due to lack of committers. Taking over the code in fact as well as practice provides more freedom to make changes and possibly remove many unused features (and attack surface). The official transition of that library has not exactly been finalized, but we have published the converted Git repository and any future SP 3.x packages will rely on that fork. It is not inconceivable that we may do something similar to Xerces, but doing so would be more contentious and probably require a formal fork because Apache is unlikely to retire that code (even though it probably should IMHO).

I have also made relatively substantial progress on the new SP plugin in Java. I have started to build foundational code for building SP web flows, including a configuration design for the agents, applications, and (in unusual cases) relying party configurations. SP flows are proving very simple to build now that the foundation is in place and we have a testing framework allowing independent unit testing of flows without requiring agents to be built ahead of time.

For now, the SP flow framework is reliant on agents providing HTTP Basic Authentication credentials to secure agent requests and allow the plugin to identify and compartmentalize work on behalf of multiple agents connecting over an insecure network. This compartmentalization extends to the use of the StorageService and DataSealer IdP components, allowing multiple agents to safely store, retrieve, and secure data without any risk of cross-contamination by other agents.

I have working (and “sort of documented”) flows for a few early utility tasks, most notably one that will parse the XML-based RequestMap syntax on behalf of agents (which will no longer require native XML parsing support). For now, the RequestMap syntax is largely, though not entirely, identical to the current V3 schema, so exists in a new V4 namespace. The hope is that this will be the extent of agents' reliance on XML as a configuration format, with any other configuration handled in simpler ways.

While a lot of uncertainty remains, my plan at this stage is to focus on building out the required functionality without worrying too much about the migration path. It should be possible to look at providing XSLT that can transform the current RequestMap into the new syntax, but I think it very unlikely that a seamless upgrade will be possible given the huge differences. The hope would be that, once a hub is configured to support an existing SP’s SAML needs, that translating an existing RequestMap (or minor adjustments to some Apache commands) should allow for a fairly painless transition. But I don’t see the kind of direct package upgrade that made the transition from 2.x to 3.x transparent. An uninstall, new install, and migration of fles and settings is probably going to be required.

The next step will be to begin actual implementation of SAML request and response handling, at least enough to get an actual exchange done. Once this is tested and working, it will be time to branch the current SP to begin implementation of the more stripped down agents and get to a working proof of concept. It is possible, though not perhaps incredibly likely, that we may have demoable code by TechExchange in December, but either way I’m pleased with the progress and how things are turning out so far.