How can I diagnose the cause of AWS Cognito's SAML assertion processing errors?

Question

I am trying to integrate AWS Cognito with a third-party SAML SSO Identity Provider. The third-party IdP is responding with a successful SAML assertion upon login.

Cognito then attempts to validate the assertion's signature, but fails with the following error message:

Error in SAML response processing: SAML Assertion signature is invalid

How can I diagnose the cause of Cognito's assertion processing?

We've tested our Cognito SP with samltest.id, which fully works.

Reading samltest.id's FAQ, signature verification errors from Shibboleth (unrelated to my solution) usually means that the key "used to sign the assertion doesn’t match any valid key with either usage="signing" or null usage in your IdP’s metadata."

Here is a redacted copy of my SP metadata:

<?xml version="1.0"?>
<EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" entityID="urn:amazon:cognito:sp:us-east-2_[REDACTED]" validUntil="2023-04-04T00:00:00Z">
  <SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol" WantAssertionsSigned="true">
    <KeyDescriptor use="signing">
      <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:X509Data>
          <ds:X509Certificate>
            [REDACTED]
          </ds:X509Certificate>
        </ds:X509Data>
      </ds:KeyInfo>
    </KeyDescriptor>
    <NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</NameIDFormat>
    <NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</NameIDFormat>
    <NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName</NameIDFormat>
    <AssertionConsumerService index="1" isDefault="true" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://[REDACTED].auth.us-east-2.amazoncognito.com/saml2/idpresponse" />
    <AssertionConsumerService index="2" isDefault="false" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://[REDACTED].auth.us-east-2.amazoncognito.com/saml2/idpresponse" />
    <AttributeConsumingService index="1">
      <ServiceName xml:lang="en">AWS Vermeer Single Sign-On</ServiceName>
      <RequestedAttribute isRequired="true" Name="mail" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" FriendlyName="email" />
      <RequestedAttribute isRequired="false" Name="given_name" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" FriendlyName="firstName" />
      <RequestedAttribute isRequired="false" Name="family_name" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" FriendlyName="lastName" />
    </AttributeConsumingService>
  </SPSSODescriptor>
  <Organization>
    <OrganizationName xml:lang="en">[REDACTED]</OrganizationName>
    <OrganizationDisplayName xml:lang="en">[REDACTED]</OrganizationDisplayName>
    <OrganizationURL xml:lang="en">[REDACTED]</OrganizationURL>
  </Organization>
</EntityDescriptor>

Unrelated StackOverflow Questions

Why is Cognito rejecting my SAML assertion?

scottwtang · Accepted Answer · 2022-05-03T17:54:58.133

Start by looking at the IdP metadata. The IdP signs the SAML response using the IdP private key, and the SP validates the signature with the IdP public key.

The IdP metadata will contain the certificate, and you can verify that the certificate matches the one in the SAML response.

Could you please elaborate on how these keys work and how, if at all, the certificates in an IdP's metadata align with those in an SP's metadata?

These would be a standard public and private key-pair. When used for digital signatures, the message is signed using the sender's private key, and the signature is verified using the sender's public key.

In a SAML exchange, there will be a SAML request (from the SP to the IdP) and a SAML response (from the IdP to the SP). Officially, it's optional for the request and/or response to be signed, although the IdP/SP may require it. SAML requests generally are not signed (although can be).

So, a SAML response is signed by the IDP using the IdP private key, and the signature is verified by the SP, using the IdP-supplied public key. A SAML request would be signed by the SP using the SP's private key, and verified by the IDP using the SP-supplied public key.

There's no relation between the certificate in the IdP metadata, and the certificate in the SP metadata, aside from both being public certificates for validating a digital signature.

Could you please elaborate on how these keys work and how, if at all, the certificates in an IdP's metadata align with those in an SP's metadata? — Chance Snow, May 03 '22 at 17:19

How can I diagnose the cause of AWS Cognito's SAML assertion processing errors?

Unrelated StackOverflow Questions

1 Answers1