Lots of vacations and other interruptions lately so this is a short update. Following on last month, work continues on code reorganization and refactoring. That’s not terribly exciting but is ongoing.
In parallel, some new work is being done in anticipation of an IdP V4.3 release, either late this year or early in 2023. This will allow us to ship a small number of in-demand features that require core changes, while getting warnings in place for deprecated and at-risk features ahead of the release of a V5.0 sometime in 2023. Maintaining and working across multiple branches is not a common thing for us to do, and it’s definitely not ideal, but it’s the only way to avoid bottlenecks in the workstream at this point.
Administrative logout has been a long-standing need. This is really not “logout” in the more usual sense, but rather revocation of active state for subjects to force re-authentication (under the assumption that accounts are either locked or reset). This work is mostly finished, and described in AdministrativeLogoutConfiguration (the logout term was kept simply because it’s a common way people refer to the feature). It was designed to be as simple to configure as possible, while retaining a fair amount of flexibility in terms of integration with the IAM environment that typically has to make this work properly. There’s still time for feedback of course.
I don’t expect much else in the way of major features for 4.3 but we’ll be reviewing the backlog (and please submit anything smallish if it’s not already filed).
We’re expecting a first milestone release of Spring Web Flow 3 in the near future, and one major contribution from us was already accepted, eliminating a number of duplicated classes we had created in the course of bending it to our will.
On the SP front, we built and posted official packages for Rocky Linux 9 (which are of course usable on RHEL 9), which took me an hour or so, as compared to the days it would have taken me in the past.
The last month has seen some additional plugin releases, and substantial progress on refactoring the code base in preparation for IdP V5 and SP development.
Another new OP feature update has been released as we continue to focus a lot of effort on extending the OIDC/OAuth feature set. The OP now supports JWT access tokens for all supported grant types, though full OAuth support for non-OIDC clients is not yet finished at this point (it should be in the next feature drop), and the OP is intelligent enough to understand when token encryption is possible or not. The other major new feature is a substantial revision to the revocation features so that individual tokens can be revoked, rather than the entire chain stemming from the original code grant. Use of refresh tokens also results in automatic rotation (the old token is revoked and a new one issued), which is a recommended security practice.
We have released the planned JDBC Storage plugin, and addressed a number of bugs so far; we hope/expect the latest release should be production-worthy at this point. It’s much more efficient to turn around new plugin releases of course, which is why you can expect most new self-contained features to be released that way.
We are well into the process of code reorganization at this point. Most of the metadata- and attribute-related classes have been migrated into new Java projects (java-shib-metadata and java-shib-attribute) and the main branch of the IdP has been purged of those classes, many modules removed, and small adjustments made in a few cases to rebase the IdP on the new libraries. So far, there don’t appear to have been any significant compatibility issues created for deployers, though that’s mostly due to a deliberate choice to leave the package names alone. It’s likely we’ll lean toward leaving “idp” in the names of the packages and some classes even while using them within the SP, but there will probably be some exceptions, particularly where implementation classes are concerned.
Note that the new repositories are not “final” at this point, so any clones made are likely to require re-cloning at some point to allow us to clean up unrelated branches and history.
The next big step is going to be to combine the java-support and spring-extensions repositories so we can begin to turn them into new multi-module projects, followed by rebasing the major projects on them. A few other low-level development cleanup tasks are underway in parallel, and we’re identifying and accounting for changes in Spring 6 that may impact the codebase.
The Spring project has seemingly agreed to accept our updated Spring WebFlow build that supports Spring 6 and Jakarta EE, so we expect to be able to leverage an official SWF release. Hopefully at least some of our local changes to it will be accepted upstream to minimize those additions, but the important thing is we don’t expect to have to fork it for our own use.
There’s not much to report re: the SP development apart from the code reorganization being critical for that process. Now that the metadata and attribute services are outside the IdP codebase, we can begin to mock up real SP designs that leverage these components as planned. This will go a long way toward figuring out what the SP configuration might actually look like, but it’s s safe bet that most of the metadata- and attribute-related configuration in the current SP will be left behind as “not supported anymore” as it would be a tremendous amount of work to support that in any sensible way. The usual IdP configuration approaches to defining metadata and attribute behavior will essentially be reused and the Spring-based service hub will handle all that on behalf of SP agents.
Finally, we have a lot of interest in potentially identifying partner projects that would be interested in collaborating on token management APIs and user interface work in support of a robust WebAuthn implementation. We’re very good at the systems development, and we’re very not-so-good at building web applications. If there are projects or people interested in collaborating, please get in touch.