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]. 

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.

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

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.

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

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 [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.

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.

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

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. 

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.

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.

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.

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:

Cons:

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

[1] Announcing AWS Single Sign-On. AWS 2017.
https://aws.amazon.com/about-aws/whats-new/2017/12/announcing-aws-single-sign-on–sso/

[2] How to retrieve short-term credentials for CLI use with AWS Single Sign-on. AWS 2018.
https://aws.amazon.com/blogs/security/aws-single-sign-on-now-enables-command-line-interface-access-for-aws-accounts-using-corporate-credentials/

[3] The Next Evolution in AWS Single Sign-On. AWS 2019.
https://aws.amazon.com/blogs/aws/the-next-evolution-in-aws-single-sign-on/

[4] AWS CLI v2 Preview Now Supports AWS Single Sign-On. AWS 2019.
https://aws.amazon.com/blogs/developer/aws-cli-v2-now-supports-aws-single-sign-on/

[5] https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsetsconcept.html

[6] https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html

[7] https://docs.aws.amazon.com/singlesignon/latest/userguide/howtocreatepermissionset.html

[8] https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2.html

[10] https://docs.aws.amazon.com/singlesignon/latest/userguide/provision-automatically.html