# External identity providers


With IAM Identity Center, you can connect your existing workforce identities from external identity providers (IdPs) through the Security Assertion Markup Language (SAML) 2.0 and System for Cross-Domain Identity Management (SCIM) protocols. This enables your users to sign in to the AWS access portal with their corporate credentials. They can then navigate to their assigned accounts, roles, and applications hosted in external IdPs.

For example, you can connect an external IdP such as Okta or Microsoft Entra ID, to IAM Identity Center. Your users can then sign in to the AWS access portal with their existing Okta or Microsoft Entra ID credentials. To control what your users can do once they've signed in, you can assign them access permissions centrally across all the accounts and applications in your AWS organization. In addition, developers can simply sign in to the AWS Command Line Interface (AWS CLI) using their existing credentials, and benefit from automatic short-term credential generation and rotation.

If you are using a self-managed directory in Active Directory or an AWS Managed Microsoft AD, see [Microsoft AD directory](manage-your-identity-source-ad.md).

**Note**  
The SAML protocol does not provide a way to query the IdP to learn about users and groups. Therefore, you must make IAM Identity Center aware of those users and groups by provisioning them into IAM Identity Center.

## Provisioning when users come from an external IdP


When using an external IdP, you must provision all applicable users and groups into IAM Identity Center before you can make any assignments to AWS accounts or applications. To do this, you can configure [Provision users and groups from an external identity provider using SCIM](provision-automatically.md) for your users and groups, or use [Manual provisioning](provision-automatically.md#provision-manually). Regardless of how you provision users, IAM Identity Center redirects the AWS Management Console, command line interface, and application authentication to your external IdP. IAM Identity Center then grants access to those resources based on policies you create in IAM Identity Center. For more information about provisioning, see [User and group provisioning](users-groups-provisioning.md#user-group-provision).

**Topics**
+ [

## Provisioning when users come from an external IdP
](#provisioning-when-external-idp)
+ [

# How to connect to an external identity provider
](how-to-connect-idp.md)
+ [

# How to change an external identity provider's metadata in IAM Identity Center
](how-to-change-idp-metadata.md)
+ [

# Using SAML and SCIM identity federation with external identity providers
](other-idps.md)
+ [

# SCIM profile and SAML 2.0 implementation
](scim-profile-saml.md)

# How to connect to an external identity provider
Connect an external identity provider

There are different prerequisites, considerations, and provisioning procedures for the supported external IdPs. There are step-by-step tutorials available for several IdPs:
+ [CyberArk](cyberark-idp.md)
+ [Google Workspace](gs-gwp.md)
+ [JumpCloud](jumpcloud-idp.md)
+ [Microsoft Entra ID](idp-microsoft-entra.md)
+ [Okta](gs-okta.md)
+ [OneLogin](onelogin-idp.md)
+ [Ping Identity](pingidentity.md)

For more information on the considerations for external IdPs that IAM Identity Center supports, see [Using SAML and SCIM identity federation with external identity providers](other-idps.md).

 The following procedure provides a general overview of the procedure that is used with all external identity providers.

**To connect to an external identity provider**

1. Open the [IAM Identity Center console](https://console.aws.amazon.com/singlesignon).

1. Choose **Settings**.

1. On the **Settings** page, choose the **Identity source** tab, and then choose **Actions > Change identity source**.

1. Under **Choose identity source**, select **External identity provider**, and then choose **Next**. 

1. Under **Configure external identity provider**, do the following:

   1. Under **Service provider metadata**, choose **Download metadata file** to download the metadata file and save it on your system. The IAM Identity Center SAML metadata file is required by your external identity provider.
**Note**  
The SAML metadata file you download contains both IPv4-only and dual-stack assertion consumer service (ACS) URLs. Further, if your IAM Identity Center is replicated to additional Regions, the metadata file contains ACS URLs for each additional Region. If your external IdP has a limit on the number of ACS URLs, you will need to remove the unnecessary ACS URLs. For example, if your organization has fully adopted dual-stack endpoints and no longer uses IP4v-only ones, you can remove the latter. An alternative approach is to not use the metadata file but to copy and paste the ACS URLs into the external IdP.

   1. Under **Identity provider metadata**, choose **Choose file**, and locate the metadata file that you downloaded from your external identity provider. Then upload the file. This metadata file contains the necessary public x509 certificate used to trust messages that are sent from the IdP.

   1. Choose **Next**.
**Important**  
Changing your source to or from Active Directory removes all existing user and group assignments. You must manually reapply assignments after you have successfully changed your source.

1. After you read the disclaimer and are ready to proceed, enter **ACCEPT**.

1. Choose **Change identity source**. A status message informs you that you successfully changed the identity source.

# How to change an external identity provider's metadata in IAM Identity Center
Change an external identity provider's metadata

You can change your external identity provider's metadata which you previously supplied to the IAM Identity Center. These changes affect your users' ability to sign in and access AWS resources through IAM Identity Center. The following procedure describes how to update your external IdP's metadata that is stored in IAM Identity Center. To complete this procedure, you'll need an Organization instance of IAM Identity Center. For more information, see [Organization and account instances of IAM Identity Center](identity-center-instances.md).

**To change an external identity provider's metadata**

1. Open the [IAM Identity Center console](https://console.aws.amazon.com/singlesignon).

1. Choose **Settings**.

1. On the **Settings** page, choose the **Identity source** tab. Choose **Actions** and then choose **Manage Authentication**.

1. In the **Identity provider metadata** section, choose **Edit IdP metadata**. You can make the changes to the IdP sign-in URL and or IdP issuer URL for your external IdP on this page. Choose **Save changes** when you've made all the necessary changes.

# Using SAML and SCIM identity federation with external identity providers
Using SAML and SCIM identity federation

IAM Identity Center implements the following standards-based protocols for identity federation:
+ SAML 2.0 for user authentication
+ SCIM for provisioning

Any identity provider (IdP) that implements these standard protocols is expected to interoperate successfully with IAM Identity Center, with the following special considerations:
+ **SAML**
  + IAM Identity Center requires a SAML nameID format of email address (that is, `urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress`).
  + The value of the nameID field in assertions must be an RFC 2822 ([https://tools.ietf.org/html/rfc2822](https://tools.ietf.org/html/rfc2822)) addr-spec compliant (“`name@domain.com`”) string ([https://tools.ietf.org/html/rfc2822\$1section-3.4.1](https://tools.ietf.org/html/rfc2822#section-3.4.1)).
  + The metadata file cannot be over 75000 characters.
  + The metadata must contain an entityId, X509 certificate, and SingleSignOnService as part of the sign-in URL.
  + An encryption key is not supported.
  + IAM Identity Center does not support signing SAML authentication requests that it sends to external IdPs.
  + The IdP has to support multiple assertion consumer service (ACS) URLs if you plan to replicate IAM Identity Center to additional Regions, and fully take advantage of the benefits of a multi-Region IAM Identity Center. For more information, see [Using IAM Identity Center across multiple AWS Regions](multi-region-iam-identity-center.md). Using a single ACS URL may affect the user experience in additional Regions. Your primary Region will continue to function normally. For more information about the user experience in additional Regions with a single ACS URL, see [Using AWS managed applications without multiple ACS URLs](multi-region-workforce-access.md#aws-app-use-without-multiple-acs-urls) and [AWS account access resiliency without multiple ACS URLs](multi-region-failover.md#account-access-resiliency-without-multiple-acs-url).
+ **SCIM**
  + The IAM Identity Center SCIM implementation is based on SCIM RFCs 7642 ([https://tools.ietf.org/html/rfc7642](https://tools.ietf.org/html/rfc7642)), 7643 ([https://tools.ietf.org/html/rfc7643](https://tools.ietf.org/html/rfc7643)), and 7644 ([https://tools.ietf.org/html/rfc7644](https://tools.ietf.org/html/rfc7644)), and the interoperability requirements laid out in the March 2020 draft of the FastFed Basic SCIM Profile 1.0 ([https://openid.net/specs/fastfed-scim-1\$10-02.html\$1rfc.section.4](https://openid.net/specs/fastfed-scim-1_0-02.html#rfc.section.4)). Any differences between these documents and the current implementation in IAM Identity Center are described in the [Supported API operations](https://docs.aws.amazon.com/singlesignon/latest/developerguide/supported-apis.html) section of the *IAM Identity Center SCIM Implementation Developer Guide*.

IdPs that do not conform to the standards and considerations mentioned above are not supported. Please contact your IdP for questions or clarifications regarding the conformance of their products to these standards and considerations.

If you have any issues connecting your IdP to IAM Identity Center, we recommend that you check:
+ AWS CloudTrail logs by filtering on the event name **ExternalIdPDirectoryLogin**
+ IdP-specific logs and/or debug logs
+ [Troubleshooting IAM Identity Center issues](troubleshooting.md)

**Note**  
Some IdPs, such as the ones in the [IAM Identity Center identity source tutorials](tutorials.md), offer a simplified configuration experience for IAM Identity Center in the form of an “application” or “connector” built specifically for IAM Identity Center. If your IdP provides this option, we recommend that you use it, being careful to choose the item that’s built specifically for IAM Identity Center. Other items called “AWS”, “AWS federation”, or similar generic "AWS" names may use other federation approaches and/or endpoints, and may not work as expected with IAM Identity Center.

# SCIM profile and SAML 2.0 implementation


Both SCIM and SAML are important considerations for configuring IAM Identity Center. 

## SAML 2.0 implementation


IAM Identity Center supports identity federation with [SAML (Security Assertion Markup Language)](https://wiki.oasis-open.org/security) 2.0. This allows IAM Identity Center to authenticate identities from external identity providers (IdPs). SAML 2.0 is an open standard used for securely exchanging SAML assertions. SAML 2.0 passes information about a user between a SAML authority (called an identity provider or IdP), and a SAML consumer (called a service provider or SP). The IAM Identity Center service uses this information to provide federated single sign-on. Single sign-on allows users to access AWS accounts and configured applications based on their existing identity provider credentials. 

IAM Identity Center adds SAML IdP capabilities to your IAM Identity Center store, AWS Managed Microsoft AD, or to an external identity provider. Users can then single sign-on into services that support SAML, including the AWS Management Console and third-party applications such as Microsoft 365, Concur, and Salesforce. 

The SAML protocol however doesn't provide a way to query the IdP to learn about users and groups. Therefore, you must make IAM Identity Center aware of those users and groups by provisioning them into IAM Identity Center. 

## SCIM profile


IAM Identity Center provides support for the System for Cross-domain Identity Management (SCIM) v2.0 standard. SCIM keeps your IAM Identity Center identities in sync with identities from your IdP. This includes any provisioning, updates, and deprovisioning of users between your IdP and IAM Identity Center.

For more information about how to implement SCIM, see [Provision users and groups from an external identity provider using SCIM](provision-automatically.md). For additional details about IAM Identity Center’s SCIM implementation, see the [IAM Identity Center SCIM Implementation Developer Guide](https://docs.aws.amazon.com/singlesignon/latest/developerguide/what-is-scim.html).

**Topics**
+ [

## SAML 2.0 implementation
](#samlfederationconcept)
+ [

## SCIM profile
](#scim-profile)
+ [

# Provision users and groups from an external identity provider using SCIM
](provision-automatically.md)
+ [

# Rotate SAML 2.0 certificates
](managesamlcerts.md)

# Provision users and groups from an external identity provider using SCIM
Provision an external identity provider

IAM Identity Center supports automatic provisioning (synchronization) of user and group information from your identity provider (IdP) into IAM Identity Center using the System for Cross-domain Identity Management (SCIM) v2.0 protocol. When you configure SCIM synchronization, you create a mapping of your identity provider (IdP) user attributes to the named attributes in IAM Identity Center. This causes the expected attributes to match between IAM Identity Center and your IdP. You configure this connection in your IdP using your SCIM endpoint for IAM Identity Center and a bearer token that you create in IAM Identity Center.

**Topics**
+ [

## Considerations for using automatic provisioning
](#auto-provisioning-considerations)
+ [

## How to monitor access token expiry
](#access-token-expiry)
+ [

# Generate an access token
](generate-token.md)
+ [

# Enable automatic provisioning
](how-to-with-scim.md)
+ [

# Delete an access token
](delete-token.md)
+ [

# Disable automatic provisioning
](disable-provisioning.md)
+ [

# Rotate an access token
](rotate-token.md)
+ [

# Audit and reconcile auto-provisioned resources
](reconcile-auto-provisioning.md)
+ [

## Manual provisioning
](#provision-manually)

## Considerations for using automatic provisioning


Before you begin deploying SCIM, we recommend that you first review the following important considerations about how it works with IAM Identity Center. For additional provisioning considerations, see the [IAM Identity Center identity source tutorials](tutorials.md) applicable to your IdP.
+ If you are provisioning a primary email address, this attribute value must be unique for each user. In some IdPs, the primary email address might not be a real email address. For example, it might be a Universal Principal Name (UPN) that only looks like an email. These IdPs may have a secondary or “other” email address that contains the user’s real email address. You must configure SCIM in your IdP to map the non-Null unique email address to the IAM Identity Center primary email address attribute. And you must map the users non-Null unique sign-in identifier to the IAM Identity Center user name attribute. Check to see whether your IdP has a single value that is both the sign-in identifier and the user’s email name. If so, you can map that IdP field to both the IAM Identity Center primary email and the IAM Identity Center user name.
+ For SCIM synchronization to work, every user must have a **First name**, **Last name**, **Username** and **Display name** value specified. If any of these values are missing from a user, that user will not be provisioned.
+ If you need to use third-party applications, you will first need to map the outbound SAML subject attribute to the user name attribute. If the third-party application needs a routable email address, you must provide the email attribute to your IdP.
+ SCIM provisioning and update intervals are controlled by your identity provider. Changes to users and groups in your identity provider are only reflected in IAM Identity Center after your identity provider sends those changes to IAM Identity Center. Check with your identity provider for details on the frequency of user and group updates.
+ Currently, multivalue attributes (such as multiple emails or phone numbers for a given user) are not provisioned with SCIM. Attempts to synchronize multivalue attributes into IAM Identity Center with SCIM will fail. To avoid failures, ensure that only a single value is passed for each attribute. If you have users with multivalue attributes, remove or modify the duplicate attribute mappings in SCIM at your IdP for the connection to IAM Identity Center.
+ Verify that the `externalId` SCIM mapping at your IdP corresponds to a value that is unique, always present, and least likely to change for your users. For example, your IdP might provide a guaranteed `objectId` or other identifier that’s not affected by changes to user attributes like name and email. If so, you can map that value to the SCIM `externalId` field. This ensures that your users won’t lose AWS entitlements, assignments, or permissions if you need to change their name or email.
+ Users who have not yet been assigned to an application or AWS account cannot be provisioned into IAM Identity Center. To synchronize users and groups, make sure that they are assigned to the application or other setup that represents your IdP’s connection to IAM Identity Center.
+ User deprovisioning behavior is managed by the identity provider and may vary by their implementation. Check with your identity provider for details on user deprovisioning.
+ After setting up automatic provisioning with SCIM for your IdP, you can no longer add or edit users in the IAM Identity Center console. If you need to add or modify a user, you must do so from your external IdP or identity source.

For more information about IAM Identity Center’s SCIM implementation, see the [IAM Identity Center SCIM Implementation Developer Guide](https://docs.aws.amazon.com/singlesignon/latest/developerguide/what-is-scim.html).

## How to monitor access token expiry


SCIM access tokens are generated with a validity of one year. When your SCIM access token is set to expire in 90 days or less, AWS sends you reminders in the IAM Identity Center console and over the AWS Health Dashboard to help you rotate the token. By rotating the SCIM access token before it expires, you continually secure automatic provisioning of user and group information. If the SCIM access token expires, the synchronization of user and group information from your identity provider into IAM Identity Center stops, so automatic provisioning can no longer make updates or create and delete information. Disruption to automatic provisioning may impose increased security risks and impact access to your services.

The Identity Center console reminders persist until you rotate the SCIM access token and delete any unused or expired access tokens. The AWS Health Dashboard events are renewed weekly between 90 to 60 days, twice per week from 60 to 30 days, three times per week from 30 to 15 days, and daily from 15 days until the SCIM access tokens expires. 

# Generate an access token


Use the following procedure to generate a new access token in the IAM Identity Center console.

**Note**  
This procedure requires that you have previously enabled automatic provisioning. For more information, see [Enable automatic provisioning](how-to-with-scim.md).

**To generate a new access token**

1. In the [IAM Identity Center console](https://console.aws.amazon.com/singlesignon), choose **Settings** in the left navigation pane.

1. On the **Settings** page, choose the **Identity source** tab, and then choose **Actions > Manage provisioning**.

1. On the **Automatic provisioning** page, under **Access tokens**, choose **Generate token**.

1. In the **Generate new access token** dialog box, copy the new access token and save it in a safe place.

1. Choose **Close**.

# Enable automatic provisioning


Use the following procedure to enable automatic provisioning of users and groups from your IdP to IAM Identity Center using the SCIM protocol.

**Note**  
Before you begin this procedure, we recommend that you first review provisioning considerations that are applicable to your IdP. For more information, see the [IAM Identity Center identity source tutorials](tutorials.md) for your IdP.

**To enable automatic provisioning in IAM Identity Center**

1. After you have completed the prerequisites, open the [IAM Identity Center console](https://console.aws.amazon.com/singlesignon).

1. Choose **Settings** in the left navigation pane.

1. On the **Settings** page, locate the **Automatic provisioning** information box, and then choose **Enable**. This immediately enables automatic provisioning in IAM Identity Center and displays the necessary SCIM endpoint and access token information.

1. In the **Inbound automatic provisioning** dialog box, copy the SCIM endpoint and access token. You'll need to paste these in later when you configure provisioning in your IdP.

   1. **SCIM endpoint** - For example, https://scim.*us-east-2*.amazonaws.com/*11111111111-2222-3333-4444-555555555555*/scim/v2

   1. **Access token** - Choose **Show token** to copy the value.
**Warning**  
This is the only time where you can obtain the SCIM endpoint and access token. Ensure you copy these values before moving forward. You will enter these values to configure automatic provisioning in your IdP later in this tutorial. 

1. Choose **Close**.

After you complete this procedure, you must configure automatic provisioning in your IdP. For more information, see the [IAM Identity Center identity source tutorials](tutorials.md) for your IdP.

# Delete an access token


Use the following procedure to delete an existing access token in the IAM Identity Center console.

**To to delete an existing access token**

1. In the [IAM Identity Center console](https://console.aws.amazon.com/singlesignon), choose **Settings** in the left navigation pane.

1. On the **Settings** page, choose the **Identity source** tab, and then choose **Actions > Manage provisioning**.

1. On the **Automatic provisioning** page, under **Access tokens**, select the access token you want to delete, and then choose **Delete**.

1. In the **Delete access token** dialog box, review the information, type **DELETE**, and then choose **Delete access token**.

# Disable automatic provisioning


Use the following procedure to disable automatic provisioning in the IAM Identity Center console.

**Important**  
You must delete the access token before you start this procedure. For more information, see [Delete an access token](delete-token.md).

**To disable automatic provisioning in the IAM Identity Center console**

1. In the [IAM Identity Center console](https://console.aws.amazon.com/singlesignon), choose **Settings** in the left navigation pane.

1. On the **Settings** page, choose the **Identity source** tab, and then choose **Actions > Manage provisioning**.

1. On the **Automatic provisioning** page, choose **Disable**.

1. In the **Disable automatic provisioning** dialog box, review the information, type **DISABLE**, and then choose **Disable automatic provisioning**.

# Rotate an access token


An IAM Identity Center directory supports up to two access tokens at a time. To generate an additional access token prior to any rotation, delete any expired or unused access tokens.

If your SCIM access token is close to expiring, you can use the following procedure to rotate an existing access token in the IAM Identity Center console.

**To rotate an access token**

1. In the [IAM Identity Center console](https://console.aws.amazon.com/singlesignon), choose **Settings** in the left navigation pane.

1. On the **Settings** page, choose the **Identity source** tab, and then choose **Actions > Manage provisioning**.

1. On the **Automatic provisioning** page, under **Access tokens**, make a note of the token ID of the token you want to rotate.

1. Follow the steps in [Generate an access token](generate-token.md) to create a new token. If you have already created the maximum number of SCIM access tokens, you will first need to delete one of the existing tokens.

1. Go to your identity provider's website and configure the new access token for SCIM provisioning, and then test connectivity to IAM Identity Center using the new SCIM access token. Once you've confirmed that provisioning is working successfully using the new token, continue to the next step in this procedure.

1. Follow the steps in [Delete an access token](delete-token.md) to delete the old access token you noted earlier. You can also use the token’s creation date as a hint for which token to remove.

# Audit and reconcile auto-provisioned resources


SCIM enables you to automatically provision users, groups, and group memberships from your identity source to IAM Identity Center. This guide helps you verify and reconcile these resources to maintain accurate synchronization.

## Why audit your resources?


Regular auditing helps ensure your access controls remain accurate and your identity provider (IdP) stays properly synchronized with IAM Identity Center. This is particularly important for security compliance and access management.

Resources you can audit:
+ Users
+ Groups
+ Group memberships

 You can use AWS Identity Store [APIs](https://docs.aws.amazon.com/singlesignon/latest/IdentityStoreAPIReference/welcome.html) or [CLI commands](https://docs.aws.amazon.com/cli/latest/reference/identitystore/) to conduct the audit and reconciliation. The following examples use AWS CLI commands. For API alternatives, refer to the [corresponding operations](https://docs.aws.amazon.com/singlesignon/latest/IdentityStoreAPIReference/API_Operations.html) in the * Identity Store API reference*. 

## How to audit resources


Here are examples for how to audit these resources using AWS CLI commands.

Before you begin, ensure you have:
+ Administrator access to IAM Identity Center.
+ AWS CLI installed and configured. For information, see the [https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html).
+ Required IAM permissions for Identity Store commands.

### Step 1: List current resources


You can view your current resources using the AWS CLI.

**Note**  
 When using the AWS CLI, pagination is handled automatically unless you specify `--no-paginate`. If you’re calling the API directly (for example, with an SDK or a custom script), handle the `NextToken` in the response. This ensures you retrieve all results across multiple pages. 

**Example for users**  

```
aws identitystore list-users \
  --region REGION \
  --identity-store-id IDENTITY_STORE_ID
```

**Example for groups**  

```
aws identitystore list-groups \
  --region REGION \
  --identity-store-id IDENTITY_STORE_ID
```

**Example for group memberships**  

```
aws identitystore list-group-memberships \
  --region REGION \
  --identity-store-id IDENTITY_STORE_ID
  --group-id GROUP_ID
```

### Step 2: Compare with your identity source


Compare the listed resources with your identity source to identify any discrepancies, such as:
+ Missing resources that should be provisioned in IAM Identity Center.
+ Extra resources that should be removed from IAM Identity Center.

**Example for users**  

```
# Create missing users
aws identitystore create-user \
  --identity-store-id IDENTITY_STORE_ID \
  --user-name USERNAME \
  --display-name DISPLAY_NAME \
  --name GivenName=FIRST_NAME,FamilyName=LAST_NAME \
  --emails Value=EMAIL,Primary=true

# Delete extra users
aws identitystore delete-user \
  --identity-store-id IDENTITY_STORE_ID \
  --user-id USER_ID
```

**Example for groups**  

```
# Create missing groups
aws identitystore create-group \
  --identity-store-id IDENTITY_STORE_ID \
  [group attributes]
  
# Delete extra groups
aws identitystore delete-group \
  --identity-store-id IDENTITY_STORE_ID \
  --group-id GROUP_ID
```

**Example for group memberships**  

```
# Add missing members
aws identitystore create-group-membership \
  --identity-store-id IDENTITY_STORE_ID \
  --group-id GROUP_ID \
  --member-id '{"UserId": "USER_ID"}'
  
# Remove extra members
aws identitystore delete-group-membership \
  --identity-store-id IDENTITY_STORE_ID \
  --membership-id MEMBERSHIP_ID
```

## Considerations

+ Commands are subject to [service quotas and API throttling](limits.md#ssothrottlelimits).
+ When you find many differences during reconciliation, make small, gradual changes to AWS Identity Store. This helps you avoid mistakes that affect multiple users.
+ SCIM synchronization can override your manual changes. Check your IdP settings to understand this behavior.

## Manual provisioning


Some IdPs do not have System for Cross-domain Identity Management (SCIM) support or have an incompatible SCIM implementation. In those cases, you can manually provision users through the IAM Identity Center console. When you add users to IAM Identity Center, ensure that you set the user name to be identical to the user name that you have in your IdP. At a minimum, you must have a unique email address and user name. For more information, see [Username and email address uniqueness](users-groups-provisioning.md#username-email-unique).

You must also manage all groups manually in IAM Identity Center. To do this, you create the groups and add them using the IAM Identity Center console. These groups do not need to match what exists in your IdP. For more information, see [Groups](users-groups-provisioning.md#groups-concept).

# Rotate SAML 2.0 certificates


IAM Identity Center uses certificates to set up a SAML trust relationship between IAM Identity Center and your external identity provider (IdP). When you add an external IdP in IAM Identity Center, you must also obtain at least one public SAML 2.0 X.509 certificate from the external IdP. That certificate is usually installed automatically during the IdP SAML metadata exchange during trust creation.

As an IAM Identity Center administrator, you'll occasionally need to replace older IdP certificates with newer ones. For example, you might need to replace an IdP certificate when the expiration date on the certificate approaches. The process of replacing an older certificate with a newer one is referred to as certificate rotation.

**Topics**
+ [

# Rotate a SAML 2.0 certificate
](rotatesamlcert.md)
+ [

# Certificate expiration status indicators
](samlcertexpirationindicators.md)

# Rotate a SAML 2.0 certificate


You may need to import certificates periodically in order to rotate invalid or expired certificates issued by your identity provider. This helps to prevent authentication disruption or downtime. All imported certificates are automatically active. Certificates should only be deleted after ensuring that they are no longer in use with the associated identity provider.

You should also consider that some IdPs might not support multiple certificates. In this case, the act of rotating certificates with these IdPs might mean a temporary service disruption for your users. Service is restored when the trust with that IdP has been successfully reestablished. Plan this operation carefully during off peak hours if possible.

**Note**  
As a security best practice, upon any signs of compromise or mishandling of an existing SAML certificate, you should immediately remove and rotate the certificate.

Rotating an IAM Identity Center certificate is a multistep process that involves the following:
+ Obtaining a new certificate from the IdP
+ Importing the new certificate into IAM Identity Center
+ Activating the new certificate in the IdP
+ Deleting the older certificate

Use all of the following procedures to complete the certificate rotation process while avoiding any authentication downtime.

**Step 1: Obtain a new certificate from the IdP**

Go to the IdP website and download their SAML 2.0 certificate. Make sure that the certificate file is downloaded in PEM encoded format. Most providers allow you to create multiple SAML 2.0 certificates in the IdP. It is likely that these will be marked as disabled or inactive. 

**Step 2: Import the new certificate into IAM Identity Center**

Use the following procedure to import the new certificate using the IAM Identity Center console.

1. In the [IAM Identity Center console](https://console.aws.amazon.com/singlesignon), choose **Settings**.

1. On the **Settings** page, choose the **Identity source** tab, and then choose **Actions > Manage authentication**.

1. On the **Manage SAML 2.0 certificates** page, choose **Import certificate**.

1. On the **Import SAML 2.0 certificate** dialog, choose **Choose file**, navigate to your certificate file and select it, and then choose **Import certificate**.

At this point, IAM Identity Center will trust all incoming SAML messages signed from both of the certificates that you have imported.

**Step 3: Activate the new certificate in the IdP**

Go back to the IdP website and mark the new certificate that you created earlier as primary or active. At this point all SAML messages signed by the IdP should be using the new certificate.

**Step 4: Delete the old certificate**

Use the following procedure to complete the certificate rotation process for your IdP. There must always be at least one valid certificate listed, and it cannot be removed.

**Note**  
Make sure that your identity provider is no longer signing SAML responses with this certificate before deleting it. 

1. On the **Manage SAML 2.0 certificates** page, choose the certificate that you want to delete. Choose **Delete**.

1. In the **Delete SAML 2.0 certificate** dialog box, type **DELETE** to confirm, and then choose **Delete**.

1. Return to the IdP’s website and perform the necessary steps to remove the older inactive certificate.

# Certificate expiration status indicators


The **Manage SAML 2.0 certificates** page displays colored status indicator icons in the **Expires on** column next to each certificate in the list. The following describes the criteria that IAM Identity Center uses to determine which icon is displayed for each certificate.
+ **Red** – Indicates that a certificate is expired.
+ **Yellow** – Indicates that a certificate expires in 90 days or less.
+ **Green** – Indicates that a certificate is valid and remains valid for at least 90 more days.

**To check the current status of a certificate**

1. In the [IAM Identity Center console](https://console.aws.amazon.com/singlesignon), choose **Settings**.

1. On the **Settings** page, choose the **Identity source** tab, and then choose **Actions > Manage authentication**.

1. On the **Manage SAML 2.0 authentication** page, under **Manage SAML 2.0 certificates**, review the status of the certificates in the list as indicated in the **Expires on** column.