A Brief History of RBAC and ABAC

If you’ve been paying attention to trends in access control, then you’ll likely have come across the terms Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC). Both have years of precedent in the field of access control, and both are used to great effect across nearly every market in the world. While these concepts may be generally understood in simple terms, it is important to understand their more than two decade history, as to better understand the steps we must take in the future of authorization and access control. 

These forms of access control did not simply spring up overnight. They come from a dense, if not short, history of early pioneering by the United States Department of Defense (DoD). The DoD first employed logical access control by Mandatory and Discretionary Access Controls, before moving onto Identity Based Access Control, or IBAC.

IBAC was a groundbreaking tool and led to further innovations which can be used in the modern day. For example, IBAC, like most other forms of access control, relies on an access control list (ACL). The way an ACL works is simple: if a user presents a credential that matches the one held in the ACL, a decision is made to provide the subject access to the object. This decision made through IBAC is based solely on the ACL, and cannot change given additional context, making it static. 

Static decision making is not necessarily a net negative for a business, as static decisions were the de-facto standard for access control for decades after, into the eras of RBAC and ABAC. RBAC, for example, is often categorized as a static form of access control, since it still needs manual oversight and cannot make exceptions for its decisions. If you aren’t on the list, or don’t have the right credentials, you are denied access.

RBAC was itself spawned from IBAC, as a way to further control who has access to which objects. It was formalized in 1992 by David Ferraiolo and Rick Kuhn, and was combined with another framework in 2000 to create the RBAC we know today. RBAC extends the power of ACLs to provide users with certain capabilities based upon their role. If a user has the role of manager, they may be able to access certain microservices or functions that those they manage cannot, for example. Without a doubt, RBAC is among the most popular forms of access control, especially for large (500 employees or more) organizations.

ABAC, on the other hand, is much newer, more dynamic, and more complex than its older cousin. ABAC, like the previous installations on this list, makes decisions based upon attributes applied to each and every user in a system, which are typically still stored in an ACL. In the words of NIST, “ACLs and RBAC are in some ways special cases of ABAC in terms of the attributes used.” This is because in RBAC, each role could be viewed as an attribute, an area in which ABAC specializes. Unlike RBAC, however, ABAC allows companies to provide significantly more options — provides them with finer-grained access control, in other words.

Originally recommended by the Federal Chief Information Officers Council (Federal CIO Council) in 2011, ABAC has quickly gained traction in the world of access management due in large part to its flexibility. While RBAC provides users with unparalleled control over user roles and those roles’ capabilities, ABAC can do that and much more. Attributes can be made up of myriad pieces of information, from aforementioned roles to a current relationship with any other object. 

As a quick refresher, we should talk about RBAC and ABAC a bit more technically, and what makes each form of Access Control valuable.

RBAC allows network access to be restricted based on user roles. These roles are decided most often by users’ position in their organization, or which team they’re a part of. RBAC lets employees have access rights only to the data they need to complete their jobs and keeps them from accessing potentially sensitive information that doesn’t necessarily relate to them. Granting employees having unwarranted access to sensitive information is obviously unwise from a security perspective — presenting new attack vectors and opportunities to make unintended mistakes where they should not exist.

By assigning roles, companies are able to designate who has access to what information, depending on if they are a specialist, for instance, or more senior user. Increased roles can be given based not only on company position, but also on position competency, or simply trust from organizational higher-ups. Access to computer resources can also be restricted to specific tasks, such as the ability to view or write files. Limiting network access is important for organizations that have a large number of employees or who hire contractors and other third-party vendors, which in itself makes monitoring network traffic a challenge. Organizations that rely upon RBAC are better prepared to secure their sensitive data and applications.

The next logical evolutionary step from RBAC is attribute-based controls.

ABAC is a more fine-grained form of access control that grants or denies access based on a combination of attributes. ABAC controls access to objects by evaluating rules against the attributes of both the subject and object entities and the environment relevant to which the request was sent. These decisions on whether or not to allow access to objects are based on a series of attributes and additional contextual data — for instance, a user’s level seniority or budget controlled — that are decided by policy. 

Attributes included are usually those that relate to one of four things: the subject, the object in question, the requested operation and, increasingly, environmental or contextual conditions like the time of day, the user’s location and so forth. The subject, or the user requesting access into the resource, most often has key attributes. These attributes often include job role, group memberships, management and security clearance, among others. Here’s what an ABAC pattern might like like: Michaela, a senior engineer who controls over $100K in budget (subject with attributes) may be authorized to access (requested action) a backend service (object), but only during her normal business hours (contextual condition). ABAC is often connected to a company’s HR system or user directory, allowing the authorization system to see which employees and users have these attributes.

Additionally, using ABAC allows users to update any single object without breaking the entire system. In legacy servers, the owner of any particular app would be responsible for changing the app at large, whenever a change to access control policy went into effect. If a new role, such as “Vice President” were created, every object individually protected by RBAC would have to be updated to accept that role as valid. However, with ABAC, the VP can be given a completely unique set of attributes, which the ABAC system could then read to provide an allow or deny action.

ABAC and RBAC are standards in the modern world of cloud-native technologies — and the former is surging in popularity, due to the growing need for finer-grained authorization. While organizations have been forced to build new methods for the shift to cloud-native applications, these methods have largely stayed the same. However, the ways in which organizations implement RBAC and ABAC have changed; for instance, cloud-native tools such as with Open Policy Agent (OPA) and Styra Declarative Authorization Service (DAS), allow companies to flexibly adopt both methods of access control interchangeably, when enforcing policy as code.

Want to learn more about RBAC and ABAC? Read our whitepaper about why RBAC is no longer enough for Kubernetes Security.