Why You Need to Start Using AWS SSO

Remove IAM users from your Organization!

The landscape of AWS access patterns has been a very frustrating one for years. Having worked with people at all skill levels in AWS, we at Trek10 have discovered that most people struggle with it, even industry-leading experts. We've even worked on solutions like awsume to help make some of it easier, but there's always more to be desired. Building access patterns with raw AWS IAM is a fundamentally difficult thing to get right, and is not something that the community can solve, but rather the AWS platform needs to evolve to support more modern access patterns.

This is where AWS SSO comes into play - the next step in the evolution of AWS access. When an organization has fully adopted AWS SSO, signing into AWS will be just like any other enterprise application or service their employees use. And the best part - AWS SSO is totally free!

What is it?

AWS SSO is a service that helps facilitate access to your Organization's AWS accounts and SAML 2.0-authenticated applications. For AWS accounts, it integrates directly with AWS Organizations. It does not yet support AWS Organizations delegated admin, so you must use the organization management account to configure it. Once it's configured, you'll be able to use the AWS SSO portal to access your AWS accounts.

Identity Provider vs Service Provider

A couple of key terms to understand are "Identity Provider" and "Service Provider." An identity provider is a service that manages information about people and machines - their identities. This could be something like Okta or Google. If you have an account registered with an identity provider, it can validate that you are who you say you are through some method of authentication (commonly username and password).

A service provider on the other hand is an application that performs a service, like Office365, something from the Atlassian suite of projects, or even GitHub. It may maintain its own identities, but if you are an organization that utilizes many different service providers, you may find it cumbersome to have your employees manage authentication to multiple different service providers since they would have to maintain separate logins to each service.

To solve this problem, you can usually hook a service provider up to an identity provider, that way authentication happens at one location, and can be re-used for any integrated service provider.

AWS SSO can serve as both an identity provider and a service provider. By default, it provides you with a default identity store that you can use to manage identities (users and groups). However, it's better to use a dedicated identity provider, such as Okta, Google, or Microsoft Active Directory, and only treat AWS SSO as a service provider. When you do this, it means that AWS becomes just another one of your "enterprise apps" that your users will have access to. The primary reason we recommend against using AWS SSO as an identity provider is that a dedicated identity provider is likely to have more of the features your organization might feel is necessary, where the AWS SSO default identity store would be lacking (context-aware MFA controls, robust API controls, or even white-labeling).

Authentication vs Authorization

When treating AWS SSO as a service provider, there are two concepts to consider: authorization and authentication.

• Authentication verifies the identity of the user. It should be handled by the identity provider.
• Authorization determines what resources a user can access. In this case, the resources are AWS accounts you're granting access to, so authorization should be handled by AWS SSO (more on that later).

The only time you'll want to federate applications to AWS SSO and not your identity provider is when the application/service sits within the AWS ecosystem. A few examples are the AWS services that get federated via SAML, such as QuickSight or IoT SiteWise Monitor. Another one could be this community self-hosted service for sandbox-style account vending: https://github.com/iann0036/aws-account-controller). For any other type of application (email, Jira/Atlassian, GitHub, etc), you should be federating them to your identity provider directly.

Beyond the actual federation, you'll want to also consider configuring automatic provisioning via the SCIM protocol. With SCIM, you can configure your identity provider with credentials from the service provider to automatically provision and de-provision users in the target service provider (AWS SSO) as they're assigned and unassigned from the service within your identity provider (Okta, etc). Without automatic provisioning, you'll have to manually replicate any assigned user within AWS SSO, which undermines some of the advantages of a true SSO solution (single source of identity management).

Unfortunately, certain identity providers don't yet support SCIM (most notably Google Workspace/G Suite) so this part may still be manual, however adopting AWS SSO is still largely beneficial even in this case, as your users will still be authenticated against your identity provider. Even if you forget to remove an old AWS SSO user, they won't be able to sign in since the identity provider authentication would fail.

AWS SSO Authorization

When it comes to authorization, this is handled on the AWS SSO side by two resources: AWS::SSO::PermissionSet and AWS::SSO::Assignment.

A permission set is simply an IAM policy. A permission set can reference multiple managed policies and also have a single inline policy associated with it. On its own, a permission set does not translate into anything tangible - no access is granted yet. To grant access, you have to create an AWS::SSO::Assignment.

An assignment grants access to a specified principal (SSO user or group) to a specified target (AWS account) using a permission set. When an assignment is created on an account, AWS SSO uses a service-linked role in the target account to create the following:

• An AWS::IAM::SAMLProvider if one does not already exist in the account - this SAML provider (usually named AWSSSO_abcde12345_DO_NOT_DELETE) defines the issuer and service location as your AWS SSO instance portal, not your actual identity provider.
• An AWS::IAM::Role that trusts the created AWS::IAM::SAMLProvider and contains the permissions defined by the permission set. This role is usually named AWSReservedSSO_PermissionSetName_abcde12345.

AWS SSO Portal

Once you have your identity provider federated, automatic provisioning setup, permission sets created, and assignments created, you'll be able to access your AWS organization via AWS SSO. This can happen in one of two ways: identity provider-initiated auth (clicking an AWS SSO app from your identity provider) or service provider-initiated auth (going to an https://{SOME_ID}.awsapps.com/start).

If you use service provider-initiated auth, you'll be directed to sign in to your identity provider, and then redirected to the AWS SSO portal. If you use identity provider-initiated auth, your identity provider will automatically authenticate the user within the AWS SSO portal when it redirects you there.

It's important to understand that your identity provider only handles authentication (federating to the portal), not authorization (access to individual accounts). Within the AWS SSO portal, you'll have a view of each account you have an assignment for, and underneath each account, you have a view of each permission set within that account you have an assignment for. From there you can get console access or get credentials for the CLI (although for CLI access we recommend configuring the AWSCLIv2 for this, along with the helper utility aws-sso-util).

Go Get Started!

So how do you get started? Well first, you'll need access to an AWS organization. If you have a personal account, you can get started with the default AWS SSO identity store, but to get a better understanding of the AWS SSO configuration lifecycle, you can get a free Okta developer account at https://developer.okta.com/signup/. If your work organization is interested, you can configure AWS SSO without any disruption to your existing access patterns (IAM users/roles) while you get familiar. If you're worried about accidentally granting unnecessary access, note that you won't grant any access if you don't create any SSO assignments, but you can configure federation from the AWS SSO portal to your identity provider.

You'll want to decide on a region to configure your AWS SSO instance in. AWS SSO can only be instantiated in a single region. Once you've decided on a region, go to the SSO console in that region and create your SSO instance. Once it's created it will be in its default state. You'll then want to configure settings like the AWS SSO portal URL. If you're federating to another identity provider, you'll also want to set that up, along with automatic provisioning if that's supported by your identity provider.

After that, you'll want to define a landscape for your AWS access by creating assignments, following the principal of least privilege. An assignment has 3 dimensions to it: principal (preferably assigning by group), AWS account, and an AWS SSO permission set, so it's helpful to have this fully described before you dig into implementation. We like to have this defined using some sort of matrix for easy reference:

Once you have your AWS SSO instance and your identity provider configured, you'll be able to sign onto the AWS SSO and view all assigned accounts and permission sets, and finally start treating AWS access like a modern federated service.