Skip to content
Start with Identity
Join free
Recipe · Intermediate · 60 min

Federate AWS IAM Identity Center with Microsoft Entra ID or Okta (SAML + SCIM)

Make Entra ID or Okta the identity source for AWS IAM Identity Center: exchange SAML metadata, turn on SCIM so users and groups sync automatically, then grant access with permission sets and account assignments from the console or the AWS CLI.

AWSSAMLSCIMEntra ID / Okta
Before you start
  • An organization instance of IAM Identity Center and admin access to the management or delegated administrator account
  • Microsoft Entra ID (Cloud Application Administrator or Application Administrator) or an Okta org with outbound provisioning (lifecycle management) licensed
  • AWS CLI v2 configured for the account that administers IAM Identity Center
  • Every user has first name, last name, username and display name populated in the IdP
Implements

To federate AWS IAM Identity Center with Microsoft Entra ID or Okta, you change the Identity Center identity source to External identity provider, exchange SAML metadata with the IdP's AWS IAM Identity Center app, and enable automatic provisioning so the IdP pushes users and groups over SCIM. Access is then granted in AWS by assigning those synced groups to accounts with permission sets. End state: people sign in once with corporate credentials and phishing-resistant MFA, get short-lived role credentials in every account, and lose AWS access when they are disabled in the IdP.

This is the AWS leg of a multi-cloud setup. Azure needs no extra federation because Entra ID is its native directory, and Google Cloud is covered in GCP Workforce Identity Federation. For the overall design (one IdP, per-cloud authorization) see the multi-cloud IAM strategy guide.

Before you start

Three rules from AWS's automatic provisioning considerations decide whether this works first time:

  • The attribute your IdP sends as the SAML NameID must be the same attribute you map to Username in SCIM. If they differ, sign-in fails.
  • Primary email must be unique per user, and only single values sync: multiple emails or phone numbers make provisioning fail.
  • Map SCIM externalId to an identifier that never changes (such as the Entra object ID), so a name or email change does not strand a user's assignments.

Once SCIM is on you can no longer add or edit users in the Identity Center console. The IdP becomes the only source.

1. Add the AWS IAM Identity Center app in your IdP

  • Entra ID: In the Microsoft Entra admin center, go to Entra ID > Enterprise apps > New application, search the gallery for AWS IAM Identity Center, and choose Create (AWS tutorial for Entra ID).
  • Okta: Applications > Applications > Browse App Catalog, search AWS IAM Identity Center, add it, then on the Sign On tab choose SAML Signing Certificates > Actions > View IdP Metadata and save it as metadata.xml (AWS tutorial for Okta).

Check: The app appears in the enterprise apps or applications list. Common failure: Creating a custom non-gallery SAML app instead, which lacks the preconfigured SCIM connector and mappings. Rollback: Delete the app; nothing in AWS has changed yet.

2. Change the identity source in IAM Identity Center

Per How to connect to an external identity provider:

IAM Identity Center console > Settings > Identity source
  Actions > Change identity source > External identity provider > Next
  Service provider metadata: Download metadata file
    (or copy the IAM Identity Center ACS URL and IAM Identity Center issuer URL)
  Identity provider metadata: IdP SAML metadata > Choose file (the IdP metadata)
  Next > type ACCEPT > Change identity source

On the IdP side, Entra ID takes the AWS file through Single sign-on > SAML > Upload metadata file; confirm Identifier is the issuer URL and Reply URL is the ACS URL, then download Federation Metadata XML for AWS. In Okta, enter the values under Sign On > Advanced Sign-on Settings as ACS URL and Issuer URL, and set Application username format to a value unique per user.

Check: The Settings page shows the external IdP as the identity source. Common failure: The downloaded metadata contains both IPv4 and dual-stack ACS URLs (and one set per replicated Region). IdPs with an ACS URL limit reject it; paste only the URLs you use. Rollback: Change identity source back to Identity Center directory. AWS warns that changing to or from Active Directory removes all existing assignments, so export assignments before any source change.

3. Enable automatic provisioning (SCIM)

