Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Despite that lack of support, we concluded that we could not in good conscience continue to ship an insecure default, so have made the decision to alter the default for new deployments to use the only secure option available.

Algorithm Selection

So why does the "default" matter and how does this impact the system?

When SAML was standardized, it defined no way of determining what signature or encryption algorithms a peer supported, in keeping with a very commercially-driven and impractical focus on manually interoperating pairs of systems one at a time with no thought of change or future evolution. As a result, IdPs and SPs make decisions about how to sign or encrypt with no information other than what they themselves can support.

The default, therefore, matters a great deal since it is, the majority of the time, the only input to the decision.

The Shibboleth Project, being neither commercial nor impractical, realized this was stupid very early on, and we defined a standard extension to SAML Metadata to allow IdPs and SPs to advertise the algorithms supported, and implemented support for that in our software. This is automatic and doesn't require any work by the receiving system, but of course the source of the metadata has a much bigger job to do in collecting or accurately capturing that information. Most deployers are hard-pressed to do this, and the information may be incomplete, fall out of date, etc.

As a result, there has been a lack of significant use of this extension and most of the time the default continues to be the only thing that matters.

With respect to the Shibboleth IdP, the process of laying out defaults for signing and encryption relies on a relatively ugly Spring XML bean definition, but a set of beans with different pre-defined defaults exist and can be selected using simple properties.

One of these properties, idp.encryption.config, is now explicitly defined to be "shibboleth.EncryptionConfiguration.GCM". The internal wiring continues to use AES-CBC as a default to prevent properly upgraded systems from any changes to their behavior.

Deployer Impact

Simply put, out of the box, your IdP is going to generate encrypted Assertions that a large percentage of non-Shibboleth SPs are going to be unable to decrypt, resulting a wide variety of failures and error messages. Some old Shibboleth SPs or software running on old Operating Systems will also fail to work, but bluntly, they're probably insecure to begin with.

If you don't care about the security of the encryption or simply don't have the will to do anything about it, then the quickest solution is to comment out the property, restart, and revert to previous behavior.

If you want to do something about this mess, then you're not going to have any choice but to attack the problem manually in a piecemeal fashion. You have two basic choices:

  • Leave the default set, and carve out exceptions for each SP that doesn't support GCM.
  • Change the default back to CBC, and carve out exceptions for each SP that supports GCM.

In both cases, knowing what something supports is largely a matter of guesswork and testing, though as a general heuristic, most Shibboleth SPs (usually recognizeable via entityID and by the /Shibboleth.sso paths in their endpoints) support GCM and most other SPs do not.

In either case, the most practical way to apply exceptions to the default is via the use of the Algorithm Metadata Filter, to attach the standard extension to an SP's metadata to denote it as supporting one or the other algorithm. Essentially you're using the filter to specify a different default algorithm for that SP.