Signature validation failing even though the request isn't signed
Wessel, Keith
kwessel at illinois.edu
Wed Dec 8 16:05:38 UTC 2021
Hi, all,
I've been chasing my tail trying to track this down. Last week, authentication with a federated SP stopped working. The vendor claims to have made no changes on their side, and our IdP hasn't changed. The IdP log is reporting:
[org.opensaml.saml.common.binding.security.impl.BaseSAMLSimpleSignatureSecurityHandler:275] - Message Handler: Simple signature validation (with no request-derived credentials) failed
[org.opensaml.saml.common.binding.security.impl.BaseSAMLSimpleSignatureSecurityHandler:214] - Message Handler: Validation of request simple signature failed for context issuer: https://riskonnectbtaauil.my.salesforce.com
It's true that there are no request-derived credentials. In fact, the authn request isn't even signed:
<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
AssertionConsumerServiceURL="https://riskonnectbtaauil.my.salesforce.com"
Destination="https://shibboleth.illinois.edu/idp/profile/SAML2/Redirect/SSO"
ID="_2CAAAAX4q9FMDMDAwMDAwMDAwMDAwMDAwAAAA6vFVf548Cft-pCCEtCx7Zs9iebdHovxP1POBzpOIRuqD1ZonBoiFnacFNYqxhZ7fN9-bT-hViGRrFZTxKrVgxyc6BaOghYDyN8Jw9b0Jp_9dT67KAvqh7QCy-5QtCPUAwPfcthwNC7eUzXCoqUnwKUAePY2n1BgGQ8OVmT5pj0zj1bqwDGHNs1LghDwKhf17yEA40JMNyoy02DLXjRtWx5aee21ePAT7vss6BX0ISlvkNCt3d3zMWdt3ByR0lBM0yg"
IssueInstant="2021-12-08T15:56:33.782Z"
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Version="2.0"
>
<saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">https://riskonnectbtaauil.my.salesforce.com</saml:Issuer>
</samlp:AuthnRequest>
That's what I'm getting from the SAML tracer plugin in my browser just before the error.
The IdP is configured with default behavior for request signatures: it shouldn't be requiring it, and the metadata for this SP has nothing about signAuthnRequests. There was a signing certificate in their metadata which I removed for good measure, but the error remains.
I'm used to seeing this error when there's a cert mismatch between metadata and the cert being used to sign the request. But since there's no signing cert in metadata and no cert being used to sign the request, that's obviously not the issue.
Thoughts?
Thanks,
Keith
More information about the users
mailing list