/
October 2025 Update

October 2025 Update

While it feels like ages since the last update, it’s only been about 6 weeks, and the progress has really been around the same general work items as the last time:

  • Testing out codeberg.org as a possible permanent hosting option for our source code as a follow on to getting GitWeb semi-restored

  • Getting ready for the Spring 7 release so we can ship V5.2 within the next few months at most

  • Continued work on OpenID Federation support

  • EDS release

  • Ongoing SP 4 development and documentation work to get us to alpha

  • Work underway in earnest on OpenID support for the SP

  • An SP security patch

We also are hoping to be involved in a multi-party grant proposal around Verified Credentials, which would acelerate the pace of some work in that space over the next couple of years.

While we have re-established SAML-based access to our GitWeb service for a subset of the community, we also discovered the Codeberg site at about the same time as a lot of others did when Microsoft moved GitHub into their AI division, confusing “stealing random code from the Internet” with “software development”. Codeberg lacks a requirement for indemnification, making it an option for us when GitHub currently is not. To that end, we have set up (temporary) mirroring from our systems to Codeberg for all of our supported codebases/projects and they are all publically available there now at Shibboleth Project.

Right now this is a one-way mirror operating on a schedule, save for one project we’re testing in the opposite direction (mirroring from Codeberg to our system, which they support natively). We are all mostly on board at this point with the idea of moving the code officially to Codeberg and mirroring it back, which addresses several issues for us:

  • The code becomes visible with a much better UI than GitWeb, and on a publically hosted site.

  • We can finally support PRs to some extent, though we cannot accept patches submitted without an appropriate license or agreement in place of course.

  • The mirroring allows us to continue to back up the code ourselves as a hedge.

  • Our CI builds can continue to pull the code locally without burdening this free service.

  • With some additional work we can discontinue GitWeb entirely.

Long term, it’s possible we might ultimately discontinue the mirroring, but that becomes an internal matter for the project without affecting anyone else.

We suggest that anyone leveraging the source code consider switching their clones to the Codeberg copy to help us evaluate it, but it’s pretty likely we will make the switch at some point.

On the development front…

We continue to make small additions to the V5.2 release, primarily based on ongoing SP development needs than anything else. We need to get serious about testing soon so we can be in position to ship it no later than January (perferably December). One notable change was a backport from the SP of support for building decoder rules for the SAML <NameID> element while proxying, which makes establishing the login identity while proxying from that spot much simpler than now. The SP has greater need for this feature but it’s somewhat useful in the IdP so was ported back into it.

Once Spring 7 is released, we will be moving the main branch to it and the release should be in a good place to be testing it.

We notably produced the first update to the EDS in a quite a while with some member-requested features.

The focus for the OpenID Federation work right now is on refactoring it to plug more seamlessly into the existing OP (and eventually RP) so that it becomes a new optional plugin component to add instead of requiring that all installs of the base OP/RP plugins contain the extra code and features. We think this is important for modularity and maintainability long term, as the viability of OpenID Federation is far more speculative than that of OpenID itself.

Similarly, much of the early work on the SP OpenID plugin is around generalizing some of the original RP plugin code so it can be repurposed for the SP without as much duplication, but in general, the design seems to be holding up to allow a relatively seamless addition of the protocol to the SP without much in the way of awareness or changes to the C++ Agent code. A few defaults will be adjusted to allow for OpenID-specific options to be supported in the Agent, but that won’t require code changes.

In terms of the SP alpha, there isn’t exactly a set in stone set of criteria for that, more a question of when I think the draft documentation is sufficient for an alpha to be of any external use, and I don’t think that’s too far off. There’s a ton left to do, but also a lot done, including some pretty comprehensive “Getting Started” material for both the Agent and Hub. In this state, the Hub is probably only usable by people with IdP experience, which is something we have to change, but is probably good enough for the first alpha.

Packaging is definitely one gating factor, so we are starting the process of revising the packaging projects to build the new Agent, which is largely a matter of stripping out a whole lot of material for the old dependencies that we are now removing. The new SP packages for both Windows and Linux are planned to install side by side with the V3 packages and avoid direct overlap. We do not expect for a second that running both in a single web server would be functional, but we do hope that it’s physically possible to aid in the necessarily manual transition from V3 to V4.

There have been significant changes to the defaults to make for a better OOB experience, and I was able to test the successful addition of POST form recovery as a feature implemented almost entirely in Java (whereas before it was a large amount of C++). Feature-wise, I think we are alpha-capable at this point, though one yet-to-be-implemented feature for managing sessions with the Hub’s StorageService may yet end up the default option for sessions by the time we get closer to finalizing things.

Not a whole lot to say about the recent SP patch other than we appreciate the reporter providing a very nice reproducible test so we could ensure that our “limited/low risk” fix would do the job well enough for now. A more complete fix is hard to justify given the limited use of the ODBC support and the fact that the code will be retired in the future regardless.