Zero-trust architectures change the attack pattern from “network compromise” based attacks to “identity compromise” based attacks. It therefore becomes imperative to determine what any authenticated user can do once they are logged in. This is the area of access management or authorization. The goal of any technology in this space is to provide least-privilege access to users. This means users can seamlessly access what they need in order to do their jobs, and nothing more. Role-Based Access Control (RBAC) is a vastly popular technology in this space, and for the past decade, Attribute-Based Access Control (ABAC) is gaining increasing traction. Here are quick descriptions of RBAC and ABAC.
The goal of any authorization technology is to provide least-privilege access to users. This means users can seamlessly access what they need in order to do their jobs, and nothing more.
RBAC:
RBAC was the first step after an older technique known as ACLs (Access Control Lists) was found hard to scale and manage. In RBAC, each resource has a list of roles that are permitted access to it. In many real-world RBAC deployments, users are added to roles that contain “entitlements”, which are bundles of related permissions. Resources could mean anything from an internal “file share” to a specific functionality in a SaaS application. RBAC is by far, the most common way of implementing access control today.
ABAC:
One may think of “role” as being just one attribute (or characteristic) of a user, and as such the user may have more attributes, e.g. “office location”, “current projects”, and “clearances”. ABAC expands from matching the attribute named “role” (as in RBAC) to matching any attribute of the user to corresponding attributes associated with the target resource, as well as to the access context. For example, an ABAC policy may specify that the user whose “clearances” attribute includes “sensitive” can only access resources tagged with the attribute “sensitive” from their office location.
Attribute information can be contextual and more dynamic (e.g. access location is determined at the time of access, and project assignments may be more short term than a user’s role within an organization). As a result, ABAC offers a level of dynamism not offered by RBAC. ABAC policies also do not need to name specific resources (see the example policy in the previous paragraph), and hence they can (in theory) deliver fine-grained access control. For example, each file may have a different value for the “sensitive” attribute. Doing the same in RBAC will require one to define permitted roles on every file, making it intractably hard to manage.
ABAC policies do not need to name specific resources and hence they can (in theory) deliver fine-grained access control.
What’s Driving the Change?
Of late, there is widespread recognition, among customers, analysts and (some) vendors alike, that existing authorization models aren’t sufficient by themselves. Here are some reasons why:
Coarse Grained Access: Today’s access management products only enable access decisions at a coarse grained level. As a result, users are provisioned with access to entire collections of unrelated data when they need access to only a small portion of it. For example, a customer service representative gets access to all customer data when they are granted access to the CSM system. Although ABAC held promise to solve this problem, it has been realized only in a limited way in the real-world
Static: Role memberships typically change only manually. ABAC policies too sometimes depend on manually set attribute values, or on custom code embedded in applications that depends directly on manually entered data
Manageability: There are three things here:
- Permissions Bloat: Due to the manual nature of adding and removing users from specific roles, users gradually amass more permissions than they should have over time. Similarly in ABAC, attributes that need manual updates may not be regularly updated to reflect new realities
- Policy Thicket: In RBAC, role memberships are actually the output of business policies understood by administrators when they add users to roles. However, when reviewed (say, during access certifications), it becomes hard to guess why certain users have been included in certain roles. Similarly in ABAC as implemented today, attribute values set manually through intermediary abstractions such as entitlements cause interpreting ABAC policies inside applications notoriously difficult. Another way is to write code in applications to filter information that is fetched or presented. This is even harder to maintain as requirements and regulations change
- Stale Access: Organizations, driven by business urgencies, can efficiently add users to roles as required. However they are not that great at removing users from roles that are no longer appropriate to their responsibilities. This is because there is no business urgency driving such removal, and it is hard to make sense of previous role memberships. ABAC only complicates the stale access problem because instead of worrying about the currency of a single attribute (“role”), administrators now have to worry about all attributes (e.g. project assignments) that may be used in determining access. In addition ABAC as implemented today can lead to stale access due to outdated policies embedded in specific applications
Auditability: Access decisions are often made inside applications that have variable amounts of logging of such decisions. This is true of both RBAC and ABAC systems. As a result, there is no central record of who requested access to what and whether and why such access was granted or denied. Even if collated from multiple apps, the policies that resulted in the access decision are impossible to identify
So, what do we call newer technology here?
At the heart of the need to improve enterprise authorization are the issues of being coarse-grained, static, hard-to-manage, tightly-coupled inside applications and un-auditable. Any new technology that addresses enterprise authorization should be dynamic (i.e. based on continuously updated data), fine-grained and contextual to specific requests for access, consistent across all applications, easy to manage, and auditable.
Any new technology that addresses enterprise authorization should be dynamic (i.e. based on continuously updated data), fine-grained and contextual to specific requests for access, consistent across all applications, easy to manage, and auditable.
While ABAC can conceptually meet many of these requirements there are only a handful of solutions that fully realize the promise of ABAC. I propose that we need to come up with a new way to describe the next iteration of technology so, as an industry, we can distinguish between older, partial approaches and genuinely new techniques.
RBAC and ABAC are both functional descriptions of the authorization models. So it would be nice to have such a functional description of whatever follows. It would be nicer though, if the name describes the end-result instead, so that there is an in-built desired objective in it.
Vendors have attempted to call newer approaches with terms such as policy-based access control. This has the issue that it could mean anything, since ABAC (and even RBAC) is also “policy based”. Another term being used is NGAC (Next Generation Access Control) NGAC also is generic because it neither defines the model nor the outcome.
I like the term “Just-In-Time Access Management” (JITAM), as it describes what could solve these issues quite well. It describes the dynamism, i.e. access decisions must be made in real-time or near-real-time; And it describes the objective of manageability (not just control).