About SAML 2.0-based federation
Amazon supports identity federation with SAML 2.0 (Security Assertion Markup Language 2.0)
IAM federation supports these use cases:
-
Federated access to allow a user or application in your organization to call Amazon API operations. You use a SAML assertion (as part of the authentication response) that is generated in your organization to get temporary security credentials. This scenario is similar to other federation scenarios that IAM supports, like those described in Requesting temporary security credentials and About web identity federation. However, SAML 2.0–based IdPs in your organization handle many of the details at run time for performing authentication and authorization checking. This is the scenario discussed in this topic.
-
Web-based single sign-on (SSO) to the Amazon Web Services Management Console from your organization. Users can sign in to a portal in your organization hosted by a SAML 2.0–compatible IdP, select an option to go to Amazon, and be redirected to the console without having to provide additional sign-in information. You can use a third-party SAML IdP to establish SSO access to the console or you can create a custom IdP to enable console access for your external users. For more information about building a custom IdP, see Enabling custom identity broker access to the Amazon console.
Using SAML-based federation for API access to Amazon
Assume that you want to provide a way for employees to copy data from their computers to a backup folder. You build an application that users can run on their computers. On the back end, the application reads and writes objects in an S3 bucket. Users don't have direct access to Amazon. Instead, the following process is used:

