Development CenterOctober 2022 Update

October 2022 Update

Created by Scott Cantor
Oct 11, 2022

The initial Java code refactoring of the IdP code base is complete and the new repositories are now in a stable state (i.e, we’re not changing them in ways requiring re-cloning). The two primary goals of this work were:

  • Migrate substantial portions of functionality out of the IdP so that it can be leveraged by the SP, including the metadata, attribute resolver, and attribute filter services and configuration.

  • Refactor the code previously in the badly named java-support and spring-extensions projects into a new multi-module project named java-shib-shared and if possible move the existing code into smaller modules with better package naming standards and fewer (if not no) optional Maven dependencies.

With this work complete, there are now more jars, but with more well-defined purposes, corrected dependencies, and better naming. We did a very thorough review of the impact of renaming these classes and have concluded that for the majority of deployers there should be little or no impact. Some Spring features should reduce the impact further by rewriting many instances of classes if they appear automatically, with warnings. In fact, any unexpected exposure to these classes will help us improve things by adding necessary layers of indirection to reduce future configuration changes. While a few changes will probably be needed, they should be very minor and easy to scan for (the V5 installer will probably be able to detect and warn about it in fact).

To this point, virtually no visible changes to the IdP’s APIs that were migrated down have been made. This is ultimately a question of compatibility over naming, as removing all of the “idp” references from the package names would be extremely disruptive, much moreso than the work done so far on the lower-level code. If the new SP ends up depending on a lot of classes with “idp” in the name, that is likely a price we’ll have to pay since those deployments will have no install base to protect.

At this point, we have aplied a lot of small fixes, added some deprecation warnings, and a feature or two to the 4.x maintenance branch, while prepping for the refactor on the main branch. We will probably start looking at when to ship IdP V4.3 and likely treating that as the last feature update for V4 while we plan the schedule for V5. Spring 6 is expected to be final this month (we presume Spring WebFlow 3 will also, but we don’t know for certain). We definitely want to proceed with a bit of SP prototyping before shipping IdP V5 in case we identify any incompatible changes we need to make, but ultimately it’s not likely the SP will even ship on the V5 platform based on timing, so we have a fair amount of freedom to decide when to call V5 done. Working out any desired installation changes will probably be the main task from here on out.

Note that the upgrade to V5 will require a “lateral” update to one’s servlet container (e.g., from Jetty 10 to 11) because of the move to the Jakarta EE servlet APIs. Tomcat should be similar. In our testing, it appears that at least with Jetty this is a seamless change but as we get closer to a release some real testing on real world configurations will better prove that.

On the plugin front, we are eyeing the following sequence:

  • A minor release of the OIDC OP plugin to add, among other things, pure OAuth request support on the front-channel. This should effectively finish the primary tasks needed for us to call this OAuth-compatible in a general sense. Of course, there are a hundred additional RFCs we could probably support, but this is a good baseline.

  • A beta and then first release of the OIDC RP plugin (this is for proxying, not a pure client/RP of course). This will rely on a new version of the commons library we house much of the OIDC/OAuth code in. The OP will be revised to work with this version and that new version will be required in order to install both the OP and RP plugins at the same time. This is needed in order to manage the overlap between the two, but that update of the OP should be seamless of course, just plugin housekeeping.

  • Branching all of the plugins we support and porting them to the IdP V5 stack. This will include additional OP work to update some of the security APIs to match the RP code. Since these releases can involve some breaking changes to APIs, we can clean up some of the overly-restrictive SAML assumptions in the core code.

So altogether we expect at least these releases before the end of the year:

  • OP feature update

  • OIDC Commons update

  • Initial RP release and a housekeeping revision of the OP for joint installation with the RP

  • IdP V4.3

In parallel, work will ramp back up on prototyping the new SP, but it will be well into 2023 before anything resembling real alpha software is likely to exist. Hopefully more details will emerge on that now that this refactoring detour is mostly done, possible with some public webinars to discuss decisions or direction as the work gets more concrete.