The only exciting? news for this month is just that I’ve gotten back to working on the SP redesign in earnest for the first time in a few months. With IdP 4.3 released and work essentially complete on that branch, attention turns back to the main branch and is more about what the SP needs from the IdP code base than actively working on the IdP itself. There’s a fair amount of polishing left to do on IdP V5 so it’s not imminent but primarily I’m working to identify sections of code we can relocate so the SP can share it, starting with configuration-related work.
I tend to work from the configuration “inward” to the functionality, so my first task has been to review the current SP configuration and to think about how the agent and the service hub will need to interact. Ideally most of the settings would be in the hub, but practically speaking a lot of the settings pertain to content in ways that would be too inconvenient to migrate up to a central location and rely on somebody else to change. Identifying exactly what the agents will need to control and how they will provide that information to the hub without making the hub too stateful is therefore a critical step. Also, many of the SP’s settings are simply irrelevant to the new design and will be going away anyway, so walking that list and taking notes was a first step.
After that, I was able to start fleshing out configuration classes for the SP, and identifying bits of existing code that aren’t IdP-specific and can be relocated. I think there’s a strong possibility that we will end up with another “shared” project in addition to the metadata and attribute libraries, but for now I’m finding existing homes for things pending taking that step. The next phase of work was to build out the SP-equivalent of the IdP’s RelyingParty design. The AssertingParty model will be used in a similar way, to authorize specific profiles and control SAML-specific (and in the future other protocol-specific) settings that apply to specific IdPs. Since the SP supports far fewer profiles (really just SSO and logout) than the IdP and will not need to support proxying, the overall amount of settings is just a lot less.
With this work done, the next step will be to start designing the SP session cache and work out the manner in which the agents will interact with it. This was work I started last year but tabled when other things took priority. Working out the statefulness (or lack thereof) of this design will be a major step, followed by implementing the first real “functional” endpoints in the hub that do real work, such as retrieving a session and updating session usage data (i.e., occasional pings indicating active use for timeout enforcement). The change to an “every so often” touch-base from the current “update on every request” model is the major shift allowing the hub to become a networked component that won’t need to be co-located with agents.
Once that work is done, it will be time to actually implement the current SP’s handler model within the hub in Java, which includes the support for issuing SAML requests and consuming responses, i.e., the real work the SP does. Once this is fleshed out a little, I believe that will be the point at which it will be time to start building the first “agent”, by branching the cpp-sp repository and stripping out code so that the core functionality is left behind to mediate between Apache and the hub. It would be reasonable I think to hope we can reach some kind of pre-alpha prototype stage this year that will be able to illustrate what the new SP will actually look like. It is my hope that we can get there fast enough so that people can get a decent sense of whether this is something they really would use or if they need to look at alternatives. The sooner we get there, the more time people have to plan.
On the non-SP front, work is continuing on the refactoring of the OIDC OP and the unreleased RP plugins to allow both to co-exist in the IdP by moving shared configuration into a new plugin they both will depend on. This isn’t anybody’s preferred choice, but to allow them to co-exist but be updated independently, it’s the only practical option. In the longer term, improving the plugin installation process to perhaps automate some of the issues around dependent plugins is a possibility, but we do want to be careful about over-complicating that work. The plugin model is working really well right now precisely because it’s simple and limited in scope.
The next major bit of IdP V5 work is applying an update to the latest Apache HttpClient, as we’ve been on 4.x for a long while and need to move to the later version. Impact on deployer configuration is not known yet, hopefully it will not be too extensive. That work should be landing on the main branches soon.
Notably, as a couple of people have inquired, while the main branches are generally stable, they should be viewed as early alpha at this stage and by no means a finished product. We also have not yet updated any of the plugins, so they remain pinned to the V4 branches and have not yet been branched themselves for the V5 work. Most of them will be re-released with new major versions along with V5.
In terms of schedule, I think it’s safe to say that IdP V5 is probably a fall release at the earliest, and V4 will be supported almost certainly throughout 2024, though no more feature releases are expected.
We are back from the holiday break and back at it.
I released a quick-turnaround SP V3.4.1 patch this evening, primarily as a vehicle to distribute a precautionary change to our libraries to block the primary attack vector that led to the advisory against the Java side of the project a couple of weeks ago. I spent a number of hours testing and analyzing code and while I concluded that for a few reasons, some accidental, the SP is not vulnerable to the exact issue reported, it was best to lock things down more aggressively and prevent something unexpected. A couple of other backlogged items were included in this patch. As I did last time, both x64 and ARM packages were published.
We have essentially finished work on IdP V4.3.0 and the release should be next week. We’re waiting on the next Spring 5 update so we can include it. This should wrap up work on the V4 branch and allow us to move full time to working on the main branch of the IdP and the libraries as we work on V5 and on the SP redesign in parallel. The SP may never ship on that codebase but we will be continuing to refactor and adjust things in support of that work so that they eventually ship on the same foundation.
Upgrades to 4.3 from anything recent will be very trivial, but one of the warnings we added is going to be a significant and necessary adjustment (though a very simple/mechanical one) for V5 compatibility. The ReleaseNotes already make a note of it. We will also be denoting the older Duo and OP plugin releases as “incompatible” with 4.3 so that we can encourage people to upgrade those to the recent versions. This is not a strictly technical requirement, but a pragmatic one, as the older versions will spit out a number of warnings that are easily avoided by just freshening the plugins along with the IdP upgrade.
Something I want to note is that I was mistaken in the past in both these updates and some public statements about Spring 5’s EOL date, which is NOT 2023 but rather 2024. So there is not a huge amount of urgency to get V5 out the door, and aiming for mid-year is both a realistic development goal and provides a full 18 months of time to upgrade (for something that isn’t likely to be a complex upgrade to begin with).
The OIDC RP plugin is basically done, more or less, but we will be completing the new JOSE security classes and moving the OP plugin over to them so that we can release the RP, OP, and updated Commons plugins at the same time. Right now, the OP and RP can’t really co-exist and that is being corrected. There will likely always be some lockstep involved in updating all those components and getting the first set out that co-exist will be a major milestone. Once that’s done we can take a step back and start planning out the future of the OP codebase and prioritizing future work there with our development partners.