January 2022 Update

All projects were impacted to some degree by the log4shell vulnerability, which triggered a wave of questionable bug reports to a lot of logging libraries and a lot of triaging and threat assessment. The Shibboleth Project migrated away from log4j a long time ago so was not directly impacted by the mess, but we kept tabs on discussions around a supposed logback vulnerability that didn’t really turn out to be one. Nevertheless the maintainer acted conservatively and issued a CVE and a number of quick updates, and we felt waiting for things to settle was the best path to take. The latest logback release actually removes a few riskier features, but they probably aren’t coming back, so in the interest of caution and avoiding surprises later, we’re going to incorporate logback 1.2.10 into the next IdP patch (V4.1.5).

We are in the process of preparing that patch release now, and it should be imminent. The other known third-party CVEs that are feasible to address should be dealt with in that patch. There’s not much else in the queue for that patch, only some minor fixes. While this patch will be built using our old “we host all the jars” process, we do have the new signature and dependency checking enforcement enabled on the branch, and we hope to be ready to move to using Maven Central for third party artifacts in the near future to reduce the burden of constantly uploading everything ourselves.

Work has started in parallel to stand up a development branch of the IdP on top of Spring 6 and Java 17, and we are identifying where we have dependencies at risk due to the transition that may have to be remediated out or become internally forked projects. The most serious of these is, as expected, Spring WebFlow, about which we are trying to get an official admission of it being end of life. We don’t think, at this point, there will be much chance we can identify a practical alternative so some kind of stripped down fork with as much removed as possible is the most likely outcome here.

During development work on the previously described OAuth enhancements to the OP plugin, some vulnerabilities around the handling of JWT client authentication were noted and fixed over the holidays, with that patch going out early this year. This doesn’t impact a lot of deployers at this point, but the JWT support probably should be more widely adopted, as it allows for public-key authentication of clients, which in turn (combined with our SAML metadata support for OIDC) essentially would open the door to practical federation of OIDC and OAuth.

Work continues on a number of parallel projects centered around OIDC and OAuth features that will require IdP V4.2, so all of those releases are likely coming sometime this quarter. This will hopefully include the initial support for proxying authentication to an OIDC OP (in the form of a new RP plugin), at worst shortly after we ship everything else. The OAuth enhancements aren’t functional yet but support for extending client (RP) authentication using the IdP’s login flow machinery is feature complete already. This allows for validating client secrets using all the pre-existing back-end options supported by the Password login flow (e.g., LDAP, Kerberos, JAAS, and local htpasswd files), and easily extending this to additional options. Use of client metadata and dynamic registration is still supported, but having secrets in files or in the clear in a database is not good, so this will allow them to be externalized seamlessly (though see above, public keys are certainly a much better way to go).

The work on the client_credentials grant and JWT access tokens should be close to feature complete this month, and a number of RFCs will factor into making that work as standardized as we can make it. It is likely that we will punt a lot of the deployer pluggability for this feature to the Attribute Resolver as a means of defining policy around scopes and resources when issuing tokens. The resolver is the most powerful way of abstracting that kind of functionality, though we may embed some kind of simple API around it to allow for other implementations.

Until we get a lot of this work done, continuing with the SP redesign will be more or less on hold until probably this summer so there’s not much to report there, but we should have packages available for some additional RPM-based platforms in the interim.