Users signin in Quicksight (via IAM Federation)

ilyasse · December 17, 2025, 11:30am

Hi

I have a private external OIDC Identity provider that i want my users to access Quicksight based on that private IDP. which means connecting to my private IDP ( and having the right roles ) will allow them to access Quicksight ( in non default namespace )

I wanted to do a basic test which is using the JWT token given by my IDP to access Quicksight.

What i’ve done, is creating an identity provider in IAM,

I set the identity provider a a url aswell as an audience that matches the claims in my jwt token.

I have a associated a role to the audience and pre registred a user in quicksight with these parameters :

aws quicksight register-user \
–aws-account-id “account_id \
–namespace default \
–identity-type IAM \
–iam-arn my-arn \
–email my_email \
–user-role ADMIN \
–external-login-federation-provider-type CUSTOM_OIDC \
–custom-federation-provider-url “my provider url” \
–external-login-id random-id \
–region my_region

i did a call to STS to assume the role with web identity

aws sts assume-role-with-web-identity
–role-arn role_arn
–role-session-name test
–web-identity-token file://id_token.jwt
–duration-seconds duration

and at the end i did get the sign in url with this peace of code :

signin_token=$(curl -s “ https: // signin. aws .amazon .com / federation “
–data-urlencode “Action=getSigninToken”
–data-urlencode “Session=$(jq -c -n --arg a “$AWS_ACCESS_KEY_ID” --arg b “$AWS_SECRET_ACCESS_KEY” --arg c “$AWS_SESSION_TOKEN” ‘{sessionId:$a,sessionKey:$b,sessionToken:$c}’)”
| jq -r ‘.SigninToken’)

login_url=$(python - <<‘PY’ “ https: // signin. aws. amazon. com/ federation “

#I added spaces in the url in order not to be changed to a beautified format
import urllib.parse
print(urllib.parse.quote(“https://eu-west-3.quicksight.aws.amazon.com/”))
PY
)

url=“https://signin.aws.amazon.com/federation?Action=login&Issuer=example&Destination=$login_url&SigninToken=$signin_token”
echo “$url”

Since i activated Email Syncing in Quicksight, i got this error :

The AWS principal tag corresponding to “PrincipalTag:Email” in your SAML assertion or OIDC token is either an invalid email or not present. Please reach out to your Quick Suite account’s admin to ensure that the email address for this AWS principal tag is correct.

My questions :

How can i fix that issue ( i want my users to access quicksight with my IDP’s email )
Is the trust policy mandatory to include a specific tag to recognize the email claim token ?
Is there another approache to authenticate my users from the IDP to quicksight directly ?( keeping in mind the namespace constraint )
since having an external OIDC IDP, what are the possible solutions to connect to Quicksight ?
From my private external IDP OIDC compatible , my users cannot access directly Quicksight via the url https://eu-west-3.quicksight.aws.amazon.com/sn/ right ? what should the url be ?
In another words, how can a user registred with the quicksight register user ( based on a custom OIDC parameters ) connect to Quicksight

Deep · December 17, 2025, 2:59pm

Hello Ilyasse,

Based on the error and your configuration, Potential Root Cause

The error occurs because QuickSight’s email syncing feature is enabled, but your OIDC token doesn’t contain the required PrincipalTag:Email claim that QuickSight expects.

Please do verify and check that.

Potential Solution 1: Add Email Principal Tag to Your OIDC Token

You need to configure your OIDC provider to pass the email as a principal tag in the OIDC token:

1. Update your IAM role trust policy to include the sts:TagSession action:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::YOUR_ACCOUNT_ID:oidc-provider/YOUR_OIDC_PROVIDER_URL"
      },
      "Action": [
        "sts:AssumeRoleWithWebIdentity",
        "sts:TagSession"
      ],
      "Condition": {
        "StringEquals": {
          "YOUR_OIDC_PROVIDER_URL:aud": "YOUR_AUDIENCE"
        }
      }
    }
  ]
}

2. Configure your OIDC provider to include the email in the token with the following structure:

{
  "https://aws.amazon.com/tags": {
    "principal_tags": {
      "Email": ["user@example.com"]
    }
  }
}

The email should be a valid email address from your IDP’s user profile.

Refer : here

Solution 2: Disable Email Syncing in QuickSight

If you don’t need email syncing, you can disable it:

Sign in to QuickSight as an administrator
Go to Manage QuickSight → Single sign-on (IAM federation)
Turn Email Syncing for Federated Users to OFF

When disabled, users will be prompted to enter their email address manually during first-time provisioning.

Answering Your Specific Questions

Q1: How can I fix that issue (I want my users to access QuickSight with my IDP’s email)?

Follow Solution 1 above. Ensure your OIDC token includes the email claim in the principal_tags format that AWS expects.

Q2: Is the trust policy mandatory to include a specific tag to recognize the email claim token?

Yes, the trust policy must include sts:TagSession to allow principal tags to be passed when assuming the role.

Q3: Is there another approach to authenticate my users from the IDP to QuickSight directly (keeping in mind the namespace constraint)?

For custom OIDC providers with non-default namespaces, your current approach (AssumeRoleWithWebIdentity) looks correct. However, you must:

Pre-register users using aws quicksight register-user with the --external-login-federation-provider-type CUSTOM_OIDC parameter
Ensure the --external-login-id matches the subject claim from your OIDC token

Refer : here

Q4: Since having an external OIDC IDP, what are the possible solutions to connect to QuickSight?

The main options are:

