AWS ABAC: Explained

Attribute-Based Access Control (ABAC) is an authorization policy that lets you create fine-grained permissions based on user attributes such as department, title, and team name. User attributes make permissions more intuitive and simplify the admin experience. Let’s learn more about AWS ABAC and how it’s become an important part SaaS ingredient.

What Is AWS ABAC?

Amazon Web Services (AWS) fully supports ABAC. You can use attributes to specify permissions, reducing the number of individual permissions required to control access, and letting you scale authorization much more easily.

For example, instead of creating an AWS Identity and Access Management (IAM) role with a separate policy for each team or individual, you can use ABAC to specify a group of attributes indicating which resources users should be able to access. When you add new users and resources, these properties will ensure that the right users have access to the right resources. There’s no longer a need to update existing policies to explicitly grant access to new users.

AWS ABAC Benefits

Using ABAC with AWS provides the following benefits:

• Fewer permission sets—with ABAC, you can create fewer permission sets because you don’t need to create different policies for each action. This reduces the complexity of permission management.
• Easily support changing teams—permissions to new resources are automatically granted based on properties, if the resource is marked appropriately at creation time.
• Leverage employee attributes from the corporate directory—ABAC lets you use existing employee attributes from any identity source configured in AWS Single Sign On (SSO) to make access control decisions in AWS.
• Monitor access to resources—security admins can identify sessions by viewing AWS CloudTrail user attributes and tracking AWS user activity.

AWS ABAC Use Cases

Here are three primary use cases for ABAC in AWS:

• Granting developers read and write access to their project resources—when permissions are based on user properties, developers can automatically get read and write access to resources that belong to their individual projects. Access is granted if these properties match those of the project resource. Otherwise, it is rejected.
• Ensure unique permissions when accessing shared resources—ABAC helps ensure different permissions for different individuals accessing the same resource. You create a minimum number of IAM roles in your AWS account, and control a user’s level of access based on user attributes.
• Validating AWS resources have the correct tags—AWS resource tags are used to organize and discover resources and assign costs. Development teams must ensure they correctly tag all resources when they are created. ABAC can be used to ensure that all new resources have the required set of tags when they are created.

AWS ABAC vs AWS RBAC

Role-based access control (RBAC) is the standard authorization approach in IAM. RBAC defines access permissions based on a user’s job function or “role” (usually referred to as an IAM role in AWS). IAM includes managed policies that assign permissions to specific roles.

RBAC in IAM involves creating separate policies for each job function and attaching them to identities (i.e., IAM users, user groups). It is best to grant the minimum required permissions for each role (least privilege) and list the resources that a role should access. 

The drawback of the traditional RBAC model is that it requires policy updates when users add resources. Otherwise, the users cannot access the new resources. It also requires assigning new roles to employees when they change jobs (individuals can have multiple roles). 

Attribute-based access control (ABAC) offers several advantages over traditional RBAC, including:

• Scalable permissions—administrators don’t have to update policies to grant access to new resources manually. 
• Fewer policies—ABAC works with fewer policies because you don’t have to create a separate policy for each job function. Policies are thus easier to manage.
• Flexibility and team growth—ABAC automatically grants permissions for new resources based on attributes, allowing teams to grow more easily. Administrators can easily create new projects and apply existing roles to them. Users can use their permissions to access a new resource or project. If employees move to different teams, an IAM administrator can assign the user to a new IAM role without changing the permission policies.
• Granularity—ABAC supports granular permissions based on the principle of least privilege. For example, a policy can allow actions on all resources provided the resource and principal (user) tags match. 
• Leveraging existing employee attributes—organizations can use their corporate directories to configure an identity provider to pass session tags to AWS. After federating employees into AWS, it applies their attributes to the relevant AWS principals/users.

Related: RBAC vs ABAC

AWS Attributes for Access Control

The administrator can use the “Attributes for access control” part of the AWS SSO console to specify user attributes applied in various access control policies. The administrator can use existing attributes from a user’s identity source to assign that user to a workload. 

There are many ways to configure attributes for access control depending on the identity source used. Creating or modifying policies is necessary after selecting user attributes, regardless of the identity source. These attribute-based policies need to enable users to access AWS resources based on identity. Here are some guidelines for choosing attributes:

Using AWS SSO—if you choose AWS SSO as your ABAC identity source, you must first add users and set up their attributes. Go to the “Attributes for access control” page and choose the policies’ attributes. Return to the “AWS accounts” page to create or modify the permissions (or permission sets) to incorporate the attributes into your ABAC policies.

Using AWS Managed Microsoft AD—if you configure AWS Managed Microsoft AD as an identity source in AWS SSO, you must choose the attributes in Active Directory. You can then map these to the user attributes in AWS SSO. Then go to “Attributes for access control” and select the attributes for your policy in the ABAC configuration. Choose attributes based on your existing SSO attributes in Active Directory. Use these access control attributes in your permissions sets to create ABAC rules granting user identity-based access to your AWS resources.

Using an external IdP—there are two ways to apply attributes for ABAC policies if you use an external identity provider as an identity source: 

• Configure the external IdP to transfer the attributes via SAML assertions. AWS SSO will pass the name and value of each attribute received from the IdP to evaluate the policy.
• Configure the attributes used via the “Attributes for access control” page of the AWS SSO console. You choose attribute values that replace all matching attributes from the IdP (via an assertion). If you use SCIM, the IdP will automatically sync the attribute values to AWS SSO. If you don’t use SCIM, you need to define each user and configure the attributes manually (as you would when using AWS SSO as an identity source).

ABAC Authentication with Frontegg

User management has become an important component of the modern SaaS application for the simple reason that customers now have different needs and requirements – from basic RBAC scenarios all the way to complex B2B use cases. Frontegg’s self-served and end-to-end platform helps implement dynamic authentication and authorization flows, all with minimal effort. 

This is helping businesses focus on their core technology and scale-up faster, all in a secure way, making Frontegg a true gamechanger in the SaaS space.

Start For Free