Types of Identity Federation


Course Introduction
Course Conclusion
Start course

Please note: this course has now been replaced with Using AWS Identity Federation to Simplify Access at Scale, which can be found here.


AWS Identity Federation is the concept of using external authorization sources to permit access to AWS Console and AWS Resources. Identity Federation comes in multiple levels that enable the use of existing directories or SAML to ensure users are accredited and authenticated to access AWS.

Intended audience

  • AWS Administrators
  • Security Engineers
  • Security Architects


  • You should review the Identity and Access Management Course
  • Have an understanding of Enterprise Identity technology such as Active Directory, LDAP; and some Open Identity Providers such as Google, Facebook, Twitter, or Amazon.

Learning Objectives

  • Understand what is Identity Federation as it relates to AWS Console Access.
  • Demonstrate the ability to set up and use Cross-Account Roles
  • Demonstrate the ability to use Simple AD for IAM authorization with Cross Account Roles
  • Understand the concepts of SAML Determine how SAML could be used for AWS Console Authorization

This Course Includes

  • 45 minutes of high-definition video
  • Live demonstration on key course concepts

What You'll Learn

  • Course Intro: What to expect from this course
  • What is Identity Federation?: This lesson defines the purpose and uses of Identity Federation
  • Types of Identity Federation: In this lesson, we’ll discuss the different ways it is used within AWS
  • Identity Federation Demos: In this lesson, we’ll walk through how to setup both Cross Account Roles using IAM User ids and using Simple AD for Authentication with Cross Account Roles
  • Course Conclusion: A wrap-up and review of the course

Now that we have a base understanding of identity federation and SSO, we can explore how to use this concept within AWS. The first concept will be cross account roles, and then we will move into the use of central directories so to authenticate users to AWS.

Now let's dive into cross account trusts and roles. With cross account trusts you're allowing AWS IAM users from one account to access another AWS account. The user from the first account is permitted to perform functions in the second account, based on an IAM role assigned to that user. Seems simple enough, but in practice it takes a careful set up to get just right. Typically, there is one account that is central and that is where IAM users are created, I'll call this the trusting account.

This trusting account serves as an authentication source. IAM now becomes the central directory where user IDs are maintained. Then users are given roles that permit access to the other account, let's call this the trusted account. It is this role in the trusted account that authorizes access to the services that are granted to users in the trusted account.

A basic three step process is all that is needed to establish this relationship between the trusted and trusting accounts.

First, create the role in the trusted account.

Two, grant access to this role in the trusting account.

And three, test, test, test. I want to give you a cross account organization power tip here real quick. One account is the trusting account, the other accounts are the trusted accounts. In your trusting account, you should contact AWS support and set all the resources to zero, so that nothing can be created in this account except for IAM users. This way you know the trusting account is just that, trusting, and the other accounts are the trusted accounts where you do work.

Now let's get into a little cross account details. In this scenario, we have an external account that has a list of users within its IAM users. The external users require access to a local account. The local account will set up a cross account role specifically for the external account. External users that assume this role will have access prescribed in the policy attached to this role. Only external accounts can manage which of its external IAM users can use this cross account role. The local account defines which external accounts can use this cross account role.

A common use case for this cross account role is managed service providers, i.e., consulting companies that help you manage your local accounts. You trust their consultants to come in and perform work on your AWS resources, such as starting and stopping EC2, putting data in an S3 bucket, and uploading billing data to their account, etc. Another use case is where your organization manages multiple AWS accounts for different tasks, development, test stage and production for your application.

A single user may take over multiple functions during the course of his or her day and access resources in different accounts. With cross account access, he or she can instantly switch to a different account without signing in again. Amazon Simple AD is a service offering that provides a directory as a platform as a service, or PaaS as it is often referred to. This is another way to federate log in to AWS console. The offering is based on LDAP and is compatible with Microsoft Active Directory.

This service provides basic directory and relieves you from having to manage the two servers that are provided in a highly available set up. The service does require a VPC with two subnets that can reach the Internet. The subnets and the service do not need to be publicly accessible or have public IPs, but the servers do need to have the ability to reach the Internet through a NAT gateway of some type.

