January 23, 2015 at 13:53Access Control Approaches: RBAC vs. Abac
In this topic, I would like to introduce readers to a relatively new approach to access control called Attribute-based access control . Acquaintance will take place through an example of comparison with the now popular Role-based access control .
When a company consists of one person, then there are no internal secrets in it. Any action and any information are available to the sole employee.
If the company is successful and the volume of work is growing, then there comes a time when one person ceases to cope. And then new employees are hired in the company.
But when the number of employees in the company increases, other problems appear, for example:
If you do not solve these problems, the company may suffer financial losses due to:
To solve these problems and correctly distinguish access, you need to understand which of the employees wants to perform the action (authentication) and whether he can do it (authorization).
The most difficult is the problem of authorization. There are several approaches to its solution, but role-based access control (RBAC) is currently the most widely used.
The essence of the approach is to create roles that repeat business roles in the company and assign them to users. Based on these roles, the ability of the user to perform an action is checked.
If business rules are one-dimensional and all actions can be divided into roles (accountant, manager, administrator, etc.), such an approach will be sufficient. Then one role will correspond to one business rule.
But business rules inevitably become more complex and multidimensional. This leads to the fact that one attribute (role) for expressing business rules becomes insufficient and other attributes (city, country, branch, day of the week, owner, limit, etc.) begin to be added.
To cope with this complexity, you need to create additional roles, the number of which is equal to the number of different combinations of all attributes.
Each time you add a new attribute value, you will have to add new roles. That is, if branch “G” appears, then you will have to add new roles, such as “Administrator of branch“ G ”,“ Manager of branch “G”, “Accountant of branch“ G ”, etc., and then assign all the required employees new roles. All this gives rise to a lot of routine manual labor.
In addition, other problems appear:
And business rules, which use attributes whose values are not known in advance and are calculated in the process, are generally impossible to express using the role model.
There are also business rules that restrict access not to actions but to data. Such business rules are also impossible to express using a role model.
To implement support for such business rules, you will have to use other tools, which only makes it more expensive and complicated to implement and maintain an access control system. It turns out that as soon as business rules become multidimensional or require data control, the role model not only does not solve current access control problems, but also creates new ones.
In order to deal with problems that cannot be solved within the RBAC framework, a different approach based on attributes has been created.
The main difference between this approach is that each situation is evaluated not from the point of view of the user's role and the action that he wants to perform, but from the point of view of the attributes that relate to them.
A business rule, in fact, is a set of conditions in which various attributes must satisfy the requirements for them.
Several categories of attributes can be clearly identified.
To perform authorization, the values of all attributes are taken at the time of checking the rights and are compared with the expected values. Fulfillment of all conditions provides access to the resource.
Simple rules are described by simple conditions.
Multidimensional rules in this model do not become more complex.
When adding new attribute values, the conditions of the business rule will not change. That is, if branch “G” appears, in the conditions of a business rule, nothing will have to be changed. All that is required is to add the attribute “Branch” - “Branch“ G ”to the necessary employees.
Thus, ABAC avoids the problems that appear in RBAC:
But most importantly, ABAC allows you to solve problems that cannot be solved using RBAC, since this approach has no restrictions on the complexity of business rules. Business rules of any complexity, including those using previously unknown attributes, do not create new problems and are easy to maintain.
It is convenient to use business rule representations in the form of a set of conditions for filtering data. Some conditions can be calculated even before accessing the resource, and the remaining conditions become a filter for selecting data.
The first three conditions can be checked before accessing the data. And the last condition can be used as a predicate to obtain only allowed data.
As you can see from the comparison, RBAC is only suitable for implementing simple business rules. With the increasing complexity of the rules, the feasibility of using RBAC decreases due to the growing cost of supporting an access control system, and starting from a certain level of complexity of the rules, this approach does not give any results.
ABAC, in turn, does not limit the complexity of business rules. Thanks to a more understandable business and compact expression, this approach allows not to increase the cost of support when implementing more complex rules, and also makes it possible to provide access control not only to actions, but also to data.
PS: Today for ABAC there is a standard XACML, which is actively developed and used. You can learn more about it in the next article.
Interesting and useful links about ABAC, XACML and their use:
When a company consists of one person, then there are no internal secrets in it. Any action and any information are available to the sole employee.
If the company is successful and the volume of work is growing, then there comes a time when one person ceases to cope. And then new employees are hired in the company.
But when the number of employees in the company increases, other problems appear, for example:
- each employee should perform only his business tasks and not have access to strangers;
- each employee should see only information related to their business tasks;
- Each task should have an employee responsible for its implementation.
If you do not solve these problems, the company may suffer financial losses due to:
- inefficient performance of other people's tasks due to incompetence;
- intentional or unintentional mistakes in other people's tasks;
- disclosure of information to unauthorized persons.
To solve these problems and correctly distinguish access, you need to understand which of the employees wants to perform the action (authentication) and whether he can do it (authorization).
The most difficult is the problem of authorization. There are several approaches to its solution, but role-based access control (RBAC) is currently the most widely used.
Role-based access control (RBAC)
The essence of the approach is to create roles that repeat business roles in the company and assign them to users. Based on these roles, the ability of the user to perform an action is checked.
If business rules are one-dimensional and all actions can be divided into roles (accountant, manager, administrator, etc.), such an approach will be sufficient. Then one role will correspond to one business rule.
But business rules inevitably become more complex and multidimensional. This leads to the fact that one attribute (role) for expressing business rules becomes insufficient and other attributes (city, country, branch, day of the week, owner, limit, etc.) begin to be added.
To cope with this complexity, you need to create additional roles, the number of which is equal to the number of different combinations of all attributes.
Each time you add a new attribute value, you will have to add new roles. That is, if branch “G” appears, then you will have to add new roles, such as “Administrator of branch“ G ”,“ Manager of branch “G”, “Accountant of branch“ G ”, etc., and then assign all the required employees new roles. All this gives rise to a lot of routine manual labor.
In addition, other problems appear:
- one business rule is “spread out” among many roles and becomes unobvious, which complicates the understanding of this rule and its support;
- an explosive increase in the number of roles begins, which greatly complicates their management.
And business rules, which use attributes whose values are not known in advance and are calculated in the process, are generally impossible to express using the role model.
There are also business rules that restrict access not to actions but to data. Such business rules are also impossible to express using a role model.
To implement support for such business rules, you will have to use other tools, which only makes it more expensive and complicated to implement and maintain an access control system. It turns out that as soon as business rules become multidimensional or require data control, the role model not only does not solve current access control problems, but also creates new ones.
Attribute-based access control (ABAC)
In order to deal with problems that cannot be solved within the RBAC framework, a different approach based on attributes has been created.
The main difference between this approach is that each situation is evaluated not from the point of view of the user's role and the action that he wants to perform, but from the point of view of the attributes that relate to them.
A business rule, in fact, is a set of conditions in which various attributes must satisfy the requirements for them.
Several categories of attributes can be clearly identified.
To perform authorization, the values of all attributes are taken at the time of checking the rights and are compared with the expected values. Fulfillment of all conditions provides access to the resource.
Simple rules are described by simple conditions.
Multidimensional rules in this model do not become more complex.
When adding new attribute values, the conditions of the business rule will not change. That is, if branch “G” appears, in the conditions of a business rule, nothing will have to be changed. All that is required is to add the attribute “Branch” - “Branch“ G ”to the necessary employees.
Thus, ABAC avoids the problems that appear in RBAC:
- the business rule is not "spread" throughout the system, which makes its understanding and support simple enough;
- there is no explosive increase in the number of conditions, which simplifies their maintenance.
But most importantly, ABAC allows you to solve problems that cannot be solved using RBAC, since this approach has no restrictions on the complexity of business rules. Business rules of any complexity, including those using previously unknown attributes, do not create new problems and are easy to maintain.
It is convenient to use business rule representations in the form of a set of conditions for filtering data. Some conditions can be calculated even before accessing the resource, and the remaining conditions become a filter for selecting data.
The first three conditions can be checked before accessing the data. And the last condition can be used as a predicate to obtain only allowed data.
Comparison of ABAC and RBAC
As you can see from the comparison, RBAC is only suitable for implementing simple business rules. With the increasing complexity of the rules, the feasibility of using RBAC decreases due to the growing cost of supporting an access control system, and starting from a certain level of complexity of the rules, this approach does not give any results.
ABAC, in turn, does not limit the complexity of business rules. Thanks to a more understandable business and compact expression, this approach allows not to increase the cost of support when implementing more complex rules, and also makes it possible to provide access control not only to actions, but also to data.
PS: Today for ABAC there is a standard XACML, which is actively developed and used. You can learn more about it in the next article.
Interesting and useful links about ABAC, XACML and their use:
- Introducing XACML, the standard for Attribute-Based Access Control
- ABAC;
- XACML standard;
- Guide to ABAC from NIST;
- Axiomatics XACML Implementation;
- WSO2 and XACML;
- Oracle WebLogic and XACML;
- IBM Tivoli Security Policy Manager and XACML;
- Cisco Enterprise Policy Manager and XACML;
- Boeing and XACML;
- PayPal and Axiomatics;
- Information resource;
- From SadBubble : JSON Profile of XACML 3.0.