/
September 2026 Update

September 2026 Update

It’s been a while since my last update. The most active area of development continues to be the SP in a number of respects.

The legacy SP is due for a refresh primarily to embed a number of new warnings flagging use of deprecated functionality that has either been removed or substantially changed in the new version under development. The complete list of known issues has been transferred out of a development parking lot over to the Agent’s ReleaseNotes as we start to get a little closer to 4.0. Most of the new warnings have been added and the Windows build has been refreshed and is more or less ready for release of V3.6.0, which will probably happen later this month. The minor version update is more symbolic than anything else, and to make it a little simpler for people to know if they’re on the “last” minor version of that code branch, as opposed to differentiating by patch version.

The Windows release will update all the libraries, including to the “final” OpenSSL branch that code will support, V3.5, which is an LTS version that will hold us until 2030, past the point that code will be supported. Any compatibility with newer versions is purely “accidental” at this stage. I have also applied a number of bug fixes from the upstream Xerces repository that I committed last month. Whether there is ever an official release of those fixes is up to the Apache project, but I won’t produce any Linux packages for it unless they tag a new version.

In parallel, a ton of development work has taken place to complete major work on 4.0 since the second alpha was released. Notably, SAML ECP support was finished, lots of bugs squashed, and more recently a new mechanism/service for managing “credentials” has been introduced that’s been under consideration for a while even in the IdP.

There were two major problems we wanted to solve in the SP:

  • Automating the intial configuration of default keys when installing the SAML and OIDC plugins to eliminate manual editing of files. No more <import> statements required that break things if you uninstall the plugins.

  • Providing a usable mechanism for configuring larger numbers of keys/certificates and client secrets in a lot of different deployment scenarios. (Laying then out in XML by hand is not a solution anybody viewed as acceptable.)

A new CredentialResolver service has been added to the SP (alongside the other new service, the AgentResolver) to act as a general purpose source of “credentials” for various purposes. This service finally pulls the job of configuring keys out of other unrelated components (the AgentResolver in the SP’s case) and opens up a lot of future extensibility to obtain key material and secrets in more secure ways without altering the rest of the system. It’s taken a lot of work over the last month, but we have what seems to be a workable framework for supporting access to file- or database-backed storage to load credentials based on flexible criteria that can be configured quite concisely. It’s not very opinionated, and leaves most of the organization of keys to the deployer through simple configuration settings. It is not yet documented, but will be very soon. We have not yet applied it to the OIDC use cases, but expect it will support the big one (client secrets on a per-Agent, per-OP basis) very nicely.

Aside from extending the OIDC plugin’s features (which will be ongoing since that stack of specs hasn’t stopped changing in years), this is pretty close to the expected MVP for the new SP. We’re close to shipping this.

A natural question is whether this new service can be ported back into the IdP. It can and probably will, but the compatibility requirements there are steep to avoid breaking things, so it’s not as simple as just doing it as though we were starting fresh with it. The main need there is for somewhat simpler scenarios than in the SP, primarily the ability to much more easily customize keys per SP for whatever reasons. I know it can handle that problem quite easily, so I’d expect some effort to merge this into V6.0.

On other fronts…

Work has started to get the OID Federation plugins documented for usable testing in pilots and we will be looking at moving all of the OID plugin materal into a separate wiki space for long term curation soon. That set of plugins has matured and evolved into its own ecosystem at this point.

We have done a fair amount of preparatory work for shipping an IdP V5.3 late this year once Spring 7.1 is available, barring any unforeseen issues there. The main branches of all the projects are targeting that version now.

Finally, Duo has been making some changes to their platform lately, some of which honestly we’ve been asking for as a community for a while now, and we’re coordinating with them on enhancements and some fixes to our plugins, some of which we have shipped and others we’re still working on. Additional updates will be coming there later this year. We’ll have more to say regarding those enhancements soon.