There are two sizes of Simple AD, small, 2,000 objects or less, or large, 20,000 objects or less. Once you have a Simple AD running you can then connect EC2 resources to the service. The service supports both Linux and Windows Instances. You can join the Instances to the server at launch provided they are Windows servers, or by accessing the servers after launch and then joining the Instances to the Simple AD domain for both Windows and Linux servers. Simple AD supports the use of Microsoft Active Directory tools and the most supported method for administering this is from a Windows 2012 Instance with the AD Remote Admin feature installed.

Now remember, this is a PaaS offering supporting the creating of users and groups to help the ease of administration as well as the organizational units, or OUs as it's commonly known, to keep the directory service organized. This service can be used by the console for federated log in authentication and can be used by EC2 Instances running Windows or Linux as a central authentication source for the applications running on those servers, or simply for logging in to those servers.

Now there are limitations to Simple AD and a few features are not supported, trust relations, Active Directory Admin Center. Not every PowerShell API command is supported. And the AD Recycle Bin and group managed service accounts and schema extensions for POSIX for example and Microsoft applications, they're just simply features that are not supported. Because remember, this is an LDAP server with some extensions on it.

Now remember also, since this is a PaaS offering, Simple AD does not permit access to the underlying servers at an Admin level. It's up to you to administer the directory but not the Instances or the operating system that provides the platform that the service runs on. Security Assertion Markup Language, also known as SAML. It is an XML based open standard data format for exchanging authentication and authorization between parties. SAML uses a central directory service that is accessed by the user.

The user provides credentials, typically a user ID and password, and then is redirected back to the requested site and granted the level of access the requested site permits. SAML AWS console flow, the most important part of this exchange is in steps one to three. A user identity is authenticated against the on-premise Active Directory, via ADFS for example. In step four, the user access to the console sign in page will call the assume role with SAML with the authenticated identity.

And finally the user is redirected to the AWS Services page in step five. This typically happens very quickly and is always faster than a user typing in their user ID and password over and over again. Note AWS has many third party partners that have developed solutions to make SAML based SSO relatively painless. There is a short list of the third party vendors listed here in this URL, which is also included in the course outline and transcript. So feel free to look at this list and get a better feel for the number of third party offerings that Amazon offers to integrate with SAML. Web federation or OpenID authentication.

Web federation or OpenID Connect grants access of AWS resources to your global Web users such as Facebook or Google or Amazon or LinkedIn, just to name a few. A common scenario is a developer who wants to offload a major headache of account management, but still provide authenticated access to an AWS resource. Remember, account management is hard and takes a lot of resources, especially when something goes wrong. The traditional method of storing credentials and storing past passwords is risky, without a good security and operations team, which is why people are offloading this task to Google and Facebook and Amazon and others, just to name a few.

Web federation solves this problem by linking OpenID Connect compatible identity providers to your AWS resources. When a user logs in with a compatible identity provider, your app will make a call to the AssumeRoleWithWebIdentity to get a set of temporary credentials. These credentials are unique to each call and expire after a set amount of time. Since you are presenting access of your AWS resources to a global audience, you should take care to lock down your role. This is not for accessing the console. This is for accessing resources and applications that are built within AWS. Now let's go over the OpenID flow.

This is a simplified example of how a user would interact with OpenID Solution to gain authorized access to a website. Step A, the user navigates to a site and selects an OpenID Source, Google, Facebook, LinkedIn, and so on. B, the site returns a redirect to the OpenID provider selected. And then step C, a series of tokens are passed and authentication is verified with the OpenID provider granting access to the website application.


About the Author

Tom an active AWS Consultant creating and deploying AWS solutions for over five years. He has worked on numerous projects that involve everything from small lean startups on a tight budget to massive commercial Enterprises that have large-scale budgets with large-scale requirements that must be met even no matter the cost. Tom has worked for several of our United States government agencies taking the agencies to the cloud by migrating solutions from on-premise data centers to the AWS cloud in a secure solution while reducing their overall cost to operate and maintain the solution.

Personally Tom spends his available time riding his bicycle, sampling a good wine or two, enjoying a good meal and watching Formula One races.