The IdP now defaults to the use of a modern data encryption algorithm family called AES-GCM to encrypt XML. Earlier versions dating back to V2.0 relied on an older variant called AES-CBC. This page outlines the reason for this change, the process of algorithm selection in the software, and (for those so inclined) how to accomplish a controlled migraton to AES-GCM for Shibboleth SPs and the very small number of other implementations that support it.
| Table of Contents |
|---|
Background
SAML supports message-level encryption of XML at a few different layers, the most common being to encrypt the entire Assertion issued to an SP so that it travels through the browser confidentially. In a few cases this might be valuable to hide information from the actual subject, but more often it's done to protect against malware in the client.
...
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.
...
The decision to make this change has spurred some discussion by other projects to finally get GCM supported, which is good news. Other projects are welcome to add information here to assist with tracking.
...
PySAML2
https://github.com/IdentityPython/pysaml2/issues/671
...