AWS News 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 were 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 youre developing a mobile app that uses the new Login with Amazon service for authentication, and part of the apps 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:
- A trust policy that specifies a trusted entity (principal)that is, who can assume the role. In this case, the trusted entity is any authenticated Amazon.com user.
- An access policy with permissions that specify what the user can do.
Setting up a trust policy for Login with Amazon
First well create the trust policy. For this example, lets assume youve registered your app with Login with Amazon and youve 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.com and 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 conditionswe now have support for identity-providerspecific 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, lets 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, were also using ${www.amazon.com:user_id}, which contains the users 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, lets 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.
- First, the user needs to be authenticated. Using the Login with Amazon SDK, the app authenticates the user and receives a token from Amazon.
- Next, the user needs to be authorized to access resources in your AWS account. The app makes an unsigned
AssumeRoleWithWebIdentityrequest to STS, passing the token from the previous step. STS verifies the authenticity of the token; if the token is valid, STS returns a set of temporary security credentials to the app. By default, the credentials can be used for one hour. - Finally, the app uses the temporary security credentials to make signed requests for resources in your S3 bucket. Because the role’s access policy used variables that reference the app ID and the user ID, the temporary security credentials are scoped to that end user and will prevent him or her from accessing objects owned by other users.
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