AWS HPC Blog
A guide to identity management in Research and Engineering Studio on AWS
Research and Engineering Studio on AWS (RES) provides the scientific and engineering communities with secure access to AWS cloud resources through virtual desktop infrastructure (or VDI) using their own enterprise identity services. To manage these secure environments, customers need a strong identity strategy.
In this post, we’ll help you understand the choices RES provides that might best fit your deployment.
What does identity mean for RES
There are two requirements for identity in RES. The first is a SAML 2.0 compliant identity provider (IdP) for single sign-on (like the AWS IAM Identity Center), and the second is an authoritative identity source (such as Microsoft Active Directory). These two components work synchronously to provide access to the web portal, through the SAML IdP, and to the VDI through Active Directory.
At the highest level, the SAML IdP provides authentication for the web portal, which RES administrators use to assign permissions for users of the VDI infrastructure. RES uses the concept of Projects which represent boundaries for cloud infrastructure like VDI, storage, and budgets. RES grants access to these resources by mapping Active Directory groups and users to Projects.
The default configuration for RES identity uses AWS IAM Identity Center to provide the SAML 2.0 authentication, and an AWS managed Active Directory as the identity source for users and groups. The authentication flow for the RES web portal is described in the Cognito developer guide.
There are several options to provide the SAML IdP and the Active Directory. The remainder of this post covers what these options are and when they might be appropriate for a given deployment.
Identity Provider (IdP)
The first choice to make is what the identity provider for the environment will be. Environments will either use an existing or dedicated IdP.
Existing IdP
Using an existing IdP is a great choice if you already manage the target user identities for other purposes; it allows for a single sign-on (SSO) approach across multiple applications within your organization.
Any existing SAML 2.0-compliant IdP may be used. Examples include AWS IAM Identity Center which is covered in the RES User Guide, or a number of third party providers, including Okta, Ping, Microsoft Entra ID, Cyberark, ForgeRock, Google Workspaces, Microsoft AD FS, RSA and others.
To integrate a third party SAML 2.0 provider, see RES User Guide Identity Provider configuration.
Dedicated IdP
Some organizations want to have independent control over user identities. This might be driven by a need to include identities from external institutions, meet password complexity requirements, or meet user lifecycle and/or other specific requirements inherited as a result of data held in the environment.
In these environments, we don’t recommend using AWS IAM Identity Center as the IdP because identities will be applied for the entire AWS organization, rather than being RES-specific.
Instead creating a dedicated SAML IDP on one of the 3rd-party services above will enable independent RES specific identity management.
Identity source
The second choice is to source users and groups using Active Directory (AD). RES requires connectivity to Active Directory, which you can achieve with an AWS Managed AD, or by using a VPN or private network to connect to an on-premises system.
Finally, it’s possible to integrate with Entra ID (formerly Azure AD) using Domain Services.
Managed Active Directory
In a situation where you’re managing the active directory users and groups in an AWS managed directory service, the managed directory must exist before deploying RES and can then be configured as the domain when you’re launching the product.
Existing Active Directory (on-premises)
When integrating with an existing on-premises Active Directory, there are two approaches.
The first is to provide network connectivity between RES and the existing system, and to specify the domain when you launch. Connectivity should be over a VPN connection to ensure data is securely routed.
The second approach is to create a trust relationship between the on-premises Active Directory and an AWS Managed Directory which RES can then use. The advantage of this latter approach is that there’s no run-time dependency on the VPN connectivity.
Entra ID (formerly Azure AD)
Customers who manage their identities in Entra ID (formerly Azure AD) can make use of Microsoft Entra Domain Services to enable user account synchronization with RES over a VPN connection.
Finally, for cases where users are managed in Microsoft Entra ID and where Entra Domain Services just can’t be made available, the AWS HPC team have released an AWS HPC recipe to get you started on proof of concept projects.
In short: this solution uses the System for Cross-domain Identity Management (SCIM) to publish users and groups from Entra ID to AWS IAM Identity Center every 40 minutes. It adds these users to an AWS Managed Directory Service and those user accounts are then synchronized by RES using its interface to the Managed AD.
There are limitations with this approach. Users will have different passwords in Entra ID and AWS managed AD, since user passwords cannot be synced from Entra ID to AWS managed AD automatically.
Users will use their Entra ID passwords to log in to the RES portal itself and then their password provided by AWS Managed AD for their desktop sessions.
Conclusion
Hopefully, you now have a better understanding of the options available for the two main components of identity management in Research and Engineering Studio on AWS, the identity source, and identity provider.
If you would like help with RES reach out to your account team or ask-hpc@amazon.com to get help planning a deployment. For more guidance on configuring your AWS research environments, and for inspiration on what’s being done by other AWS customers, keep track of the HPC blog channel, or follow HPC Tech Shorts on YouTube.