Enable IAM Identity Center

If you’ve already enabled Identity Center and you’re already familiar with how it works, then you can skip this lesson.

If you’re using IAM Users, then this lesson is for you.

About Identity Center

There’s a service by AWS called the AWS IAM Identity Center that replaces what they used to call AWS SSO, and this is a service that lets you manage users and groups at scale to replace the need for IAM users.

This is a service especially useful for organizations, but it should also be used by individuals! The reason is because it prevents you from having to create multiple different users in AWS, especially if you already have users in a corporate directory. It also prevents you from having to use long-term access keys for your users, and it makes it a bit easier to manage multiple AWS accounts.

Let’s jump in and take a look at how this works and how to set it up.

Enable Identity Center

In the AWS Management Console, search for Identity Center, and then Enable Identity Center.

After you’ve Enabled Identity Center, the first recommended step is to Choose your identity source. Let’s do that.

Settings

Clicking that link will take you to the Settings which you can always access in the left menu.

Here you get Details like:

• Instance ARN
• Region where it’s enabled
• Whether you have a Delegated administrator or not (for multi-account setups, which we’ll talk about later)
• Identity Center enabled applications

We see an option to Enable Attributes for access control which is a very useful feature to grant access to users based on their attributes. We won’t talk about how to use this in this lesson, but here’s more information if you’d like.

Next we have Identity source settings. Here we can see:

• Identity source set to Identity Center directory
• Authentication method set to Password
• Provisioning method set to Direct
• AWS access portal URL which is your unique login URL for you and your members
• Identity store ID

You can click on Actions in the top right corner of this panel to Customize AWS access portal URL which you can use to set up a custom subdomain for your URL, or Change identity source which you would use to change from using Identity Center directory to Active Directory or an External identity provider. For this, I’ll leave it at Identity Center directory and I recommend you do the same for individual accounts. The other options make more sense for organizations that already use AD or an external IdP.

Going back to the prior screen, there are also other tabs of Authentication and Management.

In the Authentication tab, we have the ability to configure how users authenticate when you’re using the CreateUser API, like if we want to send an email One-Time Password, we could enable that here.

Standard authentication

In fact, let’s go ahead and enable that by clicking on Configure.

As you can see, it tells us that by default, users created don’t have a password, and so we’ll want to check the box that says Send email OTP and then Save.

We can also configure and enforce MFA usage, and we can configure session durations.

MFA Settings

Let’s Configure our MFA settings. What you select here is up to you, but I would recommend these settings for a good balance between max security and user experience:

• Prompt users for MFA – Only when their sign-in context changes (context-aware)
• Users can authenticate with these MFA types – leave the defaults of Security keys and built-in authenticators and Authenticator apps
• If a user does not have a registered MFA device – Require them to register an MFA device at sign in
• Selecting that last option will grey out the ability to uncheck Users can add and manage their own MFA devices

Save Changes

Under the Management tab, we can delegate administration for IAM Identity Center, or we can delete our configuration.

Permission sets

Before we create an users or groups, let’s set up Permission sets by clicking on that link in the left menu. Then, click on Create permission set.

Here, you can either select Predefined permission set or you can create your own Custom permission set.

This is the same thing that we saw when using AWS managed IAM policies versus creating your own from scratch — there are trade-offs to each approach, and it depends on what you need. For this demo, I’m going to select AdministratorAccess then Next.

On this next screen, we’ll configure the Permission set details where we can change the name if we want, set a description, a session duration (which I’ll leave at the default of 1 hour) and then a Relay state which you can configure to automatically redirect a user after they’ve logged in.

By default, when you log in, you get taken to the main AWS console dashboard. Instead, you could redirect to the EC2 console, for example.

I’ll leave this blank for this and I’ll skip Tags. Next.

Review and then Create.

Create a Group

We can now go over to Groups in the left menu and Create group.

Name this whatever you’d like, but I’ll keep it simple with AdministratorAccess.

Create group.

Next, head over to AWS accounts. I briefly mentioned that we will learn about multi-account setups and security later in this course, but for now you don’t need to worry about all of this stuff you see here. Unless you’ve set up multiple accounts before, you will only see one account here — your management account which is the one you’re currently logged into. Go ahead and select its checkbox, and then Assign users or groups.

Select the group you created previously, and then Next.

The same goes for Assign permissions sets, let’s select it, click Next, and Submit.

You’ll now see the assigned Permission set next to the account.

You would, of course, repeat these steps for all of the permission sets that you’d want to create.

Then, it’s time to create users.

Create Users

Navigate to Users in the left menu, and then Add user.

Start by providing a username, followed by how you want the user to receive their password:

• Send an email to this user with password setup instructions
• Generate a one-time password that you can share with this user

