Microsoft Entra ID + AWS IAM Identity Center integration
Set up Microsoft Entra ID as the identity provider for AWS IAM Identity Center via SAML + SCIM — so AWS uses Entra ID as the external identity source.
- Entra ID Application Administrator
- AWS IAM Identity Center enabled
1. Create a new SAML 2.0 application in Entra ID
In the Entra ID admin console, create a new SAML 2.0 application. Choose "Web Application" type. Note the placeholders for ACS URL + Entity ID — you'll get these from AWS IAM Identity Center in step 3.
2. Get the SAML metadata URL from Entra ID
Entra ID exposes the IdP metadata at a stable URL. Copy this URL — you'll paste it into AWS IAM Identity Center's SSO configuration. Alternatively, download the metadata XML if AWS IAM Identity Center doesn't support URL-based metadata.
3. Configure SSO in AWS IAM Identity Center
In AWS IAM Identity Center's admin → security → SSO settings, paste the Entra ID metadata URL (or upload the XML). AWS IAM Identity Center will display the ACS URL + Entity ID it expects — copy these.
4. Return to Entra ID + complete the SAML app config
Paste AWS IAM Identity Center's ACS URL into the Entra ID app's Single Sign-On URL field. Paste the Entity ID into the Audience URI field. Set the NameID format to EmailAddress (or persistent if AWS IAM Identity Center expects that).
5. Configure attribute mapping
Map the attributes the SP expects (see the Attribute Mapping section below). At minimum, email is required. Most apps also expect firstName + lastName.
6. Assign users + groups
In Entra ID, assign the SAML app to users or groups that should have access. Test with a pilot group before broad rollout.
7. Test end-to-end
Sign in to AWS IAM Identity Center via the IdP-initiated link (from Entra ID dashboard) AND via SP-initiated (direct AWS IAM Identity Center login URL). Both should work. Check the SAML Tracer browser extension or SAML decoder to inspect the assertion if anything fails.
What flows from where.
| Source (Microsoft Entra ID) | Target (AWS IAM Identity Center) | Note |
|---|---|---|
| user.mail | NameID | — |
| user.mail | — | |
| user.givenName | givenName | — |
| user.surname | familyName | — |
- Clock skew: Entra ID and AWS IAM Identity Center clocks must be within ~5 minutes. NTP-sync both. SAML's NotBefore + NotOnOrAfter are strict.
- NameID format mismatches are the most common failure. AWS IAM Identity Center typically wants EmailAddress; Entra ID defaults vary. Mismatch → cryptic "invalid assertion" errors.
- Just-in-time (JIT) provisioning vs SCIM: many apps support both. SAML JIT creates the user on first SSO; SCIM creates them ahead of time. Pick one — both can cause attribute drift.
- Audience restriction: AWS IAM Identity Center's expected Audience URI must match exactly what the IdP sends. Trailing slashes + protocol (http vs https) matter.
- Signed Response vs signed Assertion: many SPs require the Assertion to be signed (not just the Response envelope). Check the SP's docs.
- Entra ID Conditional Access on the AWS app must allow the trusted IPs AWS uses for SCIM provisioning — otherwise SCIM may fail silently.
- Once IAM Identity Center is federated, you can't create AWS users locally — they all flow from Entra. Plan the migration carefully.
- IdP-initiated SSO works (sign in from the IdP dashboard)
- SP-initiated SSO works (visit AWS IAM Identity Center directly + get redirected to IdP)
- User attributes flow through correctly (email, name, groups)
- Logout (single logout if supported) works as expected
- Step-up MFA fires when policy requires it
- Unauthorized users (not assigned to the app) get a clean denied message
- Capture a successful SAML response and inspect it (use the SAML decoder tool)
For the latest vendor-side configuration changes, refer to:
Entra ID + AWS IAM Identity Center →