Page Comparison

...

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.

Table of Contents

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

Code Block

	xml
	xml


<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"/>
</CredentialResolver>

...

Therefore, combining these issues, if you want to perform rollover of a single keypair for both signing and encryption, you can follow these steps:

Add the a second private key to your SP configuration explicitly as an encryption keya decryption key (use="encryption").
Publish the new corresponding public key in your metadata and wait for propagation.
Switch the encryption usage constraint in the SP configuration from the new key to the old key.
Remove the old public key from the metadata and wait for propagation.
Remove the old private key from your SP configuration.

As an example, if you start here:

Code Block

	xml
	xml


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

Then the configuration after step 1 might be:

Code Block

	xml
	xml


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

After step 3:

Code Block

	xml
	xml


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

And after step 5:

Code Block

	xml
	xml


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

Note

The above examples are not meant to be taken literally. If your files go by different names, live in non-default locations, then you will obviously need to adjust. Also take care as to whether one or both of your private keys has been encrypted on disk. You may need to supply a password attribute in your elements to load the key. In all cases CHECK YOUR LOGS any time you are manipulating keys. You MUST ensure that all keys are loading correctly and that no errors are being logged during normal use.

The above example process is suitable for cases in which the metadata's <md:KeyDescriptor> elements do not carry a use XML attribute and there is no opportunity to introduce such a use attribute into metadata. Other approaches may be more suitable for non-Shibboleth implementations.

...

Configure both credentials together in a chain.
Add one or more <RelyingParty> elements in the appropriate spot with a keyName property that matches the "CN" from the desired credential's certificate subject (or that matches a subjectAltName).

Code Block

	xml
	xml
title	Example using certificate subject as keyName	xml


<ApplicationDefaults ...>
    ...
    <Errors .../>
    <RelyingParty Name="https://idp.example.org/idp/shibboleth" keyName="trusted.example.org"/>
    ...
    <CredentialResolver type="Chaining">
        <CredentialResolver type="File" key="sp-key.pem" certificate="sp-cert.pem"/>
        <CredentialResolver type="File" key="trusted-key.pem" certificate="trusted-cert.pem"/>
    </CredentialResolver>
</ApplicationDefaults>

If you find that each candidate credential shares essentially the same certificate subject information, then you can use a locally-chosen name in your <RelyingParty> element and add the same value to a keyName attribute or <Name> element in the <CredentialResolver>.

Code Block

	xml
	xml
title	Example using locally chosen keyNamexml


<ApplicationDefaults ...>
    ...
    <Errors .../>
    <RelyingParty Name="https://idp.example.org/idp/shibboleth" keyName="Special"/>
    ...
    <CredentialResolver type="Chaining">
        <CredentialResolver type="File" key="sp-key.pem" certificate="sp-cert.pem"/>
        <CredentialResolver type="File" key="trusted-key.pem" certificate="trusted-cert.pem" keyName="Special"/>
    </CredentialResolver>
</ApplicationDefaults>

Versions Compared

Old Version 8

New Version Current

Key

Separate Signing and Encryption Keys