Last update of 2022, it’s been a busy (if not so visibly busy) year for the project with a lot of technical debt work as we prepare for another major transition with the IdP. I hope those able to attend the Internet2 conference last week had a good meeting and got back safe and healthy, sorry to have missed it. I guarantee you all had a better time than I did debugging Spring XML Schema handling. Thanks to Phil Smart for covering for me and presenting the usual updates.
On the release front, Henri wrapped up work on the latest OIDC OP plugin, V3.3, which among other things finally wraps up the initial stage of work turning the IdP into a generally feature-complete OAuth server as well as OP (admittedly still limited to bearer tokens). I will confess that I did not expect us to manage that transition as quickly as we did, and this is a testament to the developers we have and the quality of the original code and design in adapting to these additional requirements. I’m sure there’s a lot more to do, but the foundation is there.
Phil was also able to produce a second prerelease snapshot of the RP plugin for testing prior to the conference, and we are on track to get that released soon. Obviously any testing we can get should accelerate the release.
Work has continued in parallel on issues for both IdP V4.3.0 and V5.0 but we recognize that with Spring 5 sunsetting at the end of 2024 that we need to get 5.0 out the door soon, which in turn means also getting 4.3.0 put to bed. Unfortunately lots of small stuff keeps popping up and demanding attention, and there are advantages to getting as much into 4.3.0 as we can, so work continues, but we’ll need to call a halt to that pretty soon and I expect 4.3.0 to be imminent with the beginning of 2023.
A notable addition I completed a draft of last week is a long-awaited feature to add audit logging to the authentication layer in the IdP to more formally record success and failure during authentication. It’s credit to Phil in coming up with a relatively clean way to add this, as I was not able to “see” the approach to use in the past when people have asked about it. It is our expectation that most people will want to route these records to a different destination than the primary audit log simply because the records won’t be in the same format, so separating them would be helpful to allow dedicated parsing of the data by tools like Splunk. The exact default content of these records is still a work in progress, but a call for input on this was sent to the mailing list last week.
Another area of work has been the start of a deep review of the main code branches (what will end up as V5) using Eclipse’s static code analyzer examining null handling. A number of subtle bugs have been flushed out, not all even related to that specific issue, but a number of incorrect annotations on APIs have also been identified. Some APIs are likely to undergo actual adjustment in V5 to reduce the use of nulls as a meaningful value where we can do so without impacting most deployers. We plan to generally leave the static code analyzer enabled in the various projects as much as possible, though it does cause a lot of unfixable warnings to show up in the sources.
Wrapping up, I think we will be pretty well done with V4.3.0 by the end of 2022 and should be looking to ship very early in 2023, so we can fully turn our attention to getting V5 out the door as expediently as possible. There’s still plenty of work to do there so the faster we can put V4 to bed development-wise the better. Neither the V4.3.0 nor the V5.0 upgrades are likely to be difficult ones for anyone on 4.0 or later, provided one simply performs the upgrade in place as intended.