Work has continued over the last month on the “big refactoring” of the Java code base targeted at V5 and in support of the next-gen SP work. The current phase of work consists of turning the monolithic (and poorly named) java-support and spring-extensions projects into a new java-shib-shared multi-module project containing a number of new (often small) modules. In addition to better file naming and code organization, this work is intended to eliminate two Maven anti-patterns: the use of optional dependencies and the use of test-jar dependencies. New -testing modules across the various projects will be used to expose APIs used for unit tests, eliminating cross-use of test classes between modules and projects.
We are gradually beginning to introduce some changes to package names, primarily with classes that either aren’t likely used directly by deployers, or primarily or exclusively used in Spring declarations. For the latter, we have a way of detecting and automatically rewriting those declarations (with warnings) to maintain configuration compatibility while still allowing code to be moved between modules more freely, so we’re not as worried about breaking anything while we move things around.
Most of this work should be done this month, after which the SP work will get going again in parallel with the IdP work streams.
Work continues on the review and redesign of the OpenID/OAuth signature and encryption classes and the RP proxy plugin should hopefully be wrapping up relatively soon. Documentation for that has been started under OIDCRelyingPartyAuthnConfiguration.
A new release of the OP plugin will be forthcoming this fall or winter that hopefully will address the remaining limitations around pure OAuth usage, and probably will add support for https://www.rfc-editor.org/rfc/rfc9126. It seems to be an intention of this new spec to facilitate decoupling RP URLs from OP configuration, which fits nicely with the direction of relaxing registration requirements for clients to add deployment flexibility. If both clients and resource servers can be used without registration (apart from having a mechanism to authenticate them via service accounts of some sort), many campus deployment scenarios become potentially very lightweight for both the OP and the endpoints.