Skip to content

SAML Shibboleth NameIDPolicy Error

0

Hi everyone,

I am setting up an AWS Cognito User Pool with a custom SAML Identity Provider (Shibboleth) from my university. I am facing an issue where my SAML Identity Provider (Shibboleth) returns a "StatusCode: InvalidNameIDPolicy" error during login.

I captured a SAML trace, and it shows Cognito sending this NameIDPolicy in the AuthnRequest: <saml2p:NameIDPolicy AllowCreate="false" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" />

I am working the OIT at the university and they have reconfigured their end to have the nameID be persistent, but the issue still persists.

My Configuration:

  1. "Enable IdP sign out flow" is UNCHECKED.
  2. I am mapping the "NameID" in the Attribute Mapping section to a custom attribute "eppn."
  3. I have a required email attribute mapped to the mail attribute.
  4. "Sign SAML Requests to Provider" is enabled (required by uni).

Question: What could be causing this? Is it something on my end and if so, how can I fix this?

Has anyone seen this persistence before?

1 Answer
0

This error is likely related to how the NameID is being handled between your Cognito User Pool and the Shibboleth IdP. Here are some potential causes and solutions:

  1. NameID Format Mismatch: Amazon Cognito requires a specific format for the NameID claim. The SAML IdP must include a NameID claim in the SAML assertion. For Cognito, the NameID is used to identify returning federated users, and it must be case-sensitive and exact. While you're requesting urn:oasis:names:tc:SAML:2.0:nameid-format:persistent, your university's IdP might not support this format or might be configured differently.

  2. Attribute Mapping Issue: You mentioned mapping "NameID" to a custom attribute "eppn." This could be causing confusion. The NameID in the SAML assertion is a special identifier that Cognito uses to recognize returning users, and it should be mapped from an attribute that doesn't change. If the "eppn" value changes, users won't be able to sign in again.

  3. Immutable Attribute Conflict: Check if you're trying to map to any immutable attributes in Cognito. You can identify immutable attributes using the AWS CLI command: aws cognito-idp describe-user-pool --user-pool-id YOUR-POOL-ID --query 'UserPool.SchemaAttributes[?Mutable==false].Name'.

Recommended actions:

  1. Use network capture tools in your browser to retrieve the SAML response and verify the NameID format being sent by Shibboleth.

  2. Ensure the attribute you're using for NameID has values that don't change, as Cognito identifies returning users by their unique and case-sensitive NameID claim.

  3. Work with your university's OIT to ensure they're sending the NameID in the format Cognito expects. Even though they've configured it to be persistent, there might be other format requirements that aren't being met.

  4. Consider removing the custom attribute mapping for NameID and let Cognito use the default NameID from the SAML assertion.

  5. If the issue persists, check if your university's IdP is sending any other required attributes correctly and that there are no conflicts with immutable attributes in your user pool.
    Sources
    Using SAML identity providers with a user pool - Amazon Cognito
    Troubleshoot Amazon Cognito - Amazon Cognito
    Things to know about SAML IdPs in Amazon Cognito user pools - Amazon Cognito

answered 10 months ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.