Just when we thought we had got our heads around Role Based Access Control (RBAC) along comes Attribute-Based Access Control (ABAC). Great. ABAC is a flexible and granular access control model that evaluates attributes—characteristics associated with users, resources, and the environment—when determining whether access should be granted. Unlike Role-Based Access Control (RBAC), which relies on predefined roles with fixed permissions, ABAC allows organisations to define access policies based on dynamic combinations of attributes.
In the Azure world, ABAC is supported through the use of custom Azure roles combined with resource and request context attributes. For example, you could define a custom role that allows access to storage blobs only when the user’s department attribute matches the resource’s “department” tag. A real-world policy might say: “Grant read access to blobs if user.department equals resource.department.” This allows a single role definition to be reused across departments without hardcoding resource-level access rules.
This model is particularly useful for large-scale environments where traditional RBAC roles become unmanageable due to the explosion of permutations. ABAC helps reduce role sprawl while still enforcing strict, attribute-driven access boundaries.
Don’t let me butcher it anymore however, there is a great article on introducing ABAC via Microsoft here:
Introducing Attribute Based Access Control (ABAC) in Azure.