ABAC with IAM Identity Center users (no external idP)

You're correct that the documentation primarily focuses on attribute mapping from external identity providers (IdPs) like Azure AD. However, it is possible to use Attribute-Based Access Control (ABAC) with IAM Identity Center users without an external IdP. Here's how you can approach this:

1. Using IAM Identity Center as the identity source: When using IAM Identity Center as your identity source, you can indeed use the built-in attributes like User Type and Department for ABAC. While user tagging is not directly supported, these built-in attributes can serve a similar purpose for access control.

To use these attributes:

• First, add users and configure their attributes in IAM Identity Center.
• Then, go to the "Attributes for access control" page in the IAM Identity Center console.
• Select the attributes you want to use for access control.
• Finally, create or edit permission sets to use these attributes for ABAC.

2. Permission Set tagging: Regarding tagging on Permission Sets, it is possible to add tags to Permission Sets. However, these tags are primarily used for resource organization and cost allocation, not for ABAC directly. The ABAC functionality in IAM Identity Center is focused on using user attributes to control access to AWS resources, rather than using tags on the Permission Sets themselves.

3. Implementing ABAC: To implement ABAC using IAM Identity Center attributes:

• Ensure your AWS resources are properly tagged to match the attributes you're using.
• Create custom permissions policies in the IAM Identity Center console that use these attributes.
• Assign users to these policies in AWS accounts based on their attributes.

While the documentation may not explicitly cover this scenario, the principles of ABAC still apply when using IAM Identity Center as your identity source. The key is to leverage the built-in attributes effectively in your permission policies.

It's worth noting that while this approach can work, using an external IdP or AWS Managed Microsoft AD often provides more flexibility in terms of attribute management and mapping. If you find the built-in attributes limiting, you might consider exploring these options in the future.

Remember to thoroughly test your ABAC implementation to ensure it's working as expected and providing the right level of access control for your users.

Sources
Attribute-based access control - AWS IAM Identity Center
Attributes for access control - AWS IAM Identity Center
Checklist: Configuring ABAC in AWS using IAM Identity Center - AWS IAM Identity Center
Manage identities in IAM Identity Center - AWS IAM Identity Center

Hi Allen, Thanks for sharing your experience. I had actually done almost exactly the same (but with attribute name UserType, should not matter as long as the policy follows) but failed to make it work the first time around. Your post made me revisit and then success.

I wonder if there are some delays that make the testing difficult or if I made a mistake in the IAM policy. Anyway, here is an exact known good setup (note that I named the attribute UserType instead of userType):

Example policy statement:

            {
              "Sid": "SampleAttributeConditionIdentityCenter",
              "Action": [
                "s3:ListBucket",
                "s3:GetBucketLocation",
                "s3:GetObject"
              ],
              "Resource": [
                "arn:aws:s3:::bucketname",
                "arn:aws:s3:::bucketname/*"
              ],
              "Effect": "Allow",
              "Condition": {
                "StringEquals": {
                  "aws:PrincipalTag/UserType": "Elevated"
                }
              }
            }

Next step is to combine with ec2:ResourceTag etc to achieve ABAC.

I hope the Identity Center documentation could actually document the attribute mapping values in the future.