Add Option (strict_cert_store) to disallow X.509 in requests when idp_cert is provided in settings

[InfAmelia]

Status

READY

Migrations

NO

Description

We'd like to ensure that configurations which make use of the idp_cert stored in the settings object do not use an X.509 certificate provided from the IdP when validating the signature of the response.

Motivation

When using traditional X.509 based signature validation and the SHA-1 signing algorithms our end users are concerned that one may spoof a request using a different public / private key pair due to the potential of checksum collisions using SHA-1.

In order to address this, we migrated to using idp_certs stored in the saml settings, though one may still provide an X509 certificate in a request and it will be evaluated prior to using the public key stored in the settings object.

(We also migrated to using SHA-256 as the signing algorithm, though this flexibility would still be useful to us in reassuring our end users)

[pitbulk]

But how are you gonna prevent IdPs to be adding ds:X509Certificate? I believe 99% of them include it in the Signature of the SAMLResponse.

[InfAmelia]

@pitbulk --

But how are you gonna prevent IdPs to be adding ds:X509Certificate? I believe 99% of them include it in the Signature of the SAMLResponse.

I can't guarantee that the IdP will not send me an X.509 certificate though they've asked us to store their public key and use that to validate their signature and my read of the code is that we'll actually use their X.509 certificate if it's present. Most of our integrations would not use this functionality, so I totally agree it's an edge case. We'd pass this option into our Settings object along with the IdP Cert so we can be certain that we're not using an X.509 certificate for those requests.

(here's some more context)

We're acting as an SP for a user integrating with ADFS who are configured to send a SamlResponse lacking an X.509 certificate. We're actually using this gem's functionality to validate the signature using a public key stored on the saml settings object (seen here) rather than an X.509 certificate. They have configured ADFS to act in that manner because they are concerned that a user might act on their behalf by using a different Public / Private key pair and passing their own X.509 certificate in the request.

(This would be extremely hard to do, though it seems possible if using a SHA-1 request signing algorithm)

[pitbulk]

If the cert of the idp is registered on the settings, then there is a call to the validate_document_with_cert method. That method at the end use in order to validate the cert registered and the comparison between cert provided and registered is done at pem comparison level, no sha-1