Everyone should be using AWS SSO. Here's why.

AWS Single Sign On (SSO) is a service which seems to have had little attention since its launch at the end of 2017 - it doesn’t seem to get much mention in the blogs and social media, at least not in the circles which I follow. This is a shame because when we at Cloudsoft tried it out, it revolutionised how everybody in our company accesses AWS services. Even on my personal AWS accounts, where I’m the only user, it has hugely simplified what I do.

Because SSO stands for “Single Sign On”, it perhaps reminds people of the old federated identity login service, relevant only to people with large Active Directory instances and other requirements that small businesses and individuals don’t have. While AWS SSO can do this, it’s optional - the main draw to AWS SSO is something else. It makes it really easy to access your AWS accounts, with or without a corporate directory, for large users and small.

The problem with IAM

Think of how difficult this is now. It is well established these days that you use an IAM user (or federated identity) to log in to a single specific AWS account. It is also well established that you have multiple AWS accounts, acting as boundaries to address institutional and security concerns. Therefore, you have different usernames and passwords for your different AWS accounts.

Having multiple credentials sets is difficult, both for the individual concerned who has to manage them all somehow, and for the organization (e.g. to onboard/offboard new employees). The “Switch Roles” functionality is intended to simplify things by logging in to one account, and switching to the others. But while this made things simpler some of the time, it can also complicate things in that the individuals now had to remember which account you had to first log in to in order to be able to switch roles to the account you really want, and for the organization to manage the extra roles and policies this introduces.

Finally, your system has probably “grown organically”, which means “it’s really messy even though I tried to make it tidy”. It’s a security liability as it’s hard to keep track of who has logins where and what roles they can switch to.

AWS SSO means you can get rid of all that.

How?

1. You have a single URL which is the gateway to all accounts in your organization.
2. You have a directory in which you can assign usernames and passwords to users.
3. You have a configuration which clearly maps users to groups, and maps groups to AWS accounts and permissions.
   
   

This means your user logs in with their own credentials, and immediately they can clearly see this:

Setting up AWS SSO

Enabling the service

So let’s try this out. The first stage is to enable the SSO service in your AWS account.

1. Log in to your AWS management account - that’s the one at your root of your organization, which pays the bill. (AWS used to call this the “master” account but the terminology has changed.) It must be the management account - this is a requirement of AWS SSO.
2. Choose your preferred region - it doesn’t really matter which one as it’s effectively a global service, although your organization may have data sovereignty considerations.
3. Go to the “AWS Single Sign-On” service. Hit the “Enable AWS SSO” button and let’s go!
4. Set your user portal URL.“AWS SSO enabled successfully”,it says to us. Brilliant! It’s suggesting some activities to get us started, but before we do that, let’s look at that User portal URL in the right corner. It’s a bit bland, so click Customize and you can change that string of numbers into something else that makes more sense for your organization.
   

Choose your identity source

Now let’s go back to the suggested next steps, and go to step 1 - choose your identity source. Click the link here, then on the page you now see, click “Change identity source”. It’ll offer you three choices. For now, select “AWS SSO” - this will provision a lightweight - and free - directory used exclusively for this service. The other options are for integrating with external directories, such as ActiveDirectory or Google Workspaces - whilst not particularly difficult to set up, we’ll leave that as more advanced option. Click Next and follow the steps to confirm.

Add users and set permissions

Next, we need to add some users.

1. Click “Users” on the left menu, then click “Add user”. Add details for yourself, and click Next.
2. It’ll prompt us to add the new user to a group, but we don’t have any groups yet, so just click Next, then confirm the details and click “Add user” for the final time.
3. You should see a pop-up window with the new user’s credentials - save them somewhere safe.

Now this is where it gets interesting - let’s start granting the user some permissions to the AWS accounts in your organization. To do this we create a three-way relationship between a set of AWS accounts, a “permission set” which is effectively an IAM policy defining what the user can do in the accounts, and a set of users and/or groups. When applied, it means that that user can access those accounts with these permissions.

Create an Administrator group

Since it’s always best to work with groups of users rather than directly assign permissions to individual users, let’s create a group:

