June 2025 Update

On the plugin front, we shipped updates to the Jetty installer and a DuoOIDC plugin update to freshen Duo’s libraries and sync up the root CA trust list in the two versions respectively.

We are also planning on shipping some small fixes to the OIDC features soon that will require a bump across all those plugins (this is likely to continue until such time as that code further matures) but luckily it’s not all that hard to update two or three plugins vs. one. Future IdP versions will also enhance the dependency warnings the installer outputs when things get out of sync to make it easier to understand the problems and reduce the noise.

Among the fixes there are some improvements aimed at supporting the recommendations in an Internet Draft that updates a number of the core OAuth RFCs. It suggests changes that are straightforward to support (in fact, they align OAuth closer to how SAML deals with similar issues) and while the threats are somewhat theoretical, they’re a “good idea”. Most of the risks depend on an RP being willing to issue requests to “arbitrary” OPs that are not inherently known/trusted by the RP. While that was the original “promise” and supposed advantage of OpenID over SAML, it’s not a real use case in practice (and if it were, this sort of attack would have been common a long time ago). So while the issue is somewhat serious, it’s more a matter of protecting against future issues than serious ones today.

We do expect some interoperability issues, so it’s possible the updates may include a need to test and in some cases disable the enhancements until more software is updated to support them. We will have approproate release notes for these changes when the updates are available.

We’re discussing changes to the design of the prospective Jetty plugin to make it more of a Jetty installer and less a bundler; that is, if you want a truly verified install, you should install it yourself, but if you want to “automate” things as a novice, the plugin should provide a mechanism to install or upgrade to whatever (supported) versions of Jetty are out there as they are released, and integrate the IdP into it, add a Dockerfile, etc. Simply put, we have to get out of the business of shipping software that isn’t ours; it just isn’t viable given our resources to keep having to update packaging for others' software. This all needs to take some final form before we seriously entertain what V6 might look like. It wll be important especially for the SP to simplify the installation process for those using the IdP in more constrained ways that shouldn’t require the same degree of Jetty or Tomcat experience.

We’re getting closer to wrapping up work on IdP V5.2, and it is expected to include an initial implementation of a SAML DataConnector modeled on the SP’s SimpleAggregation plugin; that is, it will be able to query SAML Attribute Authorities via SOAP based on static and dynamic “references” pulled from the configuration or from other resolved data, allowing a referral model that has seen some use with the SP. Implementing it in Java is useful in its own right, and will be useful to carry forward some of the more advanced capabilities in the SP. Because this is a complex piece of work, I expect we will treat the initial version os somewhat preliminary and subject to more changes than would be typical of something we ship.

Work continues (and continues and continues) on both the SP session store and the Windows “remoting” code, the latter based on WinHTTP and schannel to avoid a dependency on libcurl and OpenSSL if we can possibly avoid them. We are pretty close to declaring some form of victory there and the certificate validation behavior is getting close to what we need (in fact, we donated a PR back to libcurl to implement a feature they lacked on top of schannel). Reliability is going to be the major test with WinHTTP, as curl is a known quanity with the SP already.

The session layer is proving as fun as ever; being able to definitively say this is the last session cache I’m ever going to write is getting me through some long days. The major issue (until the next major issue) is figuring out how to design for an “eventually consistent” multi-process view of sessions so that timeouts “sort of work” with an element of imprecision. We have to fix a major drawback in the SP today, the fact that every access to a session requires a call into shibd to update a timestamp to allow timeouts to be applied precisely across any number of web server processes.

Instead, timestamps can only be updated “infrequently” based on a configurable interval so that most accesses are local to a process' cache and only occasionally involve potentially expensive operations that might involve a network or shared file system. Similarly, sessions revoked administratively can’t be guaranteed to invalidate immediately, but only after that interval elapses, at which point the call to update a timestamp can also detect a session having been revoked.

The hope is that the tunable interval and control over the caching of sessions “in process” will allow a range of deployment options that can accomodate both cheaper/simpler and more expensive but robust options for managing sessions while maintaining a desirable degree of scalability. More remoting means finer timeout and revocation precision but less request throughput.