Spring Security Should Spring Security SAML check the validity (notBefore and notAfter) of trusted X.509 certificates?

Expected Behavior

It might make sense to ignore expired (or not yet valid) X.509 certificates when accessing the certificates configured in RelyingPartyRegistration.

Spring Security SAML might sign or encrypt using an expired certificate. Strict identity providers may reject or fail to decrypt such messages.

In the other direction, Spring Security SAML could be made to reject signatures or encrypted data created with an expired certificate.

This might break existing SAML setups that ignore certificate validity, so it should probably be configurable.

If enabled, certificates must be filtered by their validity for each outgoing and incoming message, because expiration can happen after certificates have been configured in RelyingPartyRegistration.

Current Behavior

Spring Security SAML doesn't check the validity of the configured trusted X.509 certificates.

Context

This is especially important in setups where certificates are supposed to establish trust only for a limited time.

Comment From: chschu

This is already possible with a custom implementation of RelyingPartyRegistrationRepository that checks the certificates added to the returned RelyingPartyRegistration for validity.

Comment From: marcusdacoregio

Hi @chschu, thanks for the report.

I think we could change OpenSamlSigningUtils#resolveSigningParameters somehow to add an EvaluableX509CertSelectorCredentialCriterion to the CriteriaSet used. Something like:

// ...
X509CertSelector selector = new X509CertSelector();
selector.setCertificateValid(new Date());
criteria.add(new EvaluableX509CertSelectorCredentialCriterion(selector));
// ...

@jzheaux what is your input on this?

Comment From: jzheaux

I'm surprised that OpenSAML will sign with an invalid certificate by default. Perhaps they can provide some insight into that API decision.

In spite of that surprise, a change like this would likely break several people during an upgrade. We may need to introduce support in a feature release, perhaps in the way of exposing a credential predicate (for example, EvaluableCredentialCriterion) through OpenSaml4AuthenticationRequestResolver, OpenSaml4AuthenticationProvider, etc. where the default matches the default OpenSAML behavior. We could consider changing the default in 7.

Such a predicate could then be employed by OpenSamlSigningUtils and OpenSamlVerificationUtils as needed.

Comment From: 1livv

Certificates in the SAML protocol are used just as a mean to transport public key materials. The interop spec https://docs.oasis-open.org/security/saml/Post2.0/sstc-metadata-iop-os.html#__RefHeading___Toc7851_782679371 specifies :

Subsequent to accepting a metadata instance, a consumer MUST NOT apply additional criteria of any kind on the acceptance, or validity, of the keys found within it or their use at runtime.

In that light the opensaml default behaviour makes sense

Comment From: chschu

Thanks @1livv for finding that in the interop spec. It clearly states that any X.509 metadata should only ever be used to identify the public key. It explicitly advises against checking the certificate for validity.

If there are no valid reasons to deviate from the interop spec here, this issue can be closed.

Comment From: marcusdacoregio

Thanks for finding that @1livv, that gives us the insight that we needed.

I'll close this since the specification clearly says that the consumer should not apply any technique to X509 certificates.

Thank you all again for the findings.