Access Control Approaches: RBAC vs. ABAC
In this topic, I would like to acquaint readers with a relatively new approach to access control called Attribute-based access control . Acquaintance will take place on the example of comparison with the currently popular Role-based access control .
When a company consists of one person, there are no internal secrets in it. The only employee available to any actions and any information.
If the company is successful and the volume of work grows, then a moment comes when one person stops cope. And then new employees are hired at 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 firm may suffer financial losses due to:
To solve these problems and properly delimit access, you need to understand which employee wants to perform an 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 the most common today received control based on roles (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 broken down by roles (accountant, manager, administrator, etc.), this approach will be sufficient. Then one role will correspond to one business rule.
But business rules are inevitably complicated and become 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.) are added.
To cope with this complexity, it is necessary 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 a branch “G” appears, you will have to add new roles, such as “Administrator of branch“ G ”,“ Manager of branch “G”, “Accountant of branch“ G ”, etc., then assign all new employees to all roles All this gives rise to a lot of routine manual labor.
In addition, there are other problems:
And business rules that use attributes whose values ​​are not known in advance and are calculated in the course of work cannot be expressed in general using a 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 the role model.
To implement support for such business rules, you will have to use other tools, which only increases the cost and complexity of implementing and maintaining 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 the current problems of access control, but also creates new ones.
To cope with unsolvable problems within RBAC, another approach was created based on attributes.
The main difference of this approach is that each situation is evaluated not from the point of view of the user's role and the action he wants to perform, but from the point of view of the attributes that relate to them.
A business rule is essentially a set of conditions in which various attributes must satisfy their requirements.
You can explicitly select several categories of attributes.
To perform the authorization, the values ​​of all attributes are taken at the time of the rights check and compared with the expected values. Fulfillment of all conditions provides access to the resource.
Simple rules are described by simple terms.
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 a branch “G” appears, there is no need to change anything in the business rule. All that is required is to add to the necessary employees the value of the attribute “Branch” - “Branch“ G ”.
Thus, ABAC avoids the problems that appear in RBAC:
But most importantly, ABAC solves problems that cannot be solved with RBAC, since there are no restrictions on the complexity of business rules in this approach. Business rules of any complexity, including the use of previously unknown attributes, do not create new problems and are simple to maintain.
It is convenient to use business rule views as a set of conditions for filtering data. Some of the 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 get only authorized data.
As can be seen from the comparison, RBAC is well suited only for implementing simple business rules. With the increasing complexity of the rules, the expediency of using RBAC decreases due to the growing cost of supporting the access control system, and starting from a certain level of complexity of the rules, this approach does not work at all.
ABAC, in turn, does not limit the complexity of business rules. Thanks to a more comprehensible 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. Read more about it in the next article.
Interesting and useful links about ABAC, XACML and their use:
When a company consists of one person, there are no internal secrets in it. The only employee available to any actions and any information.
If the company is successful and the volume of work grows, then a moment comes when one person stops cope. And then new employees are hired at the company.
')
But when the number of employees in the company increases, other problems appear, for example:
- each employee should perform only his own business tasks and not have access to others;
- each employee should see only information related to his business tasks;
- each task must have a responsible employee.
If you do not solve these problems, the firm may suffer financial losses due to:
- inefficient performance of other people's tasks due to incompetence;
- intentional or unintentional errors in other people's tasks;
- disclosing information to unauthorized persons.
To solve these problems and properly delimit access, you need to understand which employee wants to perform an 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 the most common today received control based on roles (role-based access control, RBAC).
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 broken down by roles (accountant, manager, administrator, etc.), this approach will be sufficient. Then one role will correspond to one business rule.
But business rules are inevitably complicated and become 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.) are added.
To cope with this complexity, it is necessary 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 a branch “G” appears, you will have to add new roles, such as “Administrator of branch“ G ”,“ Manager of branch “G”, “Accountant of branch“ G ”, etc., then assign all new employees to all roles All this gives rise to a lot of routine manual labor.
In addition, there are other problems:
- one business rule is “smeared” among many roles and becomes unobvious, which complicates the understanding of such a rule and its support;
- the explosive growth of the number of roles begins, which makes it much more difficult to manage them.
And business rules that use attributes whose values ​​are not known in advance and are calculated in the course of work cannot be expressed in general using a 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 the role model.
To implement support for such business rules, you will have to use other tools, which only increases the cost and complexity of implementing and maintaining 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 the current problems of access control, but also creates new ones.
Attribute-based access control (ABAC)
To cope with unsolvable problems within RBAC, another approach was created based on attributes.
The main difference of this approach is that each situation is evaluated not from the point of view of the user's role and the action he wants to perform, but from the point of view of the attributes that relate to them.
A business rule is essentially a set of conditions in which various attributes must satisfy their requirements.
You can explicitly select several categories of attributes.
To perform the authorization, the values ​​of all attributes are taken at the time of the rights check and compared with the expected values. Fulfillment of all conditions provides access to the resource.
Simple rules are described by simple terms.
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 a branch “G” appears, there is no need to change anything in the business rule. All that is required is to add to the necessary employees the value of the attribute “Branch” - “Branch“ G ”.
Thus, ABAC avoids the problems that appear in RBAC:
- the business rule is not “smeared” on the system, which makes its understanding and support quite simple;
- there is no explosive growth in the number of conditions, which simplifies their maintenance.
But most importantly, ABAC solves problems that cannot be solved with RBAC, since there are no restrictions on the complexity of business rules in this approach. Business rules of any complexity, including the use of previously unknown attributes, do not create new problems and are simple to maintain.
It is convenient to use business rule views as a set of conditions for filtering data. Some of the 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 get only authorized data.
ABAC versus RBAC
As can be seen from the comparison, RBAC is well suited only for implementing simple business rules. With the increasing complexity of the rules, the expediency of using RBAC decreases due to the growing cost of supporting the access control system, and starting from a certain level of complexity of the rules, this approach does not work at all.
ABAC, in turn, does not limit the complexity of business rules. Thanks to a more comprehensible 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. Read 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.
Source: https://habr.com/ru/post/248649/
All Articles