The first release of the “combined” OIDC stack was completed last month, spanning 4 plugins, a common library, a shared configuration plugin, and the OP and RP plugins. The new design was necessary to allow sharing of the required code and internal system objects that are common to both use cases. The SAML proxying support would have necessitated a similar kind of approach had that not all been already part of the IdP core, so this is a required complication in order to keep these features external, and thus possible to update independently. In the short term this is all more hassle for people, but in the longer term things should solidify and the pace of updates should slow considerably (or at least deliver new features and not just churn).
We have begun to accelerate the pace of work on the backlog to completing IdP V5 and will be pushing hard over the next few weeks to complete whatever is left and make a beta available. Internal “live” testing on real world configurations will start soon. With the OIDC releases done and a few weeks gone by, we will be branching all the plugins and beginning work on porting them to V5. Most plugins will require an update, but there should be few deployer changes needed apart from the same sorts of adjustments common to all of the IdP configuration in a few mechanical areas.
Significant time was spent over the last month reviewing proposals around extending the metric information available, and making some adjustments to how existing metrics are named and reported to align the old with the new. A number of new metrics have been added at Internet2’s request to expose information about the configuration, such as metadata sources and filters used and relying party overrides applied. Additionally, a new diagnostic tool has been implemented that exposes a summary of the profile settings applied to particular requests (see https://shibboleth.atlassian.net/wiki/spaces/IDP5/pages/3230924801).
The documentation for V5 has been created and a fair amount of progress cleaning up the V4 material has been made. The space is now public with a warning at the top. My general approach has been to treat the V5 documentation as a description of how a new install would look and feel, to avoid the constant caveats of “if you upgraded from 4.0 or earlier, this is different…”. Those operating with older configurations that predate V4.1 will be best served with the V4 documentation that speaks to some of that, or can take the opportunity during this year to modernize things (per this and this). We fully intend and expect that most of the “older” ways of doing this should continue to work.
A first draft of the release notes is done and we are adding to them as we go along. Questions or feedback on them is welcome of course. Notably, the legacy Duo support is being removed (per my announcement) so all deployers need to migrate to Duo’s Universal Prompt (via our plugin) or alternatives. Additionally, I have taken the step of marking the SAML 1.1 features as “at risk” in this release, which is a signal that we would like to consider possible removal of that code in a future major version. This is obviously a big step, but we feel it’s very warranted because of the very large amount of code it would allow us to remove. There is a real cost to maintaining all that extra code, particularly during code cleanup passes (it’s not double, but it’s probably 50% more time spent every time we have to review the code base than if it were gone).
Finally, an SP security issue was reported last week and remediated with a patch to one of our libraries this week.