Rights Management — Analysis of rights Management Model (DAC, MAC, RBAC, ABAC)

The introduction

No matter 2C product manager or 2B product manager, all must know the rights management rules by heart. Only when you are familiar with the rights management rules can you better understand the architecture of your product and have a clear idea of each product iteration.

Different companies or software providers have devised countless ways to control user access to features or resources. But no matter which design, Discretionary Access Control (DAC), Mandatory Access Control (MAC), role-based Access Control (RBAC, Role-based Access Control and attribute-based Access Control (ABAC).

Essentially, any type of permission management model can abstract out three basic elements — users, system/application, and policy.

The term

Here’s a reminder of the vocabulary that will be used later:

1. User: the entity that initiates an operation;
2. Object: refers to the object object of the operation, such as order data or image files;
3. Role: Assign an identity to the user;
4. Access Control List (ACL) : data table used to describe permission rules or relationships between users and permissions.
5. Permission: used to refer to an operation on an object, such as “operation to add articles”;
6. Permission identifier: A permission identifier, such as “ARTICLE_ADD” for the “Add article” action permission.

DAC

The DAC: Discretionary Access Control model identifies the user and then analyzes the Subject’s Access Control List or Access Control matrix. Access Control Matrix) to determine whether the user can perform any operations on it, such as read or modify. Users who have access to an object can assign access to that object to other users, so this is called Discretionary control.

The most common use of this design is for file system permissions, such as Microsoft NTFS.

The biggest drawback of DAC is that it is difficult to manage permissions in a decentralized way, such as simply setting uniform permissions for a set of files and opening them up to a specified group of users.

MAC

The Mandatory Access Control model (MAC) was developed to compensate for the decentralized Access Control of DAC. In the MAC design, each object has some permission identifiers, and each user also has some permission identifiers. Whether a user can operate the object depends on the relationship between the two permission identifiers, which is usually strictly restricted by the system. For example, in movies and television works, we can often see that when agents are inquiring about confidential documents, the screen prompts “Access is not available, level 1 security clearance is required”. In this example, there is a “Level 1 security clearance” permission identifier on the file that the user does not have.

The MAC is great for secret agencies and other class-conscious industries, but it’s not flexible enough for services like business.

RBAC

RBAC0

Role-based Access Control (RBAC), as its name implies, defines roles for users and controls permissions through roles. At present, role-based access control model is widely used, especially in the FIELD of SAAS in 2B direction.

As shown in the figure above, a user has a role and can have multiple roles, each of which has different rights. The advantage of this is that there is no need to configure permissions for each user, with great flexibility and convenience. In addition, RBAC can simulate the effect of DAC and MAC.

For example, the database software MongoDB adopts the RBAC model and divides permissions for database operations:

Based on these permissions, MongoDB provides some predefined roles (users can also define their own roles) :

Finally, different roles are granted to users, and different granularity of permission assignment can be achieved.

At present, most systems on the market adopt RBAC model when designing permission system. However, some systems implement RBAC incorrectly by determining whether the user has a role rather than permissions, such as the following code:

if (user.hasRole('hr')) {
    // Perform a function that only the "HR" role can do, such as raising employees' salaries...
    // ...
}
Copy the code

If the company later rules that the department manager can also raise the employee’s salary, then you have to change the code. Therefore, the correct code logic should be to extract the roles played by the user, determine the permissions of these roles, and finally determine whether the user has the corresponding permissions.

This is basically the RBAC Core design, also known as RBAC0. In fact, RBAC has evolved into the following versions: RBAC0, RBAC1, RBAC2, and RBAC3. RBAC1, RBAC2, and RBAC3 are all extensions and supplements of RBAC0. RBAC is more perfect and powerful because of RBAC1, RBAC2, and RBAC3.

RBAC1

RBAC1, an optimization based on RBAC0, adds a layer of roles (that is, sub-roles) that can inherit all permissions of the parent role. This design can group and layer roles, which simplifies permission management to a certain extent.

RBAC2

RBAC2, the extended version of RBAC for separation of responsibilities, avoids conflicts of interest when users have too many permissions. For example, a basketball player who also has the authority of the referee (is it hard to call a foul at a glance?) .

