Your AWS Cloud Journey: Step Two – Enabling SSO

Single sign-on (SSO) is an access control method that allows a user to access the resources of multiple applications by logging in with just one set of credentials. This type of centralized authorization provides strengthened security and increased productivity by allowing users quick access to needed apps while staying fully aligned with the organization’s identity policy.

SSO within your AWS Organizations provides a way to manage access and permissions to SaaS and other applications via a portal, allowing end-users to access assigned AWS accounts, cloud and custom apps in one location. This article expands on my previous blog post, Your AWS Cloud Journey: Step One – Initial Set Up & Org Design, and details how to enable single sign-on access to all AWS accounts using one username and password. This method will be done using the built-in AWS SSO Directory, but know that it is possible to link Active Directory or Managed-AD as well, which is how we typically configure enterprise-grade AWS infrastructures.

First things first: You should NEVER login to an AWS account using ‘root’ credentials. Like ever. Seriously!

As outlined in the April 5 blog 4 Tips to Maximize Your IAM Strategy in the Cloud, best practice is to create the account, enable multi-factor authorization (MFA), create an Identity & Access Management (IAM) user with full administrator access, and then log out and never log in with those credentials again. One of the best ways to accomplish this—without having different IAM users in each account, with different credentials—is using SSO.

Now, let’s get started!

The first step is to log in to the AWS Management Console in the Master Account.

 

 

Then, click on Services and find AWS Single Sign-On under Security, Identity & Compliance, or just type SSO under Find Services. Then click on Enable AWS SSO.

 

 

Now that SSO is enabled, let’s customize the URL that users will visit to log in. At the bottom of the page under User Portal, there is a URL. Click on Customize next to the URL.

 

Once you select Customize, another window will open. The words “You will not be able to change this later” are stated clearly enough on this window, but they worth repeating. You will NOT be able to change this later, so make sure you customize the link wisely.

Next, click on Manage Your Directory.

 

 

Notice the type is AWS SSO directory. If we were connecting to AD or similar, we could set that up first, and then come back and change the directory. For this example, however, we will proceed with the default directory that’s built in since this is the least costly option.

From there, click on Groups and then Create Group. We will use this group for our Administrators, so be sure to name it accordingly.

 

 

Click on Users, and then Add user.

 

 

Now that a user and a group have been defined, the next step is to define exactly what permissions and to which applications that user will have access. There are two types of permissions to consider here:

  1. AWS Accounts, the console for administration.
  2. Applications, a large list of SAML 2.0-based applications for when AWS SSO will be used as the SSO portal (think Okta).

In this case the user will be needing AWS Console access, so click on AWS Accounts.

 

 

You now have visibility into individual accounts within the organization. SSO for a Master Payer Account (MPA) would typically not be created, in order to prevent access from unauthorized users. So here you would select the non-production account and then click on Assign Users.

Then, click on the Groups tab and select Administrators. Something to note here: You do have the ability to assign permissions directly to a specific user, but that doesn’t scale, which is why the group was created.

 

 

Click Next, and then Create new permission set.

 

 

For this demonstration, the default built-in Administrator Access job function policy will be used since that selection aligns exactly with the permissions we want this user to have. This is also where any custom permissions could be created.

 

Click Create.

 

Click on the newly created Administrator Access permission set, then click on the Finish button.

 

 

In the background, an actual role will be created in your sub-account that the user assumes.

Now you can test it out. Go to the link you customized at the beginning for SSO and log in using the credentials for the user you created. Be sure to update the password as requested.

 

 

You will now see AWS Account listed in your SSO Portal.

 

 

Click on AWS Management Console, and voilà! You are now logged in as an administrator in the sub-account.

If you had multiple accounts, each would be listed and you could pick and choose which account you wanted to access, all with a single username and password.

 

 

All done! Now you can manage each one of your accounts easily and without having to remember a bunch of different usernames and passwords!

 

Regardless of where you are in your AWS journey, Sirius cloud experts can help architect, implement and manage an optimal solution designed to enable and accelerate your business outcomes. For more details on how Sirius can help accelerate your cloud journey, contact a Sirius cloud expert today.

By |2019-06-03T09:02:42-05:00June 3rd, 2019|Blog|Comments Off on Your AWS Cloud Journey: Step Two – Enabling SSO

About the Author: