Introduction to AWS SSO

Originally launched in 2017, AWS Single Sign-On is “ a cloud SSO service that makes it easy to centrally manage SSO access to multiple AWS accounts and business applications [1].” When launched, AWS SSO was lacking some crucial features. For example, a rather cumbersome command line login integration [2] was added only later. As an infrastructure engineer I need to switch roles and accounts multiple times per day (on support duty I might need to do this over a dozen times). Copy / pasting access keys from the browser into my command line interface just didn’t cut it. Knowing this, I had never really looked into AWS SSO as a tool I’d want to use.

Finally in late 2019 AWS announced the next evolution in Single Sign-On [3] together with AWS CLI Version 2 (still on preview mode). On top of other features (namely Azure AD support) the combination of tools supports integration with AWS CLI Version 2 and AWS SSO [4].

Taking AWS SSO into use

Setting up AWS SSO is straightforward. Once enabled on the organization master account, service will take care of initializing SSO on all the accounts within an organization. After a while, the initial setup is done and the actual service configuration can be performed.

Taking AWS SSO into use is easy as 1-2-3

Service configuration is also straightforward as there are only two steps to be done:

Choosing the Identity Source
Configuring SSO access to the accounts

Choosing the Identity Source

Previously, AWS SSO supported only Active Directory as an identity source, either via AWS Managed Microsoft Active Directory or AD Connector. After the overhaul, the service now supports two additional identity sources. Local user directory stores users, groups, credentials and MFA assignments locally. Alternatively, external identity provider (Azure AD) can be used as well.

Out of the three options, the local user directory is the fastest to set up. Users and groups can be created with no extra steps. Using Active Directory or external identity provider requires either AWS Managed Microsoft Active Directory, AD Connector or Azure AD to be set up before the identity source can be configured.

AWS SSO supports multi-factor authentication via Google Authenticator. It is the only alternative for local directory. Active Directory can also use a Radius server; however this needs to be set up manually. External identity providers work differently. User authentication, including multi-factor authentication, is done externally before the user is redirected to AWS SSO portal.

Configuring SSO access to the accounts

The next step is to configure SSO to the accounts. This can be split into two parts:

Creating permission sets
Configuring SSO into AWS account

Permission set is a collection of policies that AWS SSO uses to determine the user’s effective permissions to access a given AWS account [5]. Simply put, permission sets are IAM policies stored in AWS SSO. Permission sets are used when the service configures SSO into an AWS account. Ultimately the service creates IAM roles into AWS accounts with a specific AWS SSO SAML provider as a trusted entity.

Permission sets consist of two different kinds of policies:

Existing job function policies
Custom permission sets

Existing job function policies [6] are predefined AWS Managed Policies aligned to common job functions in the IT industry (e.g. AdministratorAccess to give full access to the account, DataScientist to give access to data analytics services and SupportUser to troubleshoot and resolve issues in an AWS account). Personally, I want to follow the principle of least privilege as closely as possible. This is also a principle we follow within our company. Instead of handing out generic roles with access to ‘*’ resources I want to be able to limit access to e.g. resources with names matching to application, environment, service type etc. In this case, custom permission sets [7] can be used. Custom permission sets can have two different types of policies: AWS managed policies (the same policies available on standard IAM) and custom policies. Unfortunately, there is no way to use standard customer managed policies. Instead, custom policies need to be typed or pasted into the console when creating permission set. This is cumbersome as the creation of custom policies cannot be scripted. Similarly, there is no way to create permission sets outside the console as there is no externally available API. This is a real handicap in my opinion.

Creation of permission sets can’t be automated.

Once created, permission sets can be assigned into accounts. The first step is to select which accounts are being configured, the next step is to select which users and groups the access is given to, and the last step is to select the permission set to be deployed. Once confirmed, AWS SSO will make changes into directory and deploy SAML identity provider and actual federated roles into the account.

AWS SSO is now set up and ready to be used.

AWS SSO user experience

Logging into AWS Management Console via AWS SSO is rather straightforward.

Browse into AWS SSO User Portal
Login and provide MFA token if assigned
Clicking AWS application, a list of accounts and aliases available will be presented
Upon selecting accounts a list of available roles will be presented
After selecting a role, the user can select either console access or command line access.
If console access is selected, the browser will be redirected into the management console.
If command line access is selected, temporary AWS access keys will be presented. These keys can be copied into command line for command line / programmatic access.

Next, I present a personal experience using the new command line interface with AWS SSO.

With the release of AWS CLI Version 2, AWS tries to provide seamless SSO command line login experience. The tool is still on preview [4] and it might be a good idea not to use it on production environments [8]. I tried the tool with a few different Ubuntu versions on both Vagrant and Virtualbox.

AWS CLI 2 login is done via browser

