# Manage your identity source Your identity source in IAM Identity Center defines where your users and groups are managed. After you configure your identity source, you can look up users or groups to grant them single sign-on access to AWS accounts, applications, or both. You can have only one identity source per organization in AWS Organizations. You can choose one of the following as your identity source: + **[External identity provider](manage-your-identity-source-idp.md) –** Choose this option if you want to manage users in an external identity provider (IdP) such as Okta or Microsoft Entra ID. + **[Your on premises or AWS managed Active Directory](manage-your-identity-source-ad.md) –** Choose this option if you want to connect your Active Directory (AD). + **[Identity Center directory](manage-your-identity-source-sso.md) –** When you enable IAM Identity Center for the first time, it is automatically configured with an Identity Center directory as your default identity source unless you choose a different identity source. With the Identity Center directory, you create your users and groups, and assign their level of access to your AWS accounts and applications. **Note** IAM Identity Center does not support SAMBA4-based Simple AD as an identity source. **Topics** + [Considerations for changing your identity source](manage-your-identity-source-considerations.md) + [Change your identity source](manage-your-identity-source-change.md) + [Supported user and group attributes in IAM Identity Center](manage-your-identity-source-attribute-use.md) + [External identity providers](manage-your-identity-source-idp.md) + [Microsoft AD directory](manage-your-identity-source-ad.md) # Considerations for changing your identity source Although you can change your identity source at any time, we recommend that you consider how this change might affect your current deployment. If you are already managing users and groups in one identity source, changing to a different identity source might remove all user and group assignments that you configured in IAM Identity Center. If this occurs, all users, including the administrative user in IAM Identity Center, will lose single sign-on access to their AWS accounts and applications. Before you change the identity source for IAM Identity Center, review the following considerations before you proceed. If you want to proceed with changing your identity source, see [Change your identity source](manage-your-identity-source-change.md) for more information. ## Changing between IAM Identity Center directory and Active Directory If you are already managing users and groups in Active Directory, we recommend that you consider connecting your directory when you enable IAM Identity Center and choose your identity source. Do this before you create any users and groups in the default Identity Center directory and make any assignments. **Important** When changing your identity source type in IAM Identity Center to or from Active Directory be aware that the Identity Store ID will change. This can have the following implications: Your default AWS access portal URL will change. You will need to communicate the new URL to your workforce and update bookmarks, gatewall or firewall allow-lists, and configurations where this URL is referenced. We recommend you perform this change in a scheduled maintenance window to minimize disruption to your users. If you are using a customer managed KMS key for encryption at rest in IAM Identity Center, and have configured the KMS key policy with the encryption context, be aware that the encryption context for the Identity Store will change. For instance, in the Identity Store ARN "arn:aws:identitystore::123456789012:identitystore/d-922763e9b3", "d-922763e9b3" is the Identity Store ID. To prevent service disruption during this transition, temporarily modify your KMS key policy to use a wildcard pattern: "arn:aws:identitystore::123456789012:identitystore/\$1". If you are already managing users and groups in the default Identity Center directory, consider the following: + **Assignments removed and users and groups deleted** – Changing your identity source to Active Directory deletes your users and groups from the Identity Center directory. This change also removes your assignments. In this case, after you change to Active Directory, you must synchronize your users and groups from Active Directory into the Identity Center directory, and then reapply their assignments. If you choose to not use Active Directory, you must create your users and groups in the Identity Center directory, and then make assignments. + **Assignments aren't deleted when identities are deleted** – When identities are deleted in the Identity Center directory, corresponding assignments also get deleted in IAM Identity Center. However in Active Directory, when identities are deleted (either in Active Directory or the synced identities), corresponding assignments aren't deleted. + **No outbound synchronization for APIs** – If you use Active Directory as your identity source, we recommend that you use the [Create, Update, and Delete](https://docs.aws.amazon.com/singlesignon/latest/APIReference/API_Operations.html) APIs with caution. IAM Identity Center doesn't support outbound synchronization, so your identity source doesn't automatically update with the changes that you make to users or groups using these APIs. + **Access portal URL will change** – Changing your identity source between IAM Identity Center and Active Directory also changes the URL for the AWS access portal. + If users are deleted or disabled in the IAM Identity Center console using Identity Store APIs, users with active sessions can continue to access integrated applications and accounts. For information about authentication session duration and user behavior, see [Understanding authentication sessions in IAM Identity Center](authconcept.md). For information about how IAM Identity Center provisions users and groups, see [Microsoft AD directory](manage-your-identity-source-ad.md). ## Changing from IAM Identity Center to an external IdP If you change your identity source from IAM Identity Center to an external identity provider (IdP), consider the following: + **Assignments and memberships work with correct assertions** – your user assignments, group assignments, and group memberships continue to work as long as the new IdP sends the correct assertions (for example, SAML nameIDs). These assertions must match the user names and groups in IAM Identity Center. + **No outbound synchronization** – IAM Identity Center doesn't support outbound synchronization, so your external IdP will not automatically update with changes to users and groups that you make in IAM Identity Center. + **SCIM provisioning** – if you are using SCIM provisioning, changes to users and groups in your identity provider reflect only in IAM Identity Center after your identity provider sends those changes to IAM Identity Center. See [Considerations for using automatic provisioning](provision-automatically.md#auto-provisioning-considerations). + **Rollback** – you can revert your identity source back to using IAM Identity Center at any time. See [Changing from an external IdP to IAM Identity Center](#changing-from-idp-and-idc). + **Existing user sessions are revoked on session duration expiry** – Once you change your identity source to an external identity provider, active user sessions persist for the remainder of the maximum session duration configured in the console. For example, if the AWS access portal session duration is set to eight hours, and you changed the identity source in the fourth hour, active user sessions persist for an additional four hours. To revoke user sessions, see [View and end active sessions for your workforce users](end-active-sessions.md). If users are deleted or disabled in the IAM Identity Center console using Identity Store APIs, users with active sessions can continue to access integrated applications and accounts. For information about authentication session duration and user behavior, see [Understanding authentication sessions in IAM Identity Center](authconcept.md). **Note** You cannot revoke user sessions from the IAM Identity Center console after you've deleted the user. For information about how IAM Identity Center provisions users and groups, see [External identity providers](manage-your-identity-source-idp.md). ## Changing from an external IdP to IAM Identity Center If you change your identity source from an external identity provider (IdP) to IAM Identity Center, consider the following: + IAM Identity Center preserves all your assignments. + **Force password reset** – Users who had passwords in IAM Identity Center can continue signing in with their old passwords. For users who were in the external IdP and weren't in IAM Identity Center, an administrator must force a password reset. + **Existing user sessions are revoked on session duration expiry** – Once you change your identity source to IAM Identity Center, active user sessions persist for the remaining duration of the maximum session duration configured in the console. For example, if the AWS access portal session duration is eight hours, and you changed the identity source at the fourth hour, active user sessions continue to run for an additional four hours. To revoke user sessions, see [View and end active sessions for your workforce users](end-active-sessions.md). If users are deleted or disabled in the IAM Identity Center console using Identity Store APIs, users with active sessions can continue to access integrated applications and accounts. For information about authentication session duration and user behavior, see [Understanding authentication sessions in IAM Identity Center](authconcept.md). **Note** You will not be able to revoke user sessions from the IAM Identity Center console after you've deleted the user. + **Multi-Region support** – If you have replicated IAM Identity Center to additional Regions or plan to do so, you must use an external identity provider as the identity source. For more information including other prerequisites, see [Using IAM Identity Center across multiple AWS Regions](multi-region-iam-identity-center.md). For information about how IAM Identity Center provisions users and groups, see [Manage users in the Identity Center directory](manage-your-identity-source-sso.md). ## Changing from one external IdP to another external IdP If you are already using an external IdP as your identity source for IAM Identity Center and you change to a different external IdP, consider the following: + **Assignments and memberships work with correct assertions** – IAM Identity Center preserves all of your assignments. The user assignments, group assignments, and group memberships continue to work as long as the new IdP sends the correct assertions (for example, SAML nameIDs). These assertions must match the user names in IAM Identity Center when your users authenticate through the new external IdP. + **SCIM provisioning** – If you are using SCIM for provisioning into IAM Identity Center, we recommend that you review the IdP-specific information in this guide and the documentation provided by the IdP to ensure that the new provider matches users and groups correctly when SCIM is enabled. + **Existing user sessions are revoked on session duration expiry** – Once you change your identity source to different external identity provider, active user sessions persist for the remaining duration of the maximum session duration configured in the console. For example, if the AWS access portal session duration is eight hours, and you changed the identity source at the fourth hour, active user sessions persist for an additional four hours. To revoke user sessions, see [View and end active sessions for your workforce users](end-active-sessions.md). If users are deleted or disabled in the IAM Identity Center console using Identity Store APIs, users with active sessions can continue to access integrated applications and accounts. For information about authentication session duration and user behavior, see [Understanding authentication sessions in IAM Identity Center](authconcept.md). **Note** You cannot revoke user sessions from the IAM Identity Center console after you've deleted the user. For information about how IAM Identity Center provisions users and groups, see [External identity providers](manage-your-identity-source-idp.md). ## Changing between Active Directory and an external IdP If you change your identity source from an external IdP to Active Directory, or from Active Directory to an external IdP, consider the following: + **Users, groups, and assignments are deleted** – All users, groups, and assignments are deleted from IAM Identity Center. No user or group information is affected in either the external IdP or Active Directory. + **Provisioning users** – If you change to an external IdP, you must configure IAM Identity Center to provision your users. Alternatively, you must manually provision the users and groups for the external IdP before you can configure assignments. + **Create assignments and groups** – If you change to Active Directory, you must create assignments with the users and groups that are in your directory in Active Directory. + If users are deleted or disabled in the IAM Identity Center console using Identity Store APIs, users with active sessions can continue to access integrated applications and accounts. For information about authentication session duration and user behavior, see [Understanding authentication sessions in IAM Identity Center](authconcept.md). + **Multi-Region support** – If you have replicated IAM Identity Center to additional Regions or plan to do so, you must use an external identity provider as the identity source. For more information including other prerequisites, see [Using IAM Identity Center across multiple AWS Regions](multi-region-iam-identity-center.md). For information about how IAM Identity Center provisions users and groups, see [Microsoft AD directory](manage-your-identity-source-ad.md). # Change your identity source The following procedure describes how to change from a directory that IAM Identity Center provides (the default Identity Center directory) to Active Directory or an external identity provider, or the other way around. Before you proceed, review the information in [Considerations for changing your identity source](manage-your-identity-source-considerations.md). To complete this procedure, you'll need an Organization instance of IAM Identity Center. For more information, see [Organization and account instances of IAM Identity Center](identity-center-instances.md). **Warning** Depending on your current deployment, this change removes any user and group assignments that you configured in IAM Identity Center. This change will also remove permission set IAM roles from your AWS accounts. As a result, you may need to update your resource policies, and should ensure this will not disrupt your access to AWS KMS keys and Amazon EKS clusters. To learn more, see [Referencing permission sets in resource policies, Amazon EKS Cluster config maps, and AWS KMS key policies](referencingpermissionsets.md). When this occurs, all users and groups, including the administrative user in IAM Identity Center, will lose single sign-on access to their AWS accounts and applications. **To change your identity source** 1. Open the [IAM Identity Center console](https://console.aws.amazon.com/singlesignon). 1. Choose **Settings**. 1. On the **Settings** page, choose the **Identity source** tab. Choose **Actions**, and then choose **Change identity source**. 1. Under **Choose identity source**, select the source that you want to change to, and then choose **Next**. If you are changing to Active Directory, choose the available directory from the menu on the next page. **Important** Changing your identity source to or from Active Directory deletes users and groups from the Identity Center directory. This change also removes any assignments that you configured in IAM Identity Center. **Note** If you replicated IAM Identity Center to additional Regions, you won’t be able to change your identity source type. You can only replace the current external IdP with another one. To change the identity source type, you will need to remove all additional Regions first. For more information, see [Using IAM Identity Center across multiple AWS Regions](multi-region-iam-identity-center.md) If you are switching to an external identity provider, we recommend that you follow the steps in [How to connect to an external identity provider](how-to-connect-idp.md). 1. After you read the disclaimer and are ready to proceed, type **ACCEPT**. 1. Choose **Change identity source**. If you are changing your identity source to Active Directory, proceed to the next step. 1. Changing your identity source to Active Directory takes you to the **Settings** page. On the **Settings** page, do either of the following: + Choose **Start guided setup**. For information about how to complete the guided setup process, see [Guided setup](manage-sync-configurable-ADsync.md#manage-sync-guided-setup-configurable-ADsync). + In the **Identity source **section, choose **Actions**, and then choose **Manage sync** to configure your *sync scope*, the list of users and groups to sync. # Supported user and group attributes in IAM Identity Center This guide provides a reference for SCIM attribute support in IAM Identity Center. It lists which user and group attributes from the SCIM specification are supported in the IAM Identity Center identity store, and identifies specific attributes and sub-attributes that aren't supported. Attributes are pieces of information that help you define and identify individual user or group objects, such as `name`, `email`, or `members`. IAM Identity Center supports most commonly used attributes through both manual entry and automatic SCIM provisioning. + For information about the System for Cross-Domain Identity Management (SCIM) specification, see [https://tools.ietf.org/html/rfc7642](https://tools.ietf.org/html/rfc7642). + For information about manual and automatic provisioning, see [Provisioning when users come from an external IdP](manage-your-identity-source-idp.md#provisioning-when-external-idp). + For information about attribute mapping, see [Attribute mappings between IAM Identity Center and External Identity Providers directory](attributemappingsconcept.md). Because IAM Identity Center supports SCIM for automatic provisioning use cases, the Identity Center directory supports all of the same user and group attributes that are listed in the SCIM specification, with a few exceptions. The following sections describe which attributes aren't supported by IAM Identity Center. ## User objects not supported All attributes from the SCIM user schema ([https://tools.ietf.org/html/rfc7643\$1section-8.3](https://tools.ietf.org/html/rfc7643#section-8.3)) are supported in the IAM Identity Center identity store, except for the following: + `password` + `ims` + `photos` + `entitlements` + `x509Certificates` All sub-attributes for users are supported, except for the following: + `'display'` sub-attribute of any multi-valued attribute (For example, `emails` or `phoneNumbers`) + `'version'` sub-attribute of `'meta'` attribute ## Group objects not supported All attributes from the SCIM group schema ([https://tools.ietf.org/html/rfc7643\$1section-8.4](https://tools.ietf.org/html/rfc7643#section-8.4)) are supported. All sub-attributes for groups are supported, except for the following: + `'display'` sub-attribute of any multi-valued attribute (For example, members). # External identity providers With IAM Identity Center, you can connect your existing workforce identities from external identity providers (IdPs) through the Security Assertion Markup Language (SAML) 2.0 and System for Cross-Domain Identity Management (SCIM) protocols. This enables your users to sign in to the AWS access portal with their corporate credentials. They can then navigate to their assigned accounts, roles, and applications hosted in external IdPs. For example, you can connect an external IdP such as Okta or Microsoft Entra ID, to IAM Identity Center. Your users can then sign in to the AWS access portal with their existing Okta or Microsoft Entra ID credentials. To control what your users can do once they've signed in, you can assign them access permissions centrally across all the accounts and applications in your AWS organization. In addition, developers can simply sign in to the AWS Command Line Interface (AWS CLI) using their existing credentials, and benefit from automatic short-term credential generation and rotation. If you are using a self-managed directory in Active Directory or an AWS Managed Microsoft AD, see [Microsoft AD directory](manage-your-identity-source-ad.md). **Note** The SAML protocol does not provide a way to query the IdP to learn about users and groups. Therefore, you must make IAM Identity Center aware of those users and groups by provisioning them into IAM Identity Center. ## Provisioning when users come from an external IdP When using an external IdP, you must provision all applicable users and groups into IAM Identity Center before you can make any assignments to AWS accounts or applications. To do this, you can configure [Provision users and groups from an external identity provider using SCIM](provision-automatically.md) for your users and groups, or use [Manual provisioning](provision-automatically.md#provision-manually). Regardless of how you provision users, IAM Identity Center redirects the AWS Management Console, command line interface, and application authentication to your external IdP. IAM Identity Center then grants access to those resources based on policies you create in IAM Identity Center. For more information about provisioning, see [User and group provisioning](users-groups-provisioning.md#user-group-provision). **Topics** + [Provisioning when users come from an external IdP](#provisioning-when-external-idp) + [How to connect to an external identity provider](how-to-connect-idp.md) + [How to change an external identity provider's metadata in IAM Identity Center](how-to-change-idp-metadata.md) + [Using SAML and SCIM identity federation with external identity providers](other-idps.md) + [SCIM profile and SAML 2.0 implementation](scim-profile-saml.md) # How to connect to an external identity provider There are different prerequisites, considerations, and provisioning procedures for the supported external IdPs. There are step-by-step tutorials available for several IdPs: + [CyberArk](cyberark-idp.md) + [Google Workspace](gs-gwp.md) + [JumpCloud](jumpcloud-idp.md) + [Microsoft Entra ID](idp-microsoft-entra.md) + [Okta](gs-okta.md) + [OneLogin](onelogin-idp.md) + [Ping Identity](pingidentity.md) For more information on the considerations for external IdPs that IAM Identity Center supports, see [Using SAML and SCIM identity federation with external identity providers](other-idps.md). The following procedure provides a general overview of the procedure that is used with all external identity providers. **To connect to an external identity provider** 1. Open the [IAM Identity Center console](https://console.aws.amazon.com/singlesignon). 1. Choose **Settings**. 1. On the **Settings** page, choose the **Identity source** tab, and then choose **Actions > Change identity source**. 1. Under **Choose identity source**, select **External identity provider**, and then choose **Next**. 1. Under **Configure external identity provider**, do the following: 1. Under **Service provider metadata**, choose **Download metadata file** to download the metadata file and save it on your system. The IAM Identity Center SAML metadata file is required by your external identity provider. **Note** The SAML metadata file you download contains both IPv4-only and dual-stack assertion consumer service (ACS) URLs. Further, if your IAM Identity Center is replicated to additional Regions, the metadata file contains ACS URLs for each additional Region. If your external IdP has a limit on the number of ACS URLs, you will need to remove the unnecessary ACS URLs. For example, if your organization has fully adopted dual-stack endpoints and no longer uses IP4v-only ones, you can remove the latter. An alternative approach is to not use the metadata file but to copy and paste the ACS URLs into the external IdP. 1. Under **Identity provider metadata**, choose **Choose file**, and locate the metadata file that you downloaded from your external identity provider. Then upload the file. This metadata file contains the necessary public x509 certificate used to trust messages that are sent from the IdP. 1. Choose **Next**. **Important** Changing your source to or from Active Directory removes all existing user and group assignments. You must manually reapply assignments after you have successfully changed your source. 1. After you read the disclaimer and are ready to proceed, enter **ACCEPT**. 1. Choose **Change identity source**. A status message informs you that you successfully changed the identity source. # How to change an external identity provider's metadata in IAM Identity Center You can change your external identity provider's metadata which you previously supplied to the IAM Identity Center. These changes affect your users' ability to sign in and access AWS resources through IAM Identity Center. The following procedure describes how to update your external IdP's metadata that is stored in IAM Identity Center. To complete this procedure, you'll need an Organization instance of IAM Identity Center. For more information, see [Organization and account instances of IAM Identity Center](identity-center-instances.md). **To change an external identity provider's metadata** 1. Open the [IAM Identity Center console](https://console.aws.amazon.com/singlesignon). 1. Choose **Settings**. 1. On the **Settings** page, choose the **Identity source** tab. Choose **Actions** and then choose **Manage Authentication**. 1. In the **Identity provider metadata** section, choose **Edit IdP metadata**. You can make the changes to the IdP sign-in URL and or IdP issuer URL for your external IdP on this page. Choose **Save changes** when you've made all the necessary changes. # Using SAML and SCIM identity federation with external identity providers IAM Identity Center implements the following standards-based protocols for identity federation: + SAML 2.0 for user authentication + SCIM for provisioning Any identity provider (IdP) that implements these standard protocols is expected to interoperate successfully with IAM Identity Center, with the following special considerations: + **SAML** + IAM Identity Center requires a SAML nameID format of email address (that is, `urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress`). + The value of the nameID field in assertions must be an RFC 2822 ([https://tools.ietf.org/html/rfc2822](https://tools.ietf.org/html/rfc2822)) addr-spec compliant (“`name@domain.com`”) string ([https://tools.ietf.org/html/rfc2822\$1section-3.4.1](https://tools.ietf.org/html/rfc2822#section-3.4.1)). + The metadata file cannot be over 75000 characters. + The metadata must contain an entityId, X509 certificate, and SingleSignOnService as part of the sign-in URL. + An encryption key is not supported. + IAM Identity Center does not support signing SAML authentication requests that it sends to external IdPs. + The IdP has to support multiple assertion consumer service (ACS) URLs if you plan to replicate IAM Identity Center to additional Regions, and fully take advantage of the benefits of a multi-Region IAM Identity Center. For more information, see [Using IAM Identity Center across multiple AWS Regions](multi-region-iam-identity-center.md). Using a single ACS URL may affect the user experience in additional Regions. Your primary Region will continue to function normally. For more information about the user experience in additional Regions with a single ACS URL, see [Using AWS managed applications without multiple ACS URLs](multi-region-workforce-access.md#aws-app-use-without-multiple-acs-urls) and [AWS account access resiliency without multiple ACS URLs](multi-region-failover.md#account-access-resiliency-without-multiple-acs-url). + **SCIM** + The IAM Identity Center SCIM implementation is based on SCIM RFCs 7642 ([https://tools.ietf.org/html/rfc7642](https://tools.ietf.org/html/rfc7642)), 7643 ([https://tools.ietf.org/html/rfc7643](https://tools.ietf.org/html/rfc7643)), and 7644 ([https://tools.ietf.org/html/rfc7644](https://tools.ietf.org/html/rfc7644)), and the interoperability requirements laid out in the March 2020 draft of the FastFed Basic SCIM Profile 1.0 ([https://openid.net/specs/fastfed-scim-1\$10-02.html\$1rfc.section.4](https://openid.net/specs/fastfed-scim-1_0-02.html#rfc.section.4)). Any differences between these documents and the current implementation in IAM Identity Center are described in the [Supported API operations](https://docs.aws.amazon.com/singlesignon/latest/developerguide/supported-apis.html) section of the *IAM Identity Center SCIM Implementation Developer Guide*. IdPs that do not conform to the standards and considerations mentioned above are not supported. Please contact your IdP for questions or clarifications regarding the conformance of their products to these standards and considerations. If you have any issues connecting your IdP to IAM Identity Center, we recommend that you check: + AWS CloudTrail logs by filtering on the event name **ExternalIdPDirectoryLogin** + IdP-specific logs and/or debug logs + [Troubleshooting IAM Identity Center issues](troubleshooting.md) **Note** Some IdPs, such as the ones in the [IAM Identity Center identity source tutorials](tutorials.md), offer a simplified configuration experience for IAM Identity Center in the form of an “application” or “connector” built specifically for IAM Identity Center. If your IdP provides this option, we recommend that you use it, being careful to choose the item that’s built specifically for IAM Identity Center. Other items called “AWS”, “AWS federation”, or similar generic "AWS" names may use other federation approaches and/or endpoints, and may not work as expected with IAM Identity Center. # SCIM profile and SAML 2.0 implementation Both SCIM and SAML are important considerations for configuring IAM Identity Center. ## SAML 2.0 implementation IAM Identity Center supports identity federation with [SAML (Security Assertion Markup Language)](https://wiki.oasis-open.org/security) 2.0. This allows IAM Identity Center to authenticate identities from external identity providers (IdPs). SAML 2.0 is an open standard used for securely exchanging SAML assertions. SAML 2.0 passes information about a user between a SAML authority (called an identity provider or IdP), and a SAML consumer (called a service provider or SP). The IAM Identity Center service uses this information to provide federated single sign-on. Single sign-on allows users to access AWS accounts and configured applications based on their existing identity provider credentials. IAM Identity Center adds SAML IdP capabilities to your IAM Identity Center store, AWS Managed Microsoft AD, or to an external identity provider. Users can then single sign-on into services that support SAML, including the AWS Management Console and third-party applications such as Microsoft 365, Concur, and Salesforce. The SAML protocol however doesn't provide a way to query the IdP to learn about users and groups. Therefore, you must make IAM Identity Center aware of those users and groups by provisioning them into IAM Identity Center. ## SCIM profile IAM Identity Center provides support for the System for Cross-domain Identity Management (SCIM) v2.0 standard. SCIM keeps your IAM Identity Center identities in sync with identities from your IdP. This includes any provisioning, updates, and deprovisioning of users between your IdP and IAM Identity Center. For more information about how to implement SCIM, see [Provision users and groups from an external identity provider using SCIM](provision-automatically.md). For additional details about IAM Identity Center’s SCIM implementation, see the [IAM Identity Center SCIM Implementation Developer Guide](https://docs.aws.amazon.com/singlesignon/latest/developerguide/what-is-scim.html). **Topics** + [SAML 2.0 implementation](#samlfederationconcept) + [SCIM profile](#scim-profile) + [Provision users and groups from an external identity provider using SCIM](provision-automatically.md) + [Rotate SAML 2.0 certificates](managesamlcerts.md) # Provision users and groups from an external identity provider using SCIM IAM Identity Center supports automatic provisioning (synchronization) of user and group information from your identity provider (IdP) into IAM Identity Center using the System for Cross-domain Identity Management (SCIM) v2.0 protocol. When you configure SCIM synchronization, you create a mapping of your identity provider (IdP) user attributes to the named attributes in IAM Identity Center. This causes the expected attributes to match between IAM Identity Center and your IdP. You configure this connection in your IdP using your SCIM endpoint for IAM Identity Center and a bearer token that you create in IAM Identity Center. **Topics** + [Considerations for using automatic provisioning](#auto-provisioning-considerations) + [How to monitor access token expiry](#access-token-expiry) + [Generate an access token](generate-token.md) + [Enable automatic provisioning](how-to-with-scim.md) + [Delete an access token](delete-token.md) + [Disable automatic provisioning](disable-provisioning.md) + [Rotate an access token](rotate-token.md) + [Audit and reconcile auto-provisioned resources](reconcile-auto-provisioning.md) + [Manual provisioning](#provision-manually) ## Considerations for using automatic provisioning Before you begin deploying SCIM, we recommend that you first review the following important considerations about how it works with IAM Identity Center. For additional provisioning considerations, see the [IAM Identity Center identity source tutorials](tutorials.md) applicable to your IdP. + If you are provisioning a primary email address, this attribute value must be unique for each user. In some IdPs, the primary email address might not be a real email address. For example, it might be a Universal Principal Name (UPN) that only looks like an email. These IdPs may have a secondary or “other” email address that contains the user’s real email address. You must configure SCIM in your IdP to map the non-Null unique email address to the IAM Identity Center primary email address attribute. And you must map the users non-Null unique sign-in identifier to the IAM Identity Center user name attribute. Check to see whether your IdP has a single value that is both the sign-in identifier and the user’s email name. If so, you can map that IdP field to both the IAM Identity Center primary email and the IAM Identity Center user name. + For SCIM synchronization to work, every user must have a **First name**, **Last name**, **Username** and **Display name** value specified. If any of these values are missing from a user, that user will not be provisioned. + If you need to use third-party applications, you will first need to map the outbound SAML subject attribute to the user name attribute. If the third-party application needs a routable email address, you must provide the email attribute to your IdP. + SCIM provisioning and update intervals are controlled by your identity provider. Changes to users and groups in your identity provider are only reflected in IAM Identity Center after your identity provider sends those changes to IAM Identity Center. Check with your identity provider for details on the frequency of user and group updates. + Currently, multivalue attributes (such as multiple emails or phone numbers for a given user) are not provisioned with SCIM. Attempts to synchronize multivalue attributes into IAM Identity Center with SCIM will fail. To avoid failures, ensure that only a single value is passed for each attribute. If you have users with multivalue attributes, remove or modify the duplicate attribute mappings in SCIM at your IdP for the connection to IAM Identity Center. + Verify that the `externalId` SCIM mapping at your IdP corresponds to a value that is unique, always present, and least likely to change for your users. For example, your IdP might provide a guaranteed `objectId` or other identifier that’s not affected by changes to user attributes like name and email. If so, you can map that value to the SCIM `externalId` field. This ensures that your users won’t lose AWS entitlements, assignments, or permissions if you need to change their name or email. + Users who have not yet been assigned to an application or AWS account cannot be provisioned into IAM Identity Center. To synchronize users and groups, make sure that they are assigned to the application or other setup that represents your IdP’s connection to IAM Identity Center. + User deprovisioning behavior is managed by the identity provider and may vary by their implementation. Check with your identity provider for details on user deprovisioning. + After setting up automatic provisioning with SCIM for your IdP, you can no longer add or edit users in the IAM Identity Center console. If you need to add or modify a user, you must do so from your external IdP or identity source. For more information about IAM Identity Center’s SCIM implementation, see the [IAM Identity Center SCIM Implementation Developer Guide](https://docs.aws.amazon.com/singlesignon/latest/developerguide/what-is-scim.html). ## How to monitor access token expiry SCIM access tokens are generated with a validity of one year. When your SCIM access token is set to expire in 90 days or less, AWS sends you reminders in the IAM Identity Center console and over the AWS Health Dashboard to help you rotate the token. By rotating the SCIM access token before it expires, you continually secure automatic provisioning of user and group information. If the SCIM access token expires, the synchronization of user and group information from your identity provider into IAM Identity Center stops, so automatic provisioning can no longer make updates or create and delete information. Disruption to automatic provisioning may impose increased security risks and impact access to your services. The Identity Center console reminders persist until you rotate the SCIM access token and delete any unused or expired access tokens. The AWS Health Dashboard events are renewed weekly between 90 to 60 days, twice per week from 60 to 30 days, three times per week from 30 to 15 days, and daily from 15 days until the SCIM access tokens expires. # Generate an access token Use the following procedure to generate a new access token in the IAM Identity Center console. **Note** This procedure requires that you have previously enabled automatic provisioning. For more information, see [Enable automatic provisioning](how-to-with-scim.md). **To generate a new access token** 1. In the [IAM Identity Center console](https://console.aws.amazon.com/singlesignon), choose **Settings** in the left navigation pane. 1. On the **Settings** page, choose the **Identity source** tab, and then choose **Actions > Manage provisioning**. 1. On the **Automatic provisioning** page, under **Access tokens**, choose **Generate token**. 1. In the **Generate new access token** dialog box, copy the new access token and save it in a safe place. 1. Choose **Close**. # Enable automatic provisioning Use the following procedure to enable automatic provisioning of users and groups from your IdP to IAM Identity Center using the SCIM protocol. **Note** Before you begin this procedure, we recommend that you first review provisioning considerations that are applicable to your IdP. For more information, see the [IAM Identity Center identity source tutorials](tutorials.md) for your IdP. **To enable automatic provisioning in IAM Identity Center** 1. After you have completed the prerequisites, open the [IAM Identity Center console](https://console.aws.amazon.com/singlesignon). 1. Choose **Settings** in the left navigation pane. 1. On the **Settings** page, locate the **Automatic provisioning** information box, and then choose **Enable**. This immediately enables automatic provisioning in IAM Identity Center and displays the necessary SCIM endpoint and access token information. 1. In the **Inbound automatic provisioning** dialog box, copy the SCIM endpoint and access token. You'll need to paste these in later when you configure provisioning in your IdP. 1. **SCIM endpoint** - For example, https://scim.*us-east-2*.amazonaws.com/*11111111111-2222-3333-4444-555555555555*/scim/v2 1. **Access token** - Choose **Show token** to copy the value. **Warning** This is the only time where you can obtain the SCIM endpoint and access token. Ensure you copy these values before moving forward. You will enter these values to configure automatic provisioning in your IdP later in this tutorial. 1. Choose **Close**. After you complete this procedure, you must configure automatic provisioning in your IdP. For more information, see the [IAM Identity Center identity source tutorials](tutorials.md) for your IdP. # Delete an access token Use the following procedure to delete an existing access token in the IAM Identity Center console. **To to delete an existing access token** 1. In the [IAM Identity Center console](https://console.aws.amazon.com/singlesignon), choose **Settings** in the left navigation pane. 1. On the **Settings** page, choose the **Identity source** tab, and then choose **Actions > Manage provisioning**. 1. On the **Automatic provisioning** page, under **Access tokens**, select the access token you want to delete, and then choose **Delete**. 1. In the **Delete access token** dialog box, review the information, type **DELETE**, and then choose **Delete access token**. # Disable automatic provisioning Use the following procedure to disable automatic provisioning in the IAM Identity Center console. **Important** You must delete the access token before you start this procedure. For more information, see [Delete an access token](delete-token.md). **To disable automatic provisioning in the IAM Identity Center console** 1. In the [IAM Identity Center console](https://console.aws.amazon.com/singlesignon), choose **Settings** in the left navigation pane. 1. On the **Settings** page, choose the **Identity source** tab, and then choose **Actions > Manage provisioning**. 1. On the **Automatic provisioning** page, choose **Disable**. 1. In the **Disable automatic provisioning** dialog box, review the information, type **DISABLE**, and then choose **Disable automatic provisioning**. # Rotate an access token An IAM Identity Center directory supports up to two access tokens at a time. To generate an additional access token prior to any rotation, delete any expired or unused access tokens. If your SCIM access token is close to expiring, you can use the following procedure to rotate an existing access token in the IAM Identity Center console. **To rotate an access token** 1. In the [IAM Identity Center console](https://console.aws.amazon.com/singlesignon), choose **Settings** in the left navigation pane. 1. On the **Settings** page, choose the **Identity source** tab, and then choose **Actions > Manage provisioning**. 1. On the **Automatic provisioning** page, under **Access tokens**, make a note of the token ID of the token you want to rotate. 1. Follow the steps in [Generate an access token](generate-token.md) to create a new token. If you have already created the maximum number of SCIM access tokens, you will first need to delete one of the existing tokens. 1. Go to your identity provider's website and configure the new access token for SCIM provisioning, and then test connectivity to IAM Identity Center using the new SCIM access token. Once you've confirmed that provisioning is working successfully using the new token, continue to the next step in this procedure. 1. Follow the steps in [Delete an access token](delete-token.md) to delete the old access token you noted earlier. You can also use the token’s creation date as a hint for which token to remove. # Audit and reconcile auto-provisioned resources SCIM enables you to automatically provision users, groups, and group memberships from your identity source to IAM Identity Center. This guide helps you verify and reconcile these resources to maintain accurate synchronization. ## Why audit your resources? Regular auditing helps ensure your access controls remain accurate and your identity provider (IdP) stays properly synchronized with IAM Identity Center. This is particularly important for security compliance and access management. Resources you can audit: + Users + Groups + Group memberships You can use AWS Identity Store [APIs](https://docs.aws.amazon.com/singlesignon/latest/IdentityStoreAPIReference/welcome.html) or [CLI commands](https://docs.aws.amazon.com/cli/latest/reference/identitystore/) to conduct the audit and reconciliation. The following examples use AWS CLI commands. For API alternatives, refer to the [corresponding operations](https://docs.aws.amazon.com/singlesignon/latest/IdentityStoreAPIReference/API_Operations.html) in the * Identity Store API reference*. ## How to audit resources Here are examples for how to audit these resources using AWS CLI commands. Before you begin, ensure you have: + Administrator access to IAM Identity Center. + AWS CLI installed and configured. For information, see the [https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html). + Required IAM permissions for Identity Store commands. ### Step 1: List current resources You can view your current resources using the AWS CLI. **Note** When using the AWS CLI, pagination is handled automatically unless you specify `--no-paginate`. If you’re calling the API directly (for example, with an SDK or a custom script), handle the `NextToken` in the response. This ensures you retrieve all results across multiple pages. **Example for users** ``` aws identitystore list-users \ --region REGION \ --identity-store-id IDENTITY_STORE_ID ``` **Example for groups** ``` aws identitystore list-groups \ --region REGION \ --identity-store-id IDENTITY_STORE_ID ``` **Example for group memberships** ``` aws identitystore list-group-memberships \ --region REGION \ --identity-store-id IDENTITY_STORE_ID --group-id GROUP_ID ``` ### Step 2: Compare with your identity source Compare the listed resources with your identity source to identify any discrepancies, such as: + Missing resources that should be provisioned in IAM Identity Center. + Extra resources that should be removed from IAM Identity Center. **Example for users** ``` # Create missing users aws identitystore create-user \ --identity-store-id IDENTITY_STORE_ID \ --user-name USERNAME \ --display-name DISPLAY_NAME \ --name GivenName=FIRST_NAME,FamilyName=LAST_NAME \ --emails Value=EMAIL,Primary=true # Delete extra users aws identitystore delete-user \ --identity-store-id IDENTITY_STORE_ID \ --user-id USER_ID ``` **Example for groups** ``` # Create missing groups aws identitystore create-group \ --identity-store-id IDENTITY_STORE_ID \ [group attributes] # Delete extra groups aws identitystore delete-group \ --identity-store-id IDENTITY_STORE_ID \ --group-id GROUP_ID ``` **Example for group memberships** ``` # Add missing members aws identitystore create-group-membership \ --identity-store-id IDENTITY_STORE_ID \ --group-id GROUP_ID \ --member-id '{"UserId": "USER_ID"}' # Remove extra members aws identitystore delete-group-membership \ --identity-store-id IDENTITY_STORE_ID \ --membership-id MEMBERSHIP_ID ``` ## Considerations + Commands are subject to [service quotas and API throttling](limits.md#ssothrottlelimits). + When you find many differences during reconciliation, make small, gradual changes to AWS Identity Store. This helps you avoid mistakes that affect multiple users. + SCIM synchronization can override your manual changes. Check your IdP settings to understand this behavior. ## Manual provisioning Some IdPs do not have System for Cross-domain Identity Management (SCIM) support or have an incompatible SCIM implementation. In those cases, you can manually provision users through the IAM Identity Center console. When you add users to IAM Identity Center, ensure that you set the user name to be identical to the user name that you have in your IdP. At a minimum, you must have a unique email address and user name. For more information, see [Username and email address uniqueness](users-groups-provisioning.md#username-email-unique). You must also manage all groups manually in IAM Identity Center. To do this, you create the groups and add them using the IAM Identity Center console. These groups do not need to match what exists in your IdP. For more information, see [Groups](users-groups-provisioning.md#groups-concept). # Rotate SAML 2.0 certificates IAM Identity Center uses certificates to set up a SAML trust relationship between IAM Identity Center and your external identity provider (IdP). When you add an external IdP in IAM Identity Center, you must also obtain at least one public SAML 2.0 X.509 certificate from the external IdP. That certificate is usually installed automatically during the IdP SAML metadata exchange during trust creation. As an IAM Identity Center administrator, you'll occasionally need to replace older IdP certificates with newer ones. For example, you might need to replace an IdP certificate when the expiration date on the certificate approaches. The process of replacing an older certificate with a newer one is referred to as certificate rotation. **Topics** + [Rotate a SAML 2.0 certificate](rotatesamlcert.md) + [Certificate expiration status indicators](samlcertexpirationindicators.md) # Rotate a SAML 2.0 certificate You may need to import certificates periodically in order to rotate invalid or expired certificates issued by your identity provider. This helps to prevent authentication disruption or downtime. All imported certificates are automatically active. Certificates should only be deleted after ensuring that they are no longer in use with the associated identity provider. You should also consider that some IdPs might not support multiple certificates. In this case, the act of rotating certificates with these IdPs might mean a temporary service disruption for your users. Service is restored when the trust with that IdP has been successfully reestablished. Plan this operation carefully during off peak hours if possible. **Note** As a security best practice, upon any signs of compromise or mishandling of an existing SAML certificate, you should immediately remove and rotate the certificate. Rotating an IAM Identity Center certificate is a multistep process that involves the following: + Obtaining a new certificate from the IdP + Importing the new certificate into IAM Identity Center + Activating the new certificate in the IdP + Deleting the older certificate Use all of the following procedures to complete the certificate rotation process while avoiding any authentication downtime. **Step 1: Obtain a new certificate from the IdP** Go to the IdP website and download their SAML 2.0 certificate. Make sure that the certificate file is downloaded in PEM encoded format. Most providers allow you to create multiple SAML 2.0 certificates in the IdP. It is likely that these will be marked as disabled or inactive. **Step 2: Import the new certificate into IAM Identity Center** Use the following procedure to import the new certificate using the IAM Identity Center console. 1. In the [IAM Identity Center console](https://console.aws.amazon.com/singlesignon), choose **Settings**. 1. On the **Settings** page, choose the **Identity source** tab, and then choose **Actions > Manage authentication**. 1. On the **Manage SAML 2.0 certificates** page, choose **Import certificate**. 1. On the **Import SAML 2.0 certificate** dialog, choose **Choose file**, navigate to your certificate file and select it, and then choose **Import certificate**. At this point, IAM Identity Center will trust all incoming SAML messages signed from both of the certificates that you have imported. **Step 3: Activate the new certificate in the IdP** Go back to the IdP website and mark the new certificate that you created earlier as primary or active. At this point all SAML messages signed by the IdP should be using the new certificate. **Step 4: Delete the old certificate** Use the following procedure to complete the certificate rotation process for your IdP. There must always be at least one valid certificate listed, and it cannot be removed. **Note** Make sure that your identity provider is no longer signing SAML responses with this certificate before deleting it. 1. On the **Manage SAML 2.0 certificates** page, choose the certificate that you want to delete. Choose **Delete**. 1. In the **Delete SAML 2.0 certificate** dialog box, type **DELETE** to confirm, and then choose **Delete**. 1. Return to the IdP’s website and perform the necessary steps to remove the older inactive certificate. # Certificate expiration status indicators The **Manage SAML 2.0 certificates** page displays colored status indicator icons in the **Expires on** column next to each certificate in the list. The following describes the criteria that IAM Identity Center uses to determine which icon is displayed for each certificate. + **Red** – Indicates that a certificate is expired. + **Yellow** – Indicates that a certificate expires in 90 days or less. + **Green** – Indicates that a certificate is valid and remains valid for at least 90 more days. **To check the current status of a certificate** 1. In the [IAM Identity Center console](https://console.aws.amazon.com/singlesignon), choose **Settings**. 1. On the **Settings** page, choose the **Identity source** tab, and then choose **Actions > Manage authentication**. 1. On the **Manage SAML 2.0 authentication** page, under **Manage SAML 2.0 certificates**, review the status of the certificates in the list as indicated in the **Expires on** column. # Microsoft AD directory With AWS IAM Identity Center, you can connect a self-managed directory in Active Directory (AD) or a directory in AWS Managed Microsoft AD by using AWS Directory Service. This Microsoft AD directory defines the pool of identities that administrators can pull from when using the IAM Identity Center console to assign single sign-on access. After connecting your corporate directory to IAM Identity Center, you can then grant your AD users or groups access to AWS accounts, applications, or both. AWS Directory Service helps you to set up and run a standalone AWS Managed Microsoft AD directory hosted in the AWS Cloud. You can also use Directory Service to connect your AWS resources with an existing self-managed AD. To configure AWS Directory Service to work with your self-managed AD, you must first set up trust relationships to extend authentication to the cloud. IAM Identity Center uses the connection provided by Directory Service to perform pass-through authentication to the source AD instance. When you use AWS Managed Microsoft AD as your identity source, IAM Identity Center can work with users from AWS Managed Microsoft AD or from any domain connected through an AD trust. If you want to locate your users in four or more domains, users must use the `DOMAIN\user` syntax as their user name when performing sign-ins to IAM Identity Center. **Notes** As a prerequisite step, make sure your AD Connector or directory in AWS Managed Microsoft AD in Directory Service resides within your AWS Organizations management account. IAM Identity Center does not support SAMBA 4-based Simple AD as a connected directory. IAM Identity Center cannot synchronize Foreign Security Principals (FSPs). If a group in AWS Managed Microsoft AD contains members from a trusted domain as FSPs, those members will not sync. For a demonstration on the process of using Active Directory as an identity source for IAM Identity Center, see the following YouTube video: [![AWS Videos](http://img.youtube.com/vi/https://www.youtube.com/embed/OMbob_ef7J4?si=J23xw0EGkZOo8y9n/0.jpg)](http://www.youtube.com/watch?v=https://www.youtube.com/embed/OMbob_ef7J4?si=J23xw0EGkZOo8y9n) ## Considerations for using Active Directory If you want to use Active Directory as your identity source, your configuration must meet the following prerequisites: + If you are using AWS Managed Microsoft AD, you must enable IAM Identity Center in the same AWS Region where your AWS Managed Microsoft AD directory is set up. IAM Identity Center stores the assignment data in the same Region as the directory. To administer IAM Identity Center, you might need to switch to the Region where IAM Identity Center is configured. Also, note that the AWS access portal uses the same access URL as your directory. + Use an Active Directory residing in the management account: You must have an existing AD Connector or AWS Managed Microsoft AD directory set up in AWS Directory Service, and it must reside within your AWS Organizations management account. You can connect only one AD Connector directory or one directory in AWS Managed Microsoft AD at a time. If you need to support multiple domains or forests, use AWS Managed Microsoft AD. For more information, see: + [Connect a directory in AWS Managed Microsoft AD to IAM Identity Center](connectawsad.md) + [Connect a self-managed directory in Active Directory to IAM Identity Center](connectonpremad.md) + Use an Active Directory residing in the delegated admin account: If you plan to enable IAM Identity Center delegated admin and use Active Directory as your IAM Identity Center identity source, you can use an existing AD Connector or AWS Managed Microsoft AD directory set up in AWS Directory residing in the delegated admin account. If you decide to change IAM Identity Center identity source from any other source to Active Directory, or change it from Active Directory to any other source, the directory must reside in (be owned by) the IAM Identity Center delegated administrator member account if one exists; otherwise, it must be in the management account. # Connect Active Directory and specify a user If you are already using Active Directory, the following topics will help you prepare to connect your directory to IAM Identity Center. You can connect an AWS Managed Microsoft AD directory or a self-managed directory in Active Directory with IAM Identity Center. **Note** IAM Identity Center doesn't support SAMBA4-based Simple AD as an identity source. **AWS Managed Microsoft AD** 1. Review the guidance in [Microsoft AD directory](manage-your-identity-source-ad.md). 1. Follow the steps in [Connect a directory in AWS Managed Microsoft AD to IAM Identity Center](connectawsad.md). 1. Configure Active Directory to synchronize the user to whom you want to grant administrative permissions into IAM Identity Center. For more information, see [Synchronize an administrative user into IAM Identity Center](#sync-admin-user-from-ad). **Self-managed directory in Active Directory** 1. Review the guidance in [Microsoft AD directory](manage-your-identity-source-ad.md). 1. Follow the steps in [Connect a self-managed directory in Active Directory to IAM Identity Center](connectonpremad.md). 1. Configure Active Directory to synchronize the user to whom you want to grant administrative permissions into IAM Identity Center. For more information, see [Synchronize an administrative user into IAM Identity Center](#sync-admin-user-from-ad). **External IdP** 1. Review the guidance in [External identity providers](manage-your-identity-source-idp.md). 1. Follow the steps in [How to connect to an external identity provider](how-to-connect-idp.md). 1. Configure your IdP to provision users into IAM Identity Center. **Note** Before you set up automatic, group-based provisioning of all your workforce identities from your IdP into IAM Identity Center, we recommend that you sync the one user to whom you want to grant administrative permissions into IAM Identity Center. ## Synchronize an administrative user into IAM Identity Center After you connect your Active Directory to IAM Identity Center, you can specify a user to whom you want to grant administrative permissions, and then synchronize that user from your directory into IAM Identity Center. 1. Open the [IAM Identity Center console](https://console.aws.amazon.com/singlesignon). 1. Choose **Settings**. 1. On the **Settings** page, choose the **Identity source** tab, choose **Actions**, and then choose **Manage Sync**. 1. On the **Manage Sync** page, choose the **Users** tab, and then choose **Add users and groups**. 1. On the **Users** tab, under **User**, enter the exact user name and choose **Add**. 1. Under **Added Users and Groups**, do the following: 1. Confirm that the user to whom you want to grant administrative permissions is specified. 1. Select the check box to the left of the user name. 1. Choose **Submit**. 1. In the **Manage sync** page, the user that you specified appears in the **Users in sync scope** list. 1. In the navigation pane, choose **Users**. 1. On the **Users** page, it might take some time for the user that you specified to appear in the list. Choose the refresh icon to update the list of users. At this point, your user doesn't have access to the management account. You will set up administrative access to this account by creating an administrative permission set and assigning the user to that permission set. For more information, see [Create a permission set](howtocreatepermissionset.md). ## Provisioning when users come from Active Directory IAM Identity Center uses the connection provided by the Directory Service to synchronize user, group, and membership information from your source directory in Active Directory to the IAM Identity Center identity store. No password information is synchronized to IAM Identity Center, because user authentication takes place directly from the source directory in Active Directory. This identity data is used by applications to facilitate in-app lookup, authorization, and collaboration scenarios without passing LDAP activity back to the source directory in Active Directory. For more information above provisioning, see [User and group provisioning](users-groups-provisioning.md#user-group-provision). **Topics** + [Considerations for using Active Directory](#considerations-ad-identitysource) + [Connect Active Directory and specify a user](get-started-connect-id-source-ad-idp-specify-user.md) + [Provisioning when users come from Active Directory](#provision-users-from-ad) + [Connect a directory in AWS Managed Microsoft AD to IAM Identity Center](connectawsad.md) + [Connect a self-managed directory in Active Directory to IAM Identity Center](connectonpremad.md) + [Attribute mappings between IAM Identity Center and External Identity Providers directory](attributemappingsconcept.md) + [IAM Identity Center configurable AD sync](provision-users-from-ad-configurable-ADsync.md) # Connect a directory in AWS Managed Microsoft AD to IAM Identity Center Use the following procedure to connect a directory in AWS Managed Microsoft AD that is managed by AWS Directory Service to IAM Identity Center. **To connect AWS Managed Microsoft AD to IAM Identity Center** 1. Open the [IAM Identity Center console](https://console.aws.amazon.com/singlesignon). **Note** Make sure that the IAM Identity Center console is using one of the Regions where your AWS Managed Microsoft AD directory is located before you move to the next step. 1. Choose **Settings**. 1. On the **Settings** page, choose the **Identity source** tab, and then choose **Actions > Change identity source**. 1. Under **Choose identity source**, select **Active Directory**, and then choose **Next**. 1. Under **Connect active directory**, choose a directory in AWS Managed Microsoft AD from the list, and then choose **Next**. 1. Under **Confirm change**, review the information and when ready type **ACCEPT**, and then choose **Change identity source**. **Important** To specify a user in Active Directory as an administrative user in IAM Identity Center, you must first synchronize the user to whom you want to grant administrative permissions from Active Directory into IAM Identity Center. To do so, follow the steps in [Synchronize an administrative user into IAM Identity Center](get-started-connect-id-source-ad-idp-specify-user.md#sync-admin-user-from-ad). # Connect a self-managed directory in Active Directory to IAM Identity Center Users in your self-managed directory in Active Directory (AD) can also have single sign-on access to AWS accounts and applications in the AWS access portal. To configure single sign-on access for these users, you can do either of the following: + **Create a two-way trust relationship** – When two-way trust relationships are created between AWS Managed Microsoft AD and a self-managed directory in AD, users in your self-managed directory in AD can sign in with their corporate credentials to various AWS services and business applications. One-way trusts do not work with IAM Identity Center. AWS IAM Identity Center requires a two-way trust so that it has permissions to read user and group information from your domain to synchronize user and group metadata. IAM Identity Center uses this metadata when assigning access to permission sets or applications. User and group metadata is also used by applications for collaboration, like when you share a dashboard with another user or group. The trust from Directory Service for Microsoft Active Directory to your domain permits IAM Identity Center to trust your domain for authentication. The trust in the opposite direction grants AWS permissions to read user and group metadata. For more information about setting up a two-way trust, see [When to Create a Trust Relationship](http://docs.aws.amazon.com/directoryservice/latest/admin-guide/setup_trust.html) in the *AWS Directory Service Administration Guide*. **Note** In order to use AWS applications, like IAM Identity Center to read Directory Service directory users from trusted domains, the Directory Service accounts require permissions to the userAccountControl attribute on the trusted users. Without read permissions to this attribute, AWS applications are unable to determine if the account is enabled or disabled. Read access to this attribute is provided by default when a trust is created. If you deny access to this attribute (not recommended), you will break applications like Identity Center from being able to read trusted users. The solution is to specifically allow Read access to the `userAccountControl` attribute on the AWS service accounts under the AWS Reserved OU (prefixed with AWS\$1). + **Create an AD Connector** – AD Connector is a directory gateway that can redirect directory requests to your self-managed AD without caching any information in the cloud. For more information, see [Connect to a Directory](http://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_ad_connector.html) in the *AWS Directory Service Administration Guide*. The following are considerations when using AD Connector: + If you are connecting IAM Identity Center to an AD Connector directory, any future user password resets must be done from within AD. This means that users will not be able to reset their passwords from the AWS access portal. + If you use AD Connector to connect your Active Directory Domain Service to IAM Identity Center, IAM Identity Center only has access to the users and groups of the single domain to which AD Connector attaches. If you need to support multiple domains or forests, use Directory Service for Microsoft Active Directory. **Note** IAM Identity Center does not work with SAMBA4-based Simple AD directories. # Attribute mappings between IAM Identity Center and External Identity Providers directory Attribute mappings are used to map attribute types that exist in IAM Identity Center with like attributes in your external identity source such as Google Workspace, Microsoft Active Directory (AD), and Okta. IAM Identity Center retrieves user attributes from your identity source and maps them to IAM Identity Center user attributes. If your IAM Identity Center is synchronized to use an **external identity provider** (IdP), like Google Workspace, Okta, or Ping as the identity source, you'll need to map your attributes in your IdP. IAM Identity Center prefills a set of attributes for you under the **Attribute mappings** tab found on its configuration page. IAM Identity Center uses these user attributes to populate SAML assertions (as SAML attributes) that are sent to the application. These user attributes are in turn retrieved from your identity source. Each application determines the list of SAML 2.0 attributes it needs for successful single sign-on. For more information, see [Map attributes in your application to IAM Identity Center attributes](mapawsssoattributestoapp.md). IAM Identity Center also manages a set of attributes for you under the **Attribute mappings** section of your **Active Directory configuration page** if you're using Active Directory as an identity source. For more information, see [Mapping user attributes between IAM Identity Center and Microsoft AD directory](mapssoattributestocdattributes.md). ## Supported external identity provider attributes The following table lists all external identity provider (IdP) attributes supported and can be mapped to attributes you can use when configuring [Attributes for access control](attributesforaccesscontrol.md) in IAM Identity Center. When using SAML assertions, you can use whichever attributes your IdP supports. **** | Supported attributes in your IdP | | --- | | \$1\$1path:userName\$1 | | \$1\$1path:name.familyName\$1 | | \$1\$1path:name.givenName\$1 | | \$1\$1path:displayName\$1 | | \$1\$1path:nickName\$1 | | \$1\$1path:emails[primary eq true].value\$1 | | \$1\$1path:addresses[type eq "work"].streetAddress\$1 | | \$1\$1path:addresses[type eq "work"].locality\$1 | | \$1\$1path:addresses[type eq "work"].region\$1 | | \$1\$1path:addresses[type eq "work"].postalCode\$1 | | \$1\$1path:addresses[type eq "work"].country\$1 | | \$1\$1path:addresses[type eq "work"].formatted\$1 | | \$1\$1path:phoneNumbers[type eq "work"].value\$1 | | \$1\$1path:userType\$1 | | \$1\$1path:title\$1 | | \$1\$1path:locale\$1 | | \$1\$1path:timezone\$1 | | \$1\$1path:enterprise.employeeNumber\$1 | | \$1\$1path:enterprise.costCenter\$1 | | \$1\$1path:enterprise.organization\$1 | | \$1\$1path:enterprise.division\$1 | | \$1\$1path:enterprise.department\$1 | | \$1\$1path:enterprise.manager.value\$1 | ## Default mappings between IAM Identity Center and Microsoft AD The following table lists the default mappings for user attributes in IAM Identity Center to the user attributes in your Microsoft AD directory. IAM Identity Center only supports the list of attributes in the **User attribute in IAM Identity Center** column. **** | User attribute in IAM Identity Center | Maps to this attribute in your Active Directory | | --- | --- | | displayname | \$1\$1displayname\$1 | | emails[?primary].value \$1 | \$1\$1mail\$1 | | externalid | \$1\$1objectguid\$1 | | name.givenname | \$1\$1givenname\$1 | | name.familyname | \$1\$1sn\$1 | | name.middlename | \$1\$1initials\$1 | | sid | \$1\$1objectsid\$1 | | username | \$1\$1userprincipalname\$1 | \$1 The email attribute in IAM Identity Center must be unique within the directory. **** | Group attribute in IAM Identity Center | Maps to this attribute in your Active Directory | | --- | --- | | externalid | \$1\$1objectguid\$1 | | description | \$1\$1description\$1 | | displayname | \$1\$1samaccountname\$1@\$1associateddomain\$1 | **Considerations** + If you do not have any assignments for your users and groups in IAM Identity Center when you enable configurable AD sync, the default mappings in the previous tables are used. For information about how to customize these mappings, see [Configure attribute mappings for your sync](manage-sync-configure-attribute-mapping-configurable-ADsync.md). + Certain IAM Identity Center attributes cannot be modified because they are immutable and mapped by default to specific Microsoft AD directory attributes. For example, "username" is a mandatory attribute in IAM Identity Center. If you map "username" to an AD directory attribute with an empty value, IAM Identity Center will consider the `windowsUpn` value as the default value for "username". If you want to change the attribute mapping for "username" from your current mapping, confirm IAM Identity Center flows with dependency on "username" will continue to work as expected, before making the change. ## Supported Microsoft AD attributes for IAM Identity Center The following table lists all Microsoft AD directory attributes that are supported and that can be mapped to user attributes in IAM Identity Center. **** | Supported attributes in your Microsoft AD directory | | --- | | \$1\$1samaccountname\$1 | | \$1\$1description\$1 | | \$1\$1objectguid\$1 | | \$1\$1objectsid\$1 | | \$1\$1givenname\$1 | | \$1\$1sn\$1 | | \$1\$1initials\$1 | | \$1\$1mail\$1 | | \$1\$1userprincipalname\$1 | | \$1\$1displayname\$1 | | \$1\$1distinguishedname\$1 | | \$1\$1proxyaddresses[?type == "SMTP"].value\$1 | | \$1\$1proxyaddresses[?type == "smtp"].value\$1 | | \$1\$1useraccountcontrol\$1 | | \$1\$1associateddomain\$1 | **Considerations** + You can specify any combination of supported Microsoft AD directory attributes to map to a single mutable attribute in IAM Identity Center. ## Supported IAM Identity Center attributes for Microsoft AD The following table lists all IAM Identity Center attributes that are supported and that can be mapped to user attributes in your Microsoft AD directory. After you set up your application attribute mappings, you can use these same IAM Identity Center attributes to map to actual attributes used by that application. **** | Supported attributes in IAM Identity Center for Active Directory | | --- | | \$1\$1user:AD\$1GUID\$1 | | \$1\$1user:AD\$1SID\$1 | | \$1\$1user:email\$1 | | \$1\$1user:familyName\$1 | | \$1\$1user:givenName\$1 | | \$1\$1user:middleName\$1 | | \$1\$1user:name\$1 | | \$1\$1user:preferredUsername\$1 | | \$1\$1user:subject\$1 | # Mapping user attributes between IAM Identity Center and Microsoft AD directory You can use the following procedure to specify how your user attributes in IAM Identity Center should map to corresponding attributes in your Microsoft AD directory. **To map attributes in IAM Identity Center to attributes in your directory** 1. Open the [IAM Identity Center console](https://console.aws.amazon.com/singlesignon). 1. Choose **Settings**. 1. On the **Settings** page, choose the **Attributes for access control** tab, and then choose **Manage Attributes**. 1. On the **Manage attribute for access control** page, find the attribute in IAM Identity Center that you want to map and then type a value in the text box. For example, you might want to map the IAM Identity Center user attribute **`email`** to the Microsoft AD directory attribute **`${mail}`**. 1. Choose **Save changes**. # IAM Identity Center configurable AD sync IAM Identity Center configurable Active Directory (AD) sync enables you to explicitly configure the identities in Microsoft Active Directory that are automatically synchronized into IAM Identity Center and control the synchronization process. + With this sync method, you can do the following: + Control data boundaries by explicitly defining the users and groups in Microsoft Active Directory that are automatically synchronized into IAM Identity Center. You can [add users and groups](manage-sync-add-users-groups-configurable-ADsync.md) or [remove users and groups](manage-sync-remove-users-groups-configurable-ADsync.md) to change the scope of the sync at any time. + Assign synchronized users and groups single sign-on [access to AWS accounts](useraccess.md) or [access to applications](assignuserstoapp.md). The applications can be AWS managed applications or customer managed applications. + Control the synchronization process by [pausing and resuming the sync](manage-sync-pause-resume-sync-configurable-ADsync.md) as needed. This helps you regulate the load on production systems. ## Prerequisites and considerations Before you use configurable AD sync, be aware of the following prerequisites and considerations: + **Specifying users and groups in Active Directory to sync** Before you can use IAM Identity Center to assign new users and groups access to AWS accounts and to AWS managed applications or customer managed applications, you must specify the users and groups in Active Directory to sync, and then sync them into IAM Identity Center. + **Configurable AD sync** – IAM Identity Center doesn't search your domain controller directly for users and groups. Instead, you must first specify the list of users and groups to sync. You can configure this list, also known as the *sync scope*, in one of the following ways, depending on whether you have users and groups that are already synced into IAM Identity Center, or you have new users and groups that you are syncing for the first time by using configurable AD sync. + Existing users and groups: If you have users and groups that are already synced into IAM Identity Center, the sync scope in configurable AD sync is prepopulated with a list of those users and groups. To assign new users or groups, you must specifically add them to the sync scope. For more information, see [Add users and groups to your sync scope](manage-sync-add-users-groups-configurable-ADsync.md). + New users and groups: If you want to assign new users and groups access to AWS accounts and to applications, you must specify which users and groups to add to the sync scope in configurable AD sync before you can use IAM Identity Center to make the assignment. For more information, see [Add users and groups to your sync scope](manage-sync-add-users-groups-configurable-ADsync.md). + **Making assignments to nested groups in Active Directory** Groups that are members of other groups are called *nested groups* (or child groups). + **Configurable AD sync** – Using configurable AD sync to make assignments to a group in Active Directory that contains nested groups might increase the scope of users who have access to AWS accounts or to applications. In this case, the assignment applies to all users, including those in nested groups. For example, if you assign access to Group A, and Group B is a member of Group A, members of Group B also inherit this access. + **Updating automated workflows** If you have automated workflows that use the IAM Identity Center identity store API actions and IAM Identity Center assignment API actions to assign new users and groups access to accounts and to applications, and to sync them into IAM Identity Center, you must adjust those workflows by April 15, 2022 so that they function as expected with configurable AD sync. Configurable AD sync changes the order in which user and group assignment and provisioning occur, and the way in which queries are performed. + **Configurable AD sync** – Provisioning occurs first, and it is not automatically performed. Instead, you must first explicitly add users and groups to the identity store by adding them to your sync scope. For information about the recommended steps for automating your sync configuration for configurable AD sync, see [Automate your sync configuration for configurable AD sync](automate-sync-configuration-configurable-ADsync.md). **Topics** + [Prerequisites and considerations](#prerequisites-configurable-ADsync) + [How configurable AD sync works](how-it-works-configurable-ADsync.md) + [Configure attribute mappings for your sync](manage-sync-configure-attribute-mapping-configurable-ADsync.md) + [First-time Active Directory to IAM Identity Center sync setup](manage-sync-configurable-ADsync.md) + [Add users and groups to your sync scope](manage-sync-add-users-groups-configurable-ADsync.md) + [Remove users and groups from your sync scope](manage-sync-remove-users-groups-configurable-ADsync.md) + [Pause and resume your sync](manage-sync-pause-resume-sync-configurable-ADsync.md) + [Automate your sync configuration for configurable AD sync](automate-sync-configuration-configurable-ADsync.md) # How configurable AD sync works IAM Identity Center refreshes the AD-based identity data in the identity store by using the following process. To learn more about the prerequisites, see [Prerequisites and considerations](provision-users-from-ad-configurable-ADsync.md#prerequisites-configurable-ADsync). ## Creation After you connect your self-managed directory in Active Directory or your AWS Managed Microsoft AD directory that is managed by Directory Service to IAM Identity Center, you can explicitly configure the Active Directory users and groups that you want to sync into the IAM Identity Center identity store. The identities that you choose will be synchronized every three hours or so into the IAM Identity Center identity store. Depending on the size of your directory, the sync process might take longer. Groups that are members of other groups (called *nested groups* or *child groups*) are also written to the identity store. You can only assign access to new users or groups after they are synchronized into the IAM Identity Center identity store. ## Update The identity data in the IAM Identity Center identity store stays fresh by periodically reading data from the source directory in Active Directory. IAM Identity Center syncs data from your Active Directory every hour in a sync cycle by default. It may take 30 minutes to 2 hours for the data to sync into IAM Identity Center, based on the size of your Active Directory. User and group objects that are in the sync scope and their memberships are created or updated in IAM Identity Center to map to the corresponding objects in the source directory in Active Directory. For user attributes, only the subset of attributes listed in the **Attributes for access control ** section of the IAM Identity Center console are updated in IAM Identity Center. It may take one sync cycle for any attribute updates you make in Active Directory to reflect in IAM Identity Center. You can also update the subset of users and groups that you synchronize into the IAM Identity Center identity store. You can choose to add new users or groups to this subset, or remove them. Any identities that you add are synchronized at the next scheduled sync. Identities that you remove from the subset will stop being updated in the IAM Identity Center identity store. Any user who isn't synchronized for more than 28 days will be disabled in the IAM Identity Center identity store. The corresponding user objects will be automatically disabled in the IAM Identity Center identity store during the next sync cycle, unless they are part of another group that is still part of the sync scope. ## Deletion Users and groups are deleted from the IAM Identity Center identity store when the corresponding user or group objects are deleted from the source directory in Active Directory. Alternatively, you can explicitly delete user objects from the IAM Identity Center identity store by using the IAM Identity Center console. If you use the IAM Identity Center console, you must also remove the users from the sync scope to ensure that they aren't re-synced back into IAM Identity Center during the next sync cycle. You can also pause and restart synchronization at any time. If you pause synchronization for more than 28 days, all your users will be disabled. # Configure attribute mappings for your sync For more information about available attributes, see [Attribute mappings between IAM Identity Center and External Identity Providers directory](attributemappingsconcept.md). **To configure attribute mappings in IAM Identity Center to your directory** 1. Open the [IAM Identity Center console.](https://console.aws.amazon.com/singlesignon) 1. Choose **Settings**. 1. On the **Settings** page, choose the **Identity source** tab, choose **Actions**, and then choose **Manage Sync**. 1. Under **Manage Sync**, choose **View attribute mapping**. 1. Under **Active Directory user attributes**, configure **IAM Identity Center identity store attributes** and **Active Directory user attributes**. For example, you might want to map the IAM Identity Center identity store attribute `email` to the Active Directory user directory attribute `${objectguid}`. **Note** Under **Group attributes**, **IAM Identity Center identity store attributes** and **Active Directory group attributes** cannot be changed. 1. Choose **Save changes**. This returns you to the **Manage Sync** page. # First-time Active Directory to IAM Identity Center sync setup If you are synchronizing your users and groups from Active Directory into IAM Identity Center for the first time, follow these steps. Alternatively, you can follow steps outlined in [Change your identity source](manage-your-identity-source-change.md) to change your identity source from IAM Identity Center to Active Directory. ## Guided setup 1. Open the [IAM Identity Center console](https://console.aws.amazon.com/singlesignon). **Note** Make sure that the IAM Identity Center console is using one of the AWS Regions where your AWS Managed Microsoft AD directory is located before you move to the next step. 1. Choose **Settings**. 1. At the top of the page, in the notification message, choose **Start guided setup**. 1. In **Step 1 – *optional*: Configure attribute mappings**, review the default user and group attribute mappings. If no changes are required, choose **Next**. If changes are required, make the changes, and then choose **Save changes**. 1. In **Step 2 – *optional*: Configure sync scope**, choose the **Users** tab. Then, enter the exact username of the user that you want to add to your sync scope and choose **Add**. Next, choose the **Groups** tab. Enter the exact group name of the group that you want to add to your sync scope and choose **Add**. Then, choose **Next**. If you want to add users and groups to your sync scope later, make no changes and choose **Next**. 1. In **Step 3: Review and save configuration**, confirm your **Attribute mappings** in **Step 1: Attribute mappings** and your **Users and groups** in **Step 2: Sync scope**. Choose **Save configuration**. This takes you to the **Manage Sync** page. # Add users and groups to your sync scope **Note** When adding groups to your sync scope, sync groups directly from the trusted on-premises domain rather than from groups in the AWS Managed Microsoft AD domain. Groups synced directly from the trusted domain contain actual user objects that IAM Identity Center can access and synchronize successfully. Add your Active Directory users and groups to IAM Identity Center by following these steps. **To add users** 1. Open the [IAM Identity Center console.](https://console.aws.amazon.com/singlesignon) 1. Choose **Settings**. 1. On the **Settings** page, choose the **Identity source** tab, choose **Actions**, and then choose **Manage Sync**. 1. On the **Manage Sync** page, choose the **Users** tab, and then choose **Add users and groups**. 1. On the **Users** tab, under **User**, enter the exact user name and choose **Add**. 1. Under **Added Users and Groups**, review the user that you want to add. 1. Choose **Submit**. 1. In the navigation pane, choose **Users**. If the user that you specified doesn't display in the list, choose the refresh icon to update the list of users. **To add groups** 1. Open the [IAM Identity Center console.](https://console.aws.amazon.com/singlesignon) 1. Choose **Settings**. 1. On the **Settings** page, choose the **Identity source** tab, choose **Actions**, and then choose **Manage Sync**. 1. On the **Manage Sync** page, choose the **Groups** tab, and then choose **Add users and groups**. 1. Choose the **Groups** tab. Under **Group**, enter the exact group name and choose **Add**. 1. Under **Added Users and Groups**, review the group that you want to add. 1. Choose **Submit**. 1. In the navigation pane, choose **Groups**. If the group that you specified doesn't display in the list, choose the refresh icon to update the list of groups. # Remove users and groups from your sync scope For more information about what happens when you remove users and groups from your sync scope, see [How configurable AD sync works](how-it-works-configurable-ADsync.md). **To remove users** 1. Open the [IAM Identity Center console.](https://console.aws.amazon.com/singlesignon) 1. Choose **Settings**. 1. On the **Settings** page, choose the **Identity source** tab, choose **Actions**, and then choose **Manage Sync**. 1. Choose the **Users** tab. 1. Under **Users in sync scope**, select the check box beside the user that you want to delete. To delete all users, select the check box beside **Username**. 1. Choose **Remove**. **To remove groups** 1. Open the [IAM Identity Center console.](https://console.aws.amazon.com/singlesignon) 1. Choose **Settings**. 1. On the **Settings** page, choose the **Identity source** tab, choose **Actions**, and then choose **Manage Sync**. 1. Choose the **Groups** tab. 1. Under **Groups in sync scope**, select the check box beside the user that you want to delete. To delete all groups, select the check box beside **Group name**. 1. Choose **Remove**. # Pause and resume your sync Pausing your sync pauses all future sync cycles and prevents any changes that you make to users and groups in Active Directory from being reflected in IAM Identity Center. After you resume the sync, the sync cycle picks up these changes from the next scheduled sync. **To pause your sync** 1. Open the [IAM Identity Center console.](https://console.aws.amazon.com/singlesignon) 1. Choose **Settings**. 1. On the **Settings** page, choose the **Identity source** tab, choose **Actions**, and then choose **Manage Sync**. 1. Under **Manage Sync**, choose **Pause sync**. **To resume your sync** 1. Open the [IAM Identity Center console.](https://console.aws.amazon.com/singlesignon) 1. Choose **Settings**. 1. On the **Settings** page, choose the **Identity source** tab, choose **Actions**, and then choose **Manage Sync**. 1. Under **Manage Sync**, choose **Resume sync**. **Note** If you see **Pause sync** instead of **Resume sync**, the sync from Active Directory to IAM Identity Center has already resumed. # Automate your sync configuration for configurable AD sync To ensure that your automated workflow works as expected with configurable AD sync, we recommend that you perform the following steps to automate your sync configuration. **To automate your sync configuration for configurable AD sync** 1. In Active Directory, create a *parent sync group* to contain all users and groups that you want to sync into IAM Identity Center. For example, you can name the group *IAMIdentityCenterAllUsersAndGroups*. 1. In IAM Identity Center, add the parent sync group to your configurable sync list. IAM Identity Center will synchronize all users, groups, sub-groups, and members of all groups contained within the parent sync group. 1. Use the Active Directory user and group management API actions provided by Microsoft to add or remove users and groups from the parent sync group.