AssumeRoleWithWebIdentity (your current approach) - requires proper principal tag configuration
Pre-register users via API before they attempt to sign in
Consider using IAM Identity Center as an intermediary if your OIDC provider supports SAML

Q5: How can a user registered with the quicksight register-user (based on custom OIDC parameters) connect to QuickSight?

After registration, users must:

Obtain an ID token from your OIDC provider
Call aws sts assume-role-with-web-identity with the token
Use the temporary credentials to access QuickSight
The --external-login-id in the registration must match the subject in the OIDC token

Hope this helps in troubleshooting the issue

Cheers,

Deep

ilyasse · December 17, 2025, 3:28pm

Deep:

ial Solution 1: Add Email Principal Tag to Your OIDC Token

You need to configure your OIDC provider to pass the email as a principal tag in the OIDC token:

1. Update your IAM role trust policy to include the sts:TagSession action:
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::YOUR_ACCOUNT_ID:oidc-provider/YOUR_OIDC_PROVIDER_URL"
      },
      "Action": [
        "sts:AssumeRoleWithWebIdentity",
        "sts:TagSession"
      ],
      "Condition": {
        "StringEquals": {
          "YOUR_OIDC_PROVIDER_URL:aud": "YOUR_AUDIENCE"
        }
      }
    }
  ]
}

Hi @Deep, Thank you for your precised and fast response.

For the moment, I cannot add a new claim in my JWT token in order to have the email there. So i guess i’ll disable it.

However, is it possible to register users in Quicksight and when connecting, Quicksight won’t ask them for email for their first login since i did pre-register them ?

I used the register api but with a wrong “–external-login-id” . Does that explain that Quicksight asked for the email ?

Update:

i did disable the email sync.

What i’ve done is taking the JWT token again, registering a new user in quicksight, here’s the details of the cli :

aws quicksight register-user
–aws-account-id my-account-id
–namespace default
–identity-type IAM
–iam-arn role-arn-associated-to-idp-full-access
–session-name random-name
–email my-valid-email
–user-role ADMIN
–external-login-federation-provider-type CUSTOM_OIDC
–custom-federation-provider-url “my-provider-url”
–external-login-id sub-claim-from-token
–region my-region

and then i did call the sts for credentials and construct the url in order to connect.

when i enter the url in incongito mode, Quicksight asks for email and register a new user. Is this the normal behavior ? because i’m expecting to connect to the created user ..

Thanks

Thanks,

Deep · December 17, 2025, 4:36pm

Hello Ilyasse,

Yes, you’re correct. If you used a wrong --external-login-id when pre-registering users with the register-user API, that would explain why QuickSight is asking users for their email during first login.

Why This may Happens

When you pre-register a user with custom OIDC federation, QuickSight creates a mapping between:

The IAM role session (from AssumeRoleWithWebIdentity)
The --external-login-id you provided during registration

If the --external-login-id doesn’t match the subject claim (sub) from your OIDC token when the user actually logs in, QuickSight cannot find the pre-registered user and treats them as a new user—prompting for email registration.

Understanding `--external-login-id` for Custom OIDC

For custom OIDC providers, the --external-login-id should be the unique identifier (subject) from your OIDC provider’s ID token—typically the sub claim.

Format: Just the subject identifier (e.g., 12345678-1234-1234-abc1-a1b1234567)

Example from documentation:

aws quicksight register-user --aws-account-id 111222333 --namespace default \
  --email identity-user@amazon.com --user-role ADMIN --identity-type IAM \
  --iam-arn arn:aws:iam::111222333:role/CustomIdentityQuickSightRole \
  --session-name identity-user \
  --external-login-federation-provider-type CUSTOM_OIDC \
  --custom-federation-provider-url idp.us-east-1.amazonaws.com/us-east-1_ABCDE \
  --external-login-id 12345678-1234-1234-abc1-a1b1234567 \
  --region us-east-1

Solution: Re-register Users with Correct `--external-login-id`

Since you’ve disabled email syncing, users can now manually enter their email. However, to avoid the email prompt entirely for pre-registered users, you may need to:

1. Identify the Correct Subject from Your OIDC Token

Decode your OIDC ID token to find the sub claim. You can use:

JWT.io to decode the token
Your OIDC provider’s user management console
The token response from your authentication flow

The sub claim is the unique identifier for each user in your OIDC system.

2. Update Existing Users with Correct `--external-login-id`

Use the update-user API to fix the external login mapping:

aws quicksight update-user --aws-account-id <account-id> --namespace default \
  --user-name <identity-provider-associated-iam-role>/<identity-username> \
  --email <user-email> --role <user-role> \
  --external-login-federation-provider-type CUSTOM_OIDC \
  --custom-federation-provider-url <your-idp-url> \
  --external-login-id <correct-subject-from-oidc-token> \
  --region <your-region>

3. For New Users: Register with Correct `--external-login-id`

When pre-registering new users, ensure the --external-login-id matches the sub claim from your OIDC provider’s ID token for that user.

Verification Steps

After updating the --external-login-id:

Check the user mapping using describe-user:

aws quicksight describe-user --aws-account-id <account-id> --namespace default \
  --user-name <iam-role>/<username> --region <region>

Look for the ExternalLoginId field in the response—it should match the sub claim from your OIDC token
Test the login flow: Have the user authenticate through your OIDC provider and access QuickSight. They should no longer be prompted for email.

Key Point

The --external-login-id must exactly match the subject identifier (sub claim) that your OIDC provider sends in the ID token. Any mismatch will cause QuickSight to treat the user as new and prompt for email registration, even if they were pre-registered.

Hope this helps.