SAML Certificate/credentials rollover support

[svschouw-bb]

Context: Credential rollover

A SAML 2.0 configuration uses anywhere between 1 to 4 different types of certificates. All of these need to be configured by both the Asserting Party (Identity Provider) and Relying Party (Asserting Party). When one of the certificates expires, this needs to be changed over to a new certificate, preferably without any downtime for the users. This is generally done by configuring two certificates during a rollover window, letting the other party update the certificate and then removing the old one.

The certificate types are:

• Encryption (optional) - Provided by the Identity Provider. Used to encrypt the authentication request. Currently unsupported by Spring Security. Assuming the Identity Provider has configured both credentials configured already, might break the moment the Identity Provider stops supporting the old one.
• Verification (required) - Provided by the Identity Provider. Used to verify the assertions sent by the Identity Provider. Goes correct if both are present in the Metadata XML. Spring Security will pick the one that's been used to sign with.
• Decryption (optional) - Provided by the Service Provider. Used to decrypt encrypted assertions (if used). Goes correct if both are configured in Spring Security. It will pick the one that works.
• Signing (optional) - Provided by the Service Provider. Used to sign the authentication request, if desired by the Identity Provider. This is the main one that currently goes wrong.

Current Behavior

When multiple signing credentials are configured, OpenSAML just picks the first one that satisfies all conditions and signs with it. Since the credentials are stored in a HashSet (see RelyingPartyRegistration.java) there is no control over which one it is. If the new signing credentials are used before they are configured on the Identity Provider, this will lead to authentication failures.

Expected Behavior

It should be possible to control which credentials are used for encryption and signing if multiple are known.

One solution is to store the list of credentials in a LinkedHashSet (I don't really understand why HashSets are the default anyway, but I digress). This way the first credential added that satisfies all conditions will be used.

For encryption credentials the newest credentials (with latest expiry) will likely be the best candidate, assuming the Identity Provider has already configured them. If the data is loaded from a metadata XML, this feels like a likely assumption.

For signing credentials the oldest credentials should be used until they either expire, or the Identity Provider has loaded the new credentials, in which case it's safe to remove the old ones.

Context

Spring Security version: 5.5.3, but looking through the git sourcecode, there have been no significant changes here.
OpenSAML version: 3.4.6. OpenSAML 4 also does not seem to have changed as far as I can tell from the source.

• How has this issue affected you? This issue has not affected us yet, but we'd like to have this fixed before the first users can no longer login due to expired certificates.
• What are you trying to accomplish? Implementing a SAML 2.0 credentials rollover mechanism that does not affect users.
• Are you aware of any workarounds? If request signing is disabled, there is no issue. If the Identity Provider can configure multiple verification credentials it's possible to configure the new credentials on the Identity Provider first, and afterwards configure Spring Security. This does mean the metadata XML needs to be bypassed.

[svschouw-bb]

There might be a more convoluted workaround that also works: use a different RelyingPartyRegistration definition for the Saml2MetadataFilter compared to the one used for the OpenSamlAuthenticationProvider. Have the metadata version expose both signing credentials already, but let the authentication provider version use the older version for now. Then after rollover use the new signing credentials for both.

Note that if the same credentials are used for decryption the reverse should be done: the metadata version should use the new one already, and the authentication provider version should use both.

This workaround does require splitting the RelyingPartyRegistrationRepository and relyingPartyRegistrationResolver.

[svschouw-bb]

Maybe the "convoluted" workaround from the previous comment is actually the proper way to do it. If so, that might make it mostly a documentation issue. I have actually no experience with how Spring Boot configures all this.

[jzheaux]

@svschouw-bb, thanks for your insights. I think using LinkedHashSet makes sense, would you be able to provide a PR that makes this change?

As for introducing a custom sorting mechanism, I wonder if there is an OpenSAML credentials resolver or criteria that Spring Security should be using that follows your intuitions about which to use first. If not, I think the easiest way is to 1. rely on the metadata to affirm the preferred order or 2. rely on application developers to add them in their needed order.

[svschouw-bb]

I could probably provide a Pull Request to change the HashSet to a LinkedHashSet , although I would probably have to see how hard it is to provide a unittest for it (a HashSet might accidentally provide the right order).

I'm also having a lot of trouble getting the Spring Security tests to run. I'm not super familiar with Gradle.

But the more I think about it, the more I think this is mostly a metadata problem. As long as both parties provide the correct metadata, there is no real ambiguity. The Identity Provider (Asserting Party) should provide the newest encryption certificate and all verification certificates. The Service Provider (Relying Party / Spring Security) should provide only the newest (active?) certificate for encryption, but use all (non-expired) credentials for decryption. It should use an active credential (oldest non-expired?*) for signing, but provide the new (as well as the current) certificate ahead of time for validation.

Assuming the Asserting Party does things properly as well the above an already by accomplished by splitting the RelyingPartyRegistrations into a metadata version and an authentication version, like I mentioned in #10799 (comment), but this requires splitting the RelyingPartyRegistrationRepository and relyingPartyRegistrationResolver as well. If the RelyingPartRegistration could have an active signing and active encryption credential (not necessarily the same!) the Saml2MetadataFilter and OpenSamlAuthenticationProvider could make use of this.

Then only the issue remains where Identity Providers provide all certificates for encryption instead of just the newest. But Spring Security does not support request encryption anyway, and I don't know if there are any Identity Providers that do this wrong.

(*) Be sure not to use the oldest non-expired credentials to the very last second. By the time the request arrives at the Identity Provider, the credentials could have expired!