IAM Identity Center for AWS environments spanning AWS GovCloud (US) and standard Regions

AWS IAM Identity Center (successor to AWS Single Sign-On) from Amazon Web Services (AWS) provides administrators with a simple way to manage identity and access (IAM) across numerous AWS accounts. IAM Identity Center is available in the AWS GovCloud (US) Regions, enabling customers to simply manage access to numerous AWS accounts in their AWS GovCloud (US) organizations.

Many customers with an AWS Organization in AWS GovCloud (US) simultaneously manage numerous AWS accounts in the standard Regions. Those customers often ask how they should make the best use of IAM Identity Center in standard and AWS GovCloud (US) partitions to minimize administrative overhead and simplify the user experience. In this blog post, we cover four different architecture patterns for providing an organization’s AWS users with access to both standard and AWS GovCloud (US) accounts using IAM Identity Center.

Note: The patterns listed in this blog describe strategies to grant user access to the AWS GovCloud (US) Region. Organizations with compliance requirements should carefully consider the impact of implementing these patterns. For more information about compliance in AWS GovCloud (US), see the Compliance documentation for AWS GovCloud (US).

Pattern 1: Single IAM Identity Center instance in standard partition with custom SAML application to AWS GovCloud (US) account

Using the following architectural Pattern 1, you can deploy IAM Identity Center in a standard non-AWS GovCloud (US) Organization. If you must grant access to specific AWS GovCloud (US) accounts, then you create a custom application (SAML 2.0) and then assign the application with the users or groups who need access. Furthermore, you must deploy the necessary AWS Identity and Access Management (IAM) resources in the target AWS GovCloud (US) account.

The post, “Enabling SAML 2.0 federation with AWS IAM Identity Center and AWS GovCloud (US),” provides instructions to deploy this pattern and automation to create the correct IAM resources in the target AWS GovCloud (US) account.

Pattern 1. Diagram of federation from AWS IAM Identity Center in standard AWS account to AWS GovCloud (US) account.

Pattern 1 is beneficial for organizations that have a small number of AWS GovCloud (US) accounts as it allows your AWS users to log into both standard and AWS GovCloud (US) accounts from a single IAM Identity Center instance. However, Pattern 1 doesn’t efficiently scale beyond a few AWS GovCloud (US) accounts, as you must create a separate SAML application for each IAM role and target account combination.

Organizations with a large number of AWS GovCloud (US) accounts should consider Pattern 2 or Pattern 3.

Pattern 2: Separate IAM Identity Center instances and user pools

In Pattern 2, two separate IAM Identity Center instances are created: one in a standard Organization and one in an AWS GovCloud (US) Organization. Each IAM Identity Center instance provides a unique URL through which users can log in.

When your AWS users log into their AWS environment, they must enter the correct URL for either the AWS GovCloud (US) or standard Organization, and then provide their respective standard IAM Identity Center credentials or AWS GovCloud (US) IAM Identity Center credentials. Once authenticated, the user can choose the specific AWS account and role that they wish to access.

Identity pools are separate with this pattern. You could set up Managed Microsoft Active Directory instances and have separate domains for your IAM Identity Center instance in AWS GovCloud (US) and standard. Or you could maintain separate user pools in the native IAM Identity Center Cloud Directory.

Pattern 2. Diagram of user connecting to separate IAM Identity Center instances in standard partition (left) and AWS GovCloud (US) (right).

Pattern 2 is beneficial for organizations with a) many AWS GovCloud (US) accounts or b) organizations that require completely separated identity and access control for standard and AWS GovCloud (US) accounts. For example, an organization that abides to compliance requirements dictating separate user directories for standard and AWS GovCloud (US) environments.

Organizations without requirements for separated identity and access control for standard and AWS GovCloud (US) accounts may want to avoid Pattern 2, as it adds complexity for end users, who must use two separate URLs and remember two separate login credentials.

Note that you could slightly vary this pattern by using an Active Directory (AD) Connector to create a link to the same Active Directory domain from a virtual private cloud (VPC) in both AWS GovCloud (US) and standard. Then, you must set your IAM Identity Center configurations to use AD Connector as their directory. This would essentially allow the same pool of users (with the same credentials) to connect to both environments.

Pattern 3: Separate IAM Identity Center instances with external identity provider and SCIM

