A Road to Identity Federation

A key aspect of cloud adoption is determining how identities will be managed.

Typically, federal government customers want to use the same identities managed by their Identity Management System (IDMS) to access cloud resources. Federal agencies have their own well-managed, NIST and HSPD-12 compliant IDMS for issuing, revoking, and entitlements management of their identities. These agencies have identities on-premises (perhaps in Active Directory) that work with their Personal Identity Verification (PIV) cards that they would like to use to access AWS resources.

The ability to project your identity and authentication response for a third party to consume is called federation. By coupling federation with Single Sign-On (SSO), an agency user will automatically be signed into AWS once they are signed onto their managed desktop with their Active Directory account.

What is Identity and Access Management?

AWS Identity and Access Management (IAM) enables you to securely control access to AWS services and resources for your users. Using IAM, you can create and manage AWS users and groups, and you can federate your existing identities with IAM to implement role-based permissions that allow and deny access to AWS resources.

When using IAM, you can create identities (user accounts) for AWS Console, API, or Command Line Interface (CLI) access based on access keys or username and password. However, creating identities outside of your current IDMS means you will need to manage these identities and credentials. If you have multiple AWS accounts, you will end up with many identity stores and identities, one for each AWS account that represent a single user. This is referred to as identity sprawl.

AWS provides the ability to federate an agency IDMS with AWS IAM to control access to AWS resources. By doing this, you will not need to create identities across your AWS accounts and you will limit identity sprawl. Additional benefits of federating your IDMS with AWS IAM include: temporary security credentials, SSO or reduced sign-on for AWS Console, and CLI and API access. Also, that means that identity lifecycle management remains within your IDMS, and you can extend crypto-based two-factor authentication into AWS.

Federation Approaches

Below are two approaches to integrate an existing agency IDMS using SAML-based federation with IAM.

SAML Federation: Federation defines the exchanging of authentication and authorization information between Security Token Services (STS) and a relying party or service provider. AWS supports federation with SAML and OpenID Connect providers.

Cross-Account Access: In conjunction with SAML federation, another AWS capability is called cross-account access. Cross-account access can eliminate IAM user account maintenance and federation maintenance across your AWS account footprint. Cross-account access is where you share resources in one AWS account with users in a different AWS account. By setting up cross-account access in this way, you don’t need to create individual IAM users in, or federate with, each AWS account to grant access to AWS resources across your AWS accounts. Additionally, users won’t have to sign out of one AWS account and sign into another in order to access resources that are in different AWS accounts.

Steps to Setting up a Cross-Account Access

A good way to look at cross-account access is to look at the AWS account where the user authenticates or assumes a role (when using federation) as the trusted AWS account and the AWS account where the resource exists as the trusting AWS Account. Setting up cross-account access is a two-step process:

1. Provide the user in the trusted AWS account access to a role that grants them the permissions to call the sts:AssumeRole API for the specific Amazon Resource Name (ARN) of the role they need to assume in the trusting AWS account.
2. Define the role in the trusting AWS account that the user will assume. In this role, the permissions policy is a standard policy for defining resource actions. It is the trust policy that defines who can assume this role. In this trust policy, you can define the individual user (RoleSessionName) or a role in the trusted AWS account that can assume the role in the trusting AWS account.

SAML Federation Options

There are two options when using SAML Federation for Authentication and Authorization with your AWS account(s). The first option is to set up SAML federation with each of your AWS accounts as represented in Figure 1. Also, see AWS STS SAML Assertion Limits.

Figure 1: This Diagram shows SAML federation with multiple AWS accounts.

The second option is to use cross-account access along with SAML federation. In this option, you will need to setup SAML federation with one of your AWS accounts and implement cross-account access. This will provide access from the trusted AWS account authenticated users to resources in the trusting AWS account as represented in Figure 2.

Figure 2: This Diagram shows SAML federation with one AWS account and cross-account access to your remaining AWS accounts.

IAM is all things authentication and authorization for access to AWS resources, but if you do not want to take on the burden of managing identity stores and identities across your AWS accounts, you should leverage SAML federation. SAML federation will reduce potential administration and it will align to current compliance requirements whether you need single identity or authentication assurance or temporary or short-lived credentials. And cross-account access has the potential to further reduce the administrative burden when managing authentication and authorization across a large AWS account footprint.

A post by Michael Cotton, Sr. Solutions Architect – Federal, AWS