Use cases to implement RBAC or ABAC?

Role-based access control (RBAC) and attribute-based access control (ABAC) are two ways of controlling the authentication process and authorizing users. The primary difference between RBAC and ABAC is RBAC provides access to resources or information based on user roles, while ABAC provides access rights based on user, environment, or resource attributes. When considering RBAC vs. ABAC, RBAC controls broad access across an organization, while ABAC takes a fine-grain approach.

Role based access control (RBAC)

Someone logs into your computer system. What can that person do? If you use RBAC techniques, the answer to that question depends on the user role.

A role in RBAC language typically refers to a group of people that share certain characteristics, such as:

• Departments
• Locations
• Seniority levels 
• Work duties

RBAC is role-based, so your access permissions will vary based on your function within the organization. This is determined by an administrator, who establishes the parameters of what access a role should have, along with which users are assigned which roles. For instance, some users may be assigned a role that allows them to write and alter specific files, while others may be limited to reading but not editing files.

Multiple responsibilities can be assigned to a single user, granting them access to numerous files and abilities. Consider a group of individuals collaborating on a large project. The project manager will have access to all project files and will be able to make any necessary modifications. However, the development team may only have access to the programming files and will not be able to view or modify the project’s financial data or employee information. On the other hand, the human resources or management staff may have access to all employees and financial data, but they have no need for programming files.

With RBAC, the policies do not need to be changed whenever a person leaves the organization or changes positions; they can simply be removed from the role group or assigned a new role. This also means that access can be granted to new employees relatively rapidly, depending on their organizational role.

Attribute based access control (ABAC)

Someone logs into your computer system. What can that person do? ABAC protocols answer that question via the user, the resource attributes, or the environment.

As the administrator of a system using ABAC, you can set permissions by:

• User. A person’s job title, typical tasks, or seniority level could determine the work that can be done.
• Resource attributes. The type of file, the person who made it, or the document’s sensitivity could determine access.
• Environment. Where the person is accessing the file, the time of day, or the calendar date could all determine access.

Essentially, ABAC has a much greater number of possible control variables than RBAC. ABAC is implemented to reduce risks due to unauthorized access, as it can control security and access on a more fine-grained basis. For example, instead of people in the HR role always being able to access employee and payroll information, ABAC can place further limits on their access, such as only allowing it during certain times or for certain branch offices relevant to the employee in question. This can reduce security issues and can also help with auditing processes later.

When to consider ABAC vs RBAC

These scenarios may assist you determine when RBAC systems are more effective than ABAC systems. We’ve also provided an example of combining the two, as this can also be effective.

Companies should think about the RBAC vs. ABAC question when addressing:

Scenario 1: Small gatherings of employees. RBAC is optimal. Defining work by role is straightforward when the company is small, and the number of files is modest. A RBAC system should be efficient and simple to implement if you work for a construction company with 15 employees or fewer.

Scenario 2: Geographically diverse groupings of workers. ABAC is a viable option. You can define employee access by position, location, and business hours. You could restrict access to business hours based on the time zone of a branch.

Scenario3 Time-defined workgroups. ABAC is favored. Certain sensitive documents or systems should be inaccessible outside of normal business hours. ABAC systems permit time-based constraints.

Scenario 4: Simply structured workgroups. RBAC is optimal. Your organization is large, but access is determined by the positions individuals hold. For instance, a doctor’s office may grant receptionists read/write scheduling access, but they do not need to view medical test results or invoicing information. The RBAC system is effective here.

Scenario 5: Creative businesses. ABAC is ideal because creative firms frequently utilize their files in novel methods. Occasionally, everyone must view certain documents, while other times, only a select few do. Access requirements vary by document, not by role.

For instance, your company’s creative staff, including artists and writers, generate files that can be readily shared by other employees. However, these employees, such as invoicing departments and account executives, may require access to these files. And the marketing department may wish to distribute them.

ABAC is optimal for managing the complexities of who should view these documents and how they should be handled.

Often, neither RBAC nor ABAC will be the perfect solution to cover all the use cases you need. That’s why most organizations use a hybrid system, where high-level access is accomplished through RBAC and then fine-grained controls within that structure are accomplished through ABAC.

For example, you might use the RBAC system to hide sensitive servers from new employees. Then, you might use ABAC systems to control how people alter those documents once they do have access. Researchers say blending RBAC and ABAC can help administrators get the best of both systems. RBAC offers leak-tight protection of sensitive files, while ABAC allows for dynamic behavior. Blending them by combining the strength of both.