In this pattern, like Pattern 2, you have two separate IAM Identity Center instances – one in a standard Organization and one in AWS GovCloud (US). The difference is that your users authenticate first with your central external identity provider (e.g., Azure AD, Okta, Ping) at a portal URL that is likely already known to those users. Once authenticated, users choose one of two applications – which could be called, for example, “Standard AWS Accounts” or “GovCloud AWS Accounts.” After choosing the application, the user is federated via SAML 2.0 to the appropriate IAM Identity Center instance in either your Standard Organization or AWS GovCloud (US) Organization.

With this pattern, identity is also managed differently. You utilize System for Cross-domain Identity Management (SCIM) to automate the provisioning of users from your external identity provider into IAM Identity Center.

Pattern 3. Diagram of user connecting to separate IAM Identity Center instances via their external identity provider. Note: AWS GovCloud (US) and standard are different applications in the identity provider.

Pattern 3 is ideal for organizations that can utilize one external identity provider for providing access to both standard and AWS GovCloud (US) environments. This pattern provides the simplest option for end users, allowing them to access both AWS environments using the same single sign-on (SSO) experience and identity provider they are already familiar with. In addition, Pattern 3 is simple to manage for administrators, who can grant different levels of access to both standard and GovCloud AWS accounts simply by adding users to a specific group in the external identity provider.

Pattern 3 requires an external identity provider, so some organizations that don’t currently use an external identity provider may want to consider Pattern 2. In addition, Pattern 3 should be avoided by organizations that abide to compliance requirements necessitating a complete separation of identity and access control for standard and AWS GovCloud (US) environments.

Pattern 4: Separate IAM SAML configurations and external identity providers

Some customers find themselves operating their workloads within an AWS Organization that they do not have control over. This is encountered when working with resellers or central IT teams where each customer in the organization has their own organizational unit (OU) as well as identity store provider (IdP). In these scenarios, IAM Identity Center works at the AWS Organization level and currently cannot be used with multiple different IdPs, such as one for each customer. Similar to Pattern 3, this allows customers to utilize a single identity provider (e.g., Azure AD, Okta, Ping) to organize their users and map them to individual standard or AWS GovCloud (US) accounts and the IAM roles they will assume. This also applies for organizations who want their existing IdP to be the single pane of glass across multiple federated entities such as AWS accounts, external SaaS vendors or internal applications. To take into account compliance requirements, two different instances of an IdP can be used to point to each partition, standard or AWS GovCloud (US). While this requires some extra configuration on both the identity provider and AWS Account side of the integration, it provides fine grained access control across multiple different customers, AWS accounts, and workloads.

Pattern 4. Diagram illustrating how two instances of an IdP may be used to access both AWS standard and AWS GovCloud (US) accounts.

Pattern 4 features the following steps. In Step 1, the user logs into external identity provider. For Step 2, the external identity provider federates user to an IAM SAML identity provider in either the standard Partition or AWS GovCloud (US) partition. In Step 3, the user assumes an IAM role and receives temporary credentials in the standard Partition account or the AWS GovCloud (US) account. SAML federation to individual accounts is the primary method of SSO besides IAM Identity Center and provides value in the case of a shared AWS Organization.

Conclusion

In this blog, we covered patterns for configuring authentication in a multi-account environment that spans both standard and GovCloud (US) partitions. These four patterns show different methods to provide an organization’s AWS users access to both standard and AWS GovCloud (US) accounts. Organizations should carefully considering the administrative work, user experience, and the compliance requirements for services used in each pattern.

Several patterns in this blog require setting up federation and SCIM between an external identity provider (like Azure AD, Okta, PingFederate) and AWS IAM Identity Center. See Connect to an external identity provider documentation for details on how to perform the necessary configuration steps.

To review other best practices to consider when designing multi-account environments, see Design Principles for a Multi-Account Strategy.

Read related stories on the AWS Public Sector Blog:

Subscribe to the AWS Public Sector Blog newsletter to get the latest in AWS tools, solutions, and innovations from the public sector delivered to your inbox, or contact us.

Please take a few minutes to share insights regarding your experience with the AWS Public Sector Blog in this survey, and we’ll use feedback from the survey to create more content aligned with the preferences of our readers.

AWS Public Sector Blog