February Update

Most of our practical progress of late has been centered on the SP and the Metadata Aggregator, the latter made possible with some of the increased funding obtained over the last several months. The significance of the latter work is that the MA will be based on a newer Java version and library set that will lay the foundation for moving the IdP to the same (or newer) versions in V4.0, saving us a lot of the up front legwork to identify compatibility issues and changes we need to make.

The IdP work continues in the background; probably the most serious question is whether to hold the V3.4 release to wait for a significant revamp of the logout support, or ship without it and push that to V4.0 or a V3.5 interim update. In most other respects we're close to having a shippable release with some useful new features, though lots of small improvements and features remain in the queue.

On the SP side, we're making progress building out a new documentation space and have started working on a way to adapt the system to handle both a new and old configuration schema. The intention is for essentially complete com patibility with V2 configuration, but to allow for a newer format that will contain mostly small improvements such as removal of deprecated settings and possibly some long-asked for improvements like compositing the configuration from multiple sources. We have also started looking seriously at building in a client-side session migration feature that would simplify clustering in a similar fashion to the IdP's support for client-side sessions.

Our recent spate of security issues with the SP continued last month with a serious XML vulnerability in an area that we had correctly guessed would be a source of ongoing concerns (without having identified the specific issue discovered, unfortunately). Our defensive measures over the last couple of years prevented more widespread impact, but Red Hat's refusal to backport various security fixes and defensive code changes to their version of the Xerces library eventually caught up with us and led to the most serious impact from this bug on RHEL 7 and CentOS 7.

One of the takeaways from this issue was the recognition that XML Encryption is really not an optional feature anymore when it comes to use of the POST binding that most SAML deployments have stuck with. Even without data confidentiality concerns, encrypting the assertion mitigates or prevents attacks against the XML content that is of most importance to applications (i.e., the user's identity and attributes), both attacks we know about and attacks we don't yet know about. This will likely be reflected in SP features to require encryption, and a more aggressive stance on moving systems to the AES-GCM encryption algorithm, which fixes serious flaws that current deployments remain vulnerable to many years after the original discovery that CBC mode was broken. Certainly it will be a V4.0 default.

Expect more discussion of this important issue over the course of this year. Also note that this is really almost exclusively an IdP to SP concern. While the IdP supports decryption in some isolated cases, mainly logout, they are not common use cases, and there is very little deployment of SP to IdP encryption out there today. We don't expect that to change.