AWS IAM Identity Center - AWS Prescriptive Guidance

AWS IAM Identity Center

AWS IAM Identity Center provides a single place to create or connect your growing workforce identities and centrally manage secure access for those identities across your AWS environment. You can enable IAM Identity Center in conjunction with AWS Organizations. This is the recommended approach to provide centrally managed access to multiple AWS accounts within your AWS organization and AWS managed applications.

AWS managed services, including Amazon Q, Amazon Q Developer, Amazon SageMaker Studio, and Amazon QuickSight, integrate and use IAM Identity Center for authentication and authorization. You connect your identity source only once to IAM Identity Center and manage workforce access to all onboarded AWS-managed applications. Identities from your existing corporate directories, such as Microsoft Entra ID, Okta, Google Workspace, and Microsoft Active Directory, must be provisioned into IAM Identity Center before you can look up users or groups to grant them single sign-on access to AWS managed services. IAM Identity Center also powers application-specific, user-centric experiences. For example, users of Amazon Q experience continuity as they move from one Amazon Q-integrated service to another.

Note

You can use IAM Identity Center capabilities individually. For example, you might choose to use Identity Center only to manage access to AWS managed services such as Amazon Q while using direct account federation and IAM roles to manage access to your AWS accounts.

Trusted identity propagation provides a streamlined single sign-on experience for users of query tools and business intelligence (BI) applications who require access to data in AWS services. Data access management is based on a user's identity, so administrators can grant access based on the user's existing user and group memberships. Trusted identity propagation is built on the OAuth 2.0 Authorization Framework, which allows applications to access and share user data securely without sharing passwords. 

AWS managed services that integrate with trusted identity propagation, such as Amazon Redshift query editor v2, Amazon EMR, and Amazon QuickSight, obtain tokens from IAM Identity Center directly. IAM Identity Center also provides an option for applications to exchange identity tokens and access tokens from an external OAuth 2.0 authorization server. User access to AWS services and other events is recorded in service-specific logs and in CloudTrail events, so auditors know what actions the users took and which resources they accessed.

To use trusted identity propagation, you must enable IAM Identity Center and provision users and groups. We recommend that you use an organization instance of IAM Identity Center.

Note

Trusted identity propagation doesn't require you to set up multi-account permissions (permission sets). You can enable IAM Identity Center and use it for trusted identity propagation only.

For more information, see the prerequisites and considerations for using trusted identity propagation and view the specific use cases supported by applications that can initiate identity propagation.

The AWS access portal provides authenticated users with single sign-on access to their AWS accounts and cloud applications. You can also use the credentials generated from the AWS access portal to configure AWS CLI or AWS SDK access to resources in your AWS accounts. This helps you eliminate the use of long-term credentials for programmatic access ,which significantly reduces the chances of credentials becoming compromised and improves your security posture.

You can also automate management of account and application access by using IAM Identity Center APIs.

IAM Identity Center is integrated with AWS CloudTrail, which provides a record of the actions taken by a user in IAM Identity Center. CloudTrail records API events such as a CreateUser API call, which is recorded when a user is either manually created or provisioned or synchronized to IAM identity Center from an external IdP by using the System for Cross-domain Identity Management (SCIM) protocol. Every event or log entry recorded in CloudTrail contains information about who generated the request. This capability helps you identify unexpected changes or activities that might require further investigation. For a complete list of supported IAM Identity Center operations in CloudTrail, see the IAM Identity Center documentation.

Connecting your existing identity source to IAM Identity Center

Identity federation is a common approach to building access control systems, which manage user authentication by using a central IdP and govern their access to multiple applications and services that act as service providers (SPs). IAM Identity Center gives you the flexibility to bring identities from your existing corporate identity source, including Okta, Microsoft Entra ID, Ping, Google Workspace, JumpCloud, OneLogin, on-premises Active Directory, and any SAML 2.0 compatible identity source.

