Chapter 11: Bringing Your Users into AWS

In the previous chapter, we implemented the authentication and authorization components of the administrative user model, which we initially conceptualized back in Chapter 8, An Ounce of Prevention – Planning Your Administrative Model. We accomplished our objectives through a combination of service control policies from AWS Organizations, AWS Single Sign-On (SSO) permission sets, and group-based access controlled by an external identity provider (IDP). Our requirements for administrative user access focused on gaining access to AWS accounts and the resources within those accounts. However, what are our options for providing user identity information to those applications that our organization intends to host on AWS?

In this chapter, we will review how administrative and non-administrative identity use cases differ, examine several possible solution architectures to solve this challenge (some using AWS services and some not), and then...

Technical requirements

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

• An AWS account
• A SAML2 or SCIM-compliant IDP, such as Okta Identity Cloud, PingOne, or Azure Active Directory
• An Active Directory domain
• A remote desktop client to sign in to remote Windows servers, such as Microsoft Remote Desktop

Distinguishing administrative users from non-administrative users

We already have a connection to our AWS accounts via AWS SSO and our external IDP for the user accounts that are entitled to access our AWS environments. However, what can we do to ensure that all user accounts are available to applications in AWS, even if the users never need administrative access to an AWS account? To answer that question, first, we need to clarify how we define each of these types of accounts. In the broadest terms, administrative accounts are accounts that have enhanced permissions to modify system settings, create other accounts, and change the permissions for what other accounts can do. For our Redbeard Identity AWS use case, we classified administrative accounts as those accounts that had access to and could manipulate resources within an AWS account. We made distinctions as to where a given user had their administrative privileges via group memberships to specific accounts and permission sets...

Solutions to non-administrative user use cases for apps on AWS

Let's consider some of the solution architectures that are available to us when providing access to non-administrative user identity information to applications hosted within AWS. We will start with a baseline where we do not leverage any AWS services at all in order to access our user identities:

Figure 11.1 – An application directly integrated with an external IDP

In this configuration, the application, or its web server, is configured to operate as either a SAML service provider or an OpenID Connect (OIDC)-reliant party. Previously, we mentioned how services such as Amazon Cognito offer SDKs and code samples to facilitate application integration with those services. Standards bodies and open source communities offer similar plugins, SDKs, and web server modules that are designed to facilitate the adoption of standards-based identity protocols, such as SAML2 and OIDC. While this reduces...

Using Managed AD and trusts

We will bring our non-administrative users into AWS using a Managed AD instance in AWS Directory Services. Strictly speaking, we don't even need to import our user's accounts into the Managed AD environment in order to accomplish our goal. We can arrange for the Managed AD instance to perform lookups and binds against our on-premises AD forest using a trust. A trust allows two or more AD domains to authenticate against resources that are available in the other:

Figure 11.9 – A user signing in to an app through a domain trust

Consider the example in Figure 11.9. An AWS-hosted application that requires either AD or LDAP for user authentication or authorization is configured to look to an AWS Managed AD instance for user information. The Managed AD and the on-premises AD have a two-way trust:

1. The user signs in to the application.
2. The application looks to the Managed AD to verify the user's credentials...

Creating the trust between AWS Managed AD and on-premises AD

As we have touched so many different AWS services and created so many resources throughout this chapter, we should take a moment to reflect upon why we went through all of this effort. The aim of this exercise was to provide a mechanism by which non-administrative user identity information could be made available to applications and resources hosted inside our AWS environment. We elected to make our on-premises Active Directory accounts available through AWS Managed AD care of a two-way trust. Once the trust has been established, the accounts in both domains will be able to access resources in each of the domains. Applications that use Active Directory for user authentication or attribute lookup will be able to look inside both domains for user information.

Now that we have done all of the necessary supporting work to get to this point, let's configure the forest trust between the AWS Managed AD and our on-premises...

Summary

In this chapter, we brought our user's identity information into AWS so that it could be consumed by applications hosted on AWS. First, we considered how administrative and non-administrative identity use cases differ. Then, we examined several different solution architectures to solve the challenge of bringing user identity information into AWS. Finally, we built a solution that enabled AWS-deployed applications to access user information through our organization's authoritative sources. We did this by using AWS Directory Services and building a trust between our on-premises Active Directory and a Managed AD domain created within our AWS account.

In the next chapter, we will discuss how to use AWS-native identity services, such as Amazon Cognito, to solve application identity use cases while still deferring to our external IDP as the authoritative source of user identity information.

Questions

1. What is the difference between an administrative account and a non-administrative account?

   a. The distinction varies based upon an organization's level of risk acceptance and compliance requirements. However, generally speaking, administrative accounts have access to privileged resources and are subject to heightened access and audit controls.

   b. There is no difference.

   c. Administrative accounts must be stored in Active Directory.

2. Why would a two-way trust allow AWS-hosted applications to access users and groups in an on-premises Active Directory?

Further reading

To learn more on the topic:

• Tutorial: Setting up your base AWS Managed Microsoft AD test lab in AWS: https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_tutorial_test_lab_base.html
• Tutorial: Creating a trust from AWS Managed Microsoft AD to a self-managed Active Directory installation on Amazon EC2: https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_tutorial_test_lab_trust.html