Chapter 10: Administrative Single Sign-On to the AWS Backplane

In the previous chapter, we built out the provisioning and account synchronization processes between our Amazon Web Services (AWS) environment and the Redbeard Identity organization's existing identity provider (IDP). Our administrative users are now synchronized to the AWS single sign-on (SSO) user directory from our external IDP using the System for Cross-domain Identity Management (SCIM). Of course, populating the AWS SSO user store is only half of the administrative access equation. Next, we will address administrative user authentication and authorization to ensure that each administrator can only access the environment that is appropriate for them.

The following topics will be covered in this chapter:

• Why use federation for AWS administrators?—Learn why identity federation is a good pattern for managing administrator access into the AWS control plane
• Assigning access to AWS accounts—...

Technical requirements

To get the most out of this chapter, you will need the following:

• An AWS account
• A Security Assertion Markup Language 2 (SAML2) and an SCIM-compliant IDP such as Okta Identity Cloud, PingOne, or Azure Active Directory (Azure AD)
• A populated user directory to act as the user store for that IDP
• A workstation running the AWS CLI
• A text editor or integrated development environment (IDE) to edit JavaScript Object Notation (JSON)/YAML Ain't Markup Language (YAML) files, such as Microsoft Visual Studio Code (VS Code)

The code samples used in the chapter can be found at the following links:

• Updated Redbeard Identity comma-separated values (CSV) file: https://github.com/jonlehtinen/ImplementingAWSIdentity/blob/main/RedbeardIdentity_csv_template_new_scim_user.csv
• ITS_ec2_policy.json document: https://github.com/jonlehtinen/ImplementingAWSIdentity/blob/main/ec2_policy.json

Why use federation for AWS administrators?

Before we dive into the mechanics of connecting our AWS environment with our external IDP, let's take a moment to revisit our assumptions around why we would choose to use an external IDP for AWS access in the first place. As we have seen throughout this book, AWS has multiple services capable of addressing user authentication and authorization. It could be argued that given the AWS Identity and Access Management (IAM) service itself already evaluates every transaction and has the capability to handle user management, authentication, and authorization, daisy-chaining additional components to that service unnecessarily complicates matters.

The argument for using identity federation with administrative accounts echoes the same arguments for identity federation with most other third-party applications. Identity federation, especially automated provisioning and deprovisioning, helps control the proliferation of user and company data on...

Assigning access to AWS accounts

Now that we can sign in to AWS SSO with our external IDP, we need to assign accounts to users within AWS SSO in order to close the loop between the authorization controlled by the IDP and the authorization controlled by AWS. If we considered the IDP's authorization control coarse-grained, AWS SSO provides options for fine-grained control through a variety of mechanisms. Let's start with some basic authorization controls and refine the permissions further as we go.

We can see all of our AWS accounts listed in the AWS accounts menu inside AWS SSO, as illustrated in the following screenshot:

Figure 10.6 – Our AWS accounts

Presently, we have no users assigned to any of them. We also do not have any permission sets assigned to any of the accounts. A permission set defines what an AWS user can do within an AWS account when signing in through AWS SSO. A permission set is stored as an AWS IAM role that is assumed...

Implementing fine-grained access management for administrators

So far, we only have two levels of access for our administrators inside our AWS accounts once those administrators are placed inside a group that allows them to sign in to AWS SSO: AdministratorAccess and ReadOnly. If we defined group-based access that determines if a user is permitted to even access AWS SSO as coarse-grained access management, then the access granted by these two permission sets represents a very rudimentary example of role-based access control (RBAC). By layering on additional concepts, we can further refine our authorization model into something that is only allowed access to specific resources based upon the assumed role and the user's attributes, to achieve fine-grained access management through attribute-based access control (ABAC).

Permission sets and managed authorization policies

To achieve fine-grained access management through ABAC, we will need to marry an improved set of permission...

Administrative SSO using the AWS CLI

One of the primary benefits of using AWS SSO for administrative access is the issuance of temporary credentials. Whereas we have used durable programmatic credentials for AWS CLI access in the past, we can now use a browser for SSO and instantiate a temporary session without needing to issue or store those credentials on our workstation. We do this by selecting the command-line or programmatic access link after signing in to AWS SSO from our external IDP, as illustrated in the following screenshot:

Figure 10.40 – Our temporary AWS CLI credentials through AWS SSO

We will sign in as the Iam Dev user once again and copy the commands to export the variables we need to use the AWS CLI with our temporary credentials. These credentials are valid for the duration of the session we defined within the permission set for this assumed role. For this particular role, these credentials are good for 9 hours. Once we enter the values...

Summary

In this chapter, we put into practice what we have learned across several AWS services to design and apply an administrative account authentication and authorization model. By using an external IDP, we were able to quickly deprovision access for administrators. Synchronizing our external IDP's users and groups into AWS SSO via SCIM laid the foundation for us to pair coarse-grained authorization control managed at the IDP with a fine-grained authorization policy controlled by AWS to fulfill our administrative authorization business objectives. We wrote a custom authorization policy for our permission sets using conditional operators. Finally, we saw how that model extends into the AWS CLI as well and improves security by eliminating long-lived programmatic credentials.

In the next chapter, we will switch our focus to application-centric identity using Amazon Cognito. We will address making our enterprise user accounts available for our applications hosted in AWS.

...

Questions

1. What is coarse-grained authorization?
2. What is fine-grained authorization?
3. What is a permission set?
4. How does a permission set grant access to the AWS accounts to which it is attached?

   a. It provisions users into that account.

   b. It automatically creates an assumable AWS IAM role for the federated user to assume in the managed AWS account.

   c. It doesn't.

5. AWS CLI access through AWS SSO removes the need to use long-lived programmatic credentials managed through AWS IAM.

   a. True

   b. False

Further reading

To learn more on the subject:

• Manage SSO to your AWS accounts: https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-accounts.html
• Attribute-based access control: https://docs.aws.amazon.com/singlesignon/latest/userguide/abac.html
• Actions, resources, and condition keys for AWS services: https://docs.aws.amazon.com/service-authorization/latest/reference/reference_policies_actions-resources-contextkeys.html