Connecting your existing identity source to IAM Identity Center is the recommended approach, because it gives your workforce single sign-on access and a consistent experience across AWS services. It is also best practice to manage identities from a single location instead of maintaining multiple sources. IAM Identity Center supports identity federation with SAML 2.0, which is an open identity standard that allows IAM Identity Center to authenticate users from external IdPs. IAM Identity Center also provides support for the SCIM v2.0 standard. This standard enables automatic provisioning, updating, and deprovisioning of users and groups between any of the supported external IdPs and IAM Identity Center, except Google Workspace and PingOne, which currently support provisioning of users only through SCIM.

You can also connect other SAML 2.0-based external IdPs to IAM Identity Center, if they conform to specific standards and considerations.

You can also connect your existing Microsoft Active Directory to IAM Identity Center. This option allows you to synchronize users, groups, and group memberships from an existing Microsoft Active Directory by using AWS Directory Service. This option is suitable for large enterprises that are already managing identities, either in a self-managed Active Directory that's located on premises or in a directory in AWS Managed Microsoft AD. You can connect a directory in AWS Managed Microsoft AD to IAM Identity Center. You can also connect your self-managed directory in Active Directory to IAM Identity Center by establishing a two-way trust relationship that permits IAM Identity Center to trust your domain for authentication. Another method is to use AD Connector, which is a directory gateway that can redirect directory requests to your self-managed Active Directory without caching any information in the cloud. The following diagram illustrates this option.

Using AD Connector and two-way trust to synchronize identities from on-premises Active Directory

Benefits

  • Connect your existing identity source to IAM identity Center to streamline access and provide a consistent experience to your workforce across AWS services.

  • Efficiently manage workforce access to AWS applications. You can manage and audit user access to AWS services more easily by making user and group information from your identity source available through IAM Identity Center. 

  • Improve control and visibility of user access to data in AWS services. You can enable the transfer of user identity context from your business intelligence tool to the AWS data services you use while continuing to use your chosen identity source and other AWS access management configurations.

  • Manage workforce access to a multi-account AWS environment. You can use IAM Identity Center with your existing identity source or create a new directory, and manage workforce access to part or all of your AWS environment.

  • Provide an additional layer of protection in the event of service disruption in the AWS Region where you enabled IAM Identity Center by setting up emergency access to the AWS Management Console. 

Service consideration
  • IAM Identity Center doesn't currently support the use of idle timeout, where the user's session times out or is extended based on activity. It does support session duration for the AWS access portal and IAM Identity Center integrated applications. You can configure session duration between 15 minutes and 90 days. You can view and delete active AWS access portal sessions for IAM Identity Center users. However, modifying and ending AWS access portal sessions have no effect on the session duration of the AWS Management Console, which is defined in permission sets.

Design considerations
  • You can enable an instance of IAM Identity Center in a single AWS Region at a time. When you enable IAM Identity Center, it controls access to its permission sets and integrated applications from the primary Region. This means that in the unlikely event of a disruption of the IAM Identity Center service in this Region, users will not be able to sign in to access accounts and applications. To provide extra protection, we recommend that you set up emergency access to the AWS Management Console by using SAML 2.0-based federation.

    Note

    This emergency access recommendation is applicable if you are using a third-party external IdP as your identity source and works when the IAM service data plane and your external IdP are available.

  • If you use Active Directory or create users in IAM Identity Center, follow the standard AWS break-glass guidance.

  • If you plan to use AD Connector to connect your on-premises Active Directory to IAM Identity Center, consider that AD Connector has a one-on-one trust relationship with your Active Directory domain and doesn't support transitive trusts. This means that IAM Identity Center can access only the users and groups of the single domain that's attached to the AD Connector you created. If you need to support multiple domains or forests, use AWS Managed Microsoft AD.

  • If you are using an external IdP, multi-factor authentication (MFA) is managed from the external IdP and not in IAM Identity Center. IAM Identity Center supports MFA capabilities only when your identity source is configured with IAM Identity Center's identity store, AWS Managed Microsoft AD, or AD Connector. 