Enter the Email address, First name, Last name, and Display name.

Next, you can add Contact methods if you’d like. You can also add Job-related information like:

• User type
• Title
• Employee number
• Etc…

Address information, Preferences, and Additional attributes.

I’ll leave these blank for this, then click on Next to proceed.

Select the relevant Group, and then click Next.

Review and Add user.

Activate the new user account

You should receive an email pretty much right away that looks like this:

Accept the invitation, which will lead you to this landing page:

Type in your new password, and Set new password.

You’ll then be asked to login, and you will be asked to register a new MFA device.

Select the method you prefer and activate your MFA.

You will then get re-redirected to a dashboard where you can see one or more AWS accounts that you have access to. Because we only have access to one account, that’s the only one we’ll see on this screen. For multi-account setups, we would see all of the accounts we have access to including the roles within those accounts we can assume.

Clicking on the role name will log in you into the AWS console with that role’s credentials.

Click on the access key link will open a window with different ways of assuming this role from our local CLI or through code. The first option is the recommended option because it will automatically renew expired credentials for you.

We can use this method by typing in aws configure sso in our terminal. Let’s try that now.

AWS Configure SSO

Pull up your local terminal, and if you don’t already have the AWS CLI installed, go ahead and pause here, go to this documentation, and come back once you have the CLI version 2 installed: https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html

You can tell whether you have it installed or not by typing in:

aws help

Which should open up the AWS help menu. You can exit out of that menu by typing in q.

Once installed, type:

aws configure sso

It will ask you what you want to name your SSO session:

SSO session name (Recommended):

I’ll name mine test.

It will then ask for your SSO start URL:

SSO start URL [None]:
Code language: CSS (css)

Copy and paste the URL from the AWS instructions, which will look a little bit like this (but yours will be different):

https://d-90678874c6.awsapps.com/start#
Code language: JavaScript (javascript)

SSO start URL [None]: https://d-90678874c6.awsapps.com/start#
Code language: JavaScript (javascript)

Then, type in the SSO region:

SSO region [None]: us-east-1Code language: CSS (css)

You’ll then see a message come up that says:

Attempting to automatically open the SSO authorization page in your default browser.
If the browser does not open or you wish to use a different device to authorize this request, open the following URL:

https://device.sso.us-east-1.amazonaws.com/

Then enter the code:

GENM-XADQ
Code language: JavaScript (javascript)

And it will have a unique code, and it will open a browser window with the same code. As long as the codes match up, you can Confirm and continue. If they don’t match up, something is definitely wrong.

You’ll then be asked to grant access to botocore-client-test to access your data. Click on Allow.

After all that, you’ll get new information in your terminal:

The only AWS account available to you is: 299xxxxxx
Using the account ID 299xxxxxx
The only role available to you is: AdministratorAccess
Using the role name "AdministratorAccess"
CLI default client Region [None]:
Code language: JavaScript (javascript)

Type in your default region, I’ll use us-east-1

I won’t change the default output format, and you can keep the default CLI profile name or change it, it’s up to you.

From there, you can now use this as your profile. For example, you can run:

aws s3 ls --profile AdministratorAccess-299

I don’t have anything in S3 for this account so it won’t return anything, but you also don’t get an access denied error which is a good sign!

Another cool trick that you can do now is type in:

aws sso login --profile AdministratorAccess-299

It will ask you to confirm that the code matches, you may have to allow access again, and it will not only refresh your credentials for when they expire, but also display the Start URL that you can copy/paste to access your dashboard.

Accessing the Management Console

Let’s go back to that URL, actually, and now let’s click on Management Console.

It will sign us in, and then give us access to the AWS console.

Why do this & Conclusion

There you go! You have now enabled IAM Identity Center, you’ve created a Permission set, a Group, and an Admin user.

As you can see, this is quite different from creating IAM users, groups, and IAM policies.

One of the reasons this is the preferred approach is because it prevents you from having to use long-term access keys for local AWS CLI commands.

As you saw earlier, even though we could copy/paste temporary credentials, these are still not long-term access keys; they are short-term credentials.

We can also tell this, by the way, by looking at the Access Key ID. If it starts with ASIA instead of AKIA, then it means it’s a temporary access key, but we can also see that because there’s an AWS_SESSION_TOKEN and these tokens expire after a certain amount of time.

So even if you need to use credentials, like for a script or local code, you could use these temp credentials. But otherwise, you can simply configure SSO in your AWS CLI instead of having to set hardcoded long-term credentials.

Another benefit of this approach, as we saw earlier, is that we can set up Active Directory or an Identity Provider, in order to manage our AWS users from our existing corporate directory instead of having to re-create all of that in AWS IAM.

But this is already a long lesson, so let’s leave it at that, and let’s complete this lesson!