February 2023 Update

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.