Use custom attributes for Attribute-Based Access Control (ABAC) with Microsoft Entra ID and AWS IAM Identity Center

In this blog post, you will learn how to use custom attributes for Attribute-Based Access Control (ABAC) with Microsoft Entra ID (formerly known as Azure Active Directory) as the single sign-on (SSO) identity provider integrated with AWS IAM Identity Center (formerly known as AWS SSO).

ABAC allows you to control access or fine-grained permissions to Amazon Web Services (AWS) resources based on attribute values that you pass from your identity provider—e.g., Microsoft Entra ID in your Security Assertion Markup Language (SAML) 2.0 assertion. While AWS IAM Identity Center supports a set of pre-defined attributes by default, organizations occasionally define custom attributes, like birth date, tenure, and project phase. For example, HR may want certain documents stored in Amazon Simple Storage Service (Amazon S3) to be accessible only to those employees who have had a certain tenure in the company. Administrators need a way to use these custom attributes for access control.

This blog post will explain how to pass custom attributes in SAML assertions and use them to provide access control on AWS. It is meant to help administrators, security professionals, IAM team members, cloud security personnel—basically anyone who needs to control access from external identity providers using custom attributes. Though this blog post focuses on Microsoft Entra ID as the identity provider, the method shown here can be used with any identity provider that supports SAML 2.0.

Solution overview

In our solution, you will use Microsoft Entra ID as the identity provider for SSO integration with AWS IAM Identity Center. We will walk you through two examples.

Example 1

Your organization has several developers using the same AWS account, but they’re working on different projects. You want to allow developers to access and manage AWS resources—like Amazon Elastic Compute Cloud (Amazon EC2) and/or Amazon Relational Database Service (Amazon RDS) in a given project—but only if they are assigned to that project.

In this example, you will use ABAC with a custom attribute named Project to indicate the project they are assigned to—e.g., ProjectA. You will see how user A.Simon assigned to Project A can start/stop Amazon EC2 instances belonging to Project A. You will mark a resource as belonging to Project A by tagging it with the tag Project and value ProjectA (no space).

Example 2

You have a user B.Simon who is transitioning out of Project A and is in the handover phase. You want to prohibit B.Simon from starting/stopping the Amazon EC2 instances belonging to Project A.

For this example, you will use a custom attribute named HandoverPhase in the SAML assertion of user B.Simon and assign it a value of ProjectA. If the value of the custom attribute HandoverPhase—in this case, ProjectA—matches the value of the tag Project for the resource—in this case, the Amazon EC2 instance—it will not allow the user to start/stop the Amazon EC2 instance belonging to Project A.

SAML attributes assigned to users are passed as session tags when a user assumes a role or federates into AWS. These tags can be used in IAM policies as condition keys to grant permissions to the users.
For the purpose of this blog post, you will create a custom permission set with an inline policy that allows starting/stopping Amazon EC2 instances only if the following conditions are met:

If the value of the custom attribute Project matches the value of the tag Project on the Amazon EC2 instances; and

If the value of the custom attribute HandoverPhase DOES NOT match the value of the tag Project.

"Condition": {
                "StringEquals": {
                    "ec2:ResourceTag/Project": "${aws:PrincipalTag/Project}"
                },
                "StringNotEquals": {
                    "ec2:ResourceTag/Project": "${aws:PrincipalTag/HandoverPhase}"
                }
            }

Prerequisites

A Microsoft Entra ID tenant configured with AWS IAM Identity Center as the Enterprise Application.
An AWS account with AWS IAM Identity Center configured and integrated with Microsoft Entra ID as the external identity provider with SCIM provisioning.
An Amazon EC2 instance that has (at least) the following tag – Project:ProjectA.
Enterprise Application “AWS IAM Identity Center (Successor to AWS Single Sign-On) is configured in Microsoft Entra ID for Single Sign-On (SSO) with automatic user provisioning.

Walkthrough

You will create two users A.Simon and B.Simon as developers on ProjectA. Both users will be a part of Developers_ProjectA group that has permissions to start/stop Amazon EC2 instances. User B.Simon is transitioning out of ProjectA and is in handover phase. Hence, user B.Simon will also be added to group HandoverPhase that will be denied permission to start/stop EC2 instances belonging to ProjectA.