I have experience using multiple different SSO solutions together with AWS CLI. All these have one thing in common: they are all fully integrated with command line. However, this is not how AWS SSO works. It uses operating system default browser for authentication. When configuring / logging in, the tool will try to open the browser and synchronization page. Synchronization page is used to provide a verification code which pairs CLI and browsers session. Once synchronized, AWS SSO login page is presented and the user can login into AWS SSO portal and once successful, CLI can be configured with the flow similar to console login (select account, select role / permission set available). All configurations are stored to .aws/config -file. Additional profiles can be added easily into the configuration file assuming account id and role name are known.

It took me a few tries to realize how the flow is supposed to work on my Vagrant-based Ubuntu.

Upon configuring SSO, my terminal screen suddenly refreshed and opened a web page using w3m (command line browser) asking for the verification code. Unfortunately the code was no longer visible after the refresh. Once I realized that I had to close w3m, open another browser tab on my actual MacOS, paste the device authorization URL, provide authorization code, perform SSO login and finish setting up SSO on the CLI everything went as a breeze.

Strangely, my Ubuntu Bionic running on Virtualbox was not able to automatically open the browser so I had to copy and paste the information manually.

User types username and password into browser when logging into CLI.

After the initial configuration I was able to use the federated role without any problems. The tool works just like a standard AWS CLI with AWS profiles.

AWS SSO with Azure AD

As I don’t have previous Azure or AzureAD experience I wanted to try AWS SSO with an external IdP.

After quickly learning the ropes and getting hang of Azure portal I proceeded following the AWS -provided setup guide [3].

Following the guide, I was able to create an external identity provider. Within 10 minutes I had my AWS SSO linked with Azure AD and ready to test the federated authentication. Unfortunately my first attempt was greeted with an error message: My application identifier (link pointing to my AWS SSO SAML) was not found in my AzureAD Directory.

After a bit of head scratching I realized my SSO id did not match the one configured on the Azure AD side. The fix was rather simple: re-downloading SAML metadata from AWS SSO and re-uploading metadata file into AzureAD application solved the issue. Knowing this, I would recommend you to set up an external identity provider on AWS SSO first before downloading AWS SSO SAML Metadata xml file and uploading it into AzureAD.

AWS SSO supports two different types of provisioning with external identity providers: automatic [9] and manual. By default, manual provisioning is used and it requires matching users (username needs to be identical) to be created into both AWS SSO and AzureAD. With automatic provisioning, Azure AD manages creation and synchronization of user accounts and groups into AWS SSO, reducing management overhead.

Automated provisioning was the last thing I tested. After a few well documented extra steps I had enabled automatic provisioning. I needed to wait a moment for the initial synchronization to take place. Once synchronized, I was able to see the users and groups created in AzureAD appear into AWS SSO and I was able to use synchronized users and groups when assigning permission sets to my AWS accounts. From here on everything worked as previously described. I had successfully set up AzureAD -based SSO into AWS.

Conclusion

There are many different aspects one needs to keep in mind when selecting single sign-on. As there can’t just be one single solution for all enterprises I have simply listed pros and cons for AWS Single Sign-On below.

Pros:

Available at no additional cost. Since AWS SSO has an internal directory you can have SSO with no extra cost.
Straightforward integration with external IdPs (using AWS -provided AD tooling or Azure AD).
SSO is fast to set up, especially if using internal directory. This, however, has also the highest management overhead as you might need to create users and groups into multiple systems.

Cons:

Supports only accounts within a single AWS Organization.
Command line login is cumbersome and requires a new CLI (still in preview) unless credentials are copy/pasted from console.
Only manual configuration available.
Custom permission sets need to be created via console.
Can’t use pre-defined customer managed policies.
Google Authenticator is the only MFA choice.

Finally, a few pointers worth keeping in mind when setting up AWS SSO:

Setting up MFA with Active Directory requires either separate MFA setup per user on AWS SSO portal or setting up separate Radius server. Either way, this adds management overhead.
Your users and groups won’t get deleted from internal directory when you switch from identity source to another. Also, your users and groups won’t get deleted if you change provisioning from manual to automatic. When switching into automatic provisioning, you can’t delete resources from AWS SSO internal directory and you end up having redundant resources you can’t clean up.
If using AzureAD as an external identity provider, you need to use AzureAD Premium subscription as you need to create non-gallery enterprise application.
Your portal URL (and metadata information) will change every time you change your identity provider. Keep this in mind if you run into strange issues upon changing the identity source.
If you use external identity provider (AzureAD) and automatic provisioning it is worth noticing OAuth bearer access token set up on AWS SSO (token you create and upload into AzureAD) is valid for a year. You can have up to two access tokens and you are responsible for rotating the token.