All of our active work streams have been continuing over the last month.
SP V3.3 is nearing ready to ship, with all of the dependent work on libraries done. We plan to ship it with OpenSSL 3.0 on Windows in order to ensure adequate exposure to that version. There were essentially no code changes needed except for a very small fix to another library so we don’t expect much trouble. Future versions are a bigger concern because of the number of deprecated functions we’re using, but that code needs to be migrated to Java anyway, so the path forward there is clear, if not the timing.
This is not a significant feature release in any sense, and the changes are extremely minor. The version bump is really more a matter of convenience in order to introduce a handful of new deprecation warnings around features we know are at risk for a future version. It also marks a transition point for a change to the platforms we will be officially supporting, with macOS and some very old SUSE versions dropping off and Amazon Linux and Rocky added.
Accompanying this release will be a more forceful announcement that this code is on the path to extinction in favor of a rewrite that will require a Java component and likely significant configuration changes. There’s not a lot we can say concretely at this stage other than we have to do this and we’re doing it, and people who don’t think the result of that work will be a good fit for them should be looking at alternatives now.
I can’t say there won’t be another feature update between now and 2023 or 2024 when 4.0 emerges, but it’s certainly the hope not to do one unless we have to.
On the IdP front, we’re accumulating odds and ends for V4.2 but still don’t have a precise ETA. At this stage, the work will likely be gated by any API changes needed to support enhancements we plan to do for the OIDC plugins, and V3.1 of the OP will likely require V4.2 of the IdP. We designed the plugin handling to help us manage these kinds of transitions.
The two major features underway for the OP plugin are adding support for token-based registration of RPs and more generic OAuth support for access tokens issued via the client_credentials or password grant types. That work will include support for JWT-formatted access tokens, for which an RFC was recently approved, so we have some guidance we can follow for that. We expect to refactor some of the existing code so that any IdP-supported login flow can be used to protect the token endpoint (obviously none requiring browsers would work but many of them can run without a browser). Once we start to get these kinds of features in place we should be more able to adapt the code to other use cases as they become more clearly defined.
Finally, we have made substantial progress on a new Java build strategy that should allow us to limit the use of our existing Nexus repository and build our software against Maven Central with proper signature verification of all our dependencies. This is still not perfect but it’s a big step for us in eliminating a lot of extra work in uploading third party artifacts ourselves. We will have more announcements about the impact on third-party use of our code when a few other details are clearer. At worst, some adjustments to local Maven configuration may be required.