Background
One of the security best practices is to have a single identity source. This allows setting up of strict governance around onboarding and offboarding of such identities and managing their permissions. External services can leverage this single identity source by establishing identity federation with it.
As a best practice, Production AWS Accounts must use identity federation with your single identity source and use of identities from the AWS Account’s Identity and Access Management (IAM) must be strongly discouraged.
Microsoft’s Active Directory is one of the most prolific identity stores used these days. It also provides an elegant method for external services to federate with it as well. This is done by using Active Directory Federation Servers (ADFS), which acts as a Security Assertion Markup Language (SAML) provider.
When you move to the cloud, one of the biggest advantages is that of consuming cloud vendor managed services. In a nutshell, this means that for such services, you no longer need to worry about the daily maintenance of the underlying servers. They are looked after by the cloud vendor, thereby saving you the operational overhead.
AWS provides Microsoft Active Directory as a managed service. The customer just manages their Active Directory Forest, while the underlying infrastructure is maintained by AWS. However, if you are considering the use of Active Directory Federation Servers, unfortunately these will be have to be configured and maintained by yourself.
Alternatively, you can use AWS Single Sign-On (AWS SSO). This is a managed service from AWS, which leverages your AWS Managed Microsoft Active Directory identities and acts as a SAML Provider for all external services that you want to federate with.
Over the last few days, I tried searching for tutorials and instructions on how to setup federation between AWS SSO and an external AWS Account. While the documentation for AWS SSO is great, unfortunately I didn’t find much guidance on setting up the federation. That is one of the motivations for writing this blog.
In this blog, I will take you through the steps to configure an identity federation between AWS SSO and an external AWS Account. This will enable approved user identities from the AWS Managed Active Directory domain to login to the external AWS Account’s Management Console using single sign-on.
High Level Architecture Diagram
Below is a high-level architecture diagram of what we will be building in this blog.
The steps taken by the user to authenticate is as follows (as depicted by the numbers in the diagram):
- The user accesses the AWS Single Sign-On Portal and enters his/her AWS Managed Microsoft AD domain credentials.
-
AWS Single Sign-On contacts the AWS Managed Microsoft AD to validate the credentials. On successful authentication, the user is presented with a list of approved SSO applications. In our case, the authorised user will see an AWS SSO Application to access Account B’s AWS Management Console (in ReadOnly mode).
- The user clicks on the AWS SSO Application and is redirected to Account B’s AWS Management Console, where they can perform any activity in Read Only mode.
Prerequisites
Before we continue, the following must be already in place:
- An AWS Account A with AWS Managed Microsoft AD and AWS Single Sign-On deployed and configured.
- An AWS Account B. If AWS Account A is part of an AWS Organisation, ensure AWS Account B is not part of the same AWS Organisation.
Implementation
- Login to the Management Console for AWS Account A and then open the AWS Single Sign-On console. Choose the same region where the AWS Managed Microsoft AD is deployed.
- Click on Applications and then Add a new application.
- In the next screen, for AWS SSO Application Catalog type External AWS Account. A match will be found, click on it and then press Add Application.
- You will now be presented with the Configure External AWS Account screen. Enter a Display Name. This is the application name that will be displayed when an authorised user logs into AWS Single Sign-On User Portal (for this blog, I will use choose the Display name Account B – ReadOnly).
- Enter a Description (for this blog, I will use “Grants ReadOnly Access to AWS Account B’s AWS Management Console”).
- Download the SAML metadata file by clicking Download beside AWS SSO SAML metadata file. This will be used when we configure an Identity Provider in AWS Account B.
- Leave everything else to default settings and click the Save changes button.
-
You will be returned to the Configuration page. I would like to point out the Configuration instruction link on this page. The link opens a document that provides instructions on completing the configuration. However, if you follow this blog, I will take you through the steps myself, in much more detail.
- Login to Account B’s AWS Management Console and open the AWS Identity and Access Management (IAM) Console.
- The first task is to create an IAM Identity Provider. From the left-hand side menu, click on Identity providers and then, in the right-hand side screen, click on Create Provider.
- Set the Provider Type to SAML and type a name for the Provider (for this blog, I named the provider AccountA-SSO).
- Click on Choose File beside Metadata Document. Provide the AWS SSO SAML metadata file that was downloaded in step 6 above. Click Next Step.
- In the next screen, verify the information that was provided. Once satisfied, click Create.
- You should now see the newly created Identity Provider listed on the right-hand side screen when you click Identity providers. Click on the newly created Identity provider and note down the Provider ARN. This will be required later.
- Next, we need to create an IAM role that the federated user will assume, for accessing the AWS Management Console.
- From the left-hand side menu, click on Roles and then in the right-hand side screen, click Create role.
- For Select type of trusted entity choose SAML 2.0 federation.
- Click the dropdown arrow beside SAML provider and choose the Identity provider that was created in step 11 above.
- Next, depending on your user case, choose either Allow programmatic access only or Allow programmatic and AWS Management Console access. For this blog, we want AWS Management Console access, so choose the latter.
- You will notice that Attribute and Value gets automatically populated once the access type has been selected. Click Next: Permissions.
- For this blog, we will be assigning ReadOnly access to this role. In the next screen, choose the ReadOnlyAccess policy and then click Next: Tags.
- If you need to provide tags, do so and then Click Next: Review.
- In the next screen, provide a name and description for the role. I set the role name as SSO-AccountA-ReadOnlyAccess and provided the description as This role is assumed by the federated user from Account A. (ProTip: This role name is displayed on the top right corner when the federated user connects to the AWS Management Console). Click Create role.
- Open the newly created IAM role and note down its Role ARN. This will be required later.
- Next, we will create a domain security group inside Account A’s AWS Managed Active Directory Domain. This will be used to grant users the ability to access the AWS Management Console of Account B using federated access.
- Using a domain joined (joined to Account A’s AWS Managed Microsoft AD domain) Windows Amazon Elastic Compute Cloud (EC2) instance, create a domain security group and add any users that will be allowed to access the AWS Management Console of Account B. Name the security group appropriately. For this blog, I named the Active Directory security group SSO-AccountA-ReadOnlyAccess and added a test Active Directory domain user to it.
- Next, go to Account A’s AWS Management Console and open the AWS SSO Console. Open the Application that was created in step 8 above.
- Click the Attribute mappings tab for the application and then click Add new attribute mapping.
- For User attribute in the application enter “https://aws.amazon.com/SAML/Attributes/Role” (without quotes)
-
For Maps to this string value or user attribute in AWS SSO enter the identity provider ARN from step 14 and Role ARN from step 24 in the following format: (don’t forget the comma in the middle)
arn:aws:iam::ACCOUNTID:saml-provider/SAMLPROVIDERNAME,arn:aws:iam::ACCOUNTID:role/ROLENAME
For example, if the Identity Provider (SAML Provider) ARN is arn:aws:iam::123456789:saml-provider/AccountA-SSO and
the Role ARN is arn:aws:iam:123456789:role/SSO-AccountA-ReadOnlyAccess then use the SAML Provider ARN as the prefix and the Role ARN as the suffix, with a comma in between them to get the following, which is then used as the value for the above field.
arn:aws:iam::123456789:saml-provider/AccountA-SSO,arn:aws:iam:123456789:role/SSO-AccountA-ReadOnlyAccess
- For Format select unspecified.
- Click Save changes.
- Next, click Assigned users tab and click Assign users.
- Ensure Groups is chosen. Choose the correct Active Directory Domain name for your AWS Managed Microsoft AD and then type a few characters to uniquely identify the domain security group that had been created in step 26 above (a reminder, I named mine SSO-AccountA-ReadOnlyAccess). Then click Search Connected directory.
- The search will return all matches from your Active Directory domain. Tick the correct match and then click Assign users. This grants all members of that domain security group access to use this AWS SSO application (which in turn allows the users to access Account B’s AWS Management Console in Read Only mode via SSO federation).
Time to Test
- Open a web browser and go to the AWS Single Sign-On User Portal. If you unaware of the URL, using Account A’s AWS Management Console, open the AWS Single Sign-On Console and click on Dashboard. The URL will be displayed at the bottom of the right-hand side screen.
- Login with the test user domain credentials (this is a test user from your AWS Managed Microsoft AD domain, who is a member of the domain security group that was assigned access to the AWS SSO Application).
-
Once successfully logged in, you will see the AWS SSO Application displayed.
-
Click on the application. You will now be redirected to Account B’s AWS Management Console and automatically logged in. Take note of the Role that you have assumed. It is the one that was created in step 23 of Implementation.
- Once finished, you can sign out of the AWS Management Console (the Single Sign-On session will, by default, expire after 1 hour and you will have to re-authenticate) and return to the AWS Single Sign-On User Portal. Log out from the User Portal.
Limitations
There is a critical limitation when using AWS SSO as compared to using ADFS. An AWS SSO Application can be used to assume only a specific role in Account B. If you need users to assume a different role, then a new AWS SSO Application must be created (and a new Identity Provider and Role must be created in Account B). For example, as seen in this blog, we created an AWS SSO Application for ReadOnly Access to Account B’s AWS Management Console. To provide users with any other role to assume in Account B, for example, AdministratorAccess, a new AWS SSO Application must be created in Account A. Also a new Identity Provider using the metadata file from the new AWS SSO Application and a new IAM role with the AdministratoAccess policy attached must be created in Account B. This starts adding complexity to the solution, as more roles are required.
For anyone struggling with enabling AWS SSO federation to an external AWS Account (or anyone thinking of enabling it), I hope this blog provides valuable information.
Till the next time, Enjoy!