Getting an Organization started on AWS Part 4: Identity Center, Single-Sign-On & Directory Service

Part 1: Introduction, AWS Accounts, IAM & AWS Organizations

Part 2: Multi-Account, Landing Zones & AWS Control Tower

Part 3: Domains, DNS & Route53

Part 4: Identity Center, Single-Sign-On & Directory Service

Part 5: WorkSpaces & WorkMail — workforce style users

Part 6: WordPress & Workloads

Hello and welcome back! In part 4 of this course, we’ll be going through AWS Identity Center / AWS SSO, and we’ll cover the theory of Directory Service and how they fit together.

The goal of this is to have a platform in place which can support a simple and seamless process for creating new workforce users and grant them the access and software they’ll need to do their jobs.

By the end of this course, you’ll be able to create users for your workforce who’ll have access to 0 or more AWS Accounts, with the permissions levels you specify. We’ll also be able to grant them access to third-party SAML-enabled apps such as Slack and DropBox, all through a single-sign-on portal.

So let’s get started with some theory around Identity Center and Directory Service.

Theory

AWS Identity Center is Amazon’s recommended approach for any workforce style identity federation requirements. The users created in Identity Center are not the same as IAM users, they’re created in a store that Identity Center is configured to use. Once a user is authenticated against this store, AWS swaps out those credentials for short-lived AWS credentials behind the scenes.

The service allows you to create users, and grant them cross-account permission sets to AWS resoureces.

The identity store comes in 3 flavours:

• The built-in store is a store of users which exists solely in the Identity Center.
• AWS managed Microsoft AD, which is a full-fat Microsoft Active Directory which is managed by AWS and lives within AWS Directory Service
• External, which is any external directory service — could be an existing on-premise AD, could be GSuite, JumpCloud, Azure AD, etc…

AWS Directory Service allows for a managed AD that we could use for WorkMail, WorkSpaces, etc… This comes in 4 flavours:

AD Connector acts as a proxy for an existing AD, so if you need your existing AD users in a directory within AWS, use this. Cognito is not often used for workforce style federation, and AWS Directory Service for Microsoft AD is a more expensive, yet feature-complete, windows AD.

In this course, we’ll be using Simple AD.

Architecturally, this looks like this:

Normally, we would have Identity Center in the management account. We could delegate that to a different account though if we wanted.

This has 3 types of stores, we could store users in an external directory, use the built-in store, or use a managed Microsoft AD from either within the same account or shared by another account.

Identity Center grants the users in that store access to 0 or more AWS accounts, as well as third-party SAML-enabled apps.

We could then use the directory in the directories account to grant access to things such as WorkMail and WorkSpaces.

In the below example, we use Simple AD to power WorkSpaces & WorkMail, but cannot be used as an Identity Source for Identity Center. We could then still use built-in or external for Identity Center.

We could also use an external Microsoft AD for Identity Center, and then use an AD Connector to use that in directory service for WorkMail and WorkSpaces

However, we’re going to be keeping things cheap and simple — all on the AWS platform. We won’t use a common directory for both Identity Center and WorkSpaces / WorkMail. Instead, we’ll use the free built-in store for Identity Center, and the cheapest possible directory for WorkMail and WorkSpaces

Hopefully, that’s enough theory and context, in the following walkthrough, we’ll set up Identity Center and enable third-party apps.

Walkthrough

To start with, make sure you’re logged in to the management account as the root user. Head over to AWS Identity Center, you can search it through the search bar, or go through Control Tower => Users => View in Identity Center.

You’ll notice an access portal link at the bottom right, you can customize the name of that if you wish — but once changed, it cannot be changed back. This is the SSO portal link that you’ll be providing to your workforce users. Clicking this will prompt you with a sign-in screen, since it has defaulted to the built-in identity store, it is the default login journey for Identity Center.

If you were to change Identity sources, you would get a different sign-in journey.

If you wish, you could change the type of Identity source by clicking the link shown below. We’re not going to be changing that

To get started, we can create permission sets. When granting a user or group access to an AWS account, you apply the permission set — which grant the user(s) or group(s) those level of permissions against that account.

So head over to Permission sets

For now, we can create one permission set called Billing. This grants access to billing-only features of AWS.

