AWS Identity Federation

6-minute read
AWS • Certification • Basic • Identity Federation • SAML • SSO • IAM Identity Center • Cognito • SA-PRO

Identity federation is the process of exchanging one trusted set of credentials for another. Any form of identity federation requires a trust relationship with the identity provider, and the party granting credentials for access to resources is established. In AWS this is handled in one of several ways:

  • SAML 2.0 Identity Federation
  • IAM Identity Center (Successor to AWS Single-Sign On SSO)
  • Cognito

An essential aspect of identities in AWS is that the only identity that can access AWS resources is the identity that AWS provides. This means we cannot use an AD identity, Web Based identity, or any other identity to access AWS resources. So for a user to authenticate with another identity provider to use an AWS resource, they must exchange that credential for one issued by AWS.

SAML 2.0 Identity Federation

SAML 2.0 Identity Federation can be considered a legacy method of using a SAML 2.0 provider, like Microsoft Active Directory - though SAML2.0 is an open standard, to authenticate and provide temporary credentials to AWS resources. It has largely been replaced by IAM Identity Center (Formerly AWS SSO). This style federation is used when we have an enterprise identity provider and wish to use that identity to provide access to AWS resources.

The way that an application obtains AWS credentials using SAML 2.0 federation is:

  1. The administrators must have created an IAM SAML IdP in IAM and connected it to a SAML identity provider (often Active Directory), establishing two-way trust between these entities. In addition, appropriate roles and mappings must have been created and made.
  2. The application, authenticating with the SAML credentials, will access the SAML identity provider and authenticate. It will then be presented with a list of roles for the application.
  3. The application will select one of the roles, and the SAML provider will return a SAML assertion, which AWS will trust.
  4. The application communicates with AWS using the assume-role-with-saml passing along the role ARN, SAML provider IAM ARN and the SAML assertion. 5.The return from this call will be a set of temporary AWS credentials with authority specified in the role selected. The application can use these credentials to access AWS resources.

The typical process for a user to access the AWS console using SAML2.0 is very similar to the steps followed for application access. The significant difference is that a portal application interacts with the SAML2.0 provider. Instead of calling assume-role-with-saml, passes the assertion to the SAML/SSO endpoint, which generates temporary credentials internally and returns a sign-in URL for the user to the console to the portal application. Once the portal has these, the user is redirected to that sign-in URL and will see the portal with the correct permissions based on their role.

IAM Identity Center (Successor to AWS Single Sign On - SSO)

IAM Identity Center (formerly AWS SSO - and hereafter in this article just referred to as IAM Identity Center) is the preferred way for organizations to federate logins to AWS accounts. IAM Identity Center centrally manages single sign-on to multiple AWS accounts and some external applications (Office 365, Dropbox, Slack, etc…) It is flexible in that it can handle various types of identity providers.

  1. AWS Managed Active Directory
  2. On-Premise Microsoft Active Directory (two way trust or AD Connector)
  3. External SAML2.0 Identity Providers
  4. Built In Identity Provider

There is no cost to implement IAM Identity Center. IAM Identity Center does require an organization to get started.

When To User IAM Identity Center or SAML2.0

  • When you have an enterprise identity provider (Microsoft AD or other SAML provider)
  • When you have an existing identity management team or processes
  • When you require a single source of truth for identity information, and you can’t use IAM for that source of truth for one reason or another
  • When you need to support more than 5,000 users

One case where SAML2.0 or IAM Identity Center are not appropriate choices is when your identity provider is a web-based or social provider such as Facebook, Twitter, Google, or anything else that isn’t SAML2.0.

Cognito

Cognito consists of two products. The first product is Cognito User Pools, and the second is Cognito Identity Pools. These products have a few similarities, but only the latter offers identity federation to AWS (or at least most AWS resources).

Cognito provides authentication, authorization, and user management for web/mobile applications. Authentication refers to logging in as a user and indicates that the user used the correct credentials. Authorization is a service that manages access to services or resources. An example is that authentication means a person has valid credentials to log in to a work computer. Still, unless that person were designated as an administrator, he would not be authorized to install a software package. Finally, user management deals with creating and maintaining a database of users for an application or a system.

Cognito User Pools

The most important thing to remember when trying to understand the difference between Cognito User Pools and Cognito Identity Pools is that Cognito User Pools will never yield, directly, an AWS credential. User Pools instead provide JWTs (Jason Web Tokens), which are only directly usable by a few AWS services - like API gateway.

The primary purpose of a user pool is user directory management with sign-up and sign-in (with a customizable web UID), along with support for MFA and other features. In addition, sign-in can be federated with one or more social sign-in providers (Facebook, Google, Amazon, Apple, Etc…) along with its own database of users.

Cognito Identity Pools

Cognito Identity Pools’ primary purpose is to exchange tokens from Cognito User Pools or directly with social sign-in providers for AWS temporary credentials. In addition, identity Pools can provide Unauthenticated Identities for guest users. In these cases, roles are configured based on the supplied credentials. As a result, the application receives a set of temporary AWS credentials with authorization based on the role.

Using Cognito User Pools and Identity Pools Together

If you want to allow social sign-in but at the same time offer your users sign-in based on their username and password, using Cognito User Pools alongside Cognito Identity Pools makes sense. In this scenario, you would set up your Cognito User Pool to allow sign-in with the social providers you choose, along with its database of users.

When the users authenticate with the User Pool, we will have a Cognito User Pool JWT. Cognito Identity Pools can be configured to use this JWT to provide temporary AWS credentials for resources. The application can then use the AWS credentials to access AWS and make the required requests to things like S3, Dynamo DB, and Lambda Functions.

Setting up the structure of your authentication and authorization this way makes it easier to deal with different types of logins in the identity pool. It effectively abstracts the login using User Pools. It lets the identity pool use the appropriate roles based on the User Pool JWT instead of configuring it to respond to the various tokens from each sign-in provider.