External IdP to IAM Identity Center: SAML for sign-in, SCIM for users
How an external identity provider (Okta, Microsoft Entra ID, Google Workspace and others) hands workforce users to IAM Identity Center — SAML 2.0 for authentication, SCIM 2.0 for users and groups — what each side must agree on (NameID, username, externalId, single-valued attributes, token lifetime), a known-good setup, and known-bad ones with their exact symptoms.
markdownpatternv4P7RT-ZQVXstage: buildtrust: officialservice: identity-centerservice: external-idpinterface: consoleinterface: iacOkta IAM Identity CenterEntra ID IAM Identity CenterAzure AD AWS SSOGoogle Workspace AWS SSOSAML SCIM handoffNameID username matchexternalIdSCIM token expirynested groups Entragroup push Oktaattributes for access controlAccessControl SAML attribute
External IdP to IAM Identity Center
Two protocols cross this boundary, and both must agree on who a user is. SAML signs users in, but can't create them. SCIM creates and updates users and groups, but doesn't sign anyone in. The key that ties them together is the Identity Center user name: SCIM maps an IdP attribute to it, and the SAML NameID must carry the same value.
AWS publishes tutorials for Okta, Microsoft Entra ID, Google Workspace, JumpCloud, OneLogin, CyberArk, Ping Identity and Active Directory. You can have one identity source per organization.
What crosses the handoff
| Direction | Protocol | Carries | Must hold |
|---|---|---|---|
| IdP → Identity Center (setup) | SAML metadata | IdP certificate, SSO URL | Matches the IdP's current signing certificate |
| Identity Center → IdP (setup) | SP metadata | ACS URL (one per Region), issuer URL | The IdP's app uses exactly these values |
| IdP → Identity Center (ongoing) | SCIM 2.0, bearer token | Users (userName, name.givenName, name.familyName, displayName, emails, externalId…), groups and memberships | Single-valued attributes; unique userName, primary email, externalId and group names; token valid for 1 year |
| IdP → Identity Center (each sign-in) | SAML assertion | NameID, optional https://aws.amazon.com/SAML/Attributes/AccessControl:<key> attributes | NameID in email format equal to the user name; one unencrypted assertion; at most 50 access-control attributes, single-valued |
Identity Center then issues role credentials for the permission sets assigned to those groups: reference/identity-center/provisioned-roles-and-sessions.md.
Known-good
- A gallery app named "AWS IAM Identity Center" in the IdP. Metadata exchanged both ways. The app's username format is a unique value that is also the user's email address (for example, the UPN where it is a real address).
- SCIM enabled. The endpoint and token entered in the IdP and tested. The token's expiry is in the team calendar.
- Mappings:
userName← the same attribute the NameID sends;externalId← an immutable object ID; one email; one phone (or none). - Access goes through groups: assign them to the IdP app and (Okta) push them, using a separate group for push. Then assign those groups to permission sets on accounts in Identity Center.
- Users and groups are deleted in the IdP, never in Identity Center.
- Optional: attributes for access control for ABAC (
AccessControl:Department, …), enabled by someone withiam:UpdateAssumeRolePolicy.
Known-bad
| Configuration | Symptom |
|---|---|
| NameID sends email, SCIM maps userName from a different attribute | Provisioning works; sign-in fails with An unexpected error has occurred |
| SAML configured, SCIM never enabled, users not created manually | Every sign-in fails: there is no just-in-time creation |
| User without a last name or display name in the IdP | That user never syncs (… 'name.givenName' failed to satisfy constraint …) |
| Several emails or phones mapped | List attribute emails exceeds allowed limit of 1 / Currently list attributes only allow single item |
| Entra ID: access granted through a nested group | Those users never appear in Identity Center |
Entra ID: guest users (#EXT#) | Sync or sign-in fails until a conditional Name ID claim is used |
| Okta: same group used for assignment and push | Not supported; membership sync misbehaves |
| User deleted in Identity Center while SCIM is on | Okta push fails (No user returned for user …); the user is missing until recreated in the IdP |
| User deleted and recreated in the IdP with the same name | Shows in assignments but has no access: reassign |
| SCIM token reaches its one-year expiry | Sync stops; new hires can't sign in, and leavers keep Identity Center records |
| Identity Store API used to tweak groups alongside SCIM | Drift that SCIM won't correct |
| Oct 2026 Identity Store/SCIM network restrictions on, IdP IPs not listed | SCIM calls rejected |
| Multi-Region replication without adding the other Regions' ACS URLs | Sign-in fails in the added Regions |
Which side is wrong?
- The user doesn't exist in Identity Center → SCIM (the IdP side): check the IdP's provisioning log and CloudTrail
CreateUsererrors. - The user exists, but sign-in fails → SAML: NameID versus user name, certificate, ACS URL, clock. CloudTrail:
ExternalIdPDirectoryLogin. - Sign-in works, but the user sees no accounts → assignments: group membership synced? Permission set assigned to that group and account? Account access enabled on the instance?
- Accounts visible, but actions denied → the permission set's policies or SCPs:
guides/iam/fix-access-denied.md.