Create a group Developers_ProjectA in Microsoft Entra ID for developers of Project A. All developers that need access to ProjectA resources will be added to this group. In this example, we have added A.Simon and B.Simon, as shown in Figure 1.

Figure 1: Microsoft Entra ID group Developers_ProjectA members
Create a group HandoverPhase for users that are in handover phase of ProjectA or transitioning out of the project. In our example, we have added B.Simon to this group, as shown in Figure 2.

Figure 2: Microsoft Entra ID group HandoverPhase members
Assign both groups to the AWS Identity Center (Successor to Single Sign-On) enterprise application in Microsoft Entra ID. This will allow users in this group the ability to single sign-on in AWS using their Microsoft Entra ID credentials. See Figure 3.

Figure 3: Assign groups to AWS IAM Identity Center Enterprise Application in Microsoft Entra ID
Next, configure the custom attributes to be sent over as a part of the SAML assertion through SAML Attributes and Claims in Single Sign-on feature of the enterprise application. For this example, you will use Microsoft Entra ID groups as condition to pass custom attribute named Project with value ProjectA in SAML assertions if the user belongs to the group Developers_ProjectA—as shown in Figures 4 and 5.

Figure 4: Create a claim in Microsoft Entra ID to pass custom attribute “Project”

Figure 5: Create condition to pass Project attribute with value
For users belonging to the group HandoverPhase, you will use the same condition to pass custom attribute named HandoverPhase with value ProjectA. See Figures 6 and 7.

Figure 6: Create claim in Microsoft Entra ID to pass custom attribute “HandoverPhase”

Figure 7: Create condition to pass HandoverPhase attribute with value

You will now create a permission set in AWS IAM Identity Center with IAM Policy that uses IAM Policy Conditions to evaluate access based on session tags in the request. You will check the value of the attributes using the tag aws:PrincipalTag/<Custom Attribute> and compare it with ec2:ResourceTag/<Resource TagName>.Create a permission set Developers-EC2-Access with an inline policy to restrict access based on SAML attributes. Go to IAM Identity Center > Permissions Sets > Create Permission Set > Custom Permission Set. On the next page, choose Inline policy and paste the below policy and click Next. Provide the name Developers-EC2-Access, click Next, and then click Create.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:Describe",
                "ec2:List"
            ],
            "Resource": ""
        },
        {
            "Effect": "Allow",
            "Action": [
                "ec2:StartInstances",
                "ec2:StopInstances"
            ],
            "Resource": [
                ""
            ],
            "Condition": {
                "StringEquals": {
                    "ec2:ResourceTag/Project": "${aws:PrincipalTag/Project}"
                },
                "StringNotEquals": {
                    "ec2:ResourceTag/Project": "${aws:PrincipalTag/HandoverPhase}"
                }
            }
        }
    ]
}

Next, you will assign our Developers_ProjectA group with the newly created permission set Developers-EC2-Access to our target account named Workloads in the Sandbox OU. You do this by visiting IAM Identity Center > AWS Accounts > Sandbox > Workloads > Assign users or groups. On the next page, choose the group, then choose the permissions set you just created, and click Submit. The users in group are now assigned to the target account with the appropriate permission set. See Figure 8.

Figure 8: Assign group and permission set to Workloads account in AWS IAM Identity Center
Next, sign in as A.Simon into your AWS account using Access Portal with your Microsoft Entra ID credentials. On the AWS Access Portal, click the Workloads account, and select the Developers-EC2-Access role to log into the AWS Management Console.
(Optional) The above action federates user into the AWS account and the event is logged into AWS CloudTrail as AssumeRoleWithSAML API. To confirm that our custom attributes are being passed as session tags in the SAML assertion, check the API Event log in the CloudTrail Event History console. Search for the Event AssumeRoleWithSAML by using the ‘Lookup Attribute’ EventName and value AssumeRoleWithSAML, as shown in Figure 9.

Figure 9: View AssumeRoleWithSAML event in AWS CloudTrail Event History

