Attribute based access control (ABAC) is a more granular, fine grained form of authorization and access control. ABAC allows for the definition of access policies based on arbitrary user, subject, environment and object attributes.
The simplest ABAC policies are boolean in nature (ex. user either has an attribute or not) with more complex policies making use of multiple system and environment attributes like geo/location and time as well as more complex logic like regex matching to create more sophisticated policies.
One example of an ABAC policy is "all users with a @warrant.dev email address can access report:x". This policy is based on a user's 'email' attribute and relies on regex matching to evaluate. It's a relatively simply but powerful policy with many real-world applications.
ABAC is a very flexible form of access control that can be used in a variety of contexts. So if it's possible to use ABAC, it's recommended to use it over other, more coarse-grained forms of access control like role based access control (RBAC). However, the challenge with ABAC is that it's more challenging to set up initially and so most software products opt to start with RBAC.
Building an authz system that supports ABAC comes with its own set of challenges. It's a good idea to understand the benefits that ABAC might provide for your system prior to undertaking the complexity of building such a system. Here are a few challenges to keep in mind:
ABAC systems, especially the components related to policy resolution, are complicated to implement. They have to take user/subject, environment and object attributes into account as well as be able to resolve the complicated, nested policies that might exist between these entities in a performant fashion. While there are open source libraries to help implement parts of these systems, you might have to build custom logic and components that fit your specific use cases.
As is the case with other fine grained authorization models like ReBAC, one of the challenges with ABAC is keeping policies in sync with changes to the underlying data. For example, let's say that we have policies based on 3 user attributes: email, username, tenant. If any of these attributes change (ex. user moves tenants or is granted access to another tenant), the related ABAC policies will also need to be created, updated or deleted. In other words, a small change in the data model can lead to multiple, cascading changes to your ABAC policies. As a result, ABAC systems often need to handle synchronization, including how to deal with failures and retries, all of which further increase complexity.
One powerful aspect of ABAC systems is the ability to reference environment attributes in policies. For example, let's say that we want to define a time-based policy that specifies that "user:A can only access report:x between the hours of 9a and 5p". Implementing such a policy requires our ABAC system to understand and keep time such that it can be checked at runtime during a user query. Similarly, we might want to define policies based on user location or IP which will require our ABAC system to resolve location. Neither of these is particularly easy to implement and represents custom logic that we'll need to build into the system.
As mentioned above, implementing an ABAC system from scratch is not trivial. There are multiple parts of the system to consider including the resolution engine, policy synchronization as well as how to manage and check environment attributes (time, geo/location etc). Each of these components can take time to implement. There are open source libraries available that can help but the onus is typically on the user to choose the library that matches their desired functionality and existing system.
For those looking for a fully managed and hosted service, using a 3rd party service or vendor might be a better option. Warrant is one such service that offers ABAC-like policy support as part of its core, distributed authz offering.