May 2024 Update

April saw the planned release of the latest round of OpenID Connect plugin minor upgrade (per OPReleaseNotes and OIDCRelyingPartyAuthnConfigurationReleaseNotes). The most significant addition is probably the first release of logout support in the OP, which is designed to integrate into the IdP’s existing logout framework for SAML SPs. The plugins are designed to be compatible with both V5.0 and V5.1 to make upgrades simpler for people on different patching cycles.

A second alpha release of native WebAuthn support for the IdP is also available for testing.

Work on the Duo plugin update is finally complete at this point, so a release should be expected this month. We have updated and cataloged a number of demonstration videos covering the new passwordless features, so check those out if the documentation isn’t clear enough on how it works.

Active work at this point is focused on finishing up the first WebAuthn plugin release and on the next iteration of feature work on OpenID Connect. The next two OpenID priorities are adding support for RFC 9126: OAuth 2.0 Pushed Authorization Requestsand some initial Proof of Possession features to support stronger token verification. Work on OpenID Federation support is expected to start later this year. We are largely basing our decisions on future work on member input at this point, as there’s more demand for features there than capacity at the moment.

Because we have been receiving more feedback and testing input than in the past on some of these newer releases, we will be making a concerted effort to be more transparent and public about our work schedule and the state of the various software projects as they trend toward beta or release candidate quality. This is not so much about planning our schedule out farther in advance or meeting deadlines but about simply giving more people a clearer indication of when work on a release is wrapping up and testing would be more helpful.

As part of this effort, I’ll be circulating updates to the dev list more frequently, and we will be working on scripts to provide a simple web-based view of all our software activity and the state of each project together with links to the latest snapshots in Nexus to make testing simpler for those so inclined. The intent is just to associate the snapshots with some simple labels indicating how close they are to being stable or ready for serious testing. We will hopefully be making the information available in both human and machine-readable form.

I have also returned to work on design and prototyping for the SP, mostly a lot of mental exercises thinking about different ways of organizing the configuration. In particular the challenges of actually supporting a hub capable of being shared across many different agents operating in different web sites is proving to be a major complication as compared to the current design that tightly couples shibd to the agents it serves. Coming up with a design that keeps common cases as simple as possible is the priority, as the less common cases will likely be somewhat harder to express (e.g., consider if you want to override a behavior for a specific IdP for only a subset of agents and how that might be expressed).

A major change in the planned design is a move to replace the socket-based remoting protocol in the current SP with HTTP. This was something I tried to avoid specifically because Apache’s server API lacks an HTTP client, so making this change definitely complicates matters and will likely introduce dependencies on Microsoft’s HTTP client (on Windows) and libcurl (everywhere else). That isn’t ideal, but this use of libcurl is much different in nature than the usage now, and is at a more rudimentary level, so the hope is this won’t complicate the build too badly. In most other cases in the future, agents will likely have ready access to such a client anyway. The development of the functionality in Java will be greatly aided by using HTTP by making this a plugin to the IdP and reusing the existing Spring Web Flow design.

Work will continue over the summer and fall to start to flesh out proof of concept code in a number of areas so that work on a refactored Apache agent can also get underway. Ironically, the last and least important work to do is actually implementing SAML itself because that’s a very small part of what the SP actually does. The harder problems to solve are configuration, migration paths from the current software, sessions, and handling of attributes. Adding the SAML processing will be a relatively simple task during the later stages of work.