-
A user in your organization uses a client app to request authentication from your organization's IdP.
-
The IdP authenticates the user against your organization's identity store.
-
The IdP constructs a SAML assertion with information about the user and sends the assertion to the client app.
-
The client app calls the Amazon STS
AssumeRoleWithSAML
API, passing the ARN of the SAML provider, the ARN of the role to assume, and the SAML assertion from IdP. -
The API response to the client app includes temporary security credentials.
-
The client app uses the temporary security credentials to call Amazon S3 API operations.
Overview of configuring SAML 2.0-based federation
Before you can use SAML 2.0-based federation as described in the preceding scenario and diagram, you must configure your organization's IdP and your Amazon Web Services account to trust each other. The general process for configuring this trust is described in the following steps. Inside your organization, you must have an IdP that supports SAML 2.0, like Microsoft Active Directory Federation Service (AD FS, part of Windows Server), Shibboleth, or another compatible SAML 2.0 provider.
To configure your organization's IdP and Amazon to trust each other
-
Register Amazon as a service provider (SP) with the IdP of your organization. Use the SAML metadata document from
https://
region-code
.signin.amazonaws.cn/static/saml-metadata.xmlFor a list of possible
region-code
values, see the Region column in Amazon Sign-In endpoints.You can optionally use the SAML metadata document from
https://signin.amazonaws.cn/static/saml-metadata.xml
. -
Using your organization's IdP, you generate an equivalent metadata XML file that can describe your IdP as an IAM identity provider in Amazon. It must include the issuer name, a creation date, an expiration date, and keys that Amazon can use to validate authentication responses (assertions) from your organization.
-
In the IAM console, you create a SAML identity provider entity. As part of this process, you upload the SAML metadata document that was produced by the IdP in your organization in Step 2. For more information, see Creating IAM SAML identity providers.
-
In IAM, you create one or more IAM roles. In the role's trust policy, you set the SAML provider as the principal, which establishes a trust relationship between your organization and Amazon. The role's permission policy establishes what users from your organization are allowed to do in Amazon. For more information, see Creating a role for a third-party Identity Provider (federation).
-
In your organization's IdP, you define assertions that map users or groups in your organization to the IAM roles. Note that different users and groups in your organization might map to different IAM roles. The exact steps for performing the mapping depend on what IdP you're using. In the earlier scenario of an Amazon S3 folder for users, it's possible that all users will map to the same role that provides Amazon S3 permissions. For more information, see Configuring SAML assertions for the authentication response.
If your IdP enables SSO to the Amazon console, then you can configure the maximum duration of the console sessions. For more information, see Enabling SAML 2.0 federated users to access the Amazon Web Services Management Console.
Note The Amazon implementation of SAML 2.0 federation does not support encrypted SAML assertions between the IAM identity provider and Amazon. However, the traffic between the customer's systems and Amazon is transmitted over an encrypted (TLS) channel.
-
In the application that you're creating, you call the Amazon Security Token Service
AssumeRoleWithSAML
API, passing it the ARN of the SAML provider you created in Step 3, the ARN of the role to assume that you created in Step 4, and the SAML assertion about the current user that you get from your IdP. Amazon makes sure that the request to assume the role comes from the IdP referenced in the SAML provider.For more information, see AssumeRoleWithSAML in the Amazon Security Token Service API Reference.
-
If the request is successful, the API returns a set of temporary security credentials, which your application can use to make signed requests to Amazon. Your application has information about the current user and can access user-specific folders in Amazon S3, as described in the previous scenario.
Overview of the role to allow SAML-federated access to your Amazon resources
The role or roles that you create in IAM define what federated users from your
organization are allowed to do in Amazon. When you create the trust policy for the role, you
specify the SAML provider that you created earlier as the Principal
. You can
additionally scope the trust policy with a Condition
to allow only users that
match certain SAML attributes to access the role. For example, you can specify that only
users whose SAML affiliation is staff
(as asserted by https://openidp.feide.no)
are allowed to access the role, as illustrated by the following sample policy:
{ "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Principal": {"Federated": "arn:aws-cn:iam::
account-id
:saml-provider/ExampleOrgSSOProvider"}, "Action": "sts:AssumeRoleWithSAML", "Condition": { "StringEquals": { "saml:aud": "https://signin.amazonaws.cn/saml", "saml:iss": "https://openidp.feide.no" }, "ForAllValues:StringLike": {"saml:edupersonaffiliation": ["staff"]} } }] }
For more information about the SAML keys that you can check in a policy, see Available keys for SAML-based Amazon STS federation.
You can include regional endpoints for the saml:aud
attribute at
https://
.
For a list of possible region-code
.signin.amazonaws.cn/static/saml-metadata.xmlregion-code
values, see the
Region column in Amazon Sign-In
endpoints.
For the permission policy in the role, you specify permissions as you would for any role. For example, if users from your organization are allowed to administer Amazon Elastic Compute Cloud instances, you must explicitly allow Amazon EC2 actions in the permissions policy, such as those in the AmazonEC2FullAccess managed policy.
Uniquely identifying users in SAML-based federation
When you create access policies in IAM, it's often useful to be able to specify permissions based on the identity of users. For example, for users who have been federated using SAML, an application might want to keep information in Amazon S3 using a structure like this:
myBucket/app1/user1
myBucket/app1/user2
myBucket/app1/user3
You can create the bucket (myBucket
) and folder (app1
) through
the Amazon S3 console or the Amazon CLI, since those are static values. However, the user-specific
folders (user1
, user2
,
user3
, etc.) have to be created at run time using code, since
the value that identifies the user isn't known until the first time the user signs in
through the federation process.
To write policies that reference user-specific details as part of a resource name, the user identity has to be available in SAML keys that can be used in policy conditions. The following keys are available for SAML 2.0–based federation for use in IAM policies. You can use the values returned by the following keys to create unique user identifiers for resources like Amazon S3 folders.
-
saml:namequalifier
. A hash value based on the concatenation of theIssuer
response value (saml:iss
) and a string with theAWS
account ID and the friendly name (the last part of the ARN) of the SAML provider in IAM. The concatenation of the account ID and friendly name of the SAML provider is available to IAM policies as the keysaml:doc
. The account ID and provider name must be separated by a '/' as in "123456789012/provider_name". For more information, see thesaml:doc
key at Available keys for SAML-based Amazon STS federation.The combination of
NameQualifier
andSubject
can be used to uniquely identify a federated user. The following pseudocode shows how this value is calculated. In this pseudocode+
indicates concatenation,SHA1
represents a function that produces a message digest using SHA-1, andBase64
represents a function that produces Base-64 encoded version of the hash output.Base64 ( SHA1 ( "https://example.com/saml" + "123456789012" + "/MySAMLIdP" ) )
For more information about the policy keys that are available for SAML-based federation, see Available keys for SAML-based Amazon STS federation.
-
saml:sub
(string). This is the subject of the claim, which includes a value that uniquely identifies an individual user within an organization (for example,_cbb88bf52c2510eabe00c1642d4643f41430fe25e3
). -
saml:sub_type
(string). This key can bepersistent
,transient
, or the fullFormat
URI from theSubject
andNameID
elements used in your SAML assertion. A value ofpersistent
indicates that the value insaml:sub
is the same for a user across all sessions. If the value istransient
, the user has a differentsaml:sub
value for each session. For information about theNameID
element'sFormat
attribute, see Configuring SAML assertions for the authentication response.
The following example shows a permission policy that uses the preceding keys to grant
permissions to a user-specific folder in Amazon S3. The policy assumes that the Amazon S3 objects are
identified using a prefix that includes both saml:namequalifier
and
saml:sub
. Notice that the Condition
element includes a test to
be sure that saml:sub_type
is set to persistent
. If it is set to
transient
, the saml:sub
value for the user can be different for
each session, and the combination of values should not be used to identify user-specific
folders.
{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:PutObject", "s3:DeleteObject" ], "Resource": [ "arn:aws-cn:s3:::exampleorgBucket/backup/${saml:namequalifier}/${saml:sub}", "arn:aws-cn:s3:::exampleorgBucket/backup/${saml:namequalifier}/${saml:sub}/*" ], "Condition": {"StringEquals": {"saml:sub_type": "persistent"}} } }
For more information about mapping assertions from the IdP to policy keys, see Configuring SAML assertions for the authentication response.