I spent two hours debugging why users couldn’t authenticate to our custom SAML application through IAM Identity Center. They’d click the app icon in the access portal and get silently redirected back to the login screen. No error messages, no helpful logs—just a frustrating redirect loop. In this post, I’ll walk through exactly what causes this and how to fix it.

The Problem

Your custom SAML 2.0 application in IAM Identity Center is configured, users are assigned, but authentication fails. Users see either:

  • A blank page or redirect loop
  • “Authentication failed” or “Invalid SAML response” in the application logs
  • Users returned to the access portal unauthenticated

This happens because IAM Identity Center can’t establish a valid SAML assertion that the application accepts.

Why Does This Happen?

  • ACS URL mismatch: The Assertion Consumer Service (ACS) URL you configured in IAM Identity Center doesn’t match what your application expects. The app rejects the SAML assertion because it came from the wrong endpoint.
  • Entity ID/Audience mismatch: Your application’s SAML Entity ID (SP Entity ID) doesn’t match the audience value in the SAML assertion IAM Identity Center generates. The app rejects the assertion because the audience is wrong.
  • Missing attribute mappings: Your application expects user attributes like email, firstName, or lastName, but IAM Identity Center isn’t configured to send them. The assertion has no user data.
  • RelayState issues: The RelayState parameter (which tells the app where to redirect after auth) is lost or mismatched, causing the app to redirect to the wrong place.
  • SP-initiated vs IdP-initiated mismatch: Your app is configured for SP-initiated SSO, but IAM Identity Center is sending IdP-initiated requests, or vice versa.

The Fix

Step 1: Verify Application Metadata

First, obtain your application’s SAML metadata XML. This file defines what ACS URL and Entity ID the app expects. Contact your app vendor or download it from your app’s SSO settings.

In the metadata, look for:

<EntityDescriptor entityID="urn:example:app:saml-entity">
  <SPSSODescriptor>
    <AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://app.example.com/saml/acs" />
  </SPSSODescriptor>
</EntityDescriptor>

Note the entityID and Location (ACS URL).

Step 2: Update IAM Identity Center Application Configuration

Navigate to AWS Management Console → IAM Identity Center → Applications → Your Custom App:

  1. Edit Application ACS URL: Paste the exact Location from the metadata
  2. Edit Application SAML audience: Paste the exact entityID from the metadata
  3. Verify Application start URL matches what your app expects (if SP-initiated)

Step 3: Configure Attribute Mappings

Still in the application settings, go to Attribute mappings. Add these common mappings:

IAM Identity Center Attribute Application Attribute
${user:email} email
${user:givenName} firstName
${user:familyName} lastName

Check your application’s documentation for additional required attributes like groups or role.

Step 4: Test the Configuration

Use the Test application feature in IAM Identity Center:

# Or simulate authentication from AWS CLI
aws sso-admin describe-application \
  --instance-arn arn:aws:sso:::instance/ssoins-0123456789abcdef0 \
  --application-arn arn:aws:sso::123456789012:application/ssoins-0123456789abcdef0/apl-0123456789abcdef0

Click Test application in the console to trigger a test SAML flow.

Step 5: Download and Upload Metadata

Download IAM Identity Center’s SAML metadata (in the application settings under SAML metadata). Upload this file to your application’s SAML configuration. The metadata contains IAM Identity Center’s certificate and correct Identity Provider (IdP) endpoints.

How to Run This

  1. Get your app’s SAML metadata XML from your application administrator or vendor portal
  2. In IAM Identity Center, edit the custom application and paste the ACS URL and Entity ID from the metadata
  3. Add attribute mappings for email, givenName, and familyName
  4. Download IAM Identity Center’s SAML metadata and upload it to your application
  5. Click Test application and verify the test succeeds
  6. Have a test user try logging in through the access portal

Is This Safe?

Yes, this is safe. You’re configuring standard SAML 2.0 parameters—no credentials or secrets are involved. The attribute mappings send only the user data needed for your application to function.

Key Takeaway

SAML authentication fails when the ACS URL, Entity ID, or attribute mappings don’t match what the application expects. Always cross-reference your application’s metadata with IAM Identity Center’s configuration, and test before rolling out to users.

Have questions? Connect with me on LinkedIn or X.