We have talked about using switch role to achieve cross account access in the AWS Cross Account Access – Assume Roles article. It provides a centralised identity management option to users who manage multiple AWS accounts. However, for some scenarios, such as companies that already have their Identity Provider (IdP) and user pool established, managing a separate user pool in an AWS account can be an overhead. In this case, AWS Single Sign-On (SSO) provides another option.
Back in 2017, AWS introduced the Organization concept, as well as released their first user guide on AWS SSO. It was a “hooray” moment for large companies and consulting partners. With AWS SSO, users can
- set it as an IdP or leverage the existing IdP
- manage SSO access to all AWS accounts and cloud applications
- monitor and audit SSO activities in a central place
It ticks boxes across the AAA, i.e. Authentication, Authorization and Audit, enabling centralisation, adaptability and extensibility for identity and access management. With so many benefits called out, let’s take a look at how it works.
AWS SSO is applicable to many use cases. We’ll choose one scenario to walk through how it works. The scenario is assuming a company have their corporate identities managed in Azure AD (AAD). The company also have their cloud-based applications hosted in AWS. How do users use their existing AAD credentials sign in to AWS and access their AWS accounts and applications? Let’s take a look at the diagram below.
In this case, AAD is the Identity Provider (IdP) and AWS is the Service Provider (SP). AAD is the source of truth for corporate identities including users and groups. We can use the System for Cross-domain Identity Management (SCIM) protocol to automatically synchronise users and groups to AWS.
From the AWS side, assume we have three accounts set up in an Organization, one root account and two workload accounts. We have enabled SSO in the root account and configured it to connect to AAD using the Security Assertion Markup Language (SAML) 2.0 standard. From the AWS root account, user admins can configure permission sets for users in relevant workload accounts. AWS will then automatically create mapping roles and permissions in the workload accounts.
To avoid overloading this section with detailed user instructions, we’ll only describe the high-level steps of how to set up SSO based on the scenario used above. We will have a separate article that walks through all the detailed steps of configuring SSO between AAD and AWS.
In this Azure AD as IdP and AWS as SP scenario, assuming user X is a member in user group Y in AAD. To enable user X to only access S3 buckets in AWS workload account 1 but not the buckets in account 2, the following settings are required:
- Adding user X’s user account and user group Y to the Enterprise Application in AAD
- Provisioning/Synchronising both user account and user group to the AWS root account
- Linking user group Y to S3 access permission set under workload account 1 in the AWS root account
Once all settings are done, user X can then log in to AAD SSO panel (e.g. https://myapplications.microsoft.com/<AAD domain name>), click on the enterprise application icon to authenticate themselves to the AWS SSO panel, as shown below.
From the AWS SSO panel, user X can then click on the workload account 1 from the account list, and click the Management Console to log in to the workload account 1 to access the S3 buckets in it, as shown below.
Alternatively, user X can skip the AAD SSO panel and directly log in to AWS through the AWS SSO user portal URL (e.g. https://<orgname>.awsapps.com/start) using the AAD credentials.
We’ve selected one SSO use case in this article to walk through how AWS SSO works. There are many other use cases, e.g. leveraging on-premises AD as IdP. We won’t cover all the use cases in this article. More information about AWS SSO are available at AWS Single Sign-On. Or if you are interested in knowing more about any particular use case, please add your comments below. We can create an article to for it.