Click on the event to see the JSON log. Scroll down to requestParameters > principalTags to find our custom attribute Project with value ProjectA from the SAML assertion. See Figure 10.

Figure 10: AWS CloudTrail event for A.Simon federation to AWS with “Project” passed as a tag in request
In the Amazon EC2 console, go to the Amazon EC2 instance with a tag key Project and value ProjectA. Next, try starting and stopping the instance. User A.Simon is able to successfully start and stop this Amazon EC2 instance belonging to ProjectA, as the SAML assertion for the user contains the customer attribute Project with value ProjectA that matches the value of the resource tag Project on Amazon EC2 instance. See Figures 11 and 12.Successfully starting the instance:

Figure 11 Successful Amazon EC2 Instance start operation by user A.Simon having “Project” custom attribute from Microsoft Entra ID passed as tag in AWS

Successfully Stopping the instance:

Figure 12: Successful Amazon EC2 Instance stop operation by user A.Simon having “Project” custom attribute from Microsoft Entra ID passed as tag in AWS
Next, login as B.Simon and try starting/stopping the same Amazon EC2 instance. User B.Simon will receive an authorization failure error. This is expected because the SAML assertion for user B.Simon login also contains the HandoverPhase custom attribute with the value ProjectA, and the IAM policy has a condition that denies StartInstances/StopInstances action for any user that has HandoverPhase tag. See Figures 13 and 14.Error starting the instance:

Figure 13: Unauthorized/Denied Amazon EC2 Instance start operation by user B.Simon having “HandoverPhase” custom attribute from Microsoft Entra ID passed as tag in AWS

Error stopping the instance:

Figure 14: Unauthorized/Denied Amazon EC2 Instance stop operation by user B.Simon having “HandoverPhase” custom attribute from Microsoft Entra ID passed as tag in AWS
You can check the SAML assertion for user B.Simon using the steps mentioned above (for A.Simon). The event AssumeRoleWithSAML for B.Simon will contain an additional principalTag HandoverPhase with value ProjectA as obtained from the SAML assertion for B.Simon, as shown in Figure 15.

Figure 15: AWS CloudTrail event for B.Simon federation to AWS with “Project” and additionally, “HandoverPhase” passed as a tag in request

Cleanup

When you finish your tests or no longer need this solution in your environment, follow the steps below to remove the AWS resources so that you don’t continue to incur costs:

Terminate the Amazon EC2 instances created for the test by visiting the Amazon EC2 console, selecting your instances, clicking the Instance State button, and selecting Terminate Instance.
Remove the permission set assignment by visiting the IAM Identity Center console, then clicking AWS accounts from the menu on the left. Click the Workloads Account from the Organization structure and go to the Permission sets tab. Then select the permission set named Developers-EC2-Access and click the Remove button.

Once the permission set is unassigned, you can proceed to delete the permission set. Select Permission sets from the menu on the left, select your permission set Developers-EC2-Access, and click the Delete button.

Remove SAML claims from Single Sign-On tab in enterprise application in Microsoft Entra ID.
Remove group assignment from Enterprise Application in Microsoft Entra ID.
Remove the groups Developers_ProjectA and HandoverPhase from Microsoft Entra ID.
Remove the users A.Simon and B.Simon from Microsoft Entra ID.

Conclusion

In this blog post, you learned how to use custom attributes with IAM policies as a part of AWS IAM Identity Center permission sets. The custom attributes are sent over as session tags for the users, which can be leveraged in IAM Policy conditions to allow or restrict conditional access to AWS resources. You leveraged group assignments as a way to send custom attributes; however, you can use any method supported by Microsoft Entra ID to send custom attributes in SAML assertion as claims.

AWS has significantly more services, and more features within those services, than any other cloud provider, making it faster, easier, and more cost effective to move your existing applications to the cloud and build nearly anything you can imagine. Give your Microsoft applications the infrastructure they need to drive the business outcomes you want. Visit our .NET on AWS and AWS Database blogs for additional guidance and options for your Microsoft workloads. Contact us to start your migration and modernization journey today.

Microsoft Workloads on AWS