SCIM

SCIM (System for Cross-domain Identity Management) is a standard protocol for exchanging user identity information between an identity provider and an application. In AWS, it is how users and groups from an external identity provider are kept in step with IAM Identity Center automatically.

flowchart LR subgraph Corp["Corporate environment"] AD[Active Directory] IdP["Identity provider<br/>Entra ID, Okta, Ping"] AD --> IdP end subgraph AWS["AWS Cloud"] IC[IAM Identity Center] subgraph Accounts["Organization accounts"] ACC1[Account 1] ACC2[Account 2] ACC3[Account N] end end IdP -->|1. SCIM provisioning of users and groups| IC IdP <-->|2. SAML authentication| IC IC -->|3. Permission sets| ACC1 IC -->|3. Permission sets| ACC2 IC -->|3. Permission sets| ACC3

The problem it solves

Without SCIM, every change is made twice. A new joiner needs an account in the corporate directory and again in AWS. A leaver has to be deactivated in both. A change of team means editing group membership in two places. The result is predictable: AWS access outlives employment, and someone eventually finds an active account belonging to a person who left eighteen months ago.

With SCIM, the identity provider pushes changes as they happen. Users are created and deactivated automatically, group memberships follow, and access in AWS reflects the corporate directory without anyone maintaining it.

How it works in IAM Identity Center

1. Automatic provisioning is enabled in IAM Identity Center, which generates a SCIM endpoint URL and a bearer access token.
2. Those two values are configured in the identity provider’s provisioning settings.
3. The identity provider pushes creates, updates and deletes to the endpoint on its own schedule — the interval is controlled by the provider, not by AWS.
4. Permission sets assigned to a group apply automatically to whoever is in that group.

Requirements and constraints worth knowing before starting:

• Every user must have a first name, last name, username and display name, or they are not provisioned.
• The primary email address must be unique, and must be a real address if a third-party application needs one.
• The attribute sent as the SAML NameID must be the same attribute mapped to Username in the SCIM configuration, or sign-in fails.
• Multi-valued attributes — several email addresses or phone numbers for one user — are not provisioned and will fail the synchronisation.
• Map externalId to a stable identifier such as an object ID, not to a name or email, so that a rename does not detach a user from their entitlements.
• Users who are not assigned to the application representing the IAM Identity Center connection are not provisioned at all.
• Once SCIM is enabled, users can no longer be added or edited in the IAM Identity Center console; changes are made in the identity provider.

Access tokens are valid for one year. AWS warns through the console and the AWS Health Dashboard from 90 days out. If the token expires, provisioning stops silently — new joiners do not appear and leavers keep their access — so rotating it is a scheduled task, not an optional one.

Providers that cannot do SCIM

Not every identity provider supports SCIM, or supports it compatibly. Active Directory Federation Services (AD FS), Shibboleth and F5 either have no SCIM implementation or an incompatible one. Where one of those is the provider, the options are:

• Use Active Directory directly as the IAM Identity Center identity source, through AWS Managed Microsoft AD or AD Connector, in which case SCIM is not involved at all;
• Provision users and groups manually in the IAM Identity Center console, keeping usernames identical to those in the provider; or
• Put a provider that does support SCIM — Entra ID, Okta — in front of the directory, and federate through it.

Why it matters

The security value is not convenience. It is that deprovisioning happens at the moment employment ends rather than at the next access review, which closes the window in which a departed employee still holds working credentials.