Per Enable automatic provisioning: Settings > Automatic provisioning > Enable. The Inbound automatic provisioning dialog shows the SCIM endpoint (for example https://scim.us-east-2.amazonaws.com/<id>/scim/v2) and the Access token (Show token). This is the only time you can copy them.

Tokens are valid for one year. AWS sends console and AWS Health Dashboard reminders from 90 days before expiry, and provisioning stops if the token lapses. Put the expiry date in your rotation calendar now.

Check: Provisioning method under the Identity source tab reads SCIM. Common failure: Closing the dialog before copying the token. Generate a new token and delete the unused one. Rollback: Disable automatic provisioning; already-synced users remain.

4. Configure provisioning in the IdP

  • Entra ID: In the app, Provisioning > + New configuration, paste the SCIM endpoint into Tenant URL and the token into Secret Token, Test Connection, Create. Under Properties, set a notification email for quarantine alerts and turn on accidental deletion prevention. Review Attribute Mapping for users and groups, assign groups under Users and groups, then Start provisioning (Microsoft Learn tutorial). Entra ID does not provision members of nested groups, only direct members of assigned groups.
  • Okta: Provisioning > Integration > Edit > Enable API integration, paste Base URL and API Token, Test API Credentials, Save. Under To App, enable Create Users, Update User Attributes and Deactivate Users. Assign groups on Assignments, then push them on Push Groups. AWS notes Okta cannot use the same group for both assignment and group push, so create a separate push group.

Check: In IAM Identity Center, Users lists the synced users with Created by = SCIM, and Groups lists the pushed groups. Common failure: A 400 "violates schema" in Entra provisioning logs, with a CloudTrail CreateUser error "Currently list attributes only allow single item": a user has multiple phone numbers or emails mapped. Remove the duplicate mapping. Rollback: Turn provisioning off in the IdP. Delete users in the IdP, not in AWS; AWS warns that deleting in Identity Center breaks later pushes.

5. Create permission sets and account assignments

Use groups, never individual users. With the AWS CLI (create-permission-set, create-account-assignment):

INSTANCE_ARN=$(aws sso-admin list-instances --query 'Instances[0].InstanceArn' --output text)
STORE_ID=$(aws sso-admin list-instances --query 'Instances[0].IdentityStoreId' --output text)

PS_ARN=$(aws sso-admin create-permission-set \
  --instance-arn "$INSTANCE_ARN" --name ReadOnly \
  --session-duration PT4H \
  --query 'PermissionSet.PermissionSetArn' --output text)

aws sso-admin attach-managed-policy-to-permission-set \
  --instance-arn "$INSTANCE_ARN" --permission-set-arn "$PS_ARN" \
  --managed-policy-arn arn:aws:iam::aws:policy/ReadOnlyAccess

GROUP_ID=$(aws identitystore get-group-id --identity-store-id "$STORE_ID" \
  --alternate-identifier '{"UniqueAttribute":{"AttributePath":"displayName","AttributeValue":"aws-prod-readonly"}}' \
  --query GroupId --output text)

aws sso-admin create-account-assignment \
  --instance-arn "$INSTANCE_ARN" --target-id 123456789012 --target-type AWS_ACCOUNT \
  --permission-set-arn "$PS_ARN" --principal-type GROUP --principal-id "$GROUP_ID"

create-account-assignment provisions the permission set into the account automatically. If you later change the permission set, run provision-permission-set; attached policy changes do not reach accounts on their own.

Check: The assignment returns AccountAssignmentCreationStatus.Status of IN_PROGRESS, then SUCCEEDED from aws sso-admin describe-account-assignment-creation-status --instance-arn "$INSTANCE_ARN" --account-assignment-creation-request-id <RequestId>. Common failure: get-group-id finds nothing because the group was assigned in the IdP but never pushed or provisioned. Rollback: aws sso-admin delete-account-assignment with the same arguments.

Verify it works

  1. SP-initiated sign-in: Open the AWS access portal URL in a private window. You should be redirected to Entra ID or Okta, complete MFA, and land on the portal showing only the assigned account and ReadOnly.
  2. CLI: aws configure sso, then aws sts get-caller-identity --profile <profile> should return an assumed-role ARN for a role named AWSReservedSSO_ReadOnly_ plus a unique suffix, the role IAM Identity Center creates in the account.
  3. Joiner: Add a test user to the IdP group; after the next sync (Entra runs every 40 minutes for this app, or use Provision on demand) the user appears in Identity Center with the group membership.
  4. Leaver: Remove the user from the group or disable them in the IdP; confirm in Identity Center that the user is disabled or loses the membership and can no longer start a portal session.
  5. Audit: In CloudTrail, look for CreateUser and group events from the SCIM service and the federated sign-in events for your test user.

Frequently asked questions

How do I integrate IAM with AWS, Azure and GCP?
Pick one workforce identity provider and federate each cloud to it. For AWS that means IAM Identity Center with SAML and SCIM from Entra ID or Okta, Azure uses Entra ID natively, and Google Cloud uses Workforce Identity Federation or Cloud Identity federation to the same IdP.
Is there one SSO that integrates with AWS, GCP and Azure?
Yes. Microsoft Entra ID and Okta both ship gallery or catalog apps for AWS IAM Identity Center and can federate Google Cloud, and Entra ID is already the identity plane for Azure. Users get one sign-in while each cloud keeps its own authorization model.
Do groups come over SAML or SCIM in IAM Identity Center?
Groups and users come from SCIM provisioning. SAML only authenticates the user at sign-in and cannot be queried for users or groups, so you must provision them before you can assign them to AWS accounts.
How long is the IAM Identity Center SCIM access token valid?
AWS generates SCIM access tokens with a validity of one year and starts reminding you in the console and the AWS Health Dashboard when 90 days or less remain. If the token expires, provisioning stops until you rotate it.
Why does SAML sign-in fail after SCIM provisioning works?
The SAML NameID your IdP sends must equal the value you map to Username in SCIM. If one sends the UPN and the other sends an email or a different format, IAM Identity Center cannot match the user and sign-in fails.
Last reviewed By SWI Community TeamSuggest a correctionHow we research
Free to read and use. Code is illustrative, vendor-neutral, and built on the open standards. Review it against your provider's docs and your threat model before shipping. See more in the recipes index and the standards library.