A Solution to Fix Authorization

In my last post, I explained fundamental issues with Role Based Access Control (RBAC) including application brittleness, role explosion, and role accumulation. But let’s turn the discussion to how Attribute Based Access Control (ABAC) solves most — if not all — of the issues associated with RBAC.

However, to explain the benefits of RBAC, we need to take a detour to discuss an important, yet related concept that for most data an Authoritative Data Source (ADS) exists. An ADS is the primary system where data — trusted as the most accurate and up-to-date — exists. Every organization has at least one ADS. Some organizations have many. But for most organizations, the primary use of an ADS is for managing people. This contains information such as the person’s hire date, birth date, SSN, title, organization, location, etc. Usually this is referred to as an HR or HCM system, and is often purchased as a package from a major Enterprise Resource Planning vendor. This system becomes the basis for managing most of the critical information about employees. Organizations can also have other ADS systems directly related to the organization’s mission, operations, or finances. For our purposes, we’ll stick with an example that involves an organization with one ADS.

To outline the benefits of ABAC, we need to connect the concept of ADS to the concept of ABAC. Since the last post didn’t explain ABAC, I’ve included a brief explanation here – but more information can be found in the Guide to Attribute Based Access Control on the National Institute of Standards and Technology website.

ABAC — a brief explanation

Fundamentally, ABAC is a method for access control that relies on attributes of subjects (person, organization, device) and objects (information or capability), based on a known set of environmental conditions and policies. ABAC is implemented as a service for other applications to consume. Basically, when a subject uses an application to access an object, a request is sent to an ABAC server with the attributes of the subject and the object as well as environmental conditions. The ABAC server, which has a repository of policies, evaluates the request to see if the subject is allowed to access the object within those environmental conditions. The result is either to permit or deny access. Suppose a person (subject) that works in accounting wants to access payroll information (object) for herself at 8:00 PM (environmental condition). An ABAC policy states that subjects can always access objects about themselves at any time, so the request is granted. However, instead of the person searching for this same information about herself, she wants to access information about her supervisor at the same time in the evening. The ABAC policy states that only subjects in the Human Resources Department can access payroll objects about others during normal work hours, and it also logs any after-hours requests. In the second example, access is denied, and the attempt is logged.

This sounds complicated and difficult to do, so what about that is “more elegant”? Let’s disassemble what is happening and examine how each piece of the chain relies on the least technically complex resolution to achieve that level of access control.

A closer look at ABAC in action

In ABAC access control is managed outside of the application. The individual application only needs to provide an attribute for identifying the subject and the object and an attribute that identifies what the subject wants to perform on the object (in this case read payroll information). The logic for making the access control decision is controlled by policies in the ABAC server. If the ABAC server needs other attributes related to the subject or the object, it will access policy information points to get those attributes. From a technical perspective instead of each application building access control rules access control is done with an ABAC server and with one set of policies. This solution greatly reduces Application Brittleness.

Creating a complex policy that relies on multiple attributes for access control is not easy in RBAC. Complex policies that require multiple attributes will require multiple roles to have fine grain control access control. The example above used User Name, Employee Id, Employee Dept., and Work Hours. Of those, two played a crucial part; Employee Dept. and Work Hours. And both of those have at least two values, which means we would need at least four roles (HR-WithinWorkHours, HR-OutsideWorkHours, NotHR-WithinWorkHours, NotHR-OutsideWorkHours). Realistically many more roles would need to be created. In ABAC it was just a matter of getting the correct subject and object attributes and the environmental condition, then writing the access control policy on the ABAC server. This process eliminates Role Explosion one of the other major issues with RBAC.

Now, let’s connect the ADS concept to ABAC. Simply put, with ABAC we don’t have to rely on a secondary or tertiary data repository to get the attributes for the subject or the object. In RBAC, the user information is provided by (at best) a secondary data repository getting its information from some other source — possibly an ADS.

With ABAC, once we know the subject identifier (one attribute) we can have the ABAC server (using a defined policy information point) query the ADS for people (HR System) to get the most up-to-date information on that subject. The same is true for the object attributes. We can get them either from the object that the subject is attempting to access, or from an ADS associated with that object that has more definitive attributes. In the example, we know the subject because her login name is part of the authentication process. Once we have her login information the only other information necessary in ActiveDirectory would be her Employee ID. With that ID we can access the ADS, which contains information associated with the Employee ID thus providing her department, her working hours, status, etc.

It is important to stress — we are using the Authoritative Data Source as the repository of subject attributes, which implies we have the most up-to-date and accurate information to make an access control decision. It also means that, as subjects change roles within the organization, access is not granted or revoked, but simply relies on accurate information in the ADS, thereby eliminating role accumulation.

My team has adopted a slogan, Think Big, Start Small, Scale Smartly. In my next post I will explain that principle, and explain how to transition from RBAC to a more elegant and inherently integrated solution, using ABAC.