# Attribute-based access control Attribute-based access control (ABAC) is an authorization strategy that defines permissions based on attributes. You can use IAM Identity Center to manage access to your AWS resources across multiple AWS accounts using user attributes that come from any IAM Identity Center identity source. In AWS, these attributes are called tags. Using user attributes as tags in AWS helps you simplify the process of creating fine-grained permissions in AWS and ensures that your workforce gets access only to the AWS resources with matching tags. For example, you can assign developers Bob and Sally, who are from two different teams, to the same permission set in IAM Identity Center and then select the team name attribute for access control. When Bob and Sally sign in to their AWS accounts, IAM Identity Center sends their team name attribute in the AWS session so Bob and Sally can access AWS project resources only if their team name attribute matches the team name tag on the project resource. If Bob moves to Sally’s team in the future, you can modify his access by simply updating his team name attribute in the corporate directory. When Bob signs in next time, he will automatically get access to the project resources of his new team without requiring any permissions updates in AWS. This approach also helps in reducing the number of distinct permissions you need to create and manage in IAM Identity Center as users associated with the same permission sets can now have unique permissions based on their attributes. You can use these user attributes in IAM Identity Center permission sets and resource-based policies to implement ABAC to AWS resources and simplify permissions management at scale. ## Benefits The following are additional benefits of using ABAC in IAM Identity Center. + **ABAC requires fewer permission sets **– Because you do not have to create different policies for different job functions, you create fewer permission sets. This reduces your permissions management complexity. + **Using ABAC, teams can change and grow quickly **– Permissions for new resources are automatically granted based on attributes when resources are appropriately tagged upon creation. + **Use employee attributes from your corporate directory with ABAC **– You can use existing employee attributes from any identity source configured in IAM Identity Center to make access control decisions in AWS. + **Track who is accessing resources **– Security administrators can easily determine the identity of a session by reviewing the user attributes in AWS CloudTrail to track user activity in AWS. For information about how to configure ABAC using the IAM Identity Center console, see [Attributes for access control](attributesforaccesscontrol.md). For information about how to enable and configure ABAC using the IAM Identity Center APIs, see [CreateInstanceAccessControlAttributeConfiguration](https://docs.aws.amazon.com/singlesignon/latest/APIReference/API_CreateInstanceAccessControlAttributeConfiguration.html) in the *IAM Identity Center API Reference Guide*. **Topics** + [Benefits](#abac-benefits) + [Checklist: Configuring ABAC in AWS using IAM Identity Center](abac-checklist.md) + [Attributes for access control](attributesforaccesscontrol.md) # Checklist: Configuring ABAC in AWS using IAM Identity Center This checklist includes the configuration tasks that are necessary to prepare your AWS resources and to set up IAM Identity Center for ABAC access. Complete the tasks in this checklist in order. When a reference link takes you to a topic, return back to this topic so that you can proceed with the remaining tasks in this checklist. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/abac-checklist.html) After you complete these steps, users who federate into an AWS account using single sign-on will get access to their AWS resources based on matching attributes. # Attributes for access control **Attributes for access control** is the name of the page in the IAM Identity Center console where you select user attributes that you want to use in policies to control access to resources. You can assign users to workloads in AWS based on existing attributes in the users' identity source. For example, suppose you want to assign access to S3 buckets based on department names. While on the **Attributes for access control** page, you select the **Department** user attribute for use with attribute-based access control (ABAC). In the IAM Identity Center permission set, you then write a policy that grants users access only when the **Department** attribute matches the department tag that you assigned to your S3 buckets. IAM Identity Center passes the user's department attribute to the account being accessed. The attribute is then used to determine access based on the policy. When IAM Identity Center passes these attributes to the account, they are sent as session tags that you can reference using the `aws:PrincipalTag/tag-key` condition key in all relevant AWS IAM policy types. For more information about ABAC, see [Attribute-based access control](abac.md). ## Getting started How you get started configuring attributes for access control depends on which identity source you are using. Regardless of the identity source you choose, after you have selected your attributes you need to create or edit permission set policies. These policies must grant user identities access to AWS resources. ### Choosing attributes when using IAM Identity Center as your identity source When you configure IAM Identity Center as the identity source, you first add users and configure their attributes. Next, navigate to the **Attributes for access control** page and select the attributes you want to use in policies. Finally, navigate to the **AWS accounts** page to create or edit permission sets to use the attributes for ABAC. ### Choosing attributes when using AWS Managed Microsoft AD as your identity source When you configure IAM Identity Center with AWS Managed Microsoft AD as your identity source, you first map a set of attributes from Active Directory to user attributes in IAM Identity Center. Next, navigate to the **Attributes for access control** page. Then choose which attributes to use in your ABAC configuration based on the existing set of SSO attributes mapped from Active Directory. Finally, author ABAC rules using the access control attributes in permission sets to grant user identities access to AWS resources. For a list of the default mappings for user attributes in IAM Identity Center to the user attributes in your AWS Managed Microsoft AD directory, see [Default mappings between IAM Identity Center and Microsoft AD](attributemappingsconcept.md#defaultattributemappings). ### Choosing attributes when using an external identity provider as your identity source When you configure IAM Identity Center with an external identity provider (IdP) as your identity source, there are two ways to use attributes for ABAC. + **Configure attribute mappings in the IAM Identity Center console.** You can map attributes from the IAM Identity Center directory to session tags on the **Attributes for access control** page in the IAM Identity Center console. The attribute values that you choose here are sourced from the Identity Center directory and replace the values for any matching attributes that come from an IdP through a SAML assertion. Depending on whether you are using SCIM, consider the following: + If using SCIM, the IdP automatically synchronizes the attribute values into IAM Identity Center. You can then select these synchronized attributes on the **Attributes for access control** page to use them as session tags. + If you are not using SCIM, you must manually add the users and set their attributes just as if you were using IAM Identity Center as an identity source. Next, navigate to the **Attributes for access control** page and choose the attributes you want to use in policies. + **Pass attributes from your IdP through SAML assertions.** You can configure your IdP to send attributes as session tags through SAML assertions. To do this, configure your IdP to send SAML assertions with the attribute name set to `https://aws.amazon.com/SAML/Attributes/AccessControl:TagKey`, replacing *TagKey* with the session tag key you want to populate. IAM Identity Center passes the attribute name and value from the IdP through for policy evaluation. It is not necessary to configure an ABAC attribute mapping on the **Attributes for access control** page for attributes that you pass in through SAML assertions from your external IdP. However, if you configure an ABAC mapping for the same attribute on the **Attributes for access control** page, the mapping from the Identity Center directory takes precedence and replaces the value sent by your IdP in the SAML assertion. **Note** Attributes in SAML assertions will not be visible to you on the **Attributes for access control** page. You will have to know these attributes in advance and add them to access control rules when you author policies. If you decide to trust your external IdPs for attributes, then these attributes will always be passed when users federate into AWS accounts. For information about how to configure user attributes for access control in your IdP to send through SAML assertions, see the [IAM Identity Center identity source tutorials](tutorials.md) for your IdP. For a complete list of supported attributes for user attributes in IAM Identity Center to the user attributes in your external IdPs, see [Supported external identity provider attributes](attributemappingsconcept.md#supportedidpattributes). To get started with ABAC in IAM Identity Center, see the following topics. **Topics** + [Getting started](#abac-getting-started) + [Enable and configure attributes for access control](configure-abac.md) + [Create permission policies for ABAC in IAM Identity Center](configure-abac-policies.md) # Enable and configure attributes for access control To use attribute-based access control (ABAC), you must first enable it in either the **Settings** page of the IAM Identity Center console or the [IAM Identity Center API](https://docs.aws.amazon.com//singlesignon/latest/APIReference/API_CreateInstanceAccessControlAttributeConfiguration.html). Regardless of the identity source, you can always configure user attributes from the Identity Store for use in ABAC. In the console, you can do this by navigating to the **Attributes for access control** tab on the **Settings** page. If you use an external identity provider (IdP) as the identity source, you also have the option of receiving attributes from the external IdP in SAML assertions. In this case, you need to configure the external IdP to send the desired attributes. If an attribute from a SAML assertion is also defined as an ABAC attribute in IAM Identity Center, IAM Identity Center will send the value from its Identity Store as a [session tag](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_session-tags.html) on sign-in to an AWS account. **Note** You cannot view attributes configured and sent by an external IdP from the **Attributes for access control** page in the IAM Identity Center console. If you are passing access control attributes in the SAML assertions from your external IdP, then those attributes are directly sent to the AWS account when users federate in. The attributes won’t be available in IAM Identity Center for mapping. **Topics** + [Enable attributes for access control](enable-abac.md) + [Select your attributes for access control](configure-abac-attributes.md) + [Disable attributes for access control](disable-abac.md) # Enable attributes for access control Use the following procedure to enable the attributes for access (ABAC) control feature using the IAM Identity Center console. **Note** If you have existing permission sets and you plan to enable ABAC in your IAM Identity Center instance, additional security restrictions require you to first have the `iam:UpdateAssumeRolePolicy` policy. These additional security restrictions are not required if you do not have any permission sets created in your account. If your IAM Identity Center instance was created before December 2020 and you plan to enable ABAC in it, you must have the `iam:UpdateAssumeRolePolicy` policy associated with the IAM Identity Center administrative role, regardless of whether you have permission sets created in your account. **To enable Attributes for access control** 1. Open the [IAM Identity Center console](https://console.aws.amazon.com/singlesignon). 1. Choose **Settings** 1. On the **Settings** page, locate the **Attributes for access control** information box, and then choose **Enable**. Continue to the next procedure to configure it. # Select your attributes for access control Use the following procedure to set up attributes for your ABAC configuration. **Note** This procedure applies only when you want to map attributes from your IAM Identity Center directory for use as session tags. If you are passing attributes from an external identity provider (IdP) through SAML assertions, you do not need to configure attribute mappings here. For more information, see [Choosing attributes when using an external identity provider as your identity source](attributesforaccesscontrol.md#abac-getting-started-idp). Values set in the mapping from the Identity Center directory overwrite values set in SAML assertions. **To select your attributes using the IAM Identity Center console** 1. Open the [IAM Identity Center console](https://console.aws.amazon.com/singlesignon). 1. Choose **Settings** 1. On the **Settings** page, choose the **Attributes for access control** tab, and then choose **Manage attributes**. 1. On the **Attributes for access control** page, choose **Add attribute** and enter the **Key** and **Value** details. This is where you will be mapping the attribute coming from your identity source to an attribute that IAM Identity Center passes as a session tag. ![\[Key value details in the IAM Identity Center console.\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/abac_key_value.png) **Key** represents the name you are giving to the attribute for use in policies. This can be any arbitrary name, but you need to specify that exact name in the policies you author for access control. For example, lets say that you are using Okta (an external IdP) as your identity source and need to pass your organization's cost center data along as session tags. In **Key**, you would enter a similarly matched name like **CostCenter** as your key name. It's important to note that whichever name you choose here, it must also be named exactly the same in your `aws:PrincipalTag condition key` (that is, `"ec2:ResourceTag/CostCenter": "${aws:PrincipalTag/CostCenter}"`). **Note** Use a single-value attribute for your key, for example, **Manager**. IAM Identity Center doesn't support multi-value attributes for ABAC, for example, **Manager, IT Systems**. **Value** represents the content of the attribute coming from your configured identity source. Here you can enter any value from the appropriate identity source table listed in [Attribute mappings between IAM Identity Center and External Identity Providers directory](attributemappingsconcept.md). For example, using the context provided in the above mentioned example, you would review the list of supported IdP attributes and determine that the closest match of a supported attribute would be **`${path:enterprise.costCenter}`** and you would then enter it in the **Value** field. See the screenshot provided above for reference. Note, that you can’t use external IdP attribute values outside of this list for ABAC unless you use the option of passing attributes through the SAML assertion. 1. Choose **Save changes**. Now that you have configured mapping your access control attributes, you need to complete the ABAC configuration process. To do this, create your ABAC rules and add them to your permission sets and/or resource-based policies. This is required so that you can grant user identities access to AWS resources. For more information, see [Create permission policies for ABAC in IAM Identity Center](configure-abac-policies.md). # Disable attributes for access control Use the following procedure to disable the ABAC feature and delete all of the attribute mappings that have been configured. **To disable Attributes for access control** 1. Open the [IAM Identity Center console](https://console.aws.amazon.com/singlesignon). 1. Choose **Settings**. 1. On the **Settings** page, choose the **Attributes for access control** tab, and then choose **Manage attributes**. 1. On the **Manage attributes for access control** page, choose **Disable**. 1. In the **Disable attributes for access control** dialog window, review the information and when ready enter **DISABLE**, and then choose **Confirm**. **Important** This step deletes all attributes and stops the use of attributes for access control when federating into AWS accounts regardless of whether any attributes are present in SAML assertions from an external identity source provider. # Create permission policies for ABAC in IAM Identity Center You can create permissions policies that determine who can access your AWS resources based on the configured attribute value. When you enable ABAC and specify attributes, IAM Identity Center passes the attribute value of the authenticated user into IAM for use in policy evaluation. ## aws:PrincipalTag condition key You can use access control attributes in your permission sets using the `aws:PrincipalTag` condition key for creating access control rules. For example, in the following policy you can tag all the resources in your organization with their respective cost centers. You can also use a single permission set that grants developers access to their cost center resources. Now, whenever developers federate into the account using single sign-on and their cost center attribute, they only get access to the resources in their respective cost centers. As the team adds more developers and resources to their project, you only have to tag resources with the correct cost center. Then you pass cost center information in the AWS session when developers federate into AWS accounts. As a result, as the organization adds new resources and developers to the cost center, developers can manage resources aligned to their cost centers without needing any permission updates. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ec2:DescribeInstances" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "ec2:StartInstances", "ec2:StopInstances" ], "Resource": "*", "Condition": { "StringEquals": { "ec2:ResourceTag/CostCenter": "${aws:PrincipalTag/CostCenter}" } } } ] } ``` ------ When users federate into an AWS account through IAM Identity Center, the configured access control attributes are passed as session tags. You can reference these session tags in your policies using the `aws:PrincipalTag/tag-key` condition key. This condition key is supported in all relevant AWS IAM policy types where you can use conditions, including identity-based policies, resource-based policies, permissions boundaries, service control policies (SCPs), and VPC endpoint policies. This enables you to make fine-grained access control decisions based on user attributes across your entire AWS environment. For more information, see [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-principaltag](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-principaltag) and [EC2: Start or stop instances based on matching principal and resource tags](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_ec2-start-stop-match-tags.html) in the *IAM User Guide*. If policies contain invalid attributes in their conditions, then the policy condition will fail and access will be denied. For more information, see [Error 'An unexpected error has occurred' when a user tries to sign in using an external identity provider](troubleshooting.md#issue8).