Businesses adoption of AWS SSO is increasing. But how do you know if now is the time migrate away from using Identity Access Management (IAM) and adopt AWS SSO? If you have multiple usernames, passwords and access keys for several AWS accounts and other business applications, you may find that IAM becomes difficult to manage as your business grows.

AWS SSO stands for Amazon Web Services Single Sign-On, and offers a user portal that make it easy for businesses to centrally manage access to multiple AWS accounts and other Security Assertion Markup Language (SAML) 2.0 business applications. It also integrates with AWS Control Tower and AWS Organisations, which will be covered in later blogs.

So what is it that makes AWS SSO such a compelling security offering?
 

What are the benefits of AWS SSO?

There are too many benefits to adopting AWS SSO to count! However, these are some of the most common responses from customers choosing to adopt SSO, as well as some of my personal favourites:

1. Gone are the days of employees needing to remember different usernames and passwords for each AWS account and business application. With AWS SSO, users can sign into the user portal with one set of credentials and have access to the accounts and applications they need. Each user will only have access to the account and application depending on the group or role they perform in the business, allowing the “grant least privilege” model.


2. Programmatic access is requested daily using temporary credentials that last up to 12 hours, unlike IAM role chaining for temporally access which only lasts for one hour. This means that employees do not have to store persistent credentials on disk and maintain them by rotating credentials manually. AWS SSO will force the use of Multi Factor Authentication (MFA) before allowing users access to the portal or any other business application.
    
3. Businesses can connect existing Identity Providers to AWS SSO (e.g. Microsoft Active Directory) so that these existing users can login to the AWS SSO with the credentials already in use by your business. It’s worth noting here that a password change can be forced at the first login attempt for extra security. Other identity providers could be used, or AWS SSO can even act as an identity provider for businesses that do not need or want to migrate user accounts.
    
4. AWS SSO provides better visibility into which users accessed which accounts and applications from the user portal by recording all user portal sign-in activities in the AWS CloudTrail. The users will see their name and the account name they are logged into in the top right of the AWS Console.

Example AWS SSO user portal:
 

What are the AWS SSO areas requiring development?

AWS SSO is still relatively new and like all new services, there are a couple of areas still requiring fine tuning. However, this should not put organisations off adoption, as new features and developments are added regularly. The below are common problems encountered, most of which can we worked around either by using other AWS services or community-created solutions with trusted third parties.

1. AWS SSO does not support Application Programming Interface (API) calls to create new users. This means that if your business is using AWS SSO as the identity provider, the only way to create new users is via the AWS SSO console. Groups can be created via API calls and existing users can be moved into groups via API calls. If your business uses any other identity provider new users will continue to be created using existing provider methods.
    
2. Existing IAM users cannot be migrated to AWS SSO users. This is a deliberate decision made by AWS; the idea being that IAM, and AWS SSO are two different and completely isolated access methods. However, this does mean that business can work on building their AWS SSO architecture without effecting existing users’ access to IAM, as you can simply disable IAM accounts when the user is ready to use the AWS SSO access.
    
3. Non-human account access. Most business will have AWS accounts that have trust relationships with other services and tools. The problem is due to how credentials are stored and accessed. IAM credentials are stored persistently in the ~/.aws/credentials folder, and most services and tools are designed to investigate this location to get the credentials needed to authenticate. However, AWS SSO does not store credentials in this folder as they are temporary and only valid for the duration of the session. AWS SSO requires authentication profiles to be set up for each account credentials are never stored outside of AWS. There are workarounds for this issue but at the time of writing, nothing is being provided directly by AWS. 

How does your business get started with AWS SSO?

Choosing to adopt AWS SSO is no simple task, but it is a step in the right direction to save time, reduce administration costs, and improve your AWS accounts security.

The below diagram illustrates a high-level view of a business architecture using AWS SSO with an existing Microsoft Active Directory (AD). This AD can be on-premises or cloud hosted. AWS SSO will even support an AD in other cloud providers; for example, Google Cloud or Microsoft Azure.
 

The takeaway

I believe all business can benefit from adopting SSO, but there are some use cases where IAM access will still be required. This should be limited and only used if absolutely needed, as most access requirements can be supported by AWS SSO. It is also worth noting that AWS are focused on developing their SSO offering, so there is a good chance that any concerns holding businesses back from adopting AWS SSO are currently being addressed. Finally, at the time of writing this blog, AWS SSO is offered as a free service.