AWS Identity and Access Management – Now With Identity Federation

 In the past 6 months we have launched several AWS Identity and Access Management (IAM) features that have made it easier for our customers to control access to their AWS account. For example, weve launched support for IAM in the AWS Management Console, we’ve enabled users to log in to the AWS Management Console, and we announced general availability of IAM.

Identity Federation
Today we are enabling Identity Federation with IAM. This new capability allows existing identities (e.g. users) in your enterprise to access AWS APIs and resources using IAM’s fine-grained access controls, without the need to create an IAM user for each identity.

Applications can now request temporary security credentials that can be used to sign requests to AWS. The temporary security credentials are comprised of short lived (1-36 hour) access keys and session tokens associated with the keys. Your enterprise users (or, to be a bit more precise, the AWS-powered applications that they run) can use the access keys the same way as before, as long as they pass the token along in the calls that they make to the AWS APIs. The permissions associated with temporary security credentials are at most equal to those of the IAM user who issued them; you can further restrict them by specifying explicit permissions as part of the request to create them. Moreover, there is no limit on the number of temporary security credentials that can be issued.

How it Works
Suppose that you want to allow each employee of a large organization to use a reporting application to store data files in their own slice of an S3 bucket. Before making any calls to S3, the application would use the new GetFederationToken function (one of two functions in the new Security Token Service) to create a set of temporary security credentials specific to the particular employee. Here is the general flow:

Let’s go through this, one step at a time:

1. The Identity Broker
   

   This flow presupposes the existence of an Identity Broker. The broker is responsible for mapping the employee identifier in to a set of AWS credentials. This could be implemented as a separate process or network service, or it could be embedded in the calling application. If the broker is running in a separate process, there is no need to embed an AWS credentials in the storage application.

   We have put together a sample Identity Broker in order to show you how to build one of your own. The sample code implements a proxy using Microsoft Active Directory. The proxy issues temporary security credentials for access to Amazon S3 buckets and objects, using permissions that are tied to a particular Active Directory User. The code includes a sample Federation Proxy and a sample console application.

   

   If you build an Identity Broker that works with another directory, let me know and I’ll post an update to this blog.

   An employee decides to use an AWS-powered reporting application to save some information in Amazon S3.

2. The application calls an Identity Broker. The broker accepts an employee identifier as input.
3. The Identity Broker uses the organization’s LDAP directory to validate the employee’s identity.
4. The Identity Broker calls the new GetFederationToken function using IAM credentials. The call must include an IAM policy and a duration (1 to 36 hours), along with a policy that  specifies the permissions to be granted to the temporary security credentials.
5. The Security Token Service confirms that the policy of the IAM user making the call to GetFederationToken gives permission to create new tokens and then returns four values to the application: An access key, a secret access key, a token, and a duration (the token’s lifetime).
6. The Identity Broker returns the temporary security credentials to the reporting application.
7. The data storage application uses the temporary security credentials (including the token) to make requests to Amazon S3.
8. Amazon S3 uses IAM to verify that the credentials allow the requested operation on the given S3 bucket and key
9. IAM provides S3 with the go-ahead to perform the requested operation.

The Security Token Service can elect to return a token that is valid for less than the duration requested in the call to GetFederationToken. The client application must track the expiration date and time of the token so that it can obtain a new token before the current one expires. Any request made with an expired token will fail.

The token can have any subset of the permissions granted to the caller (an IAM user) of GetFederationToken. This means that you can create an IAM user with access only to the APIs and resources that the application needs.

Identity Federation can be used with a number of AWS services including EC2, S3, SNS, and SQS. We expect to enable additional services over time.

The IAM Hotel
The latest version of the IAM documentation provides detailed information on how to use this new functionality, but I think it is worth showing you how it ties in with the rest of IAM using a simple metaphor:

Imagine that your AWS account is like a hotel and you are the innkeeper. In the early days of AWS our customers were often startups or individuals, essentially small groups for which basic security met their needs. So we offered a single master key granting unconditional access to all of your AWS resources.

Over time, our customer base grew more sophisticated, including more complex organizations and more significant resources to protect. The old model required sharing of the master key; this was not sufficient to meet the security needs of these larger organizations. With the introduction of IAM you can create the equivalent of access badges for your hotel employees housekeeping gets access to guest rooms, cooks get access to the kitchen, in effect allowing you to grow your business while giving you explicit control over the permissions granted to your employees. You, the owner, can define and enforce the appropriate level of access.

However, taking the hotel metaphor further, lets think of your hotel guests. You could give them the same access badges as you give to your employees, but since their stay is short you would need to ensure that they return their badges when they leave. Or you could ask your hotel employees to help guests enter their room or access hotel facilities, but that level of personalized service would not scale as your business grows. Of course, we all know what the solution is to that problem: to enable your front desk to issue temporary hotel access cards to your guests for accessing only their room and hotel facilities.

As you can see, identity federation opens up new use cases for our enterprise customers. In the language of the hotel metaphor, you now have the ability to issue hotel cards to your guests. You can provision temporary security credentials for identities you are responsible for managing, with no limits on the number of identities you can represent or the number of credentials you can obtain.

— Jeff;