Amazon Web Services Blog: AWS IAM Now Supports Amazon, Facebook, and Google Identity Federation

Jeff Wierer, Principal Product Manager on the AWS Identity and Access Management (IAM) team sent along a guest post to introduce a powerful new federation feature.

-- Jeff;

In a previous blog post we discussed how AWS Identity and Access Management (IAM) supports identity federation by allowing developers to grant temporary security credentials to users managed outside of AWS. Today we’re expanding this capability with support for web identity federation.  Web identity federation simplifies the development of cloud-backed applications that use public identity providers such as Facebook, Google, or the newly launched Login with Amazon service for authentication. For those of you not yet familiar with Login with Amazon, it's a new service you can use to securely connect your websites and apps with millions of Amazon.com customers. If you’re interested in learning more about Login with Amazon, please visit their launch page.

Web identity federation enables your users to sign in to your app using their Amazon.com, Facebook, or Google identity and authorize them to seamlessly access AWS resources that are managed under your AWS account. If you are building a mobile or a client-based application, you can now integrate these three popular identity providers and authorize users without any server-side code and without distributing long-term credentials with the app. To support this scenario, this release introduces a new AWS Security Token Service (STS) API, AssumeRoleWithWebIdentity. This API lets you request temporary security credentials for your customers who have been authenticated by Amazon.com, Facebook, or Google. Your app can then use the temporary security credentials to access AWS resources such as Amazon Simple Storage Service (S3) objects, DynamoDB tables, or Amazon Simple Queue Service queues.

Let's walk through an example use case.

Imagine you’re developing a mobile app that uses the new Login with Amazon service for authentication, and part of the app’s functionality allows end users to upload an image file as their personal avatar. Behind the scenes, you want to store those images as objects in one of your S3 buckets. To enable this, you need to configure a role that is used to delegate access to users of your app. Roles are configured in two parts:

Setting up a trust policy for Login with Amazon
First we’ll create the trust policy. For this example, let’s assume you’ve registered your app with Login with Amazon and you’ve been assigned an application identifier (app_id) of amzn1.app.123456SAMPLE. This application ID uniquely identifies your app with Login with Amazon. (If you register the app with Facebook or Google, you'll get a different app ID from each of these providers.) To delegate access to Amazon.com users, the trust policy for your role needs to include the new federated principal type www.amazon.comand the app_id value. The following trust policy allows any Amazon.com user who has authenticated using your app to call the sts:AssumeRoleWithWebIdentity API and assume the role.

{"Version":"2012-10-17","Statement":[{"Principal":{"Federated":"www.amazon.com"},"Effect":"Allow","Action":"sts:AssumeRoleWithWebIdentity","Condition": {"StringEquals":{"www.amazon.com:app_id":"amzn1.app.123456SAMPLE"}
 }
 ]
}

Notice that we have introduced a new type of key that can be used in policy conditions—we now have support for identity-provider–specific keys for Amazon.com, Facebook, and Google. In this case, the www.amazon.com:app_id key ensures that the request is coming from your app by doing a string comparison against your app's registered ID. (To read more about the new policy keys that support web identity federation, see Creating Temporary Security Credentials for Mobile Apps Using Public Identity Providers in the AWS STS guide.)

Next, let’s create an access policy for the role.

Sample Policy Allowing S3 Access

The following access policy grants end users of your app limited access to an S3 bucket named myBucket in your AWS account. Specifically, it grants every user read-only access (Get*) to a shared folder whose prefix matches the app_id value, and it grants read, write, and delete access (GetObject, PutObject, and DeleteObject) to a folder whose prefix matches the user ID provided by Amazon. Notice that the new identity provider keys described in the previous section, such as ${www.amazon.com:app_id}, can also be used as AWS access control policy variables. In this case, we’re also using ${www.amazon.com:user_id}, which contains the user’s unique Amazon.com ID. (Remember, when using a variable you must always set the Version element to 2012-10-17.)

{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":["s3:Get*"],"Resource":["arn:aws:s3:::myBucket"],"Condition":
 {"StringEquals":
 {"s3:prefix":["${www.amazon.com:app_id}","${www.amazon.com:app_id}/"]}
 }
 },
 {"Effect":"Allow","Action":["s3:GetObject", "s3:PutObject", "s3:DeleteObject"],"Resource":["arn:aws:s3:::myBucket/${www.amazon.com:app_id}/${www.amazon.com:user_id}","arn:aws:s3:::myBucket/${www.amazon.com:app_id}/${www.amazon.com:user_id}/*"
 ]
 }
 ]
}

Putting it All Together
Now that the role has been created, let’s take a look at how the role will be used to provide federated access to your end users. The following diagram illustrates the steps that occur to authenticate an Amazon.com user and authorize the user to access objects in an S3 bucket.

This is just one example of how web identity federation can be used. A similar flow can also be enabled for Facebook or Google identities by integrating their SDKs with your app and simply creating an additional role. For more information about web identity federation and how to create roles that support other identity providers, please see Creating Temporary Security Credentials for Mobile Apps Using Public Identity Providers in the AWS STS guide.

-- Jeff Wierer