Creating and managing identities in AWS

We recommend that you use IAM Identity Center with an external IdP. However, if you don't have an existing IdP, you can create and manage users and groups in the IAM Identity Center directory, which is the default identity source for the service. This option is illustrated in the following diagram. It is preferred over creating IAM users or roles in each AWS account for workforce users. For more information, see the IAM Identity Center documentation. 

Creating and managing identities in AWS
Service considerations
  • When you create and manage identities in IAM Identity Center, your users must adhere to the default password policy, which can't be modified. If you want to define and use your own password policy for your identities, change your identity source to either Active Directory or to an external IdP.

  • When you create and manage identities in IAM Identity Center, consider planning for disaster recovery. IAM Identity Center is a regional service that is built to operate across multiple Availability Zones to withstand the failure of an Availability Zone. However, in the unlikely event of a disruption in the Region where your IAM identity Center is enabled, you will not be able to implement and use the emergency access setup recommended by AWS, because the IAM Identity Center directory that contains your users and groups will also be affected by any disruption in that Region. To implement disaster recovery, you need to change your identity source to either an external SAML 2.0 IdP or to Active Directory.

Design considerations
  • IAM Identity Center supports the use of only one identity source at a time. However, you can change your current Identity source to one of the other two identity source options. Before you make this change, evaluate the impact by reviewing the considerations for changing your identity source.

  • When you use the IAM Identity Center directory as your identity source, MFA is enabled by default for instances that were created after  November 15, 2023. New users are prompted to register an MFA device when they sign in to IAM Identity Center for the first time. Administrators can update MFA settings for their users based on their security requirements.

General design considerations for IAM Identity Center

  • IAM Identity Center supports attribute-based access control (ABAC), which is an authorization strategy that enables you to create fine-grained permissions by using attributes. There are two ways to pass attributes for access control to IAM Identity Center:

    • If you're using an external IdP, you can pass attributes directly in the SAML assertion by using the prefix https://aws.amazon.com/SAML/Attributes/AccessControl.

    • If you're using IAM Identity Center as an identity source, you can add and use attributes that are in the IAM Identity Center identity store.

    • To use ABAC in all cases, you must first select the access control attribute on the Attributes for access control page on the IAM Identity Center console. To pass it by using SAML assertion, you must set the attribute name in the IdP to https://aws.amazon.com/SAML/Attributes/AccessControl:<AttributeName>

    • The attributes that are defined on the IAM Identity Center console Attributes for access control page take precedence over the attributes passed through SAML assertions from your IdP. If you want to use attributes passed from SAML assertion only, don't define any attributes manually in IAM Identity Center. After you define attributes either in the IdP or in IAM Identity Center, you can create custom permissions policies in your permission set by using the aws:PrincipalTag global condition key. This ensures that that only users with attributes that match the tags on your resources have access to those resources in your AWS accounts.

  • IAM Identity Center is a workforce identity management service, so it requires human interaction to complete the authentication process for programmatic access. If you need short-term credentials for machine-to-machine authentication, explore Amazon EC2 instance profiles for workloads in AWS or IAM Roles Anywhere for workloads outside AWS.

  • IAM Identity Center provides access to resources in AWS accounts within your organizations. However, if you want to provide single sign-on access to external accounts (that is, AWS accounts outside your organisation) by using IAM Identity Center without inviting those accounts into your organizations, you can configure the external accounts as SAML applications in IAM Identity Center.

  • IAM Identity Center supports integration with temporary elevated access management (TEAM) solutions (also known as just-in-time access). This integration provides time-bound elevated access to your multi-account AWS environment at scale. Temporary elevated access allows users to request access to perform a specific task for a specific period of time. An approver reviews each request and decides whether to approve or reject it. IAM Identity Center supports both vendor-managed TEAM solutions from supported AWS security partners or self-managed solutions, which you maintain and tailor to address your time-bound access requirements.