# IAM Identity Center identity source tutorials
You can connect your existing identity source in your AWS Organizations management account to [an organization instance of IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html). If you do not have an existing identity provider, you can create and manage users directly in the default IAM Identity Center directory. You can have one identity source per organization.
The tutorials in this section describe how to set up an organization instance of IAM Identity Center with a commonly used identity source, create an administrative user, and if you are using IAM Identity Center to manage access to AWS accounts, create and configure permission sets. If you’re using IAM Identity Center for application access only, you do not need to use permission sets.
These tutorials do not describe how to set up account instances of IAM Identity Center. You can use account instances to assign users and groups to applications, but you cannot use this instance type to manage user access to AWS accounts. For more information, see [Account instances of IAM Identity Center](account-instances-identity-center.md).
**Note**
Before starting any of these tutorials, enable IAM Identity Center. For more information, see [Enable IAM Identity Center](enable-identity-center.md).
**Topics**
+ [
# Using Active Directory as an identity source
](gs-ad.md)
+ [
# Setting up SCIM provisioning between CyberArk and IAM Identity Center
](cyberark-idp.md)
+ [
# Configure SAML and SCIM with Google Workspace and IAM Identity Center
](gs-gwp.md)
+ [
# Using IAM Identity Center to connect with your JumpCloud Directory Platform
](jumpcloud-idp.md)
+ [
# Configure SAML and SCIM with Microsoft Entra ID and IAM Identity Center
](idp-microsoft-entra.md)
+ [
# Configure SAML and SCIM with Okta and IAM Identity Center
](gs-okta.md)
+ [
# Setting up SCIM provisioning between OneLogin and IAM Identity Center
](onelogin-idp.md)
+ [
# Using Ping Identity products with IAM Identity Center
](pingidentity.md)
+ [
# Configure user access with the default IAM Identity Center directory
](quick-start-default-idc.md)
+ [
## Video tutorials
](#w2aac15c31)
# Using Active Directory as an identity source
If you are managing users in either your AWS Managed Microsoft AD directory using Directory Service or your self-managed directory in Active Directory (AD), you can change your IAM Identity Center identity source to work with those users. We recommend that you consider connecting this identity source when you enable IAM Identity Center and choose your identity source. Doing this before you create any users and groups in the default Identity Center directory will help you avoid the additional configuration that is required if you change your identity source later.
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 administrator account:
If you plan to enable an IAM Identity Center delegated administrator 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 the 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.
This tutorial guides you through the basic set up for using Active Directory as an IAM Identity Center identity source.
# Step 1: 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.
**Note**
If you plan to connect an AWS Managed Microsoft AD directory or a self-managed directory in Active Directory and you are not using RADIUS MFA with AWS Directory Service, enable MFA in IAM Identity Center.
**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](get-started-connect-id-source-ad-idp-specify-user.md#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](get-started-connect-id-source-ad-idp-specify-user.md#sync-admin-user-from-ad).
## Step 2: Synchronize an administrative user into IAM Identity Center
After you connect your 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 username 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 username.
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).
# Setting up SCIM provisioning between CyberArk and IAM Identity Center
IAM Identity Center supports automatic provisioning (synchronization) of user information from CyberArk Directory Platform into IAM Identity Center. This provisioning uses the System for Cross-domain Identity Management (SCIM) v2.0 protocol. For more information, see [Using SAML and SCIM identity federation with external identity providers](other-idps.md).
Before you begin deploying SCIM, we recommend that you first review the [Considerations for using automatic provisioning](provision-automatically.md#auto-provisioning-considerations). Then continue reviewing additional considerations in the next section.
**Topics**
+ [
## Prerequisites
](#cyberark-prereqs)
+ [
## SCIM considerations
](#cyberark-considerations)
+ [
## Step 1: Enable provisioning in IAM Identity Center
](#cyberark-step1)
+ [
## Step 2: Configure provisioning in CyberArk
](#cyberark-step2)
+ [
## (Optional) Step 3: Configure user attributes in CyberArk for access control (ABAC) in IAM Identity Center
](#cyberark-step3)
+ [
## (Optional) Passing attributes for access control
](#cyberark-passing-abac)
## Prerequisites
You will need the following before you can get started:
+ CyberArk subscription or free trial. To sign up for a free trial visit [https://www.cyberark.com/try-buy/](https://www.cyberark.com/try-buy/).
+ An IAM Identity Center enabled account ([free](https://aws.amazon.com/single-sign-on/)). For more information, see [ Enable IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/setup-enable-idc.html).
+ A SAML connection from your CyberArk account to IAM Identity Center, as described in [CyberArk documentation for IAM Identity Center](https://docs.cyberark.com/identity/Latest/en/Content/Applications/AppsWeb/AWS_SAML_SSO.htm#).
+ Associate the IAM Identity Center connector with the roles, users and organizations you want to allow access to AWS accounts.
## SCIM considerations
The following are considerations when using CyberArk federation for IAM Identity Center:
+ Only roles mapped in the application Provisioning section will be synchronized to IAM Identity Center.
+ The provisioning script is supported only in its default state, once changed the SCIM provisioning might fail.
+ Only one phone number attribute can be synchronized and the default is “work phone”.
+ If the role mapping in CyberArk IAM Identity Center application is changed, the below behavior is expected:
+ If the role names are changed - no changes to the group names in IAM Identity Center.
+ If the group names are changed - new groups will be created in IAM Identity Center, old groups will remain but will have no members.
+ User synchronization and de-provisioning behavior can be set up from the CyberArk IAM Identity Center application, make sure you set up the right behavior for your organization. These are the options you have:
+ Overwrite (or not) users in Identity Center directory with the same principal name.
+ De-provision users from IAM Identity Center when the user is removed from the CyberArk role.
+ De-provision user behavior - disable or delete.
## Step 1: Enable provisioning in IAM Identity Center
In this first step, you use the IAM Identity Center console to enable automatic provisioning.
**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**.
Now that you have set up provisioning in the IAM Identity Center console, you need to complete the remaining tasks using the CyberArk IAM Identity Center application. These steps are described in the following procedure.
## Step 2: Configure provisioning in CyberArk
Use the following procedure in the CyberArk IAM Identity Center application to enable provisioning with IAM Identity Center. This procedure assumes that you have already added the CyberArk IAM Identity Center application to your CyberArk admin console under **Web Apps**. If you have not yet done so, refer to the [Prerequisites](#cyberark-prereqs), and then complete this procedure to configure SCIM provisioning.
**To configure provisioning in CyberArk**
1. Open the CyberArk IAM Identity Center application that you added as part of configuring SAML for CyberArk (**Apps > Web App**). See [Prerequisites](#cyberark-prereqs).
1. Choose the **IAM Identity Center** application and go to the **Provisioning** section.
1. Check the box for **Enable provisioning for this application** and choose **Live Mode**.
1. In the previous procedure, you copied the **SCIM endpoint** value from IAM Identity Center. Paste that value into the **SCIM Service URL** field, in the CyberArk IAM Identity Center application set the **Authorization Type** to be **Authorization Header**.
1. Set the **Header Type** to **Bearer Token**.
1. From the previous procedure you copied the **Access token** value in IAM Identity Center. Paste that value into the **Bearer Token** field in the CyberArk IAM Identity Center application.
1. Click **Verify** to test and apply the configuration.
1. Under the **Sync Options**, choose the right behavior for which you want the outbound provisioning from CyberArk to work. You can choose to overwrite (or not) existing IAM Identity Center users with similar principal name, and the de-provisioning behavior.
1. Under **Role Mapping** set up the mapping from CyberArk roles, under the **Name** field to the IAM Identity Center group, under the **Destination Group**.
1. Click **Save** at the bottom once you are done.
1. To verify that users have been successfully synchronized to IAM Identity Center, return to the IAM Identity Center console and choose **Users**. Synchronized users from CyberArk will appear on the **Users** page. These users can now be assigned to accounts and can connect within IAM Identity Center.
## (Optional) Step 3: Configure user attributes in CyberArk for access control (ABAC) in IAM Identity Center
This is an optional procedure for CyberArk should you choose to configure attributes for IAM Identity Center to manage access to your AWS resources. The attributes that you define in CyberArk are passed in a SAML assertion to IAM Identity Center. You then create a permission set in IAM Identity Center to manage access based on the attributes you passed from CyberArk.
Before you begin this procedure, you must first enable the [Attributes for access control](attributesforaccesscontrol.md) feature. For more information about how to do this, see [Enable and configure attributes for access control](configure-abac.md).
**To configure user attributes in CyberArk for access control in IAM Identity Center**
1. Open the CyberArk IAM Identity Center application that you installed as part of configuring SAML for CyberArk (**Apps > Web Apps**).
1. Go to the **SAML Response** option.
1. Under **Attributes**, add the relevant attributes to the table following the below logic:
1. **Attribute Name** is the original attribute name from CyberArk.
1. **Attribute Value** is the attribute name sent in the SAML assertion to IAM Identity Center.
1. Choose **Save**.
## (Optional) Passing attributes for access control
You can optionally use the [Attributes for access control](attributesforaccesscontrol.md) feature in IAM Identity Center to pass an `Attribute` element with the `Name` attribute set to `https://aws.amazon.com/SAML/Attributes/AccessControl:{TagKey}`. This element allows you to pass attributes as session tags in the SAML assertion. For more information about session tags, see [Passing session tags in AWS STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_session-tags.html) in the *IAM User Guide*.
To pass attributes as session tags, include the `AttributeValue` element that specifies the value of the tag. For example, to pass the tag key-value pair `CostCenter = blue`, use the following attribute.
```
blue
```
If you need to add multiple attributes, include a separate `Attribute` element for each tag.
# Configure SAML and SCIM with Google Workspace and IAM Identity Center
If your organization is using Google Workspace you can integrate your users from Google Workspace into IAM Identity Center to give them access to AWS resources. You can achieve this integration by changing your IAM Identity Center identity source from the default IAM Identity Center identity source to Google Workspace.
**Note**
Google Workspace doesn’t currently support SAML multiple assertion consume service (ACS) URLs in the AWS IAM Identity Center application. This SAML feature is required to fully take advantage of [multi-Region support](multi-region-iam-identity-center.md) in IAM Identity Center. If you plan to replicate IAM Identity Center to additional Regions, be aware that using a single ACS URL may affect the user experience in those additional Regions. Your primary Region will continue to function normally. We recommend that you work with your IdP vendor to enable this feature. 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).
User information from Google Workspace is synchronized into IAM Identity Center using the [System for Cross-domain Identity Management (SCIM) 2.0 protocol](scim-profile-saml.md#scim-profile). For more information, see [Using SAML and SCIM identity federation with external identity providers](other-idps.md).
You configure this connection in Google Workspace using your SCIM endpoint for IAM Identity Center and an IAM Identity Center bearer token. When you configure SCIM synchronization, you create a mapping of your user attributes in Google Workspace to the named attributes in IAM Identity Center. This mapping matches the expected user attributes between IAM Identity Center and Google Workspace. To do this, you need to set up Google Workspace as an identity provider and connect with your IAM Identity Center.
**Objective**
The steps in this tutorial help guide you through establishing the SAML connection between Google Workspace and AWS. Later, you will synchronize users from Google Workspace using SCIM. To verify everything is configured correctly, after completing the configuration steps you will sign-in as a Google Workspace user and verify access to AWS resources. Note that this tutorial is based on a small Google Workspace directory test environment. Directory structures such as groups and organization units aren't included in this tutorial. After completing this tutorial, your users will be able to access the AWS access portal with your Google Workspace credentials.
**Note**
To sign up for a free trial of Google Workspace visit [https://workspace.google.com/](https://workspace.google.com/) on Google's website.
If you haven't enabled IAM Identity Center yet, see [Enable IAM Identity Center](enable-identity-center.md).
## Considerations
+ Before you configure SCIM provisioning between Google Workspace and IAM Identity Center, we recommend that you first review [Considerations for using automatic provisioning](provision-automatically.md#auto-provisioning-considerations).
+ SCIM automatic synchronization from Google Workspace is currently limited to user provisioning. Automatic group provisioning is not supported at this time. Groups can be manually created with AWS CLI Identity Store [create-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/identitystore/create-group.html) command or AWS Identity and Access Management (IAM) API [CreateGroup](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateGroup.html). Alternatively, you can use [ssosync](https://github.com/awslabs/ssosync) to synchronize Google Workspace users and groups into IAM Identity Center.
+ Every Google Workspace user must have a **First name**, **Last name**, **Username** and **Display name** value specified.
+ Each Google Workspace user has only a single value per data attribute, such as email address or phone number. Any users that have multiple values will fail to synchronize. If there are users that have multiple values in their attributes, remove the duplicate attributes before attempting to provision the user in IAM Identity Center. For example, only one phone number attribute can be synchronized, since the default phone number attribute is "work phone", use the "work phone" attribute to store the user's phone number, even if the phone number for the user is a home phone or a mobile phone.
+ Attributes are still synchronized if the user is disabled in IAM Identity Center, but still active in Google Workspace.
+ If there is an existing user in Identity Center directory with the same username and email, the user will be overwritten and synchronized using SCIM from Google Workspace.
+ There are additional considerations when changing your identity source. For more information, see [Changing from IAM Identity Center to an external IdP](manage-your-identity-source-considerations.md#changing-from-idc-and-idp).
## Step 1: Google Workspace: Configure the SAML application
1. Sign in to your **Google Admin console** using an account with super administrator privileges.
1. In the left navigation panel of your **Google Admin console**, choose **Apps** and then choose **Web and Mobile Apps**.
1. In the **Add app** dropdown list, select **Search for apps**.
1. In the search box enter **Amazon Web Services**, then select **Amazon Web Services (SAML)** app from the list.
1. On the **Google Identity Provider details - Amazon Web Services** page, you can do either of the following:
1. Download IdP metadata.
1. Copy the SSO URL, Entity ID URL, and Certificate information.
You will need either the XML file or URL information in Step 2.
1. Before moving to the next step in the Google Admin console, leave this page open and move to the IAM Identity Center console.
## Step 2: IAM Identity Center and Google Workspace: Change the IAM Identity Center identity source and setup Google Workspace as an SAML identity provider
1. Sign in to the [IAM Identity Center console](https://console.aws.amazon.com/singlesignon) using a role with administrative permissions.
1. Choose **Settings** in the left navigation pane.
1. On the **Settings** page, choose **Actions**, and then choose **Change identity source**.
+ If you haven't enabled IAM Identity Center, see [Enable IAM Identity Center](enable-identity-center.md) for more information. After enabling and accessing IAM Identity Center for the first time, you will arrive at the **Dashboard** where you can select **Choose your identity source**.
1. On the **Choose identity source** page, select **External identity provider**, and then choose **Next**.
1. The **Configure external identity provider** page opens. To complete this page and the Google Workspace page in Step 1, you will need to complete the following:
1. Under **Identity Provider metadata** section in the **IAM Identity Center** console, you will need to do either of the following:
1. Upload the **Google SAML metadata** as the **IdP SAML metadata** in the IAM Identity Center console.
1. Copy and paste the **Google SSO URL** into the **IdP Sign-in URL** field, **Google Issuer URL** into the **IdP issuer URL** field, and upload the **Google Certificate** as the **IdP certificate**.
1. After providing the Google metadata in the **Identity Provider metadata** section of the **IAM Identity Center** console, copy the **IAM Identity Assertion Consumer Service (ACS) URL** and **IAM Identity Center issuer URL**. You will need to provide these URLs in the Google Admin console in the next step.
1. Leave the page open with the IAM Identity Center console and return to the Google Admin console. You should be on the **Amazon Web Services - Service Provider details** page. Select **Continue**.
1. On the **Service provider details** page, enter the **ACS URL** and **Entity ID** values. You copied these values in the previous step and they can be found in the IAM Identity Center console.
+ Paste the **IAM Identity Center Assertion Consumer Service (ACS) URL** into the **ACS URL** field
+ Paste the **IAM Identity Center issuer URL** into the **Entity ID** field.
1. On the **Service provider details** page, complete the fields under **Name ID** as follows:
+ For **Name ID format**, select **EMAIL**
+ For **Name ID**, select **Basic Information > Primary email**
1. Choose **Continue**.
1. On the **Attribute Mapping** page, under **Attributes**, choose **ADD MAPPING**, and then configure these fields under **Google Directory attribute**:
+ For the `https://aws.amazon.com/SAML/Attributes/RoleSessionName` **app attribute**, select the field **Basic Information, Primary Email** from the **Google Directory attributes**.
+ For the `https://aws.amazon.com/SAML/Attributes/Role` **app attribute**, select any **Google Directory attributes**. A Google Directory attribute could be **Department**.
1. Choose **Finish**
1. Return to the **IAM Identity Center** console and choose **Next**. On the **Review and Confirm** page, review the information and then enter **ACCEPT** into the space provided. Choose **Change identity source.**
You are now ready to enable the Amazon Web Services app in Google Workspace so that your users can be provisioned into IAM Identity Center.
## Step 3: Google Workspace: Enable the apps
1. Return to the **Google Admin Console** and your AWS IAM Identity Center application which can be found under **Apps** and **Web and Mobile Apps**.
1. In the **User access** panel next to **User access**, choose the down arrow to expand **User access** to display the **Service status** panel.
1. In **Service status** panel, choose **ON for everyone**, and then choose **SAVE**.
**Note**
To help maintain the principle of least privilege, we recommend that after you complete this tutorial you change the **Service status** to **OFF for everyone**. Only users that need access to AWS should have the service enabled. You can use Google Workspace groups or organizational units to give user access to a particular subset of your users.
## Step 4: IAM Identity Center: Set up IAM Identity Center automatic provisioning
1. Return to the IAM Identity Center console.
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 each of the values for the following options. In Step 5 of this tutorial, you will enter these values to configure automatic provisioning in Google Workspace.
1. **SCIM endpoint** - For example,
+ IPv4`https://scim.Region.amazonaws.com/11111111111-2222-3333-4444-555555555555/scim/v2`
+ Dual-stack`https://scim.Region.api.aws/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.
1. Choose **Close**.
Now that you've set up provisioning in the IAM Identity Center console, in the next step you will configure auto provisioning in Google Workspace.
## Step 5: Google Workspace: Configure auto provisioning
1. Return to the Google Admin console and your AWS IAM Identity Center application which can be found under **Apps** and **Web and Mobile apps**. In the **Auto provisioning** section, choose **Configure auto provisioning**.
1. In the previous procedure, you copied the **Access token** value in IAM Identity Center console. Paste that value into the **Access token** field and choose **Continue**. Also, in the previous procedure, you copied the **SCIM endpoint** value in IAM Identity Center console. Paste that value into the **Endpoint URL** field and choose **Continue**.
1. Verify that all mandatory IAM Identity Center attributes (those marked with \$1) are mapped to Google Cloud Directory attributes. If not, choose the down arrow and map to the appropriate attribute. Choose **Continue**.
1. In **Provisioning scope** section, you can choose a group with your Google Workspace directory to provide access to the Amazon Web Services app. Skip this step and select **Continue**.
1. In **Deprovisioning** section, you can choose how to respond to different events that remove access from a user. For each situation you can specify the amount of time before deprovisioning begins to:
+ within 24 hours
+ after one day
+ after seven days
+ after 30 days
Each situation has a time setting for when to suspend an account's access and when to delete the account.
**Tip**
Always set more time before deleting a user's account than for suspending a user's account.
1. Choose **Finish.** You are returned to the Amazon Web Services app page.
1. In the **Auto-provisioning** section, turn on the toggle switch to change it from **Inactive** to **Active**.
**Note**
The activation slider is disabled if IAM Identity Center isn’t turned on for users. Choose **User access** and turn the app on to enable the slider.
1. In the confirmation dialog box, choose **Turn on**.
1. To verify that users are successfully synchronized to IAM Identity Center, return to the IAM Identity Center console and choose **Users**. The **Users** page lists the users from your Google Workspace directory that were created by SCIM. If users aren't listed yet, it might be that provisioning is still in process. Provisioning can take up to 24 hours, although in most cases it completes within minutes. Make sure to refresh the browser window every few minutes.
Select a user and view their details. The information should match the information in the Google Workspace directory.
**Congratulations\$1**
You have successfully set up a SAML connection between Google Workspace and AWS and have verified that automatic provisioning is working. You can now assign these users to accounts and applications in **IAM Identity Center**. For this tutorial, in the next step let's designate one of the users as the IAM Identity Center administrator by granting them administrative permissions to the management account.
## Passing attributes for access control - *Optional*
You can optionally use the [Attributes for access control](attributesforaccesscontrol.md) feature in IAM Identity Center to pass an `Attribute` element with the `Name` attribute set to `https://aws.amazon.com/SAML/Attributes/AccessControl:{TagKey}`. This element allows you to pass attributes as session tags in the SAML assertion. For more information about session tags, see [Passing session tags in AWS STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_session-tags.html) in the *IAM User Guide*.
To pass attributes as session tags, include the `AttributeValue` element that specifies the value of the tag. For example, to pass the tag key-value pair `CostCenter = blue`, use the following attribute.
```
blue
```
If you need to add multiple attributes, include a separate `Attribute` element for each tag.
## Assign access to AWS accounts
The following steps are only required to grant access to AWS accounts only. These steps are not required to grant access to AWS applications.
**Note**
To complete this step, 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).
### Step 1: IAM Identity Center: Grant Google Workspace users access to accounts
1. Return to the **IAM Identity Center** console. In the IAM Identity Center navigation pane, under **Multi-account permissions**, choose **AWS accounts**.
1. On the **AWS accounts** page the **Organizational structure** displays your organizational root with your accounts underneath it in the hierarchy. Select the checkbox for your management account, then select **Assign users or groups**.
1. The **Assign users and groups** workflow displays. It consists of three steps:
1. For **Step 1: Select users and groups** choose the user that will be performing the administrator job function. Then choose **Next**.
1. For **Step 2: Select permission sets** choose **Create permission set** to open a new tab that steps you through the three sub-steps involved in creating a permission set.
1. For **Step 1: Select permission set type** complete the following:
+ In **Permission set type**, choose **Predefined permission set**.
+ In **Policy for predefined permission set**, choose **AdministratorAccess**.
Choose **Next**.
1. For **Step 2: Specify permission set details**, keep the default settings, and choose **Next**.
The default settings create a permission set named *AdministratorAccess* with session duration set to one hour.
1. For **Step 3: Review and create**, verify that the **Permission set type** uses the AWS managed policy **AdministratorAccess**. Choose **Create**. On the **Permission sets** page a notification appears informing you that the permission set was created. You can close this tab in your web browser now.
1. On the **Assign users and groups** browser tab, you are still on **Step 2: Select permission sets** from which you started the create permission set workflow.
1. In the **Permissions sets** area, choose the **Refresh** button. The *AdministratorAccess* permission set you created appears in the list. Select the checkbox for that permission set and then choose **Next**.
1. For **Step 3: Review and submit** review the selected user and permission set, then choose **Submit**.
The page updates with a message that your AWS account is being configured. Wait until the process completes.
You are returned to the AWS accounts page. A notification message informs you that your AWS account has been reprovisioned and the updated permission set applied. When the user sign in they will have the option of choosing the *AdministratorAccess* role.
**Note**
SCIM automatic synchronization from Google Workspace only supports provisioning users. Automatic group provisioning is not supported at this time. You cannot create groups for your Google Workspace users using the AWS Management Console. After provisioning users, you can create groups using AWS CLI Identity Store [create-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/identitystore/create-group.html) command or IAM API [CreateGroup](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateGroup.html).
### Step 2: Google Workspace: Confirm Google Workspace users access to AWS resources
1. Sign in to Google using a test user account. To learn how to add users to Google Workspace, see [Google Workspace documentation](https://knowledge.workspace.google.com/kb/how-to-create-a-new-user-000007668).
1. Select the Google apps launcher (waffle) icon.
1. Scroll to the bottom of the apps list where your custom Google Workspace apps are located. The **Amazon Web Services** app is displayed.
1. Select the **Amazon Web Services** app. You are signed into the AWS access portal and can see the AWS account icon. Expand that icon to see the list of AWS accounts that the user can access. In this tutorial you only worked with a single account, so expanding the icon only shows one account.
1. Select the account to display the permission sets available to the user. In this tutorial you created the **AdministratorAccess** permission set.
1. Next to the permission set are links for the type of access available for that permission set. When you created the permission set, you specified both management console and programmatic access be enabled, so those two options are present. Select **Management console** to open the AWS Management Console.
1. The user is signed in to the console.
## Next steps
Now that you've configured Google Workspace as an identity provider and provisioned users in IAM Identity Center, you can:
+ Use the AWS CLI Identity Store [create-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/identitystore/create-group.html) command or IAM API [CreateGroup](https://docs.aws.amazon.com/singlesignon/latest/IdentityStoreAPIReference/API_CreateGroup.html) to create groups for your users.
Groups are useful when assigning access to AWS accounts and applications. Rather than assign each user individually, you give permissions to a group. Later, as you add or remove users from a group, the user dynamically gets or loses access to accounts and applications that you assigned to the group.
+ Configure permissions based on job functions, see [Create a permission sets](howtocreatepermissionset.md).
Permission sets define the level of access that users and groups have to an AWS account. Permission sets are stored in IAM Identity Center and can be provisioned to one or more AWS accounts. You can assign more than one permission set to a user.
**Note**
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. Make sure to review how to [manage the SAML certificates](managesamlcerts.md) for Google Workspace.
## Troubleshooting
For general SCIM and SAML troubleshooting with Google Workspace, see the following sections:
+ [Specific users fail to synchronize into IAM Identity Center from an external SCIM provider](troubleshooting.md#issue2)
+ [Issues regarding contents of SAML assertions created by IAM Identity Center](troubleshooting.md#issue1)
+ [Duplicate user or group error when provisioning users or groups with an external identity provider](troubleshooting.md#duplicate-user-group-idp)
+ For Google Workspace troubleshooting, see [Google Workspace documentation](https://support.google.com/a/topic/7579248?sjid=11091727091254312767-NA).
The following resources can help you troubleshoot as you work with AWS:
+ [AWS re:Post](https://repost.aws/) - Find FAQs and links to other resources to help you troubleshoot issues.
+ [AWS Support](https://aws.amazon.com/premiumsupport/) - Get technical support
# Using IAM Identity Center to connect with your JumpCloud Directory Platform
IAM Identity Center supports automatic provisioning (synchronization) of user information from JumpCloud Directory Platform into IAM Identity Center. This provisioning uses the [Security Assertion Markup Language (SAML) 2.0](scim-profile-saml.md) protocol. For more information, see [Using SAML and SCIM identity federation with external identity providers](other-idps.md).
You configure this connection in JumpCloud using your IAM Identity Center SCIM endpoint and access token. When you configure SCIM synchronization, you create a mapping of your user attributes in JumpCloud to the named attributes in IAM Identity Center. This causes the expected attributes to match between IAM Identity Center and JumpCloud.
This guide is based on JumpCloud as of June 2021. Steps for newer versions may vary. This guide contains a few notes regarding configuration of user authentication through SAML.
The following steps walk you through how to enable automatic provisioning of users and groups from JumpCloud to IAM Identity Center using the SCIM protocol.
**Note**
Before you begin deploying SCIM, we recommend that you first review the [Considerations for using automatic provisioning](provision-automatically.md#auto-provisioning-considerations). Then continue reviewing additional considerations in the next section.
**Topics**
+ [
## Prerequisites
](#jumpcloud-prereqs)
+ [
## SCIM considerations
](#jumpcloud-scim)
+ [
## Step 1: Enable provisioning in IAM Identity Center
](#jumpcloud-step1)
+ [
## Step 2: Configure provisioning in JumpCloud
](#jumpcloud-step2)
+ [
## (Optional) Step 3: Configure user attributes in JumpCloud for access control in IAM Identity Center
](#jumpcloud-step3)
+ [
## (Optional) Passing attributes for access control
](#jumpcloud-passing-abac)
## Prerequisites
You will need the following before you can get started:
+ JumpCloud subscription or free trial. To sign up for a free trial visit [https://console.jumpcloud.com/signup](https://console.jumpcloud.com/signup).
+ An IAM Identity Center enabled account ([ free](https://aws.amazon.com/single-sign-on/)). For more information, see [Enable IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/setup-enable-idc.html).
+ A SAML connection from your JumpCloud account to IAM Identity Center, as described in [JumpCloud documentation for IAM Identity Center ](https://support.jumpcloud.com/support/s/article/Single-Sign-On-SSO-With-AWS-SSO).
+ If you replicated IAM Identity Center to additional Regions, you must update your identity provider configuration to enable access to AWS managed applications and AWS accounts from those Regions. For more details, see [Step 3: Update external IdP setup](replicate-to-additional-region.md#update-external-idp-setup). See the JumpCloud documentation for additional details.
+ Associate the IAM Identity Center connector with the groups you want to allow access to AWS accounts.
## SCIM considerations
The following are considerations when using JumpCloud federation for IAM Identity Center.
+ Only groups associated with the AWS Single Sign-On connector in JumpCloud will be synchronized with SCIM.
+ Only one phone number attribute can be synchronized and the default is "work phone."
+ Users in JumpCloud directory must have first and last names configured to be synchronized to IAM Identity Center with SCIM.
+ Attributes are still synchronized if the user is disabled in IAM Identity Center but still activate in JumpCloud.
+ You can choose to enable SCIM sync for only user information by unchecking the "Enable management of User Groups and Group membership" in the connector.
## Step 1: Enable provisioning in IAM Identity Center
In this first step, you use the IAM Identity Center console to enable automatic provisioning.
**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**.
Now that you have set up provisioning in the IAM Identity Center console, you need to complete the remaining tasks using the JumpCloud IAM Identity Center connector. These steps are described in the following procedure.
## Step 2: Configure provisioning in JumpCloud
Use the following procedure in the JumpCloud IAM Identity Center connector to enable provisioning with IAM Identity Center. This procedure assumes that you have already added the JumpCloud IAM Identity Center connector to your JumpCloud admin portal and groups. If you have not yet done so, refer to [Prerequisites](#jumpcloud-prereqs), and then complete this procedure to configure SCIM provisioning.
**To configure provisioning in JumpCloud**
1. Open the JumpCloud IAM Identity Center connector that you installed as part of configuring SAML for JumpCloud (**User Authentication** > **IAM Identity Center**). See [Prerequisites](#jumpcloud-prereqs).
1. Choose the **IAM Identity Center** connector, and then choose the third tab **Identity Management**.
1. Check the box for **Enable management of User Groups and Group membership in this application** if you want groups to SCIM sync.
1. Click on **Configure**.
1. In the previous procedure, you copied the **SCIM endpoint** value in IAM Identity Center. Paste that value into the **Base URL** field in the JumpCloud IAM Identity Center connector.
1. From the previous procedure you copied the **Access token** value in IAM Identity Center. Paste that value into the **Token Key** field in the JumpCloud IAM Identity Center connector.
1. Click **Activate** to apply the configuration.
1. Make sure you have a green indicator next to **Single Sign-On activated**.
1. Move to the fourth tab **User Groups** and check the groups you want to be provisioned with SCIM.
1. Click **Save** at the bottom once you are done.
1. To verify that users have been successfully synchronized to IAM Identity Center, return to the IAM Identity Center console and choose **Users**. Synchronized users from JumpCloud appear on the **Users** page. These users can now be assigned to accounts within IAM Identity Center.
## (Optional) Step 3: Configure user attributes in JumpCloud for access control in IAM Identity Center
This is an optional procedure for JumpCloud should you choose to configure attributes for IAM Identity Center to manage access to your AWS resources. The attributes that you define in JumpCloud are passed in a SAML assertion to IAM Identity Center. You then create a permission set in IAM Identity Center to manage access based on the attributes you passed from JumpCloud.
Before you begin this procedure, you must first enable the [Attributes for access control](https://docs.aws.amazon.com/singlesignon/latest/userguide/attributesforaccesscontrol.html) feature. For more information about how to do this, see [ Enable and configure attributes for access control](https://docs.aws.amazon.com/singlesignon/latest/userguide/configure-abac.html).
****To configure user attributes in JumpCloud for access control in IAM Identity Center****
1. Open the JumpCloud IAM Identity Center connector that you installed as part of configuring SAML for JumpCloud (**User Authentication** > **IAM Identity Center**).
1. Choose the **IAM Identity Center** connector. Then, choose the second tab ** IAM Identity Center**.
1. At the bottom of this tab you have **User Attribute Mapping**, choose **Add new attribute**, and then do the following: You must perform these steps for each attribute you will add for use in IAM Identity Center for access control.
1. In the **Service Provide Attribute Name** field, enter `https://aws.amazon.com/SAML/Attributes/AccessControl: AttributeName.` Replace ` AttributeName ` with the name of the attribute you are expecting in IAM Identity Center. For example, ` https://aws.amazon.com/SAML/Attributes/AccessControl: Email ` .
1. In the **JumpCloud Attribute Name** field, choose user attributes from your JumpCloud directory. For example, **Email (Work)**.
1. Choose **Save**.
## (Optional) Passing attributes for access control
You can optionally use the [Attributes for access control](attributesforaccesscontrol.md) feature in IAM Identity Center to pass an `Attribute` element with the `Name` attribute set to `https://aws.amazon.com/SAML/Attributes/AccessControl:{TagKey}`. This element allows you to pass attributes as session tags in the SAML assertion. For more information about session tags, see [Passing session tags in AWS STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_session-tags.html) in the *IAM User Guide*.
To pass attributes as session tags, include the `AttributeValue` element that specifies the value of the tag. For example, to pass the tag key-value pair `CostCenter = blue`, use the following attribute.
```
blue
```
If you need to add multiple attributes, include a separate `Attribute` element for each tag.
# Configure SAML and SCIM with Microsoft Entra ID and IAM Identity Center
AWS IAM Identity Center supports integration with [Security Assertion Markup Language (SAML) 2.0](scim-profile-saml.md) as well as [automatic provisioning](provision-automatically.md) (synchronization) of user and group information from Microsoft Entra ID (formerly known as Azure Active Directory or Azure AD) into IAM Identity Center using the [System for Cross-domain Identity Management (SCIM) 2.0](scim-profile-saml.md#scim-profile) protocol. For more information, see [Using SAML and SCIM identity federation with external identity providers](other-idps.md).
**Objective**
In this tutorial, you will set up a test lab and configure a SAML connection and SCIM provisioning between Microsoft Entra ID and IAM Identity Center. During the initial preparation steps, you'll create a test user (Nikki Wolf) in both Microsoft Entra ID and IAM Identity Center which you'll use to test the SAML connection in both directions. Later, as part of the SCIM steps, you'll create a different test user (Richard Roe) to verify that new attributes in Microsoft Entra ID are synchronizing to IAM Identity Center as expected.
## Prerequisites
Before you can get started with this tutorial, you'll first need to set up the following:
+ A Microsoft Entra ID tenant. For more information, see [Quickstart: Set up a tenant](https://docs.microsoft.com/en-us/azure/active-directory/develop/quickstart-create-new-tenant) in Microsoft documentation.
+ An AWS IAM Identity Center-enabled account. For more information, see [Enable IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/get-started-enable-identity-center.html) in the *AWS IAM Identity Center User Guide*.
## Considerations
The following are important considerations about Microsoft Entra ID that can affect how you plan to implement [automatic provisioning](provision-automatically.md) with IAM Identity Center in your production environment using the SCIM v2 protocol.
**Automatic Provisioning**
Before you begin deploying SCIM, we recommend that you first review [Considerations for using automatic provisioning](provision-automatically.md#auto-provisioning-considerations).
**Attributes for access control**
Attributes for access control is used in permission policies that determine who in your identity source can access your AWS resources. If an attribute is removed from a user in Microsoft Entra ID, that attribute will not be removed from the corresponding user in IAM Identity Center. This is a known limitation in Microsoft Entra ID. If an attribute is changed to a different (non-empty) value on a user, that change will be synchronized to IAM Identity Center.
**Nested Groups**
The Microsoft Entra ID user provisioning service cannot read or provision users in nested groups. Only users that are immediate members of an explicitly assigned group can be read and provisioned. Microsoft Entra ID doesn't recursively unpack the group memberships of indirectly assigned users or groups (users or groups that are members of a group that is directly assigned). For more information, see [Assignment-based scoping](https://learn.microsoft.com/en-us/azure/active-directory/app-provisioning/how-provisioning-works#assignment-based-scoping) in the Microsoft documentation. Alternatively, you can use [IAM Identity Center configurable AD sync](https://aws.amazon.com/blogs//security/managing-identity-source-transition-for-aws-iam-identity-center/) to integrate Active Directory groups with IAM Identity Center.
**Dynamic Groups**
The Microsoft Entra ID user provisioning service can read and provision users in [dynamic groups](https://learn.microsoft.com/en-us/azure/active-directory/enterprise-users/groups-create-rule). See below for an example showing the users and groups structure while using dynamic groups and how they are displayed in IAM Identity Center. These users and groups were provisioned from Microsoft Entra ID into IAM Identity Center via SCIM
For example, if Microsoft Entra ID structure for dynamic groups is as follows:
1. Group A with members ua1, ua2
1. Group B with members ub1
1. Group C with members uc1
1. Group K with a rule to include members of Group A, B, C
1. Group L with a rule to include members Group B and C
After the user and group information is provisioned from Microsoft Entra ID into IAM Identity Center through SCIM, the structure will be as follows:
1. Group A with members ua1, ua2
1. Group B with members ub1
1. Group C with members uc1
1. Group K with members ua1, ua2, ub1, uc1
1. Group L with members ub1, uc1
When you configure automatic provisioning using dynamic groups, keep the following considerations in mind.
+ A dynamic group can include a nested group. However, Microsoft Entra ID provisioning service doesn’t flatten the nested group. For example, if you have the following Microsoft Entra ID structure for dynamic groups:
+ Group A is a parent of group B.
+ Group A has ua1 as a member.
+ Group B has ub1 as a member.
The dynamic group that includes Group A will only include the direct members of group A (that is, ua1). It won’t recursively include members of group B.
+ Dynamic groups can’t contain other dynamic groups. For more information, see [Preview limitations](https://learn.microsoft.com/en-us/azure/active-directory/enterprise-users/groups-dynamic-rule-member-of#preview-limitations) in the Microsoft documentation.
## Step 1: Prepare your Microsoft tenant
In this step, you will walk through how to install and configure your AWS IAM Identity Center enterprise application and assign access to a newly created Microsoft Entra ID test user.
------
#### [ Step 1.1 > ]
**Step 1.1: Set up the AWS IAM Identity Center enterprise application in Microsoft Entra ID**
In this procedure, you install the AWS IAM Identity Center enterprise application in Microsoft Entra ID. You will need this application later to configure your SAML connection with AWS.
1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com/) as at least a Cloud Application Administrator.
1. Navigate to **Identity > Applications > Enterprise applications**, and then choose **New application**.
1. On the **Browse Microsoft Entra Gallery** page, enter ****AWS IAM Identity Center**** in the search box.
1. Select **AWS IAM Identity Center** from the results.
1. Choose **Create**.
------
#### [ Step 1.2 > ]
**Step 1.2: Create a test user in Microsoft Entra ID**
Nikki Wolf is the name of your Microsoft Entra ID test user that you will create in this procedure.
1. In the [Microsoft Entra admin center](https://entra.microsoft.com/) console, navigate to **Identity > Users > All users**.
1. Select **New user**, and then choose **Create new user** at the top of the screen.
1. In **User principal name**, enter ****NikkiWolf****, and then select your preferred domain and extension. For example, *NikkiWolf*@*example.org*.
1. In **Display name**, enter ****NikkiWolf****.
1. In **Password**, enter a strong password or select the eye icon to show the password that was auto-generated, and either copy or write down the value that is displayed.
1. Choose **Properties**, in **First name**, enter ****Nikki****. In **Last name**, enter ****Wolf****.
1. Choose **Review \$1 create**, and then choose **Create**.
------
#### [ Step 1.3 ]
**Step 1.3: Test Nikki's experience prior to assigning her permissions to AWS IAM Identity Center**
In this procedure, you will verify what Nikki can successfully sign into her Microsoft [My Account portal](https://myaccount.microsoft.com/).
1. In the same browser, open a new tab, go to the [My Account portal](https://myaccount.microsoft.com/) sign-in page, and enter Nikki's full email address. For example, *NikkiWolf*@*example.org*.
1. When prompted, enter Nikki's password, and then choose **Sign in**. If this was an auto-generated password, you will be prompted to change the password.
1. On the **Action Required** page, choose **Ask later** to bypass the prompt for additional security methods.
1. On the **My account** page, in the left navigation pane, choose **My Apps**. Notice that besides **Add-ins**, no apps are displayed at this time. You'll add an **AWS IAM Identity Center** app that will appear here in a later step.
------
#### [ Step 1.4 ]
**Step 1.4: Assign permissions to Nikki in Microsoft Entra ID**
Now that you have verified that Nikki can successfully access the **My account portal**, use this procedure to assign her user to the **AWS IAM Identity Center** app.
1. In the [Microsoft Entra admin center](https://entra.microsoft.com/) console, navigate to **Identity > Applications > Enterprise applications** and then choose **AWS IAM Identity Center** from the list.
1. On the left, choose **Users and groups**.
1. Choose **Add user/group**. You can ignore the message stating that groups are not available for assignment. This tutorial does not use groups for assignments.
1. On the **Add Assignment** page, under **Users**, choose **None Selected**.
1. Select **NikkiWolf**, and then choose **Select**.
1. On the **Add Assignment** page, choose **Assign**. NikkiWolf now appears in the list of users who are assigned to the **AWS IAM Identity Center** app.
------
## Step 2: Prepare your AWS account
In this step, you'll walk through how to use **IAM Identity Center** to configure access permissions (via permission set), manually create a corresponding Nikki Wolf user, and assign her the necessary permissions to administer resources in AWS.
------
#### [ Step 2.1 > ]
**Step 2.1: Create a RegionalAdmin permission set in IAM Identity Center**
This permission set will be used to grant Nikki the necessary AWS account permissions required to manage Regions from the **Account** page within the AWS Management Console. All other permissions to view or manage any other information for Nikki's account is denied by default.
1. Open the [IAM Identity Center console](https://console.aws.amazon.com/singlesignon).
1. Under **Multi-account permissions**, choose **Permission sets**.
1. Choose **Create permission set**.
1. On the **Select permission set type** page, select **Custom permission set**, and then choose **Next**.
1. Select **Inline policy** to expand it, and then create a policy for the permission set using the following steps:
1. Choose **Add new statement** to create a policy statement.
1. Under **Edit statement**, select **Account** from the list, and then choose the following checkboxes.
+ **`ListRegions`**
+ **`GetRegionOptStatus`**
+ **`DisableRegion`**
+ **`EnableRegion`**
1. Next to **Add a resource**, choose **Add**.
1. On the **Add resource** page, under **Resource type**, select **All Resources**, and then choose **Add resource**. Verify that your policy looks like the following:
```
{
"Statement": [
{
"Sid": "Statement1",
"Effect": "Allow",
"Action": [
"account:ListRegions",
"account:DisableRegion",
"account:EnableRegion",
"account:GetRegionOptStatus"
],
"Resource": [
"*"
]
}
]
}
```
1. Choose **Next**.
1. On the **Specify permission set details** page, under **Permission set name**, enter ****RegionalAdmin****, and then choose **Next**.
1. On the **Review and create** page, choose **Create**. You should see **RegionalAdmin** displayed in the list of permission sets.
------
#### [ Step 2.2 > ]
**Step 2.2: Create a corresponding NikkiWolf user in IAM Identity Center**
Since the SAML protocol does not provide a mechanism to query the IdP (Microsoft Entra ID) and automatically create users here in IAM Identity Center, use the following procedure to manually create a user in IAM Identity Center that mirrors the core attributes from Nikki Wolfs user in Microsoft Entra ID.
1. Open the [IAM Identity Center console](https://console.aws.amazon.com/singlesignon).
1. Choose **Users**, choose **Add user**, and then provide the following information:
1. For both **Username** and **Email address** – Enter the same ****NikkiWolf**@*yourcompanydomain.extension*** that you used when creating your Microsoft Entra ID user. For example, *NikkiWolf*@*example.org*.
1. **Confirm email address** – Re-enter the email address from the previous step
1. **First name** – Enter ****Nikki****
1. **Last name** – Enter ****Wolf****
1. **Display name** – Enter ****Nikki Wolf****
1. Choose **Next** twice, then choose **Add user**.
1. Select **Close**.
------
#### [ Step 2.3 ]
**Step 2.3: Assign Nikki to the RegionalAdmin permission set in IAM Identity Center**
Here you locate the AWS account in which Nikki will administer Regions, and then assign the necessary permissions required for her to successfully access the AWS access portal.
1. Open the [IAM Identity Center console](https://console.aws.amazon.com/singlesignon).
1. Under **Multi-account permissions**, choose **AWS accounts**.
1. Select the checkbox next to the account name (for example, *Sandbox*) where you want to grant Nikki access to manage Regions, and then choose **Assign users and groups**.
1. On the **Assign users and groups** page, choose the **Users** tab, find and check the box next to Nikki, and then choose **Next**.
1.
**Example**
1. On the** Review and submit** page, review your selections and then choose **Submit**.
------
## Step 3: Configure and test your SAML connection
In this step, you configure your SAML connection using the AWS IAM Identity Center enterprise application in Microsoft Entra ID together with the external IdP settings in IAM Identity Center.
------
#### [ Step 3.1 > ]
**Step 3.1: Collect required service provider metadata from IAM Identity Center**
In this step, you will launch the **Change identity source** wizard from within the IAM Identity Center console and retrieve the metadata file and the AWS specific sign-in URL you'll need to enter when configuring the connection with Microsoft Entra ID in the next step.
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 > Change identity source**.
1. On the **Choose identity source** page, select **External identity provider**, and then choose **Next**.
1. On the **Configure external identity provider** page, under **Service provider metadata**, choose **Default IPv4** or **Dual-stack**. You can download the service provider metadata file after you complete the identity source change.
1. In the same section, locate the **AWS access portal sign-in URL** value and copy it. You will need to enter this value when prompted in the next step.
1. Leave this page open, and move to the next step (**`Step 3.2`**) to configure the AWS IAM Identity Center enterprise application in Microsoft Entra ID. Later, you'll return to this page to complete the process.
------
#### [ Step 3.2 > ]
**Step 3.2: Configure the AWS IAM Identity Center enterprise application in Microsoft Entra ID**
This procedure establishes one-half of the SAML connection on the Microsoft side using the values from the metadata file and Sign-On URL you obtained in the last step.
1. In the [Microsoft Entra admin center](https://entra.microsoft.com/) console, navigate to **Identity > Applications > Enterprise applications** and then choose **AWS IAM Identity Center**.
1. On the left, choose **2. Set up Single sign-on**.
1. On the **Set up Single Sign-On with SAML** page, choose **SAML**. Then choose **Upload metadata file**, choose the folder icon, select the service provider metadata file that you downloaded in the previous step, and then choose **Add**.
1. On the **Basic SAML Configuration** page, verify that both the **Identifier** and **Reply URL (Assertion Consumer Service URL)** values now point to endpoints in AWS.
+ **Identifier** - This is the **Issuer URL** from IAM Identity Center. The same value applies regardless of whether you use IPv4-only or dual-stack endpoints.
+ **Reply URL (Assertion Consumer Service URL)** - The values here include both IPv4-only and dual-stack endpoints from all enabled Regions of your IAM Identity Center. You can use the primary Region's ACS URL as the default one so that users are redirected to the primary Region when they launch the Amazon Web Services application from Microsoft Entra ID. For more information on ACS URLs, see [ACS endpoints in the primary and additional AWS Regions](multi-region-workforce-access.md#acs-endpoints).
+ (Optional) If you replicated IAM Identity Center to additional Regions, you can also create a bookmark app in Microsoft Entra ID for the AWS access portal in each additional Region. This enables your users to access the AWS access portal in additional Regions from Microsoft Entra ID. Make sure to grant your users permissions to access the bookmark apps in Microsoft Entra ID. See [Microsoft Entra ID documentation](https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/configure-linked-sign-on) for more details. If you plan to replicate IAM Identity Center to additional Regions later, visit [Microsoft Entra ID configuration for access to additional Regions](#gs-microsoft-entra-multi-region) for guidance how to enable access to the additional Regions after this initial setup.
1. Under **Sign on URL (Optional)**, paste in the **AWS access portal sign-in URL** value you copied in the previous step (**`Step 3.1`**), choose **Save**, and then choose **X** to close the window.
1. If prompted to test single sign-on with AWS IAM Identity Center, choose **No I'll test later**. You will do this verification in a later step.
1. On the **Set up Single Sign-On with SAML** page, in the **SAML Certificates** section, next to **Federation Metadata XML**, choose **Download** to save the metadata file to your system. You will need to upload this file when prompted in the next step.
------
#### [ Step 3.3 > ]
**Step 3.3: Configure the Microsoft Entra ID external IdP in AWS IAM Identity Center**
Here you will return to the **Change identity source** wizard in the IAM Identity Center console to complete the second-half of the SAML connection in AWS.
1. Return to the browser session you left open from **`Step 3.1`** in the IAM Identity Center console.
1. On the **Configure external identity provider** page, in the **Identity provider metadata** section, under **IdP SAML metadata**, choose the **Choose file** button, and select the identity provider metadata file that you downloaded from Microsoft Entra ID in the previous step, and then choose **Open**.
1. Choose **Next**.
1. After you read the disclaimer and are ready to proceed, enter ****ACCEPT****.
1. Choose **Change identity source** to apply your changes.
------
#### [ Step 3.4 > ]
**Step 3.4: Test that Nikki is redirected to the AWS access portal**
In this procedure, you will test the SAML connection by signing in to Microsoft's **My Account portal** with Nikki's credentials. Once authenticated, you'll select the AWS IAM Identity Center application which will redirect Nikki to the AWS access portal.
1. Go to the [My Account portal](https://myaccount.microsoft.com/) sign in page, and enter Nikki's full email address. For example, ***NikkiWolf**@**example.org*.
1. When prompted, enter Nikki's password, and then choose **Sign in**.
1. On the **My account** page, in the left navigation pane, choose **My Apps**.
1. On the **My Apps** page, select the app named **AWS IAM Identity Center**. This should prompt you for additional authentication.
1. On Microsoft's sign in page, choose your NikkiWolf credentials. If prompted a second time for authentication, choose your NikkiWolf credentials again. This should automatically redirect you to the AWS access portal.
**Tip**
If you are not redirected successfully, check to make sure the **AWS access portal sign-in URL** value you entered in **`Step 3.2`** matches the value you copied from **`Step 3.1`**.
1. Verify that your AWS accounts display.
**Tip**
If the page is empty and no AWS accounts display, confirm that Nikki was successfully assigned to the **RegionalAdmin** permission set (see **`Step 2.3`**).
------
#### [ Step 3.5 ]
**Step 3.5: Test Nikki's level of access to manage her AWS account**
In this step, you will check to determine Nikki's level of access to manage the Region settings for her AWS account. Nikki should only have sufficient administrator privileges to manage Regions from the **Accounts** page.
1. In the AWS access portal, choose the **Accounts** tab to display the list of accounts. The account names, account IDs, and email addresses associated with any accounts where you've defined permission sets appear.
1. Choose the account name (for example, *Sandbox*) where you applied the permission set (see **`Step 2.3`**). This will expand the list of permission sets that Nikki can choose from to manage her account.
1. Next to **RegionalAdmin** choose **Management console** to assume the role you defined in the **RegionalAdmin** permission set. This will redirect you to the AWS Management Console home page.
1. In the upper-right corner of the console, choose your account name, and then choose **Account**. This will take you to the **Account** page. Notice that all other sections on this page display a message that you do not have the necessary permissions to view or modify those settings.
1. On the **Account** page, scroll down to the section **AWS Regions**. Select a checkbox for any available Region in the table. Notice that Nikki does have the necessary permissions to **Enable** or **Disable** the list of Regions for her account as was intended.
**Nicely done\$1**
Steps 1 through 3 helped you to successfully implement and test your SAML connection. Now, to complete the tutorial, we encourage you to move on to Step 4 to implement automatic provisioning.
------
## Step 4: Configure and test your SCIM synchronization
In this step, you will set up [automatic provisioning](provision-automatically.md) (synchronization) of user information from Microsoft Entra ID into IAM Identity Center using the SCIM v2.0 protocol. You configure this connection in Microsoft Entra ID using your SCIM endpoint for IAM Identity Center and a bearer token that is created automatically by IAM Identity Center.
When you configure SCIM synchronization, you create a mapping of your user attributes in Microsoft Entra ID to the named attributes in IAM Identity Center. This causes the expected attributes to match between IAM Identity Center and Microsoft Entra ID.
The following steps walk you through how to enable automatic provisioning of users that primarily reside in Microsoft Entra ID to IAM Identity Center using the IAM Identity Center app in Microsoft Entra ID.
------
#### [ Step 4.1 > ]
**Step 4.1: Create a second test user in Microsoft Entra ID**
For testing purposes, you will create a new user (Richard Roe) in Microsoft Entra ID. Later, after you set up SCIM synchronization, you will test that this user and all relevant attributes were synced successfully to IAM Identity Center.
1. In the [Microsoft Entra admin center](https://entra.microsoft.com/) console, navigate to **Identity > Users > All users**.
1. Select **New user**, and then choose **Create new user** at the top of the screen.
1. In **User principal name**, enter ****RichRoe****, and then select your preferred domain and extension. For example, *RichRoe*@*example.org*.
1. In **Display name**, enter ****RichRoe****.
1. In **Password**, enter a strong password or select the eye icon to show the password that was auto-generated, and either copy or write down the value that is displayed.
1. Choose **Properties**, and then provide the following values:
+ **First name** - Enter ****Richard****
+ **Last name** - Enter ****Roe****
+ **Job title** - Enter ****Marketing Lead****
+ **Department** - Enter ****Sales****
+ **Employee ID** - Enter ****12345****
1. Choose **Review \$1 create**, and then choose **Create**.
------
#### [ Step 4.2 > ]
**Step 4.2: Enable automatic provisioning in IAM Identity Center**
In this procedure, you will use the IAM Identity Center console to enable automatic provisioning of users and groups coming from Microsoft Entra ID into IAM Identity Center.
1. Open the [IAM Identity Center console](https://console.aws.amazon.com/singlesignon), and choose **Settings** in the left navigation pane.
1. On the **Settings** page, under the **Identity source** tab, notice that **Provisioning method** is set to **Manual**.
1. 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 each of the values for the following options. You will need to paste these in the next step when you configure provisioning in Microsoft Entra ID.
1. **SCIM endpoint** - For example,
+ IPv4: `https://scim.aws-region.amazonaws.com/11111111111-2222-3333-4444-555555555555/scim/v2`
+ Dual stack: `https://scim.aws-region.api.aws/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.
1. Choose **Close**.
1. Under the **Identity source** tab, notice that **Provisioning method** is now set to **SCIM**.
------
#### [ Step 4.3 > ]
**Step 4.3: Configure automatic provisioning in Microsoft Entra ID**
Now that you have your RichRoe test user in place and have enabled SCIM in IAM Identity Center, you can proceed with configuring the SCIM synchronization settings in Microsoft Entra ID.
1. In the [Microsoft Entra admin center](https://entra.microsoft.com/) console, navigate to **Identity > Applications > Enterprise applications** and then choose **AWS IAM Identity Center**.
1. Choose **Provisioning**, under **Manage**, choose **Provisioning** again.
1. In **Provisioning Mode** select **Automatic**.
1. Under **Admin Credentials**, in **Tenant URL** paste in the **SCIM endpoint** URL value you copied earlier in **`Step 4.2`**. In **Secret Token**, paste in the **Access token** value.
1. Choose **Test Connection**. You should see a message indicating that the tested credentials were successfully authorized to enable provisioning.
1. Choose **Save**.
1. Under **Manage**, choose **Users and groups**, and then choose **Add user/group**.
1. On the **Add Assignment** page, under **Users**, choose **None Selected**.
1. Select **RichRoe**, and then choose **Select**.
1. On the **Add Assignment** page, choose **Assign**.
1. Choose **Overview**, and then choose **Start provisioning**.
------
#### [ Step 4.4 ]
**Step 4.4: Verify that synchronization occurred**
In this section, you will verify that Richard's user was successfully provisioned and that all attributes are displayed in IAM Identity Center.
1. In the [IAM Identity Center console](https://console.aws.amazon.com/singlesignon), choose **Users**.
1. On the **Users** page, you should see your **RichRoe** user displayed. Notice that in the **Created by** column the value is set to **SCIM**.
1. Choose **RichRoe**, under **Profile**, verify that the following attributes were copied from Microsoft Entra ID.
+ **First name** - ****Richard****
+ **Last name** - ****Roe****
+ **Department** - ****Sales****
+ **Title** - ****Marketing Lead****
+ **Employee number** - ****12345****
Now that Richard's user has been created in IAM Identity Center, you can assign it to any permission set so you can control the level of access he has to your AWS resources. For example, you could assign **RichRoe** to the **RegionalAdmin** permission set you used earlier to grant Nikki the permissions to manage Regions (see **`Step 2.3`**) and then test his level of access using **`Step 3.5`**.
**Congratulations\$1**
You have successfully set up a SAML connection between Microsoft and AWS and have verified that automatic provisioning is working to keep everything in sync. Now you can apply what you've learned to more smoothly set up your production environment.
------
## Step 5: Configure ABAC - *Optional*
Now that you have successfully configured SAML and SCIM, you can optionally choose to configure attribute-based access control (ABAC). ABAC is an authorization strategy that defines permissions based on attributes.
With Microsoft Entra ID, you can use either of the following two methods to configure ABAC for use with IAM Identity Center.
------
#### [ Configure user attributes in Microsoft Entra ID for access control in IAM Identity Center ]
**Configure user attributes in Microsoft Entra ID for access control in IAM Identity Center**
In the following procedure, you will determine which attributes in Microsoft Entra ID should be used by IAM Identity Center to manage access to your AWS resources. Once defined, Microsoft Entra ID sends these attributes to IAM Identity Center through SAML assertions. You will then need to [Create a permission set](howtocreatepermissionset.md) in IAM Identity Center to manage access based on the attributes you passed from Microsoft Entra ID.
Before you begin this procedure, you first need to enable the [Attributes for access control](attributesforaccesscontrol.md) feature. For more information about how to do this, see [Enable and configure attributes for access control](configure-abac.md).
1. In the [Microsoft Entra admin center](https://entra.microsoft.com/) console, navigate to **Identity > Applications > Enterprise applications** and then choose **AWS IAM Identity Center**.
1. Choose **Single sign-on**.
1. In the **Attributes & Claims** section, choose **Edit**.
1. On the **Attributes & Claims** page, do the following:
1. Choose **Add new claim**
1. For **Name**, enter `AccessControl:AttributeName`. Replace *AttributeName* with the name of the attribute you are expecting in IAM Identity Center. For example, `AccessControl:Department`.
1. For **Namespace**, enter ****https://aws.amazon.com/SAML/Attributes****.
1. For **Source**, choose **Attribute**.
1. For **Source attribute**, use the drop-down list to choose the Microsoft Entra ID user attributes. For example, `user.department`.
1. Repeat the previous step for each attribute you need to send to IAM Identity Center in the SAML assertion.
1. Choose **Save**.
------
#### [ Configure ABAC using IAM Identity Center ]
**Configure ABAC using IAM Identity Center**
With this method, you use the [Attributes for access control](attributesforaccesscontrol.md) feature in IAM Identity Center to pass an `Attribute` element with the `Name` attribute set to `https://aws.amazon.com/SAML/Attributes/AccessControl:{TagKey}`. You can use this element to pass attributes as session tags in the SAML assertion. For more information about session tags, see [Passing session tags in AWS STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_session-tags.html) in the *IAM User Guide*.
To pass attributes as session tags, include the `AttributeValue` element that specifies the value of the tag. For example, to pass the tag key-value pair `Department=billing`, use the following attribute:
```
billing
```
If you need to add multiple attributes, include a separate `Attribute` element for each tag.
------
## Assign access to AWS accounts
The following steps are only required to grant access to AWS accounts only. These steps are not required to grant access to AWS applications.
**Note**
To complete this step, 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).
### Step 1: IAM Identity Center: Grant Microsoft Entra ID users access to accounts
1. Return to the **IAM Identity Center** console. In the IAM Identity Center navigation pane, under **Multi-account permissions**, choose **AWS accounts**.
1. On the **AWS accounts** page the **Organizational structure** displays your organizational root with your accounts underneath it in the hierarchy. Select the checkbox for your management account, then select **Assign users or groups**.
1. The **Assign users and groups** workflow displays. It consists of three steps:
1. For **Step 1: Select users and groups** choose the user that will be performing the administrator job function. Then choose **Next**.
1. For **Step 2: Select permission sets** choose **Create permission set** to open a new tab that steps you through the three sub-steps involved in creating a permission set.
1. For **Step 1: Select permission set type** complete the following:
+ In **Permission set type**, choose **Predefined permission set**.
+ In **Policy for predefined permission set**, choose **AdministratorAccess**.
Choose **Next**.
1. For **Step 2: Specify permission set details**, keep the default settings, and choose **Next**.
The default settings create a permission set named *AdministratorAccess* with session duration set to one hour.
1. For **Step 3: Review and create**, verify that the **Permission set type** uses the AWS managed policy **AdministratorAccess**. Choose **Create**. On the **Permission sets** page a notification appears informing you that the permission set was created. You can close this tab in your web browser now.
1. On the **Assign users and groups** browser tab, you are still on **Step 2: Select permission sets** from which you started the create permission set workflow.
1. In the **Permissions sets** area, choose the **Refresh** button. The *AdministratorAccess* permission set you created appears in the list. Select the checkbox for that permission set and then choose **Next**.
1. For **Step 3: Review and submit** review the selected user and permission set, then choose **Submit**.
The page updates with a message that your AWS account is being configured. Wait until the process completes.
You are returned to the AWS accounts page. A notification message informs you that your AWS account has been reprovisioned and the updated permission set applied. When the user sign in they will have the option of choosing the *AdministratorAccess* role.
### Step 2: Microsoft Entra ID: Confirm Microsoft Entra ID users access to AWS resources
1. Return to the **Microsoft Entra ID** console and navigate to your IAM Identity Center SAML-based Sign-on application.
1. Select **Users and groups** and select **Add users or groups**. You’ll add the user you created in this tutorial in Step 4 to the Microsoft Entra ID application. By adding the user, you’ll allow them to sign-in to AWS. Search for the user you created at Step 4. If you followed this step, it would be **RichardRoe**.
1. For a demo, see [Federate your existing IAM Identity Center instance with Microsoft Entra ID](https://youtu.be/iSCuTJNeN6c?si=29HSAK8DgBEhSVad)
## Microsoft Entra ID configuration for access to additional Regions of IAM Identity Center - Optional
If you replicated IAM Identity Center to additional Regions, you must update your identity provider configuration to enable access to AWS managed applications and AWS accounts through the additional Regions. The steps below guide you through the procedure. For more details about this topic including the prerequisites, see [Using IAM Identity Center across multiple AWS Regions](multi-region-iam-identity-center.md).
1. Retrieve ACS URLs for the additional regions from the IAM Identity Center console as outlined in [ACS endpoints in the primary and additional AWS Regions](multi-region-workforce-access.md#acs-endpoints).
1. In the [Microsoft Entra admin center](https://entra.microsoft.com/) console, navigate to **Identity > Applications > Enterprise applications** and then choose **AWS IAM Identity Center**.
1. On the left, choose **2. Set up Single sign-on**.
1. On the **Basic SAML Configuration** page, under **Reply URL (Assertion Consumer Service URL)** section, choose **Add reply URL** for each additiona Region's ACS URL. You can keep the primary Region's ACS URL as the default ones so that users keep getting redirected to the primary Region when they launch the AWS IAM Identity Center application from Microsoft Entra ID.
1. When done adding the ACS URLs, save the **AWS IAM Identity Center** application.
1. You can create a bookmark app in Microsoft Entra ID for the AWS access portal in each additional Region. This enables your users to access the AWS access portal in additional Regions from Microsoft Entra ID. Make sure to grant your users permissions to access the bookmark apps in Microsoft Entra ID. See [Microsoft Entra ID documentation](https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/configure-linked-sign-on) for more details.
1. Verify that you can sign into the AWS access portal in each additional Region. Navigate to the [AWS access portal URLs](multi-region-workforce-access.md#portal-endpoints) or launch the bookmark apps from Microsoft Entra ID.
## Troubleshooting
For general SCIM and SAML troubleshooting with Microsoft Entra ID, see the following sections:
+ [Synchronization issues with Microsoft Entra ID and IAM Identity Center](#entra-scim-troubleshooting)
+ [Specific users fail to synchronize into IAM Identity Center from an external SCIM provider](troubleshooting.md#issue2)
+ [Issues regarding contents of SAML assertions created by IAM Identity Center](troubleshooting.md#issue1)
+ [Duplicate user or group error when provisioning users or groups with an external identity provider](troubleshooting.md#duplicate-user-group-idp)
+ [Additional resources](#entra-scim-troubleshooting-resources)
### Synchronization issues with Microsoft Entra ID and IAM Identity Center
If you are experiencing issues with Microsoft Entra ID users not synchronizing to IAM Identity Center, it might be due to a syntax issue that IAM Identity Center has flagged when a new user is being added to IAM Identity Center. You can confirm this by checking the Microsoft Entra ID audit logs for failed events, such as an `'Export'`. The **Status Reason** for this event will state:
```
{"schema":["urn:ietf:params:scim:api:messages:2.0:Error"],"detail":"Request is unparsable, syntactically incorrect, or violates schema.","status":"400"}
```
You can also check AWS CloudTrail for the failed event. This can be done by searching in the **Event History** console of CloudTrail using the following filter:
```
"eventName":"CreateUser"
```
The error in the CloudTrail event will state the following:
```
"errorCode": "ValidationException",
"errorMessage": "Currently list attributes only allow single item“
```
Ultimately, this exception means that one of the values passed from Microsoft Entra ID contained more values than anticipated. The solution is to review the attributes of the user in Microsoft Entra ID, ensuring that none contain duplicate values. One common example of duplicate values is having multiple values present for contact numbers such as **mobile**, **work**, and **fax**. Although separate values, they are all passed to IAM Identity Center under the single parent attribute **phoneNumbers**.
For general SCIM troubleshooting tips, see [Troubleshooting](troubleshooting.md#issue2).
### Microsoft Entra ID Guest Account Synchronization
If you would like to sync your Microsoft Entra ID guest users to IAM Identity Center, see the following procedure.
Microsoft Entra ID guest users’ email is different than Microsoft Entra ID users. This difference causes issues when attempting to synchronize Microsoft Entra ID guest users with IAM Identity Center. For example, see the following email address for a guest user:
`exampleuser_domain.com#EXT#@domain.onmicrosoft.com.`
IAM Identity Center does not expect the email address to contain the *\$1EXT\$1@domain* format.
1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com/) and navigate to **Identity** > **Applications** > **Enterprise applications** and then choose **AWS IAM Identity Center**
1. Navigate to the **Single Sign On** tab in the left pane.
1. Select **Edit** which appears next to **User Attributes & Claims**.
1. Select **Unique User Identifier (Name ID)** following **Required Claims**.
1. You will create two claim conditions for your Microsoft Entra ID users and guest users:
1. For Microsoft Entra ID users, create a user type for members with source attribute set to ` user.userprincipalname`.
1. For Microsoft Entra ID guest users, create a user type for external guests with the source attribute set to `user.mail`.
1. Select **Save** and retry signing in as a Microsoft Entra ID guest user.
### Additional resources
+ For general SCIM troubleshooting tips, see [Troubleshooting IAM Identity Center issues](troubleshooting.md).
+ For Microsoft Entra ID troubleshooting, see [Microsoft documentation](https://learn.microsoft.com/en-us/entra/identity/saas-apps/aws-single-sign-on-provisioning-tutorial#troubleshooting-tips).
+ To learn more about federation across multiple AWS accounts, see [Securing AWS accounts with Azure Active Directory Federation](https://aws.amazon.com//blogs/apn/securing-aws-accounts-with-azure-active-directory-federation/).
The following resources can help you troubleshoot as you work with AWS:
+ [AWS re:Post](https://repost.aws/) - Find FAQs and links to other resources to help you troubleshoot issues.
+ [AWS Support](https://aws.amazon.com/premiumsupport/) - Get technical support
# Configure SAML and SCIM with Okta and IAM Identity Center
You can automatically provision or synchronize user and group information from Okta into IAM Identity Center using the [System for Cross-domain Identity Management (SCIM) 2.0 protocol](scim-profile-saml.md#scim-profile). For more information, see [Using SAML and SCIM identity federation with external identity providers](other-idps.md).
To configure this connection in Okta, you use your SCIM endpoint for IAM Identity Center and a bearer token that is created automatically by IAM Identity Center. When you configure SCIM synchronization, you create a mapping of your user attributes in Okta to the named attributes in IAM Identity Center. This mapping matches the expected user attributes between IAM Identity Center and your Okta account.
Okta supports the following provisioning features when connected to IAM Identity Center through SCIM:
+ Create users – Users assigned to the IAM Identity Center application in Okta are provisioned in IAM Identity Center.
+ Update user attributes – Attribute changes for users who are assigned to the IAM Identity Center application in Okta are updated in IAM Identity Center.
+ Deactivate users – Users who are unassigned from the IAM Identity Center application in Okta are disabled in IAM Identity Center.
+ Group push – Groups (and their members) in Okta are synchronized to IAM Identity Center.
**Note**
To minimize administrative overhead in both Okta and IAM Identity Center, we recommend that you assign and *push* groups instead of individual users.
+ Import users – Users can be imported from IAM Identity Center to Okta.
**Objective**
In this tutorial, you will walk through setting up a SAML connection with Okta IAM Identity Center. Later, you will synchronize users from Okta, using SCIM. In this scenario, you manage all users and groups in Okta. Users sign in through the Okta portal. To verify everything is configured correctly, after completing the configuration steps you will sign in as an Okta user and verify access to AWS resources.
The following features are supported when connecting Okta to IAM Identity Center through SAML:
+ IdP-initiated SAML sign-in – Users sign in through the Okta portal and gain access to IAM Identity Center.
+ SP-initiated SAML sign-in – Users access the AWS access portal, which redirects them to sign in through the Okta portal.
**Note**
You can sign up for an Okta account ([free trial](https://www.okta.com/free-trial/)) that has Okta's [IAM Identity Center application](https://www.okta.com/integrations/aws-single-sign-on/) installed. For paid Okta products, you might need to confirm that your Okta license supports *lifecycle management* or similar capabilities that enable outbound provisioning. These features might be necessary to configure SCIM from Okta to IAM Identity Center.
If you haven't enabled IAM Identity Center yet, see [Enable IAM Identity Center](enable-identity-center.md).
## Considerations
+ Before you configure SCIM provisioning between Okta and IAM Identity Center, we recommend that you first review [Considerations for using automatic provisioning](provision-automatically.md#auto-provisioning-considerations).
+ Every Okta user must have a **First name**, **Last name**, **Username** and **Display name** value specified.
+ Each Okta user has only a single value per data attribute, such as email address or phone number. Any users that have multiple values will fail to synchronize. If there are users that have multiple values in their attributes, remove the duplicate attributes before attempting to provision the user in IAM Identity Center. For example, only one phone number attribute can be synchronized, since the default phone number attribute is "work phone", use the "work phone" attribute to store the user's phone number, even if the phone number for the user is a home phone or a mobile phone.
+ When using Okta with IAM Identity Center, IAM Identity Center is generally configured as an Application in Okta. This allows you to configure multiple instances of IAM Identity Center as multiple applications, supporting access to multiple AWS Organizations, within a single instance of the Okta.
+ Entitlements and role attributes aren't supported and cannot be synchronized with IAM Identity Center.
+ Using the same Okta group for both assignments and group push isn't currently supported. To maintain consistent group memberships between Okta and IAM Identity Center, create a separate group and configure it to push groups to IAM Identity Center.
+ If you replicated IAM Identity Center to additional Regions, you must update your identity provider configuration to enable access to AWS managed applications and AWS accounts through additional Regions. For more details including the prerequisites, see [Using IAM Identity Center across multiple AWS Regions](multi-region-iam-identity-center.md). Okta-specific steps are described in [Okta configuration for access to additional Regions](#gs-okta-multi-region)
## Step 1: Okta: Obtain the SAML metadata from your Okta account
1. Sign in to the Okta admin dashboard, expand **Applications**, then select **Applications**.
1. On the **Applications** page, choose **Browse App Catalog**.
1. In the search box, type** AWS IAM Identity Center**, select the app to add the IAM Identity Center app.
1. Select the **Sign On** tab.
1. Under **SAML Signing Certificates**, select **Actions**, and then select **View IdP Metadata**. A new browser tab opens showing the document tree of an XML file. Select all of the XML from `` to `` and copy it to a text file.
1. Save the text file as `metadata.xml`.
Leave the Okta admin dashboard open, you will continue using this console in the later steps.
## Step 2: IAM Identity Center: Configure Okta as the identity source for IAM Identity Center
1. Open the [IAM Identity Center console](https://console.aws.amazon.com/singlesignon) as a user with administrative privileges.
1. Choose **Settings** in the left navigation pane.
1. On the **Settings** page, choose **Actions**, and then choose **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**, copy the following items to a text file for easy access:
+ **IAM Identity Center Assertion Consumer Service (ACS) URL** – You have a choice between IPv4-only and dual-stack ACS URLs. Also, if your IAM Identity Center instance is enabled in multiple Regions, each additional Region has its own IPv4-only and dual-stack ACS URLs. For more information on ACS URLs, see [ACS endpoints in the primary and additional AWS Regions](multi-region-workforce-access.md#acs-endpoints).
+ **IAM Identity Center issuer URL**
You'll need these values later in this tutorial.
1. Under **Identity provider metadata**, under **IdP SAML metadata**, select **Choose file** and then select the `metadata.xml` file you created in the previous step.
1. Choose **Next**.
1. After you read the disclaimer and are ready to proceed, enter **ACCEPT**.
1. Choose **Change identity source**.
Leave the AWS console open, you will continue using this console in the next step.
1. Return to the Okta admin dashboard and select the **Sign On** tab of the AWS IAM Identity Center app, then select **Edit**.
1. Under **Advanced Sign-on Settings** enter the following:
+ For **ACS URL**, enter the value(s) you copied for **IAM Identity Center Assertion Consumer Service (ACS) URL**. You can use the primary Region's ACS URL as the default one so that users are redirected to the primary Region when they launch the Amazon Web Services application from Okta.
+ (Optional) If you replicated IAM Identity Center to additional Regions, you can also create a bookmark app in Okta for the AWS access portal in each additional Region. This enables your users to access the AWS access portal in additional Regions from Okta. Make sure to grant your users permissions to access the bookmark apps in Okta. See [Okta documentation](https://support.okta.com/help/s/article/create-a-bookmark-app) for more details. If you plan to replicate IAM Identity Center to additional Regions later, visit [Okta configuration for access to additional Regions](#gs-okta-multi-region) for guidance how to enable access to the additional Regions after this initial setup.
+ For **Issuer URL**, enter the value you copied for **IAM Identity Center issuer URL**
+ For **Application username format**, select one of the options from the menu.
Ensure the value you choose is unique for each user. For this tutorial, select **Okta username**
1. Choose **Save**.
You are now ready to provision users from Okta to IAM Identity Center. Leave the Okta admin dashboard open, and return to the IAM Identity Center console for the next step.
## Step 3: IAM Identity Center and Okta: Provision Okta users
1. In the IAM Identity Center console on the **Settings** page, locate the **Automatic provisioning** information box, and then choose **Enable**. This 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 each of the values for the following options:
1. **SCIM endpoint** - The endpoint format depends on your configuration:
+ IPv4: https://scim.*us-east-2*.amazonaws.com/*11111111111-2222-3333-4444-555555555555*/scim/v2
+ Dual-stack: https://scim.*us-east-2*.api.aws/*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 Okta later in this tutorial.
1. Choose **Close**.
1. Return to the Okta admin dashboard and navigate to the IAM Identity Center app.
1. On the **IAM Identity Center app** page, choose the **Provisioning** tab, and then in the left navigation under **Settings**, choose **Integration**.
1. Choose **Edit**, and then select the checkbox next to **Enable API integration** to enable automatic provisioning.
1. Configure Okta with the SCIM provisioning values from AWS IAM Identity Center that you copied earlier in this step:
1. In the **Base URL** field, enter the **SCIM endpoint** value.
1. In the **API Token** field, enter the **Access token** value.
1. Choose **Test API Credentials** to verify the credentials entered are valid.
The message **AWS IAM Identity Center was verified successfully\$1** displays.
1. Choose **Save**. You're moved to the **Settings** section, with **Integration** selected.
1. Under **Settings**, choose **To App**, and then select the **Enable** checkbox for each of the **Provisioning to App** features you want to enable. For this tutorial, select all the options.
1. Choose **Save**.
You are now ready to synchronize your users from Okta with IAM Identity Center.
## Step 4: Okta: Synchronize users from Okta with IAM Identity Center
By default, no groups or users are assigned to your Okta IAM Identity Center app. Provisioning groups provisions the users that are members of the group. Complete the following steps to synchronize groups and users with AWS IAM Identity Center.
1. In the **Okta IAM Identity Center app** page, choose the **Assignments** tab. You can assign both people and groups to the IAM Identity Center app.
1. To assign people:
+ In the **Assignments** page, choose **Assign**, and then choose **Assign to people**.
+ Choose the Okta users that you want to have access to the IAM Identity Center app. Choose **Assign**, choose **Save and Go Back**, and then choose **Done**.
This starts the process of provisioning the users into IAM Identity Center.
1. To assign groups:
+ In the **Assignments** page, choose **Assign**, and then choose **Assign to groups**.
+ Choose the Okta groups that you want to have access to the IAM Identity Center app. Choose **Assign**, choose **Save and Go Back**, and then choose **Done**.
This starts the process of provisioning the users in the group into IAM Identity Center.
**Note**
You might be required to specify additional attributes for the group if they aren't present in all of the user records. The attributes specified for the group will override any individual attribute values.
1. Choose the **Push Groups** tab. Choose the Okta group you want to synchronize with IAM Identity Center. Choose **Save**.
The group status changes to **Active** after the group and its members have been pushed to IAM Identity Center.
1. Return to the **Assignments** tab.
1. To add individual Okta users to IAM Identity Center, use the following steps:
1. In the **Assignments** page, choose **Assign**, and then choose **Assign to People**.
1. Choose the Okta users that you want to have access to the IAM Identity Center app. Choose **Assign**, choose **Save and Go Back**, and then choose **Done**.
This starts the process of provisioning the individual users into IAM Identity Center.
**Note**
You can also assign users and groups to the AWS IAM Identity Center app, from the **Applications** page of the Okta admin dashboard. To do this select the **Settings** icon and then choose **Assign to Users** or **Assign to Groups** and then specify the user or group.
1. Return to the IAM Identity Center console. In the left navigation, select **Users**, you should see the user list populated by your Okta users.
**Congratulations\$1**
You have successfully set up a SAML connection between Okta and AWS and have verified that automatic provisioning is working. You can now assign these users to accounts and applications in **IAM Identity Center**. For this tutorial, in the next step let's designate one of the users as the IAM Identity Center administrator by granting them administrative permissions to the management account.
## Passing attributes for access control - *Optional*
You can optionally use the [Attributes for access control](attributesforaccesscontrol.md) feature in IAM Identity Center to pass an `Attribute` element with the `Name` attribute set to `https://aws.amazon.com/SAML/Attributes/AccessControl:{TagKey}`. This element allows you to pass attributes as session tags in the SAML assertion. For more information about session tags, see [Passing session tags in AWS STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_session-tags.html) in the *IAM User Guide*.
To pass attributes as session tags, include the `AttributeValue` element that specifies the value of the tag. For example, to pass the tag key-value pair `CostCenter = blue`, use the following attribute.
```
blue
```
If you need to add multiple attributes, include a separate `Attribute` element for each tag.
## Assign access to AWS accounts
The following steps are only required to grant access to AWS accounts only. These steps are not required to grant access to AWS applications.
**Note**
To complete this step, 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).
### Step 1: IAM Identity Center: Grant Okta users access to accounts
1. In the IAM Identity Center navigation pane, under **Multi-account permissions**, choose **AWS accounts**.
1. On the **AWS accounts** page the **Organizational structure** displays your organizational root with your accounts underneath it in the hierarchy. Select the checkbox for your management account, then select **Assign users or groups**.
1. The **Assign users and groups** workflow displays. It consists of three steps:
1. For **Step 1: Select users and groups**, choose the user that will be performing the administrator job function. Then choose **Next**.
1. For **Step 2: Select permission sets**, choose **Create permission set** to open a new tab that walks you through the three sub-steps involved in creating a permission set.
1. For **Step 1: Select permission set type** complete the following:
+ In **Permission set type**, choose **Predefined permission set**.
+ In **Policy for predefined permission set**, choose **AdministratorAccess**.
Choose **Next**.
1. For **Step 2: Specify permission set details**, keep the default settings, and choose **Next**.
The default settings create a permission set named *AdministratorAccess* with session duration set to one hour.
1. For **Step 3: Review and create**, verify that the **Permission set type** uses the AWS managed policy **AdministratorAccess**. Choose **Create**. On the **Permission sets** page, a notification appears informing you that the permission set was created. You can close this tab in your web browser now.
On the **Assign users and groups** browser tab, you are still on **Step 2: Select permission sets** from which you started the create permission set workflow.
In the **Permissions sets** area, choose the **Refresh** button. The *AdministratorAccess* permission set you created appears in the list. Select the checkbox for that permission set and then choose **Next**.
1. For **Step 3: Review and submit**, review the selected user and permission set, then choose **Submit**.
The page updates with a message that your AWS account is being configured. Wait until the process completes.
You are returned to the AWS accounts page. A notification message informs you that your AWS account has been reprovisioned and the updated permission set applied. When the user signs-in they will have the option of choosing the *AdministratorAccess* role.
### Step 2: Okta: Confirm Okta users access to AWS resources
1. Sign in using a test account to the Okta dashboard.
1. Under **My Apps**, select the AWS IAM Identity Center icon.
1. You should see the AWS account icon. Expand that icon to see the list of AWS accounts that the user can access. In this tutorial you only worked with a single account, so expanding the icon only shows one account.
1. Select the account to display the permission sets available to the user. In this tutorial you created the **AdministratorAccess** permission set.
1. Next to the permission set are links for the type of access available for that permission set. When you created the permission set, you specified access to both the AWS Management Console and programmatic access. Select **Management console** to open the AWS Management Console.
1. The user is signed in to the AWS Management Console.
You can also use the AWS access portal. This redirects you to sign in through the Okta portal before taking you to the AWS access portal. This path follows the SP-initiated SAML sign-in flow.
## Okta configuration for access to additional Regions of IAM Identity Center - Optional
If you replicated IAM Identity Center to additional Regions, you must update your identity provider configuration to enable access to AWS managed applications and AWS accounts through the additional Regions. The steps below guide you through the procedure. For more details about this topic including the prerequisites, see [Using IAM Identity Center across multiple AWS Regions](multi-region-iam-identity-center.md).
1. Retrieve ACS URLs for the additional regions from the IAM Identity Center console as outlined in [ACS endpoints in the primary and additional AWS Regions](multi-region-workforce-access.md#acs-endpoints).
1. In the Okta admin dashboard's navigation pane, choose **Applications**, and then **Applications** again in the expanded list.
1. Choose the **AWS IAM Identity Center** application.
1. Choose the **Sign On** tab.
1. Under **Advanced Sign-on Settings**, and **Other Requestable SSO URLs**, choose **Add another** for each additional Region's ACS URL, and paste the ACS URL into the text field.
1. When done adding the ACS URLs, save the **AWS IAM Identity Center** application.
1. You can create a bookmark app in Okta for the AWS access portal in each additional Region. This enables your users to access the AWS access portal in additional Regions from Okta. Make sure to grant your users permissions to access the bookmark apps in Okta. See [Okta documentation](https://support.okta.com/help/s/article/create-a-bookmark-app) for more details.
1. Verify that you can sign into the AWS access portal in each additional Region. Navigate to the [AWS access portal URLs](multi-region-workforce-access.md#portal-endpoints) or launch the bookmark apps from Okta.
## Next steps
Now that you've configured Okta as an identity provider and provisioned users in IAM Identity Center, you can:
+ Grant access to AWS accounts, see [Assign user or group access to AWS accounts](assignusers.md).
+ Grant access to cloud applications, see [Assign user access to applications in the IAM Identity Center console](assignuserstoapp.md).
+ Configure permissions based on job functions, see [Create a permission set](howtocreatepermissionset.md).
## Troubleshooting
For general SCIM and SAML troubleshooting with Okta, see the following sections:
+ [Reprovisioning users and groups deleted from IAM Identity Center](#reprovisioning-deleted-users-groups)
+ [Automatic Provisioning Error in Okta](#okta-auto-provisioning-error)
+ [Specific users fail to synchronize into IAM Identity Center from an external SCIM provider](troubleshooting.md#issue2)
+ [Issues regarding contents of SAML assertions created by IAM Identity Center](troubleshooting.md#issue1)
+ [Duplicate user or group error when provisioning users or groups with an external identity provider](troubleshooting.md#duplicate-user-group-idp)
+ [Additional resources](#gs-okta-troubleshooting-resources)
### Reprovisioning users and groups deleted from IAM Identity Center
+ You could receive the following error message in the Okta Console, if you're attempting to change either a user or group in Okta that was once synchronized and then deleted from IAM Identity Center:
+ Automatic profile push of user *Jane Doe* to app AWS IAM Identity Center failed: Error while trying to push profile update for *jane\$1doe@example.com*: No user returned for user *xxxxx-xxxxxx-xxxxx-xxxxxxx*
+ Linked group is missing in AWS IAM Identity Center. Change the linked group to resume pushing group memberships.
+ You could also receive the following error message in the Okta's Systems Logs for either synchronized and deleted IAM Identity Center users or groups:
+ Okta Error: Eventfailed application.provision.user.push\$1profile : No user returned for user *xxxxx-xxxxxx-xxxxx-xxxxxxx*
+ Okta Error: application.provision.group\$1push.mapping.update.or.delete.failed.with.error : Linked group is missing in AWS IAM Identity Center. Change the linked group to resume pushing group memberships.
**Warning**
Users and groups should be deleted from Okta rather than IAM Identity Center if you have synchronized Okta and IAM Identity Center using SCIM.
**Troubleshooting deleted IAM Identity Center Users**
To address this issue with deleted IAM Identity Center users, the users must be deleted from Okta. If necessary, these users would also need to be recreated in Okta. When the user is recreated in Okta, it will also be reprovisioned into the IAM Identity Center through SCIM. For more information on deleting a user, see [Okta documentation](https://help.okta.com/en-us/content/topics/users-groups-profiles/usgp-deactivate-user-account.htm).
**Note**
If you need to remove a Okta user’s access to IAM Identity Center, you should first remove them from their Group Push and then their Assignment Group in Okta. This ensures the user is removed from their associated group membership in IAM Identity Center. For more information on troubleshooting Group Push, see [Okta documentation](https://help.okta.com/en-us/content/topics/users-groups-profiles/usgp-group-push-troubleshoot.htm).
**Troubleshooting deleted IAM Identity Center Groups**
To address this issue with deleted IAM Identity Center groups, the group must be deleted from Okta. If necessary, these groups would also need to be recreated in Okta using Group Push. When the user is recreated in Okta, it will also be reprovisioned into the IAM Identity Center through SCIM. For more information on deleting a group, see [Okta documentation](https://help.okta.com/oie/en-us/content/topics/users-groups-profiles/usgp-group-push-troubleshoot.htm).
### Automatic Provisioning Error in Okta
If you receive the following error message in Okta:
Automatic provisioning of user Jane Doe to app AWS IAM Identity Center failed: Matching user not found
See [Okta documentation](https://support.okta.com/help/s/article/aws-iam-identity-center-provisioning-error-automatic-provisioning-of-user-name-of-user-to-app-aws-iam-identity-center-failed-matching-user-not-found?language=en_US) for more information.
### Additional resources
+ For general SCIM troubleshooting tips, see [Troubleshooting IAM Identity Center issues](troubleshooting.md).
The following resources can help you troubleshoot as you work with AWS:
+ [AWS re:Post](https://repost.aws/) - Find FAQs and links to other resources to help you troubleshoot issues.
+ [AWS Support](https://aws.amazon.com/premiumsupport/) - Get technical support
# Setting up SCIM provisioning between OneLogin and IAM Identity Center
IAM Identity Center supports automatic provisioning (synchronization) of user and group information from OneLogin into IAM Identity Center using the System for Cross-domain Identity Management (SCIM) v2.0 protocol. For more information, see [Using SAML and SCIM identity federation with external identity providers](other-idps.md).
**Note**
OneLogin doesn’t currently support SAML multiple assertion consume service (ACS) URLs in the AWS IAM Identity Center application. This SAML feature is required to fully take advantage of [multi-Region support](multi-region-iam-identity-center.md) in IAM Identity Center. If you plan to replicate IAM Identity Center to additional Regions, be aware that using a single ACS URL may affect the user experience in those additional Regions. Your primary Region will continue to function normally. We recommend that you work with your IdP vendor to enable this feature. 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).
You configure this connection in OneLogin, using your SCIM endpoint for IAM Identity Center and a bearer token that is created automatically by IAM Identity Center. When you configure SCIM synchronization, you create a mapping of your user attributes in OneLogin to the named attributes in IAM Identity Center. This causes the expected attributes to match between IAM Identity Center and OneLogin.
The following steps walk you through how to enable automatic provisioning of users and groups from OneLogin to IAM Identity Center using the SCIM protocol.
**Note**
Before you begin deploying SCIM, we recommend that you first review the [Considerations for using automatic provisioning](provision-automatically.md#auto-provisioning-considerations).
**Topics**
+ [
## Prerequisites
](#onelogin-prereqs)
+ [
## Step 1: Enable provisioning in IAM Identity Center
](#onelogin-step1)
+ [
## Step 2: Configure provisioning in OneLogin
](#onelogin-step2)
+ [
## (Optional) Step 3: Configure user attributes in OneLogin for access control in IAM Identity Center
](#onelogin-step3)
+ [
## (Optional) Passing attributes for access control
](#onelogin-passing-abac)
+ [
## Troubleshooting
](#onelogin-troubleshooting)
## Prerequisites
You will need the following before you can get started:
+ A OneLogin account. If you do not have an existing account, you may be able to obtain a free trial or developer account from the [OneLogin website](https://www.onelogin.com/free-trial).
+ An IAM Identity Center-enabled account ([free](https://aws.amazon.com/single-sign-on/)). For more information, see [Enable IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/setup-enable-idc.html).
+ A SAML connection from your OneLogin account to IAM Identity Center. For more information, see [Enabling Single Sign-On Between OneLogin and AWS](https://aws.amazon.com/blogs/apn/enabling-single-sign-on-between-onelogin-and-aws/) on the AWS Partner Network Blog.
## Step 1: Enable provisioning in IAM Identity Center
In this first step, you use the IAM Identity Center console to enable automatic provisioning.
**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**.
You have now set up provisioning in the IAM Identity Center console. Now you need to do the remaining tasks using the OneLogin admin console as described in the following procedure.
## Step 2: Configure provisioning in OneLogin
Use the following procedure in the OneLogin admin console to enable integration between IAM Identity Center and the IAM Identity Center app. This procedure assumes you have already configured the AWS Single Sign-On application in OneLogin for SAML authentication. If you have not yet created this SAML connection, please do so before proceeding and then return here to complete the SCIM provisioning process. For more information about configuring SAML with OneLogin, see [Enabling Single Sign-On Between OneLogin and AWS](https://aws.amazon.com/blogs/apn/enabling-single-sign-on-between-onelogin-and-aws/) on the AWS Partner Network Blog.
**To configure provisioning in OneLogin**
1. Sign in to OneLogin, and then navigate to **Applications > Applications**.
1. On the **Applications** page, search for the application you created previously to form your SAML connection with IAM Identity Center. Choose it and then choose **Configuration** from the navigation pane.
1. In the previous procedure, you copied the **SCIM endpoint** value in IAM Identity Center. Paste that value into the **SCIM Base URL** field in OneLogin. Also, in the previous procedure you copied the **Access token** value in IAM Identity Center. Paste that value into the **SCIM Bearer Token** field in OneLogin.
1. Next to **API Connection**, click **Enable**, and then click **Save** to complete the configuration.
1. In the navigation pane, choose **Provisioning**.
1. Select the check boxes for **Enable provisioning**, **Create user**, **Delete user**, and **Update user**, and then choose **Save**.
1. In the navigation pane, choose **Users**.
1. Click **More Actions** and choose **Sync logins**. You should receive the message *Synchronizing users with AWS Single Sign-On*.
1. Click **More Actions** again, and then choose **Reapply entitlement mappings**. You should receive the message *Mappings are being reapplied*.
1. At this point, the provisioning process should begin. To confirm this, navigate to **Activity > Events**, and monitor the progress. Successful provisioning events, as well as errors, should appear in the event stream.
1. To verify that your users and groups have all been successfully synchronized to IAM Identity Center, return to the IAM Identity Center console and choose **Users**. Your synchronized users from OneLogin appear on the **Users** page. You can also view your synchronized groups on the **Groups** page.
1. To synchronize user changes automatically to IAM Identity Center, navigate to the **Provisioning** page, locate the **Require admin approval before this action is performed** section, de-select **Create User**, **Delete User**, and/or **Update User**, and click **Save**.
## (Optional) Step 3: Configure user attributes in OneLogin for access control in IAM Identity Center
This is an optional procedure for OneLogin if you choose to configure attributes you will use in IAM Identity Center to manage access to your AWS resources. The attributes that you define in OneLogin are passed in a SAML assertion to IAM Identity Center. You will then create a permission set in IAM Identity Center to manage access based on the attributes you passed from OneLogin.
Before you begin this procedure, you must first enable the [Attributes for access control](attributesforaccesscontrol.md) feature. For more information about how to do this, see [Enable and configure attributes for access control](configure-abac.md).
**To configure user attributes in OneLogin for access control in IAM Identity Center**
1. Sign in to OneLogin, and then navigate to **Applications > Applications**.
1. On the **Applications** page, search for the application you created previously to form your SAML connection with IAM Identity Center. Choose it and then choose **Parameters** from the navigation pane.
1. In the **Required Parameters** section, do the following for each attribute you want to use in IAM Identity Center:
1. Choose **\$1**.
1. In **Field name**, enter `https://aws.amazon.com/SAML/Attributes/AccessControl:AttributeName`, and replace **AttributeName** with the name of the attribute you are expecting in IAM Identity Center. For example, `https://aws.amazon.com/SAML/Attributes/AccessControl:Department`.
1. Under **Flags**, check the box next to **Include in SAML assertion**, and choose **Save**.
1. In the **Value** field, use the drop-down list to choose the OneLogin user attributes. For example, **Department**.
1. Choose **Save**.
## (Optional) Passing attributes for access control
You can optionally use the [Attributes for access control](attributesforaccesscontrol.md) feature in IAM Identity Center to pass an `Attribute` element with the `Name` attribute set to `https://aws.amazon.com/SAML/Attributes/AccessControl:{TagKey}`. This element allows you to pass attributes as session tags in the SAML assertion. For more information about session tags, see [Passing session tags in AWS STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_session-tags.html) in the *IAM User Guide*.
To pass attributes as session tags, include the `AttributeValue` element that specifies the value of the tag. For example, to pass the tag key-value pair `CostCenter = blue`, use the following attribute.
```
blue
```
If you need to add multiple attributes, include a separate `Attribute` element for each tag.
## Troubleshooting
The following can help you troubleshoot some common issues you might encounter while setting up automatic provisioning with OneLogin.
**Groups are not provisioned to IAM Identity Center**
By default, groups may not be provisioned from OneLogin to IAM Identity Center. Ensure that you’ve enabled group provisioning for your IAM Identity Center application in OneLogin. To do this, sign in to the OneLogin admin console, and check to make sure that the **Include in User Provisioning** option is selected under the properties of the IAM Identity Center application (**IAM Identity Center application > Parameters > Groups**). For more details on how to create groups in OneLogin, including how to synchronize OneLogin roles as groups in SCIM, please see the [OneLogin website](https://onelogin.service-now.com/support).
**Nothing is synchronized from OneLogin to IAM Identity Center, despite all settings being correct**
In addition to the note above regarding admin approval, you will need to **Reapply entitlement mappings** for many configuration changes to take effect. This can be found in **Applications > Applications > IAM Identity Center application > More Actions**. You can see details and logs for most actions in OneLogin, including synchronization events, under **Activity > Events**.
**I’ve deleted or disabled a group in OneLogin, but it still appears in IAM Identity Center**
OneLogin currently does not support the SCIM DELETE operation for groups, which means that the group continues to exist in IAM Identity Center. You must therefore remove the group from IAM Identity Center directly to ensure that any corresponding permissions in IAM Identity Center for that group are removed.
**I deleted a group in IAM Identity Center without first deleting it from OneLogin and now I’m having user/group sync issues**
To remedy this situation, first ensure that you do not have any redundant group provisioning rules or configurations in OneLogin. For example, a group directly assigned to an application along with a rule that publishes to the same group. Next, delete any undesirable groups in IAM Identity Center. Finally, in OneLogin, **Refresh** the entitlements (**IAM Identity Center App > Provisioning > Entitlements**), and then **Reapply entitlement mappings (IAM Identity Center App > More Actions)**. To avoid this issue in the future, first make the change to stop provisioning the group in OneLogin, then delete the group from IAM Identity Center.
# Using Ping Identity products with IAM Identity Center
The following Ping Identity products have been tested with IAM Identity Center.
**Topics**
+ [
# PingFederate
](pingfederate-idp.md)
+ [
# PingOne
](pingone-idp.md)
# PingFederate
IAM Identity Center supports automatic provisioning (synchronization) of user and group information from the PingFederate product by Ping Identity (hereafter “Ping”) into IAM Identity Center. This provisioning uses the System for Cross-domain Identity Management (SCIM) v2.0 protocol. For more information, see [Using SAML and SCIM identity federation with external identity providers](other-idps.md).
You configure this connection in PingFederate using your IAM Identity Center SCIM endpoint and access token. When you configure SCIM synchronization, you create a mapping of your user attributes in PingFederate to the named attributes in IAM Identity Center. This causes the expected attributes to match between IAM Identity Center and PingFederate.
This guide is based on PingFederate version 10.2. Steps for other versions may vary. Contact Ping for more information about how to configure provisioning to IAM Identity Center for other versions of PingFederate.
The following steps walk you through how to enable automatic provisioning of users and groups from PingFederate to IAM Identity Center using the SCIM protocol.
**Note**
Before you begin deploying SCIM, we recommend that you first review the [Considerations for using automatic provisioning](provision-automatically.md#auto-provisioning-considerations). Then continue reviewing additional considerations in the next section.
**Topics**
+ [
## Prerequisites
](#pingfederate-prereqs)
+ [
## Considerations
](#pingfederate-considerations)
+ [
## Step 1: Enable provisioning in IAM Identity Center
](#pingfederate-step1)
+ [
## Step 2: Configure provisioning in PingFederate
](#pingfederate-step2)
+ [
## (Optional) Step 3: Configure user attributes in PingFederate for access control in IAM Identity Center
](#pingfederate-step3)
+ [
## (Optional) Passing attributes for access control
](#pingfederate-passing-abac)
+ [
## Troubleshooting
](#pingfederate-troubleshooting)
## Prerequisites
You'll need the following before you can get started:
+ A working PingFederate server. If you do not have an existing PingFederate server, you might be able to obtain a free trial or developer account from the [Ping Identity](https://www.pingidentity.com/developer/en/get-started.html#:~:text=Get%20started%20developing%20with%20open,a%20developer%20trial%20of%20PingOne.) website. The trial includes licenses and software downloads and associated documentation.
+ A copy of the PingFederate IAM Identity Center Connector software installed on your PingFederate server. For more information about how to obtain this software, see [IAM Identity Center Connector](https://support.pingidentity.com/s/marketplace-integration/a7i1W000000TOZ1/) on the Ping Identity website.
+ An IAM Identity Center-enabled account ([free](https://aws.amazon.com/single-sign-on/)). For more information, see [Enable IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/setup-enable-idc.html).
+ A SAML connection from your PingFederate instance to IAM Identity Center. For instructions on how to configure this connection, see the PingFederate documentation. In summary, the recommended path is to use the IAM Identity Center Connector to configure "Browser SSO" in PingFederate, using the “download" and "import" metadata features on both ends to exchange SAML metadata between PingFederate and IAM Identity Center.
+ If you replicated IAM Identity Center to additional Regions, you must update your identity provider configuration to enable access to AWS managed applications and AWS accounts from those Regions. For more details, see [Step 3: Update external IdP setup](replicate-to-additional-region.md#update-external-idp-setup). See the PingFederate documentation for additional details.
## Considerations
The following are important considerations about PingFederate that can affect how you implement provisioning with IAM Identity Center.
+ If an attribute (such as a phone number) is removed from a user in the data store configured in PingFederate, that attribute will not be removed from the corresponding user in IAM Identity Center. This is a known limitation in PingFederate’s provisioner implementation. If an attribute is changed to a different (non-empty) value on a user, that change will be synchronized to IAM Identity Center.
## Step 1: Enable provisioning in IAM Identity Center
In this first step, you use the IAM Identity Center console to enable automatic provisioning.
**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**.
Now that you have set up provisioning in the IAM Identity Center console, you must complete the remaining tasks using the PingFederate administrative console., The steps are described in the following procedure.
## Step 2: Configure provisioning in PingFederate
Use the following procedure in the PingFederate administrative console to enable integration between IAM Identity Center and the IAM Identity Center Connector. This procedure assumes that you have already installed the IAM Identity Center Connector software. If you have not yet done so, refer to [Prerequisites](#pingfederate-prereqs), and then complete this procedure to configure SCIM provisioning.
**Important**
If your PingFederate server has not been previously configured for outbound SCIM provisioning, you may need to make a configuration file change to enable provisioning. For more information, see Ping documentation. In summary, you must modify the `pf.provisioner.mode` setting in the **pingfederate-/pingfederate/bin/run.properties** file to a value other than `OFF` (which is the default), and restart the server if currently running. For example, you may choose to use `STANDALONE` if you don’t currently have a high-availability configuration with PingFederate.
**To configure provisioning in PingFederate**
1. Sign on to the PingFederate administrative console.
1. Select **Applications** from the top of the page, then click **SP Connections**.
1. Locate the application you created previously to form your SAML connection with IAM Identity Center, and click on the connection name.
1. Select **Connection Type** from the dark navigation headings near the top of the page. You should see **Browser SSO** already selected from your previous configuration of SAML. If not, you must complete those steps first before you can continue.
1. Select the **Outbound Provisioning** check box, choose **IAM Identity Center Cloud Connector** as the type, and click **Save**. If **IAM Identity Center Cloud Connector** does not appear as an option, ensure that you have installed the IAM Identity Center Connector and have restarted your PingFederate server.
1. Click **Next** repeatedly until you arrive on the **Outbound Provisioning** page, and then click the **Configure Provisioning** button.
1. In the previous procedure, you copied the **SCIM endpoint** value in IAM Identity Center. Paste that value into the **SCIM URL** field in the PingFederate console. Also, in the previous procedure you copied the **Access token** value in IAM Identity Center. Paste that value into the **Access Token** field in the PingFederate console. Click **Save**.
1. On the **Channel Configuration (Configure Channels)** page, click **Create**.
1. Enter a **Channel Name** for this new provisioning channel (such as **AWSIAMIdentityCenterchannel**), and click **Next**.
1. On the **Source** page, choose the **Active Data Store** you want to use for your connection to IAM Identity Center, and click **Next**.
**Note**
If you have not yet configured a data source, you must do so now. See the Ping product documentation for information on how to choose and configure a data source in PingFederate.
1. On the **Source Settings** page, confirm all values are correct for your installation, then click **Next**.
1. On the **Source Location** page, enter settings appropriate to your data source, and then click **Next**. For example, if using Active Directory as an LDAP directory:
1. Enter the **Base DN** of your AD forest (such as **DC=myforest,DC=mydomain,DC=com**).
1. In **Users > Group DN**, specify a single group that contains all of the users that you want to provision to IAM Identity Center. If no such single group exists, create that group in AD, return to this setting, and then enter the corresponding DN.
1. Specify whether to search subgroups (**Nested Search**), and any required LDAP **Filter**.
1. In **Groups > Group DN**, specify a single group that contains all of the groups that you want to provision to IAM Identity Center. In many cases, this may be the same DN as you specified in the **Users** section. Enter **Nested Search** and **Filter** values as required.
1. On the **Attribute Mapping** page, ensure the following, and then click **Next**:
1. The **userName** field must be mapped to an **Attribute** that is formatted as an email (user@domain.com). It must also match the value that the user will use to log in to Ping. This value in turn is populated in the SAML `nameId` claim during federated authentication and used for matching to the user in IAM Identity Center. For example, when using Active Directory, you may choose to specify the `UserPrincipalName` as the **userName**.
1. Other fields suffixed with a **\$1** must be mapped to attributes that are non-null for your users.
1. On the **Activation & Summary** page, set the **Channel Status** to **Active** to cause the synchronization to start immediately after the configuration is saved.
1. Confirm that all configuration values on the page are correct, and click **Done**.
1. On the **Manage Channels** page, click **Save**.
1. At this point, provisioning starts. To confirm activity, you can view the **provisioner.log** file, located by default in the **pingfederate-/pingfederate/log** directory on your PingFederate server.
1. To verify that users and groups have been successfully synchronized to IAM Identity Center, return to the IAM Identity Center Console and choose **Users**. Synchronized users from PingFederate appear on the **Users** page. You can also view synchronized groups on the **Groups** page.
## (Optional) Step 3: Configure user attributes in PingFederate for access control in IAM Identity Center
This is an optional procedure for PingFederate if you choose to configure attributes you will use in IAM Identity Center to manage access to your AWS resources. The attributes that you define in PingFederate are passed in a SAML assertion to IAM Identity Center. You will then create a permission set in IAM Identity Center to manage access based on the attributes you passed from PingFederate.
Before you begin this procedure, you must first enable the [Attributes for access control](attributesforaccesscontrol.md) feature. For more information about how to do this, see [Enable and configure attributes for access control](configure-abac.md).
**To configure user attributes in PingFederate for access control in IAM Identity Center**
1. Sign on to the PingFederate administrative console.
1. Choose **Applications** from the top of the page, then click **SP Connections**.
1. Locate the application you created previously to form your SAML connection with IAM Identity Center, and click on the connection name.
1. Choose **Browser SSO** from the dark navigation headings near the top of the page. Then click on **Configure Browser SSO**.
1. On the **Configure Browser SSO** page, choose **Assertion Creation**, and then click on **Configure Assertion Creation**.
1. On the **Configure Assertion Creation** page, choose **Attribute Contract**.
1. On the **Attribute Contract** page, under **Extend the Contract** section, add a new attribute by performing the following steps:
1. In the text box, enter `https://aws.amazon.com/SAML/Attributes/AccessControl:AttributeName`, replace **AttributeName** with the name of the attribute you are expecting in IAM Identity Center. For example, `https://aws.amazon.com/SAML/Attributes/AccessControl:Department`.
1. For **Attribute Name Format**, choose **urn:oasis:names:tc:SAML:2.0:attrname-format:uri**.
1. Choose **Add**, and then choose **Next**.
1. On the **Authentication Source Mapping** page, choose the Adapter Instance configured with your application.
1. On the **Attribute Contract Fulfillment** page, choose the **Source** (*data store*) and **Value** (*data store attribute*) for the **Attribute Contract** `https://aws.amazon.com/SAML/Attributes/AccessControl:Department`.
**Note**
If you have not yet configured a data source, you will need to do so now. See the Ping product documentation for information on how to choose and configure a data source in PingFederate.
1. Click **Next** repeatedly until you arrive on the **Activation & Summary** page, and then click **Save**.
## (Optional) Passing attributes for access control
You can optionally use the [Attributes for access control](attributesforaccesscontrol.md) feature in IAM Identity Center to pass an `Attribute` element with the `Name` attribute set to `https://aws.amazon.com/SAML/Attributes/AccessControl:{TagKey}`. This element allows you to pass attributes as session tags in the SAML assertion. For more information about session tags, see [Passing session tags in AWS STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_session-tags.html) in the *IAM User Guide*.
To pass attributes as session tags, include the `AttributeValue` element that specifies the value of the tag. For example, to pass the tag key-value pair `CostCenter = blue`, use the following attribute.
```
blue
```
If you need to add multiple attributes, include a separate `Attribute` element for each tag.
## Troubleshooting
For general SCIM and SAML troubleshooting with PingFederate, see the following sections:
+ [Specific users fail to synchronize into IAM Identity Center from an external SCIM provider](troubleshooting.md#issue2)
+ [Issues regarding contents of SAML assertions created by IAM Identity Center](troubleshooting.md#issue1)
+ [Duplicate user or group error when provisioning users or groups with an external identity provider](troubleshooting.md#duplicate-user-group-idp)
+ For more information on PingFederate, see [PingFederate documentation](https://docs.pingidentity.com/pingfederate/latest/pf_pf_landing_page.html).
The following resources can help you troubleshoot as you work with AWS:
+ [AWS re:Post](https://repost.aws/) - Find FAQs and links to other resources to help you troubleshoot issues.
+ [AWS Support](https://aws.amazon.com/premiumsupport/) - Get technical support
# PingOne
IAM Identity Center supports automatic provisioning (synchronization) of user information from the PingOne product by Ping Identity (hereafter “Ping”) into IAM Identity Center. This provisioning uses the System for Cross-domain Identity Management (SCIM) v2.0 protocol. You configure this connection in PingOne using your IAM Identity Center SCIM endpoint and access token. When you configure SCIM synchronization, you create a mapping of your user attributes in PingOne to the named attributes in IAM Identity Center. This causes the expected attributes to match between IAM Identity Center and PingOne.
The following steps walk you through how to enable automatic provisioning of users from PingOne to IAM Identity Center using the SCIM protocol.
**Note**
Before you begin deploying SCIM, we recommend that you first review the [Considerations for using automatic provisioning](provision-automatically.md#auto-provisioning-considerations). Then continue reviewing additional considerations in the next section.
**Topics**
+ [
## Prerequisites
](#pingone-prereqs)
+ [
## Considerations
](#pingone-considerations)
+ [
## Step 1: Enable provisioning in IAM Identity Center
](#pingone-step1)
+ [
## Step 2: Configure provisioning in PingOne
](#pingone-step2)
+ [
## (Optional) Step 3: Configure user attributes in PingOne for access control in IAM Identity Center
](#pingone-step3)
+ [
## (Optional) Passing attributes for access control
](#pingone-passing-abac)
+ [
## Troubleshooting
](#pingone-troubleshooting)
## Prerequisites
You'll need the following before you can get started:
+ A PingOne subscription or free trial, with both federated authentication and provisioning capabilities. For more information about how to obtain a free trial, see the [https://www.pingidentity.com/en/trials.html](https://www.pingidentity.com/en/trials.html) website.
+ An IAM Identity Center-enabled account ([free](https://aws.amazon.com/single-sign-on/)). For more information, see [Enable IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/setup-enable-idc.html).
+ The PingOne IAM Identity Center application added to your PingOne admin portal. You can obtain the PingOne IAM Identity Center application from the PingOne Application Catalog. For general information, see [Add an application from the Application Catalog](https://docs.pingidentity.com/pingone/applications/p1_applicationcatalog.html) on the Ping Identity website.
+ A SAML connection from your PingOne instance to IAM Identity Center. After the PingOne IAM Identity Center application has been added to your PingOne admin portal, you must use it to configure a SAML connection from your PingOne instance to IAM Identity Center. Use the “download” and “import" metadata feature on both ends to exchange SAML metadata between PingOne and IAM Identity Center. For instructions on how to configure this connection, see the PingOne documentation.
+ If you replicated IAM Identity Center to additional Regions, you must update your identity provider configuration to enable access to AWS managed applications and AWS accounts from those Regions. For more details, see [Step 3: Update external IdP setup](replicate-to-additional-region.md#update-external-idp-setup). See the PingOne documentation for additional details.
## Considerations
The following are important considerations about PingOne that can affect how you implement provisioning with IAM Identity Center.
+ PingOne does not support provisioning of groups through SCIM. Contact Ping for the latest information on group support in SCIM for PingOne.
+ Users may continue to be provisioned from PingOne after disabling provisioning in the PingOne admin portal. If you need to terminate provisioning immediately, delete the relevant SCIM bearer token, and/or disable [Provision users and groups from an external identity provider using SCIM](provision-automatically.md) in IAM Identity Center.
+ If an attribute for a user is removed from the data store configured in PingOne, that attribute will not be removed from the corresponding user in IAM Identity Center. This is a known limitation in PingOne’s provisioner implementation. If an attribute is modified, the change will be synchronized to IAM Identity Center.
+ The following are important notes regarding your SAML configuration in PingOne:
+ IAM Identity Center supports only `emailaddress` as a `NameId` format. This means you need to choose a user attribute that is unique within your directory in PingOne, non-null, and formatted as an email/UPN (for example, user@domain.com) for your **SAML\$1SUBJECT** mapping in PingOne. **Email (Work)** is a reasonable value to use for test configurations with the PingOne built-in directory.
+ Users in PingOne with an email address containing a **\$1** character may be unable to sign in to IAM Identity Center, with errors such as `'SAML_215'` or `'Invalid input'`. To fix this, in PingOne, choose the **Advanced** option for the **SAML\$1SUBJECT** mapping in **Attribute Mappings**. Then set **Name ID Format to send to SP:** to **urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress** in the drop-down menu.
## Step 1: Enable provisioning in IAM Identity Center
In this first step, you use the IAM Identity Center console to enable automatic provisioning.
**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**.
Now that you have set up provisioning in the IAM Identity Center console, you need to complete the remaining tasks using the PingOne IAM Identity Center application. These steps are described in the following procedure.
## Step 2: Configure provisioning in PingOne
Use the following procedure in the PingOne IAM Identity Center application to enable provisioning with IAM Identity Center. This procedure assumes that you have already added the PingOne IAM Identity Center application to your PingOne admin portal. If you have not yet done so, refer to [Prerequisites](#pingone-prereqs), and then complete this procedure to configure SCIM provisioning.
**To configure provisioning in PingOne**
1. Open the PingOne IAM Identity Center application that you installed as part of configuring SAML for PingOne (**Applications** > **My Applications**). See [Prerequisites](#pingone-prereqs).
1. Scroll to the bottom of the page. Under **User Provisioning**, choose the **complete** link to navigate to the user provisioning configuration of your connection.
1. On the **Provisioning Instructions** page, choose **Continue to Next Step**.
1. In the previous procedure, you copied the **SCIM endpoint** value in IAM Identity Center. Paste that value into the **SCIM URL** field in the PingOne IAM Identity Center application. Also, in the previous procedure you copied the **Access token** value in IAM Identity Center. Paste that value into the **ACCESS\$1TOKEN** field in the PingOne IAM Identity Center application.
1. For **REMOVE\$1ACTION**, choose either **Disabled** or **Deleted** (see the description text on the page for more details).
1. On the **Attribute Mapping** page, choose a value to use for the **SAML\$1SUBJECT** (`NameId`) assertion, following guidance from [Considerations](#pingone-considerations) earlier on this page. Then choose **Continue to Next Step**.
1. On the **PingOne App Customization - IAM Identity Center** page, make any desired customization changes (optional), and click **Continue to Next Step**.
1. On the **Group Access** page, choose the groups containing the users you would like to enable for provisioning and single sign-on to IAM Identity Center. Choose **Continue to Next Step**.
1. Scroll to the bottom of the page, and choose **Finish** to start provisioning.
1. To verify that users have been successfully synchronized to IAM Identity Center, return to the IAM Identity Center console and choose **Users**. Synchronized users from PingOne will appear on the **Users** page. These users can now be assigned to accounts and applications within IAM Identity Center.
Remember that PingOne does not support provisioning of groups or group memberships through SCIM. Contact Ping for more information.
## (Optional) Step 3: Configure user attributes in PingOne for access control in IAM Identity Center
This is an optional procedure for PingOne if you choose to configure attributes for IAM Identity Center to manage access to your AWS resources. The attributes that you define in PingOne is passed in a SAML assertion to IAM Identity Center. You then create a permission set in IAM Identity Center to manage access based on the attributes you passed from PingOne.
Before you begin this procedure, you must first enable the [Attributes for access control](attributesforaccesscontrol.md) feature. For more information about how to do this, see [Enable and configure attributes for access control](configure-abac.md).
**To configure user attributes in PingOne for access control in IAM Identity Center**
1. Open the PingOne IAM Identity Center application that you installed as part of configuring SAML for PingOne (**Applications > My Applications**).
1. Choose **Edit**, and then choose **Continue to Next Step** until you get to the **Attribute Mappings** page.
1. On the **Attribute Mappings** page, choose **Add new attribute**, and then do the following. You must perform these steps for each attribute you will add for use in IAM Identity Center for access control.
1. In the **Application Attribute** field, enter `https://aws.amazon.com/SAML/Attributes/AccessControl:AttributeName`. Replace *AttributeName* with the name of the attribute you are expecting in IAM Identity Center. For example, `https://aws.amazon.com/SAML/Attributes/AccessControl:Email`.
1. In the **Identity Bridge Attribute or Literal Value** field, choose user attributes from your PingOne directory. For example, **Email (Work)**.
1. Choose **Next** a few times, and then choose **Finish**.
## (Optional) Passing attributes for access control
You can optionally use the [Attributes for access control](attributesforaccesscontrol.md) feature in IAM Identity Center to pass an `Attribute` element with the `Name` attribute set to `https://aws.amazon.com/SAML/Attributes/AccessControl:{TagKey}`. This element allows you to pass attributes as session tags in the SAML assertion. For more information about session tags, see [Passing session tags in AWS STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_session-tags.html) in the *IAM User Guide*.
To pass attributes as session tags, include the `AttributeValue` element that specifies the value of the tag. For example, to pass the tag key-value pair `CostCenter = blue`, use the following attribute.
```
blue
```
If you need to add multiple attributes, include a separate `Attribute` element for each tag.
## Troubleshooting
For general SCIM and SAML troubleshooting with PingOne, see the following sections:
+ [Specific users fail to synchronize into IAM Identity Center from an external SCIM provider](troubleshooting.md#issue2)
+ [Issues regarding contents of SAML assertions created by IAM Identity Center](troubleshooting.md#issue1)
+ [Duplicate user or group error when provisioning users or groups with an external identity provider](troubleshooting.md#duplicate-user-group-idp)
+ For more information on PingOne, see [PingOne documentation](https://docs.pingidentity.com/pingone/p1_cloud__platform_main_landing_page.html).
The following resources can help you troubleshoot as you work with AWS:
+ [AWS re:Post](https://repost.aws/) - Find FAQs and links to other resources to help you troubleshoot issues.
+ [AWS Support](https://aws.amazon.com/premiumsupport/) - Get technical support
# Configure user access with the default IAM Identity Center directory
When you enable IAM Identity Center for the first time, it is automatically configured with an Identity Center directory as your default identity source, so you do not need to choose an identity source. If your organization uses another identity provider such as Microsoft Active Directory, Microsoft Entra ID, or Okta consider integrating that identity source with IAM Identity Center instead of using the default configuration.
**Objective**
In this tutorial, you'll use the default directory as your identity source and an IAM Identity Center organization instance to set up and test an administrative user. This administrative user creates and manages users and groups and grants AWS access with permission sets. In the next steps, you'll create the following:
+ An administrative user named *Nikki Wolf*
+ A group named *Admin team*
+ A permission set named *AdminAccess*
To verify everything was created correctly, you'll sign in and set the administrative user's password. After completing this tutorial, you can use the administrative user to add more users in IAM Identity Center, create additional permission sets, and set up organizational access to applications. Alternatively, if you want to grant users access to application, you can follow [step 1](#gs-qs-step1) of this procedure and [configure application access](manage-your-applications.md).
## Prerequisites
The following prerequisites are needed to complete this tutorial:
+ [Enable IAM Identity Center](enable-identity-center.md) and have an [organization instance of IAM Identity Center](organization-instances-identity-center.md).
+ If you have an [account instance](account-instances-identity-center.md) of IAM Identity Center, you can create users and groups as well as grant them access to applications. For more information, see [Application access](manage-your-applications.md).
+ Sign in to the AWS Management Console and access the IAM Identity Center console either as a:
+ **New to AWS (root user)** – Sign in as the account owner by choosing **AWS account root user** and entering your AWS account email address. On the next page, enter your password.
+ **Already using AWS (IAM credentials)** – Sign in using your IAM credentials with administrative permissions.
+ For more help signing in to the AWS Management Console, see [AWS Sign-In Guide.](https://docs.aws.amazon.com//signin/latest/userguide/how-to-sign-in.html)
+ You can configure multi-factor authentication for your IAM Identity Center users. For more information, see [Configure MFA in IAM Identity Center](mfa-configure.md).
## Step 1: Add a user
1. Open the [IAM Identity Center console](https://console.aws.amazon.com/singlesignon).
1. In the IAM Identity Center navigation pane, choose **Users**, then select **Add user**.
1. On the **Specify user details** page, complete the following information:
+ **Username** - For this tutorial, enter *nikkiw*.
When creating users, choose usernames that are easy to remember. Your users must remember the username to sign in to the AWS access portal and you cannot change it later.
+ **Password** - Choose **Send an email to this user with password setup instructions (Recommended)**.
This option sends the user an email addressed from Amazon Web Services, with the subject line **Invitation to join IAM Identity Center**. The email comes from either `no-reply@signin.aws` or `no-reply@login.awsapps.com`. Add these email addresses to your approved senders list.
+ **Email address** - Enter an email address for the user where you can receive the email. Then, enter it again to confirm it. Each user must have a unique email address.
+ **First name** - Enter the first name for the user. For this tutorial, enter *Nikki*.
+ **Last name** - Enter the last name for the user. For this tutorial, enter *Wolf*.
+ **Display name** - The default value is the first and last name of the user. If you want to change the display name, you can enter something different. The display name is visible in the sign-in portal and users list.
+ Complete the optional information if desired. It isn’t used during this tutorial and you can change it later.
1. Choose **Next**. The **Add user to groups** page appears. We're going to create a group to assign administrative permissions to instead of giving them directly to *Nikki*.
Choose **Create group**
A new browser tab opens to display the **Create group** page.
1. Under **Group details**, in **Group name** enter a name for the group. We recommend a group name that identifies the role of the group. For this tutorial, enter *Admin team*.
1. Choose **Create group**
1. Close the **Groups** browser tab to return to the **Add user** browser tab
1. In the **Groups** area, select the **Refresh** button. The *Admin team* group appears in the list.
Select the checkbox next to *Admin team*, and then choose **Next**.
1. On the **Review and add user** page, confirm the following:
+ Primary information appears as you intended
+ Groups shows the user added to the group you created
If you want to make changes, choose **Edit**. When all details are correct choose **Add user**.
A notification message informs you that the user was added.
Next, you'll add administrative permissions for the *Admin team* group so that *Nikki* has access to resources.
## Step 2: Add administrative permissions
**Important**
Follow these steps only if you enabled an [organization instance of IAM Identity Center](identity-center-instances.md).
1. In the IAM Identity Center navigation pane, under **Multi-account permissions**, choose **AWS accounts**.
1. On the **AWS accounts** page the **Organizational structure** displays your organization with your accounts underneath it in the hierarchy. Select the checkbox for your management account, then select **Assign users or groups**.
1. The **Assign users and groups** workflow displays. It consists of three steps:
1. For **Step 1: Select users and groups** choose the *Admin team* group you created. Then choose **Next**.
1. For **Step 2: Select permission sets** choose **Create permission set** to open a new tab that steps you through the three sub-steps involved in creating a permission set.
1. For **Step 1: Select permission set type** complete the following:
+ In **Permission set type**, choose **Predefined permission set**.
+ In **Policy for predefined permission set**, choose **AdministratorAccess**.
Choose **Next**.
1. For **Step 2: Specify permission set details**, keep the default settings, and choose **Next**.
The default settings create a permission set named *AdministratorAccess* with session duration set to one hour. You can change the name of the permission set by entering a new name in the **Permission set name** field.
1. For **Step 3: Review and create**, verify that the **Permission set type** uses the AWS managed policy **AdministratorAccess**. Choose **Create**. On the **Permission sets** page a notification appears informing you that the permission set was created. You can close this tab in your web browser now.
On the **Assign users and groups** browser tab, you are still on **Step 2: Select permission sets** from which you started the create permission set workflow.
In the **Permissions sets** area, choose the **Refresh** button. The *AdministratorAccess* permission set you created appears in the list. Select the check box for that permission set and then choose **Next**.
1. On the **Step 3: Review and submit assignments** page, confirm that the *Admin team* group is selected and that the *AdministratorAccess* permission set is selected, then choose **Submit**.
The page updates with a message that your AWS account is being configured. Wait until the process completes.
You are returned to the AWS accounts page. A notification message informs you that your AWS account has been reprovisioned and the updated permission set applied.
**Congratulations\$1**
You have successfully set up your first user, group, and permission set.
In the next portion of this tutorial you'll test *Nikki's* access by signing in to the AWS access portal with their administrative credentials and set their password. Sign out of the console now.
## Step 3: Test user access
Now that *Nikki Wolf* is a user in your organization, they can sign in and access the resources to which they are granted permission according to their permission set. To verify that the user is correctly configured, in this next step you'll use *Nikki's* credentials to sign in and set up their password. When you added the user *Nikki Wolf* in Step 1 you chose to have *Nikki* receive an email with password setup instructions. It's time to open that email and do the following:
1. In the email, select the **Accept invitation** link to accept the invitation.
**Note**
The email also includes *Nikki's* user name and the AWS access portal URL that they'll use to sign in to the organization. Record this information for future use.
You are taken to the **New user sign up** page where you can set *Nikki's* password and [register their MFA device](enable-mfa.md).
1. After setting *Nikki's* password, you are navigated to the **Sign in** page. Enter *nikkiw* and choose **Next**, then enter *Nikki's* password and choose **Sign in**.
1. The AWS access portal opens displaying the organization and applications you can access.
Select the organization to expand it into a list of AWS accounts then select the account to display the roles that you can use to access resources in the account.
Each permission set has two management methods you can use, either **Role** or **Access keys**.
+ **Role**, for example *AdministratorAccess* - Opens the AWS Console Home.
+ **Access keys** - Provides credentials that you can use with the AWS CLI or and AWS SDK. Includes the information for using either short-term credentials that automatically refresh or short-term access keys. For more information, see [Getting IAM Identity Center user credentials for the AWS CLI or AWS SDKs](howtogetcredentials.md).
1. Choose the **Role** link to sign in to the AWS Console Home.
You are signed in and navigated to the AWS Console Home page. Explore the console and confirm that you have the access you expected.
## Next steps
Now that you've created an administrative user in IAM Identity Center, you can:
+ [Assign applications](manage-your-applications.md)
+ [Add other users](addusers.md)
+ [Assign users to accounts](assignusers.md)
+ [Configure additional permission sets](howtocreatepermissionset.md)
**Note**
You can assign multiple permission sets to the same user. To follow the best practice of applying least-privilege permissions, after you create your administrative user, create a more restrictive permission set and assign it to the same user. That way, you can access your AWS account with only the permissions that you require, rather than administrative permissions.
After your users [ accept their invitation](howtoactivateaccount.md) to activate their account and they sign into the AWS access portal, the only items that appear in the portal are for the AWS accounts, roles, and applications to which they are assigned.
## Video tutorials
As an additional resource, you can use these video tutorials to learn more about setting up external identity providers:
+ [Migrating between external identity providers in AWS IAM Identity Center](https://www.youtube.com/watch?v=A87tSiBdSnU)
+ [Federating your existing AWS IAM Identity Center instance with Microsoft Entra ID](https://www.youtube.com/watch?v=iSCuTJNeN6c)