Page tree

The Shibboleth 2.x software has reached its End of Life and is no longer supported. This documentation is available for historical purposes only. See the IDP30 and SP3 wiki spaces for current documentation on the supported versions.

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

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".

<CredentialResolver type="Chaining">
     <CredentialResolver type="File" key="signing.key" certificate="signing.crt" use="signing"/>
     <CredentialResolver type="File" key="decrypt.key" certificate="decrypt.crt" use="encryption"/>

For this use case, no additional labeling or configuration should be necessary to get the right key selected.

Key Rollover

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:

  1. Add the second key to your SP configuration explicitly as an encryption key.
  2. Publish the new key in your metadata and wait for propagation.
  3. Remove the old key and the usage constraint from your SP configuration.

As an example, if you start here:

<CredentialResolver type="File" key="sp-key.pem" certificate="sp-cert.pem"/>

Then the configuration after step 1 might be:

<CredentialResolver type="Chaining">
     <CredentialResolver type="File" key="sp-key.pem" certificate="sp-cert.pem"/>
     <CredentialResolver type="File" key="new-key.pem" certificate="new-cert.pem" use="encryption"/>

And after step 3:

<CredentialResolver type="File" key="new-key.pem" certificate="new-cert.pem"/>

Multiple Certificate Scenarios

  • No labels