There are a few typical reasons for supplying the SP with multiple keypairs, or "credentials", to use for authentication and encryption:
- separating signing/TLS and encryption keys
- key "rollover"
- federation or partner-dictated requirements to use particular certificates
These scenarios are discussed in more detail below, with examples explaining how to configure the SP in each case. In each scenario, the common factor is the use of a "Chaining"
<CredentialResolver> to "wrap" two or more individual resolvers (usually of type "File") and enable each credential to be loaded and used. The varying part pertains to how credentials are labeled so that the selection process works as intended in each case.
Note also that the use of encryption in this context is specific to XML Encryption, and for the present, limited to use of SAML 2.0.
Separate Signing and Encryption Keys
This is the simplest (but also not all that common) case, and is handled by labeling the individual resolvers in the chain with a
use property, typically of "signing" or "encryption".
For this use case, no additional labeling or configuration should be necessary to get the right key selected.
Typically with rolling over keys or certificates you have two separate concerns: migrating your signing/authentication keys and your encryption keys. On the authentication side, the solution is to publish the new key/certificate in your metadata and wait for that to propagate before switching your SP from the old credential to the new one. In that scenario, you need not ever configure both within the SP itself (i.e., it's different from this topic's goal).
On the other hand, with encryption you have the opposite problem. Once you publish a new key in your metadata, your peers may start using it but not all of them will switch at the same time. So in this case, you MUST configure both the old and new credentials into the SP so that either key can be available for decryption.
It's likely the case that both of these scenarios apply; often, a single credential is used for both signing and encryption and the migration is from one credential for both to another for both.
Therefore, combining these issues, the simplest approach is:
- Add the second key to your SP configuration explicitly as an encryption key.
- Publish the new key in your metadata and wait for propagation.
- Remove the old key and the usage constraint from your SP configuration.
As an example, if you start here:
Then the configuration after step 1 might be:
And after step 3: