March 2025 Update
This month’s update is largely similar to last month’s. The 1.1 WebAuthn plugin update will be released shortly, after which we’ll park that for a while to let things settle and get feedback. The OpenID Federation work continues apace, and we will have at least one, possibly two, project representatives at an interop event occuring soon in Sweden.
Continued prototyping/POC work for the new SP on Windows has been happening, but for the most part the SP development is back-burned for a bit to devote time to getting the IdP backlog cleared with an eye to getting V5.2 released by late Spring or early Summer. A number of bugs have been addressed, and I’ve started work on some larger feature enhancements this month.
I’m particularly focusing on the authentication layer again, which was among the earliest parts of the design and reflects a lot of poorer decisions dating to the earliest work on V3, and much of it has shown its age for a while now. The username normalization (c14n) features have always been hard to configure and fairly inflexible, owing mainly to the questionable choice to use the Spring Web Flow engine to implement it. At the time, it was imagined that people may need to build mechanisms for users to select from among different “personas” (student employees are a common case study for this). In practice, I feel pretty strongly the persona model is an application problem, not an IdP one, but be that as it may, it’s never been used that way. Without losing the potential for that feature, the existing methods have been reimplemented as simpler procedural Java classes that are easier to write, configure, and use with more flexibility.
With the new design, it becomes relatively easy to do a couple of things that were very hard or impossible before:
Configure multiple copies of a given c14n method with different behavior.
Directly specify what c14n method(s) to use for a particular login flow.
This work is particularly targeted at people using the SAML or OpenID proxying features, which if used alongside “local” authentication options can make c14n rather awkward at times to avoid conflicting requirements. This is now much simpler to deal with. A new documentation overview is drafted and more material has been added to the individual method pages.
The new implementation is of course compatible with existing configurations. We have a history of not getting things “right” initially and ending up with a lot of legacy approaches that most people never get the chance to fix, and this is unfortunately probably another case of that, but all we can do is get it right eventually and hope it’s of value to do so as people’s needs evolve.
The next area I’m targeting is support for more dynamic control over authentication lifetime/timeout policy to better support more customizable behavior based on users, groups, networks, and so forth. Today these settings are largely static, or have to be overridden with more complex pluggable logic after the fact. The intention is to allow mechanisms like the MFA flow to customize results ahead of time more simply and with more obvious behavior.
We have not as of yet starting digging into the unscheduled backlog, but if there are bugs or requests yet to be scheduled, dropping a comment into them is a good way to raise the visibiity for review before we start to finalize the work going into this version.