March 2023 Update

Following on from February, I have been primarily working on refactoring code into a new java-shib-profile project, the third new library in between OpenSAML and the IdP. Of late, we’ve also been discussing the possibility of migrating some of the OpenSAML “implementation” classes that pertain to the IdP to reduce the size of the that library and migrate out code that is largely unique to our projects. In the meantime, my focus has been on reviewing and refactoring the RelyingParty and ProfileConfiguration classes in the IdP. The end goal is to ensure that for the most part only interfaces remain public, moving the concrete classes out of the API since they are implementation details for the most part.

In addition, I have been refactoring and altering the various profile configuration interfaces to both add new settings introduced by the needs of the SP (where they also make sense for the IdP) and also moving around settings that were “too high” in the interface tree. For example, settings pertaining to signing and encrypting assertions were vsible on profiles (like logout) that obviously don’t include assertions. Some of this work is already reflected in the V4 documentation to better reflect where the settings will be available in the future. These changes could technically impact deployers but it seems unlikely in practice since one would have to have applied a setting that was being ignored anyway.

One new feature introduced by this work is a functional hook to install code that can make changes to incoming or outgoing SAML messages more simply than having to create an entire interceptor flow. This isn’t a common need but once in a while it comes up on the list.

The end result is a package of shared profile interfaces with common behavior, with IdP- (and SP-) specific extensions to those interfaces where necessary, and a focus on making sure settings are only available where they actually make sense.

In addition I have continued to work out in draft form how the SP configuration might work and relate to these existing designs before really working on any code for it. In the process, I abandoned my original plan to produce an “AssertingParty” parallel in favor of going back to the existing (though relocated) RelyingParty concept from the IdP. The SP already uses that nomenclature in its configuration so breaking with this seemed to offer little benefit, even if it’s a little awkward conceptually. How much actual code will be reused is unclear, but one change is that most of the RelyingParty machinery is now outside the IdP, and the changes to package names will impact deployers a little bit, requiring some additional mechanical string replacement in scripts. We hope to extend the installer to scan the configuration to flag as much of this as we can.

My current (as of today, it changes a lot) thinking about the SP is that I would like to try and adapt at least some of the general structure of the existing configuration in this area. Much like with the transition from IdP V2’s relying-party.xml from custom XML to Spring, a similar kind of change will play out here, retaining (in Spring syntax) the notion of an “Application” as a containing object that optionally includes “RelyingParty” overrides. Notably we cannot support the existing SP syntax the way we did for the IdP, but the hope is to make the transition less structurally jarring than a completely different approach would be. A lot of this will start to take shape now as I wire things up and see how it fits together, and incorporates all of the IdP’s security configuration wiring.

On other fronts, we released another snapshot of the OIDC RP plugin, and we have snapshots released now of the first interations of all the OIDC plugins in a form allowing them to co-exist with each other. This marks a milestone signaling we’re pretty close to being able to ship all that work.

Phil Smart ably represented the project at the recent FedCM session in San Francisco. New proposals to adapt the FedCM work to allow for SAML and OIDC to keep working were crafted with representatives from Google and Mozilla , and now have to be prototyped and “sold” to the wider community. Moving in a cross-protocol direction is hugely important to head off an OIDC-specific approach. An interesting aspect of this effort is the spreading realization that metadata-based federations are the only infrastructure (for either protocol) that actually provides any trust that a particular SP or IdP endpoint is legitimate. Typical commercial use of SAML has no such source of “truth”, and OIDC was trustless by design. Perhaps for the first time, the limits of self-asserted metadata are dawning on more people.