April 2022 Update

Well, all the IdP 4.2 and related releases would be done at this point except for the Spring vulnerability from last week throwing a wrench into things. We put everything on hold at that point while we waited for official word and then needed that whole day to research the issue and produce a 4.1 patch out of caution; it’s still our belief that the vulnerability appeared to be limited to a data binding feature that we don’t use, but there’s no official statement to that effect so we’re assuming there may be other triggers involved and certainly would urge anybody to patch immediately.

We also continued to identify a number of small issues during testing, along with a few late feature requests, so punting a week allowed for a bit more work to get done anyway. Unfortunately, Spring also announced that another “early” release was coming this week, and we don’t know why at this point. Out of further caution, we decided to hold the releases again to pick up that Spring update, so the plan for the moment is to get that applied tomorrow and possibly do the releases at the end of this week. If it turns out that this is a publically acknowledged security patch again, then we’re likely to do another 4.1 patch, either instead of 4.2 or in addition if we don’t discover what’s going on until afterward. So that is our plan, but everything is still subject to change as we get new information.

Speaking from experience, upgrading to 4.2 has been trivial; the main consideration would be for those using SAML proxying, due to a bug fix mentioned in the ReleaseNotes that does change the behavior of the IdP when it’s configured to map in the user’s proxied identity from a scoped attribute. This is easy to deal with, typically via defining a bean to transform the scoped value back into the unscoped part. The fix was necessary because it’s much easier to explicitly drop information from a value than to recover it when it’s already removed.

I’ll cover more of the “less obvious” enhancements in 4.2 in a future post once it’s actually available.

The 4.1 patch was the first release done completely based on retrieving most third party dependencies from Maven Central in conjunction with an enforcer plugin that is verifying signatures against “known” keys on all dependencies and ultimately on the entire Maven repository constructed to produce the releases. That is, only keys we have explicitly decided to trust for specific artifacts are used to verify the signatures, all the way down to the Maven plugins and their huge list of dependencies. The total size of a repository in the end can be larger than half a gigabyte. This mechanism will be applied to all Java products going forward.