AWS Identity and Access Management (IAM) Roles, SSO(Single Sign On), SAML(Security Assertion Markup Language), IdP(identity provider), STS(Security Token Service), and ADFS(Active Directory Federation Services)

bogotobogo.com site search:

Note

We'll learn how to make our users to single sign in to the AWS Management Console or to make programmatic calls to AWS APIs by using assertions from a SAML(Security Assertion Markup Language)-compliant IdP(identity provider).

Since there are good materials how to implement the SSO(Single Sign On), in this tutorial, we'll just look into what the work flow looks like via AD FS (Active Directory Federation Services).

SAML and ADFS

SAML is an open standard used by many identity providers. It enables federated single sign-on (SSO), which lets users sign into the AWS Management Console. Many of us are using Windows AD for our corporate directory, and because Windows Server includes ADFS, it's naural to use ADFS as our IdP.

The following diagrams demostrate, at a high level, how an Active Directory (AD) user is federated by AD FS to gain access to AWS resources:

The flow is initiated when a user (Bob) browses to the ADFS sample site inside his domain.
The sign-on page authenticates Bob against AD.
Bob's browser receives a SAML assertion in the form of an authentication response from ADFS. So, this 1,2, and 3 steps are the processes of the federated user authenticates against ADFS. If authentication is successful, the user is sent a SAML assertion.
Bob's browser posts the SAML assertion to the AWS Security Token Service (STS) in the form of a SAML request. If the SAML request is valid, STS returns a SAML response that contains the user's AWS temporary credentials.
Bob's browser receives the sign-in URL and is redirected to the console.

Note that the applications or services assume the role (permissions) at run time. This means that AWS is providing to the application or the user temporary security credentials that can be used whenever they need access to those resources.

IAM roles are designed so that our applications can securely make API requests from our instances, without requiring us to manage the security credentials that the applications use. Instead of creating and distributing our AWS credentials, we can delegate permission to make API requests using IAM roles.

The Tools for Windows PowerShell authenticate against ADFS by using the Windows user's current credentials, or interactively, when a cmdlet that requires credentials to call into AWS is run.
ADFS authenticates the user.
ADFS generates a SAML 2.0 authentication response that includes an assertion; the purpose of the assertion is to identify and provide information about the user. The PowerShell cmdlet extracts the list of the user's authorized roles from the SAML assertion.
The PowerShell cmdlet forwards the SAML request, including the requested role Amazon Resource Names (ARN), to STS by making the AssumeRoleWithSAMLRequest API call.
If the SAML request is valid, STS returns a response that contains the AWS AccessKeyId, SecretAccessKey, and SessionToken. These credentials last for 3,600 seconds (1 hour).
The Tools for Windows PowerShell user now has valid credentials to work with any AWS service APIs that the user's role is authorized to access. The Tools for Windows PowerShell automatically apply these credentials for any subsequent AWS API calls, and renew them automatically when they expire.

Here is a similar diagram:

A user in your organization uses a client app to request authentication from our organization's IdP.
The IdP authenticates the user against our organization's identity store.
The IdP constructs a SAML assertion with information about the user and sends the assertion to the client app.
The client app calls the AWS STS AssumeRoleWithSAML API, passing the ARN of the SAML provider, the ARN of the role to assume, and the SAML assertion from IdP.
The API response to the client app includes temporary security credentials.
The client app uses the temporary security credentials to call Amazon S3 APIs.

STS API Methods

AssumeRole
AssumeRole does require us to start with some basic AWS credentials, but those are allowed to be short-term ones as opposed to GetFederationToken.
AssumeRoleWithWebIdentity
AssumeRoleWithWebIdentity requires no AWS credentials to start with. Instead, it takes an external identity (Facebook etc.) and uses the trust policy built into the role to elevate AWS access for a short period of time.
AssumeRoleWithSAML
Same with AssumeRoleWithWebIdentity but it's used within AWS Organizations.
GetFederationToken
We must call the GetFederationToken action using the long-term security credentials of an IAM user. It scopes AWS credentials down in power (weaker) and time (shorter: up to 36h) so they can be handed out to someone else.
GetSessionToken

How to Connect Your On-Premises Active Directory to AWS Using AD Connector

AD Connector is designed to give us an easy way to establish a trusted relationship between our Active Directory and AWS. When AD Connector is configured, the trust allows us to:

Seamlessly join Windows instances to our Active Directory domain either through the Amazon EC2 launch wizard or programmatically through the EC2 Simple System Manager (SSM) API.
Provide federated sign-in to the AWS Management Console by mapping Active Directory identities to AWS Identity and Access Management (IAM) roles.

AD Connector forwards sign-in requests to our Active Directory domain controllers for authentication and provides the ability for applications to query the directory for data. When we configure AD Connector, we provide it with service account credentials that are securely stored by AWS. This account is used by AWS to enable single sign-on (SSO).

Given AD Connector's role as a proxy, it does not store or cache user credentials. Rather, all authentication, lookup, and management requests are handled by our Active Directory.