1. Go to the Groups page, create a new group called Administrators, add your new user to this group, and create the group.
2. Go to the Permission sets page - click “Create permission set”, then click “Predefined permission set”, then “AdministratorAccess”, click “Next” twice, then “Create”.
3. Finally, we complete the relationship by going to the “AWS accounts” page. In this scenario our administrators need to administer every account, so select every account in the organization with a tick (you can switch from hierarchy to list view to make this easier), and click “Assign users or groups”. Select the Groups tab, tick the Administrators group, and click Next. In the next page, tick our new AdministratorAccess permission set and click Next, then click Submit to complete the process.

Give it a try!

Now to try it out. Sign out of AWS, or switch browser, or open an Incognito or Private Browsing window. Bring back the credential information you put aside earlier - go to the URL, and enter the username and password. You’ll probably need to change the password on the first login. Once you’re past that, you’ll see a screen like this (after I’ve expanded everything that can be expanded):

Every AWS account in my organization is listed here, and underneath each account is an AdministratorAccess line with links to open the management console, or get API access keys.

So now it’s incredibly easy to access any account in my organization, just by using my own username and password. No need for different credentials for each account, no need to switch role. Just log in once, and pick what I need from a list. Truly a “Single Sign-on” experience.

Create another, more restricted group

Let’s develop this a bit further. Your organization will probably have a finance department, with some people who are interested in reading and controlling the AWS bills, but who do not have the right to manage any of the resources. This group should be able to access bills in the management account only.

1. Create a group called “Finance” - you can add your existing user to this group, or create a new user.
2. Create a permission set as before, but for “Billing” instead of AdministratorAccess.
3. Then in the AWS accounts page, tick the management account only, click Assign users and groups, and assign the new Finance group.
4. On the final page, tick the Billing permission set.

Next time you log in with your account, you’ll see this:

My management account now has a “Billing” access row - but only on the AWS management account, and this can only access what is allowed by the “Billing” IAM policy.

SSO - it's much simpler!

Hopefully I’ve now convinced you that this is such a simpler way of accessing your own AWS accounts, and you can throw away your IAM user accounts and cross-account access roles.

That said, this does not solve for all problems, even though it has vastly simplified how we do things at Cloudsoft. Whilst this works extremely well for human users, for software and systems that are automated and need API keys, you will still need IAM users. There is also a very occasional AWS system that breaks when accessed using AWS SSO - step forward, the Chime management console. But these limitations are small and our team have been very happy to use the SSO service since we rolled it out.

Where next?

After having got this far, here are some more things that you might want to try out:

• Manual setup is bad, automation is good, and AWS SSO configuration is supported by the Terraform AWS provider, so you can set this configuration down in Terraform files and commit it to source control. (Unfortunately the user directory part of AWS SSO is read-only in Terraform. Hopefully this will change in future versions, but if you are dealing with large numbers of users and groups, integrating with a corporate directory may be better.)
• If you’ve got an existing corporate directory, you can integrate this into AWS SSO, so you can authenticate to this using your existing directory. This is pretty straightforward to do for the well-known providers, such as Microsoft Active Directory, Google Workspaces, Auth0, etc.
• If you want to stick with SSO’s own directory, you should probably mandate MFA and generally make sure that the security options are appropriate.
• You can also use this service to sign on to other external applications - it’s not just limited to AWS accounts. For example, this blog post AWS SSO Integration with Common Business Applications explains how to add Jenkins to your SSO landing page next to your AWS account list, and sign onto Jenkins with a single click.
• The AWS CLI supports SSO too, so if you’re regularly using the CLI have a look into configuring it for SSO. Doing so means less API credentials need to be stored, reducing your security exposure.

Conclusions

When might you want to use AWS SSO? Considering the title of this article is “Everyone should use AWS SSO”, it perhaps makes more sense to note when you might not want to use AWS SSO. There are a few occasions - if your corporation has already built or bought an SSO service that can do everything AWS SSO can, then obviously there’s no need. And if you’ve only got one or two individuals using only one or two AWS accounts, then even though SSO will still simplify it, your current operational overhead probably isn’t too bad.

But considering AWS SSO can scale all the way up to large corporate directories and all the way down to a single individual’s personal AWS account such as my own, then no matter what your AWS usage is, you can probably benefit from using AWS SSO.