Give it a name, and you can specify how long the session for this permission set would live. I set mine to 4 hours.

Once done, head over to Users and add a user. We’re going to create a user who will have cross-account access with the Billing permission set.

Enter the details you want and click Next

Now, we can create a billing group. CLick Create group which will open a new tab, name it Billing and then go back to the create-user journey. CLick the refresh button and your group should be there

Copy the details

Now, you can go to AWS Accounts — select the accounts you want the Billing group to have access to, and click Assign users or groups

Choose your new permission set and click next

Click Submit. Now, this will create cross-account permissions for this user

Now you can click this link and log-in with our new user

Enter the username and copied password and click Sign-In. Reset the password and click set new password.

You can now see cross-account access with the Billing permission set. Choose an account, and click the Management console link.

Now that you’re logged in, you can see billing. Try to do anything else, however, like launch an Ec2 instance — and you’ll see that you do not have access.

Sign out of there and log back into the management account as the root user. Make your way back to the Identity Center dashboard.

Now that we have a way of creating new users and granting them granular access to our organization’s accounts, we can now also provide those same users with access to third-party SAML-enabled apps.

Some third-party apps require premium subscriptions to allow SSO, Slack requires Slack Business+, for example.

To start with, find an app you want to integrate, and find the online guide for integrating external SSO.

Once you’ve found your app, and have the relevant guide for configuration, go to Applications => Add application

Find your app from the list, and if it is not there, click “Add custom SAML 2.0 application”.

Now you will see IAM identity centre metadata, you could download the entire file if the app you’re working with supports SAML metadata uploads, or copy individual values. You’ll also have to upload the certificate, which Identity Center provides as a download link

Upload that in your application, and then enter the ACL and SAML audience values from the third-party app.

In the case of Slack, that is http://www.slack.com and https://www.yourworkspace.slack.com respectively.

Submit that.

Now back in Identity Center applications, assign your users or groups to the aplication

Now when you log into the SSO portal, Slack will be there.

JIT (Just-In-Time) provisioning of users is not supported by the built-in store, so you’ll have to create your users in the 3rd-party app first, and then invite the user to the app through the app. Once the user is created in both Identity Center and in the app, the one-click login from the SSO portal will work.

If you used an external provider for Identity Center, like GSuite or Azure AD — then you could provision JIT users, that would be a setting in the Identity Source provider itself.

Now you’ve granted application access to the user, one other thing you can do is enable MFA for Identity Center.

Firstly, any users created in Identity Center will need their email verified. The user’s email should have an email come through with a verification link, ensure users click that link to verify their email.

Once you’ve done that, you can now configure MFA. So go to Identity Center => Settings => Configure multi-factor authentication.

We will prompt for an MFA code every time a user logs in, we will support authenticator apps, and allow the users to sign-in if they don’t have an MFA configured, and we will allow users to manage their own MFA devices.

Save those changes.

Now we can go back to the sign-in portal, and click MFA devices in the top right. It is from here that the user can register his or her MFA device. Every time they sign-in now, they will be prompted for their MFA code.

Conclusion:

And that’s pretty much everything for Identity Center. We’ve explained the role it plays, how it can relate to directory service, as well as your options for configuration of Identity Center— and we’ve demonstrated how to configure it. You can now add new users to your business and grant them access to various services and AWS accounts.

In part 5, we’ll be configuring WorkMail and WorkSpaces for your users. You will be able to give a user an email address on your domain, grant them a virtual desktop environment if you want to, and have that managed by a directory in Directory Service we’ll create.

IT members of the organization will be able to remotely connect to a domain controller machine, where they can add new users to the organization through Active Directory. Users will have their own email addresses and optionally their own work desktops.

Technically, that will involve:

• Creating a shared networking account, with a VPC and network configuration that the directories account can use.
• Create a directory in Directory Service
• Create a domain controller to manage the directory
• Configure WorkMail, so that we can give users created in AD a mailbox and email address that they can use from anywhere (mobile phone, mail app, etc). Bonus feature, the email will support aliases!
• Configure WorkSpaces against the active directory users
• Create an end-to-end process for creating, managing, and deleting workforce users.

So I hope this has been useful, I’ll see you in the next part