IAM tutorial: Use SAML session tags for ABAC - Amazon Identity and Access Management
Services or capabilities described in Amazon Web Services documentation might vary by Region. To see the differences applicable to the China Regions, see Getting Started with Amazon Web Services in China (PDF).

IAM tutorial: Use SAML session tags for ABAC

Attribute-based access control (ABAC) is an authorization strategy that defines permissions based on attributes. In Amazon, these attributes are called tags. You can attach tags to IAM resources, including IAM entities (users or roles), and to Amazon resources. When the entities are used to make requests to Amazon, they become principals and those principals include tags.

You can also pass session tags when you assume a role or federate a user. You can then define policies that use tag condition keys to grant permissions to your principals based on their tags. When you use tags to control access to your Amazon resources, you allow your teams and resources to grow with fewer changes to Amazon policies. ABAC policies are more flexible than traditional Amazon policies, which require you to list each individual resource. For more information about ABAC and its advantage over traditional policies, see What is ABAC for Amazon?.

If your company uses a SAML-based identity provider (IdP) to manage corporate user identities, you can use SAML attributes for fine-grained access control in Amazon. Attributes can include cost center identifiers, user email addresses, department classifications, and project assignments. When you pass these attributes as session tags, you can then control access to Amazon based on these session tags.

To complete the ABAC tutorial by passing SAML attributes to your session principal, complete the tasks in IAM tutorial: Define permissions to access Amazon resources based on tags, with the changes that are included in this topic.

Prerequisites

To perform the steps to use SAML session tags for ABAC, you must already have the following:

  • Access to a SAML-based IdP where you can create test users with specific attributes.

  • The ability to sign in as a user with administrative permissions.

  • Experience creating and editing IAM users, roles, and policies in the Amazon Web Services Management Console. However, if you need help remembering an IAM management process, the ABAC tutorial provides links where you can view step-by-step instructions.

  • Experience setting up a SAML-based IdP in IAM. To view more details and links to detailed IAM documentation, see Passing session tags using AssumeRoleWithSAML.

Step 1: Create test users

Skip the instructions in Step 1: Create test users. Because your identities are defined in your provider, it's not necessary for you to add IAM users for your employees.

Step 2: Create the ABAC policy

Follow the instructions in Step 2: Create the ABAC policy to create the specified managed policy in IAM.

Step 3: Create and configure the SAML role

When you use the ABAC tutorial for SAML, you must perform additional steps to create the role, configure the SAML IdP, and enable Amazon Web Services Management Console access. For more information, see Step 3: Create roles.

Step 3A: Create the SAML role

Create a single role that trusts your SAML identity provider and the test-session-tags user that you created in step 1. The ABAC tutorial uses separate roles with different role tags. Because you are passing session tags from your SAML IdP, you need only one role. To learn how to create a SAML-based role, see Create a role for SAML 2.0 federation (console).

Name the role access-session-tags. Attach the access-same-project-team permissions policy to the role. Edit the role trust policy to use the following policy. For detailed instructions on how to edit the trust relationship of a role, see Modifying a role (console).

The following role trust policy allows your SAML identity provider and the test-session-tags user to assume the role. When they assume the role, they must pass the three specified session tags. The sts:TagSession action is required to allow passing session tags.

{ "Version": "2012-10-17", "Statement": [ { "Sid": "AllowSamlIdentityAssumeRole", "Effect": "Allow", "Action": [ "sts:AssumeRoleWithSAML", "sts:TagSession" ], "Principal": {"Federated":"arn:aws-cn:iam::123456789012:saml-provider/ExampleCorpProvider"}, "Condition": { "StringLike": { "aws:RequestTag/cost-center": "*", "aws:RequestTag/access-project": "*", "aws:RequestTag/access-team": [ "eng", "qas" ] }, "StringEquals": {"SAML:aud": "https://signin.aws.amazon.com/saml"} } } ] }

The AllowSamlIdentityAssumeRole statement allows members of the Engineering and Quality Assurance teams to assume this role when they federate into Amazon from the Example Corporation IdP. The ExampleCorpProvider SAML provider is defined in IAM. The administrator has already set up the SAML assertion to pass the three required session tags. The assertion can pass additional tags, but these three must be present. The identity's attributes can have any value for the cost-center and access-project tags. However, the access-team attribute value must match eng or qas to indicate that the identity is on the Engineering or Quality Assurance team.

Step 3B: Configure the SAML IdP

Configure your SAML IdP to pass the cost-center, access-project, and access-team attributes as session tags. For more information, see Passing session tags using AssumeRoleWithSAML.

To pass these attributes as session tags, include the following elements in your SAML assertion.

<Attribute Name="http://www.amazonaws.cn/SAML/Attributes/PrincipalTag:cost-center"> <AttributeValue>987654</AttributeValue> </Attribute> <Attribute Name="http://www.amazonaws.cn/SAML/Attributes/PrincipalTag:access-project"> <AttributeValue>peg</AttributeValue> </Attribute> <Attribute Name="http://www.amazonaws.cn/SAML/Attributes/PrincipalTag:access-team"> <AttributeValue>eng</AttributeValue> </Attribute>

Step 3C: Enable console access

Enable console access for your federated SAML users. For more information, see Enabling SAML 2.0 federated users to access the Amazon Web Services Management Console.

Step 4: Test creating secrets

Federate into the Amazon Web Services Management Console using the access-session-tags role. For more information, see Enabling SAML 2.0 federated users to access the Amazon Web Services Management Console. Then follow the instructions in Step 4: Test creating secrets to create secrets. Use different SAML identities with attributes to match the tags that are indicated in the ABAC tutorial. For more information, see Step 4: Test creating secrets.

Step 5: Test viewing secrets

Follow the instructions in Step 5: Test viewing secrets to view the secrets that you created in the previous step. Use different SAML identities with attributes to match the tags that are indicated in the ABAC tutorial.

Step 6: Test scalability

Follow the instructions in Step 6: Test scalability to test scalability. Do this by adding a new identity in your SAML-based IdP with the following attributes:

  • cost-center = 101010

  • access-project = cen

  • access-team = eng

Step 7: Test updating and deleting secrets

Follow the instructions in Step 7: Test updating and deleting secrets to update and delete secrets. Use different SAML identities with attributes to match the tags that are indicated in the ABAC tutorial.

Important

Delete all of the secrets that you created to avoid billing charges. For details about pricing in Secrets Manager, see Amazon Secrets Manager Pricing.

Summary

You've now successfully completed all of the steps necessary to use SAML session tags and resource tags for permissions management.

Note

You added policies that allow actions only under specific conditions. If you apply a different policy to your users or roles that has broader permissions, then the actions might not be limited to require tagging. For example, if you give a user full administrative permissions using the AdministratorAccess Amazon managed policy, then these policies don't restrict that access. For more information about how permissions are determined when multiple policies are involved, see Determining whether a request is allowed or denied within an account.