Easily enable SSO (Single Sign-On) to protect your AWS Accounts

4 minute read

Enabling SSO on your AWS Accounts is strongly encouraged, adds additional security, access to multiple accounts from a single entry point (with different permission sets), and above all, it is free.

The following is a walk-through of how to enable Single Sign On in the AWS console. These instructions are for people with individual accounts to a few accounts. Actually, these instructions are just a good general starting point for smaller size orgs.

Enable Organizations

  • Log into the AWS Console as the Root account
    • Note: This should be in the primary account that will hold the Organization if you have more than one account. These instructions only go through getting SSO enabled, not adding accounts to an Organization.
  • Go to Organizations (once again another service free of charge)
![](https://codex.org/wp-content/uploads/2020/12/2020-12-28-organizations-landing-page-1024x632.png)
  • Click “Create organization” and then click “Create organization”
    • Note, this can only be done for one account in the org, and it would be best to do this in a new account if you are going to be adding a large number of other accounts or people.
    • If this is your only account it is not a big deal. Just add it to your base account.
![](https://codex.org/wp-content/uploads/2020/12/2020-12-28-organizations-created-1024x713.png)
  • Verify your email address to finish the setup process.
    • This is a default. I think it is for security reasons to ensure that not just anyone that has admin access to the account creates an Organization.
    • The email will be sent to the root account email address.

Enable Single Sign On

![](https://codex.org/wp-content/uploads/2020/12/2020-12-28-sso_landing_page-1024x551.png)
AWS SSO Landing Page
  • There are two options here. Click the link to “Enable AWS Single Sign On” or search for SSO in the top level search bar.
  • Click “Enable AWS SSO”.
    • Assumptions here:
      • You are going to use AWS as the Identity Source.
      • You have already created the Organization
      • You are happy to be getting this done, and looking forward to being able to access all your accounts from a single location. (Without being charged extra for it). (This sounded much funnier when I was writing it the first time)
![](https://codex.org/wp-content/uploads/2020/12/2020-12-28-sso_created_next_steps-1024x533.png)
Default Landing Page for SSO After Account Creation

Configure Single Sign On

![](https://codex.org/wp-content/uploads/2020/12/2020-12-28-sso_configure_multi_factor_auth-1024x910.png)
  • Go to Settings.
    • Identity Source — Leave this set to AWS SSO.
      • For me this makes sense. I don’t have a third party solution for this, and I don’t want to have to manage it.
    • User Portal — you can create a custom url. This is nice so that you do not have to attempt to remember the default one that is provided.
    • Multi-factor Authentication — these are my preferred settings.
      • Prompt for MFA – Every time they sign in (always-on)
      • MFA types – for me, either works, but I like to use Authy, because then I can get into it from anywhere. And, if my device breaks, I still have access to my keys.
      • If a user does not yet have a registered MFA device
        • Require them to provide a one-time password sent by email to sign in
        • If you are going to protect your accounts, go all the way with it.
      • Who can manage MFA devices — Users can add their own.

Create Users and Groups

![](https://codex.org/wp-content/uploads/2020/12/2020-12-28-sso_add_users_create_group.png)
The Create Group Pop-up
  • Next step is to create Groups and Users
    • I like to add the Group first because then I can just add the Users to all the groups when I create them.

    • Users are the people that will have access to the accounts.
    • The groups are just groups of users. The permissions are not tied to there.

Configuring Account Access

Setting up and configuring AWS Single Sign On is almost complete. The last remaining steps are to create Permission Sets and then to assign them to users or groups that are bound to accounts. As a default, I like to create an Admin and ReadOnly permission set. You can attach the users/groups to the accounts first, but I prefer to create them the other way and to create the permission sets, and then attach users/groups to the accounts.

  • Create Permission Set
    • Standard that you can select from a list. These are limited to an hour.
    • Custom. Can still be almost the same, but, one nice thing is that you can change the timeout to up to 12 hours.
![](https://codex.org/wp-content/uploads/2020/12/2020-12-28-sso_create_permission_set-1-2-1024x302.png)
Dialog for adding permission set
  • Assign users and groups from the AWS Organization Tab.
    • I only have the 1 account. Click the check box and then click “Assign Users” (it should really read assign users and groups)
    • I like to assign groups and not users. So I have added both to my mix here.
    • Note, you can only add 1 group at a time or they get all the permission sets.
![](https://codex.org/wp-content/uploads/2020/12/2020-12-28-sso-add-users-to-accounts-2-1024x606.png)
  • On the AWS accounts page. Click on the Name of the account to get an overview of it.
![](https://codex.org/wp-content/uploads/2020/12/2020-12-28-sso-account-summary-1024x562.png)

You can now login via SSO

All you have to do now is go to the link that is provided in the configuration. Once you log in, you will get a list of the accounts that you have available to you and the roles that you can assume in each one.

That is really all there is too it. It is quick and easy to setup, and after you start using it, you will wonder why you did not do it sooner. This is a great solution for solo developers, small companies, and even larger companies if you want to get into integration with your own federation servers.