MuneebA.78958 (Customer)
Issue Summary
We are setting up single sign-on (SSO) for an AWS application using the Okta AWS Account Federation app via SAML 2.0, but the SAML assertions are failing. There are two primary
issues:
- Role Mapping Failure: The Role attribute is sending the raw variable string appuser.idpRolePairs instead of resolving into the actual AWS Role/Provider ARN pair.
- Malformed Recipient URL: The Recipient URL is generating as [https://signin..com/saml](https://signin..com/saml) (missing aws), despite the ACS URL being explicitly set to the standard AWS sign-in endpoint.
We need guidance on fixing the attribute mapping behavior and getting Okta to successfully resolve the AWS roles.
Full Details
Hi everyone,
We need assistance with configuring Okta AWS Account Federation for AWS / Amazon Quick Desktop SSO.
We are trying to configure Okta as the identity provider for AWS federation so users can access the application through SSO.
Current setup details:
- Okta tenant: https://[YOUR_OKTA_TENANT].okta.com
- AWS Account ID: [AWS_ACCOUNT_ID]
- AWS IAM SAML Provider ARN: arn:aws:iam::[AWS_ACCOUNT_ID]:saml-provider/Okta
- AWS IAM Federation Role ARN: arn:aws:iam::[AWS_ACCOUNT_ID]:role/OktaQuickFederationRole
- Okta application: AWS Account Federation / Amazon Quick
- Test user: [USER_EMAIL]
We have already completed the following:
- Created an Okta AWS Account Federation application using SAML 2.0.
- Created an AWS IAM SAML identity provider named “Okta” using Okta metadata.
- Created an AWS IAM role named “OktaQuickFederationRole”.
- Updated the IAM role trust relationship to allow AssumeRoleWithSAML from the Okta SAML provider.
- Added the Identity Provider ARN in Okta Advanced Sign-on Settings: arn:aws:iam::[AWS_ACCOUNT_ID]:saml-provider/Okta
- Set AWS Environment to Regular AWS.
- Set ACS URL to: [https://signin.aws.amazon.com/saml](https://signin.aws.amazon.com/saml)
- Enabled “Join all roles”.
- Assigned the test user/group to the Okta AWS Account Federation app.
The IAM role trust policy currently looks like this:
JSON
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::[AWS_ACCOUNT_ID]:saml-provider/Okta"
},
"Action": "sts:AssumeRoleWithSAML",
"Condition": {
"StringEquals": {
"SAML:aud": "https://signin.aws.amazon.com/saml"
}
}
}
]
}
However, the SAML assertion generated by Okta is still not correct.
Current incorrect SAML output from Okta preview:
- Role attribute is being sent as: appuser.idpRolePairs
- RoleSessionName is being sent as: userName
- Recipient is being generated as: [https://signin..com/saml](https://signin..com/saml)
Expected SAML output should be:
- Role: arn:aws:iam::[AWS_ACCOUNT_ID]:role/OktaQuickFederationRole,arn:aws:iam::[AWS_ACCOUNT_ID]:saml-provider/Okta
- RoleSessionName: [USER_EMAIL]
- Recipient: [https://signin.aws.amazon.com/saml](https://signin.aws.amazon.com/saml)
Because the Role attribute is not resolving to the real AWS role/provider ARN pair, AWS rejects the login with an invalid SAML response error.
The main issue seems to be that Okta is not resolving appuser.idpRolePairs into the actual AWS role pair. Also, the Recipient URL is malformed as [https://signin..com/saml](https://signin..com/saml), even though we selected Regular AWS and set the ACS URL to [https://signin.aws.amazon.com/saml](https://signin.aws.amazon.com/saml).
Can you please help us confirm the correct configuration for the Okta AWS Account
Federation app so that:
- appuser.idpRolePairs resolves correctly to the AWS Role and SAML Provider string.
- RoleSessionName resolves to the user email.
- Recipient/ACS URL is correctly generated as [https://signin.aws.amazon.com/saml](https://signin.aws.amazon.com/saml).
- The user/group assignment is correctly mapped to the AWS IAM role.
Please also confirm whether we should use role import/provisioning, group mapping, or direct assignment for this AWS Account Federation app to ensure the attributes map dynamically.
Regards,
Hello @MuneebA.78958 (Customer) Thank you for posting on our Community page!
From all the information you provided the only thing that I currently see that might be a potential mistake seems to be the ACS URL which should be left blank.
In Okta you only need to add the Identity Provider ARN and for the ACS URL you should leave that blank.
The root cause of the Role attribute showing the raw string appuser.idpRolePairs and the RoleSessionName showing userName is typically a misconfiguration in either the SAML Attribute Statements or, more commonly, the user/group assignment profile within the Okta application.Role Mapping (appuser.idpRolePairs not resolving)
The field appuser.idpRolePairs is an internal attribute that is expected to be resolved when a user or group is assigned a role in the application profile. When it appears raw in the SAML assertion, it means the assigned value is missing.
Action to Confirm:
Thank you for reaching out to our Community and have a great day!
--
Help others in the community by liking or hitting Select as Best if this response helped you.