There are two modes of separation of responsibilities:

• Static Separation of Duty: Users cannot be assigned conflicting roles at the same time.
• Dynamic Separation of Duty: A user cannot simultaneously activate his or her own conflicting roles in a Session, but must choose one of them.

RBAC3

RBAC3, the most complex and comprehensive RBAC model, integrates the optimized part of RBAC1 and RBAC2 on the basis of RBAC0, and can be considered as the summation of RBAC0, RBAC1 and RBAC2.

How to use RBAC model to design authority system?

Now that we know what the RBAC model is, let’s break it down a bit before we look at how to design a permissions system based on this model.

The first is: users, roles, permissions. And permissions, specific to a software, actually contains two aspects: one is menu permissions, the other is data permissions.

Different industries will have different use scenarios, user role permission model will also have different degrees of change. But at the bottom, I can’t do without the picture I drew above.

Next, let’s abstract a scenario or case to help us understand the overall permission management design process. Assume that Company A is A medium or large manufacturing company with OA, HR, CRM and ERP management software. There are tens of thousands of employees in the company, and different personnel have different responsibilities, which are reflected in the management software, and they need to use different functions to complete the work.

Account management

An account is a transformation of identity when people and software interact. The back of the account represents the person doing the operation. Account management should be the unified management of all people who need to interact with the system, including basic information, such as the person’s name, gender, mobile phone number, department and other attributes.

Role management

Role management is to start from the actual situation, for example: the enterprise or group using the system, which types of roles – that is, which types of people, need to have different business menus and business data.

In the final analysis, role management is to divide the menus and functions needed by the person corresponding to this role into a group. Define different names — role names — for each action group.

Of course, this role management not only defines the functions that the person in this role can view, but also defines the scope of data that the role can see. As mentioned above, permissions actually contain two parts: menu permissions and data permissions.

The finer the granularity of function control in the system, the more flexible it will be for users to configure roles, but the complexity of the system will naturally increase and the cost will also increase for system designers.

Therefore, the level of control depends on the specific business scenario, for example: In some industries, it may be possible to control only one level of the menu (some SAAS tools), but in some systems, not only do you need to control all the sub-menus, every button action, but you may even need to control different fields (such as Salesforce’s permission control system).

However, we abstract the basic model, according to the actual business to diverge, is not the most difficult thing.

ABAC

Attribute-Based Access Control (ABAC) is regarded by some as the future of permission system design.

Instead of the usual way of associating users with permissions in some way, ABAC makes authorization decisions by dynamically calculating whether one or a set of attributes meets certain conditions (simple logic can be written). Attributes are generally divided into four categories: user attributes (such as user age), environment attributes (such as current time), operation attributes (such as read) and object attributes (such as an article, also known as resource attributes), so in theory it can achieve very flexible permission control, almost to meet all types of requirements.

For example, “allow all class teachers to freely enter and exit the school gate during class time” rule, wherein, “class teacher” is the user’s role attribute, “class time” is the environment attribute, “in and out” is the operation attribute, and “school gate” is the object attribute. ABAC usually has configuration files (XML, YAML, etc.) or DSLS that are used in conjunction with a rule parsing engine for easy rule setting and rule determination. XACML(eXtensible Access Control Markup Language) is an implementation of ABAC, but the design is too complex to be introduced.

If ABAC is so good, why is RBAC the most popular? I think it’s mainly because most systems don’t have much need for permission control, and ABAC management is relatively complex. Kubernetes introduced RBAC in version 1.8 because ABAC was too difficult to use.

ABAC is also sometimes called PBAC(Policy-based Access Control) or CBAC(Claims-Based Access Control).

conclusion

1. Understand the concepts of DAC, MAC and ABAC;
2. Familiar with the entire RBAC model family, especially RBAC0 as the base;
3. Think about how to design a simple permission management system using RBAC.

Refer to the reading

1. Familiarize yourself with these four permission management models to understand product iteration
2. Analysis of permission System design Model (DAC, MAC, RBAC, ABAC)
3. Permission System Design Based on RBAC Model (Github Open Source Project)