The Importance Of AWS Single Sign-On (SSO) For SaaS Products

The Software as a Service (SaaS) development model offers many advantages over traditional software installations, including flexibility, scalability, and cost-effectiveness (read more here: https://medium.com/p/8e741bb1c9d6).

Businesses use many SaaS products to automate their daily operational processes. However, one of the biggest challenges they face when moving to the cloud is identity and access management. You only need to look at the recent news to learn more about SaaS security incidents to understand the importance of getting this right. If every SaaS product you use requires you to create a new username and password, you will end up with a large set of credentials leading to security challenges. One of the best ways to secure access to SaaS applications is through single sign-on (SSO), thereby allowing users to access them with a single username and password issued by the organization to which the user belongs.

AWS SSO From Amazon Web Services

SSO is an authentication strategy that allows users to access multiple applications with one set of credentials. Typically, the user signs in with their username and password, and then they are granted access to all the applications they are authorized to use.

AWS Single Sign-on is the single sign-on access providing service by Amazon Web Services. AWS SSO allows you to access multiple AWS accounts and other business applications just with a single access credential having them centrally managed. The initial application talks to the identity provider — AWS SSO — with the user’s credentials and gets a token, from then onwards, every other application sees that token as part of the request and knows how to parse that token and get the user information without prompting the user for credentials again. Let’s deep dive and look into more interesting things you could do with the AWS SSO service.

Let’s get started

You can access AWS SSO right from the AWS Management Console. The AWS Organisation Administrator can configure permissions and access controls for all the AWS accounts and users centrally and without any complexity. Since all this work can be done in a single dashboard-like user portal, it eliminates the work of setting up the configurations manually on each account.

Creating and managing user identities in AWS SSO

The AWS Organization Administrator can create new identities for individual users and even user groups within the AWS SSO user portal and manage them centrally all in one place. The AWS SSO also provides the facility of connecting existing user identities from third-party external user directories with the AWS SSO user directory. They include

· Microsoft Active Directory

· Okta Universal Directory

· Azure AD

And many more supported identity providers. Click here to learn more. You can also automate this process of granting users and user groups with permission by using APIs and the AWS CloudFormation service.

Auto-sync identities from other directories

After integrating user identities from any of the external directories mentioned above, user identities are automatically synchronized from those directories. This means, whenever new identities are created or changes are made to the existing identities, it automatically gets reflected in the AWS SSO dashboard, eliminating the need for manual periodic synchronizations.

Built-in integrations for other business applications

AWS SSO not only allows us to grant access to AWS accounts and services but also supports other business applications. To mention a few popular ones,

· Atlassian

· Dropbox

· Github

· G Suite

· Office365

· Salesforce

· Slack

Many more pre-integrated applications can be found here. Click to view

Steps to setup AWS SSO in the Management Console

Step 1: Enable AWS SSO

· Log in to your AWS Management Console on your favorite browser.

· Search for AWS Single Sign-On in AWS Services.

· Make sure you have an AWS Organization setup. If not, click “Create AWS Organization” to set one up.

· After setting up an organization, Click “Enable AWS SSO” as shown below.

Step 2: Select the source of Identity

The AWS SSO store holds the identities of the users that are needed to be given access. You are also given the option to choose from the list of supported external identity providers as the source of identity. As discussed earlier the AWS SSO also provides automatic synchronization of users from those external sources as well.

After adding users, they appear as a list of authenticated users. Now you can assign specific permissions to each user individually or put together a bunch of users as a user group and assign permissions to that group.

Here is a guide for setting up a few popular external identities:

· AWS SSO Store -managing user identities in default AWS SSO store.

· Microsoft AD Directory — Connect your Microsoft AD Directory with AWS SSO.

· OKTA Directory — Connecting with OKTA user directory.

Step 3: Assigning SSO access to AWS Accounts and Applications

The AWS SSO provides authorized users with personalized user portal access to several AWS Accounts or Applications, using their credentials that were set up in AWS SSO.

AWS Accounts:

1. Inside the AWS SSO console, Click on AWS Accounts.

2. Click “Assign users” to add a list of users to specific AWS accounts that they can access using their AWS SSO credentials.

3. Create permissions set in the permissions tab. A permission set is a set of permissions that can be assigned to users or groups.

AWS Applications:

1. In the AWS SSO console, choose Applications in the left navigation pane.

2. Select your desired application in the list.

3. Choose Actions, and then choose either Disable or Enable.

Other Business Applications:

The AWS SSO not only works with AWS Applications but also with other businesses’ cloud applications. A detailed guide for setting up AWS SSO credentials for those applications from other businesses can be found here. Click to learn more.

AWS SSO + IAM

When getting started with AWS, we start by creating an AWS Account. In that account, we first create an organization, and under that organization, we create one or more AWS user accounts. Next, we create IAM roles and permissions for several users and group them based on their type of job or department, etc. At the end of the day, you end up with many IAM roles and permissions for every single account added to the organization. It can indeed get complicated in handling the users and the IAM configuration. That’s one of the main reasons for AWS to come up with AWS SSO.

AWS SSO eliminates the work of managing users with IAM permissions by giving access to the users to handle their individual accounts. In SSO, all you have to do is to add the user to the AWS SSO directory and assign to them the required permissions. Then the users can log in to their accounts through the SSO user portal without any hassle.

From a security standpoint, when you have to assign IAM permissions to a user, you have to go to the specific user and alter their permissions or roles. When a user has to access something from another account, which is typically called cross-account access, the administrator has to give access permission to every AWS account. As long as it goes smoothly we don’t have a problem. The security of the sensitive components in the cloud is at stake when excessive permissions are assigned to undesignated personnel in the company. But in the case of AWS SSO, you can manage the users in groups all in one place and can be confident that the right person has the right access permissions without having to worry about things going wrong. Dealing with each user individually and assigning IAM permissions is what stands out in the case of SSO.

Let’s imagine a case where we have a user called Chloe. Now Chloe has access to her account ‘X’. She wants to access an S3 bucket that resides in another account, and says ‘Y’. Now she has to assume a role that was assigned to her, which grants access to S3 service alone from her account ‘X’ and access to the bucket in account ‘Y’. This role gives temporary credentials to Chloe with which she can access the S3 bucket in account ‘Y’. This is the main source of the pain because the administrator needs to deploy and manage many policies and roles across the AWS accounts.

Conclusion

The AWS SSO eliminates a lot of layers when configuring IAM access to users and makes it easy to handle user access management — all in one place. It also eliminates the fear of security breaches from misconfigured IAM permissions and roles and moreover, the combination of AWS SSO and IAM just makes life easier in the world of AWS user management.

To know more reach out to us at cloudengagement@ankercloud.com