In the actual development of the project, we not only need to control which resources a user can access, but also need to control the user can only access some part of the data in the resource.

We have a very mature permission management model, namely RBAC, to control which resources a user can access. However, it is not enough to control which resources a user can access only (data permission, as we often say). In this paper, we try to integrate the management control of data permission on the basis of RBAC model.

First, let’s look at the RBAC model.

RBAC model

RBAC is an abbreviation of Role-based Access Control, meaning role-based access Control.

RBAC defines different roles in the system in advance, and different roles have different permissions. A role is actually a set of permissions. All users in the system are assigned to different roles, and one user may have multiple roles. Using RBAC can greatly simplify permission management.

The RBAC model can also be subdivided into RBAC0, RBAC1, RBAC2, and RBAC3. We will not discuss the differences between them here, and those who are interested can do their own research. We will focus on the common RBAC0 model.

The following figure is the database design of a classic RBAC0 model.

In the RBAC model, the system only verifies whether user A belongs to role RoleX, but does not determine whether user A can access data DataB belonging to user B. This problem is called the “horizontal rights management problem”.

Data access

List data authority, mainly through the data authority control line data, so that different people have different view data rules; To implement data permissions, the most important thing is to abstract data rules.

Data rules

For example, the business opportunity data of our system needs to be controlled from the following dimensions.

  1. Salespeople can only look at their own data;
  2. The sales manager of each region can only see the data of each region (the sales manager of Anhui Region can only see the business opportunity data of Anhui region), and the same applies to the leader in charge of a BG who can only see the business opportunity data of his own BG.
  3. Accountants can only look at numbers less than $10,000.

These dimensions are data rules.

In this way, we have also clarified several key elements of data rules, that is, rule fields, rule expressions and rule values. The rules corresponding to the above three scenarios are as follows:

  1. Rule field: creator, rule expression: =, rule value: current logon
  2. Rule field: Region, rule expression: =, rule value: Anhui region
  3. Rule field: sales amount, rule expression: <, rule value: 10000

Rule field configuration description: Conditional expression: Greater than/Greater than or equal to/Less than/Less than or equal to/Equal to/Inclusive/Fuzzy/not equal Rule value: Specified value (fixed value/system context variable)Copy the code

Associate resources and users

It is not enough to have data rules; we also need to bind data rules to resources and users.

The binding of data rules to resources is very simple, we just need to create an intermediate table, as shown below:

This way resources can be associated with data rules.

In the application design, we need a separate data rule management function, which is convenient for us to input data rules, and then we can choose the built-in data rules on the resource management page (such as the list of business opportunities) to bind resources and rules.

So how do you let different users have different data rules?

In the RBAC model, users manage resources by granting different roles. Similarly, we can associate data rules with roles when granting permissions, so that different users have different data rules in the system.

It’s a bit of a mouthful, so let’s stick to the example above.

Sales personnel, regional sales manager, and financial personnel belong to different roles, and they all have the resource rights of the business opportunity list. However, when binding the resource rights of the business opportunity list to these roles, we can select the corresponding data rules (resources and data rules have been bound above). In the database design, we can add a field in the role resource mapping table Role_Permission to store the associated data rules. If there are multiple data rules, they can be separated by delimiters.

Finally, the RBAC model evolved into the following model:

According to the above design, we need to distinguish the data rights of each region and establish different regional roles, such as Anhui Regional sales manager and Shanghai regional sales manager, and then check corresponding data rules for the roles respectively. This is similar to the concept of role inheritance in RBAC1.

So we have basically implemented the binding of RBAC to the data rules, but we still have the problem of how to implement it into the system.

Here we will use the famous AOP to achieve, this article only speaks of principle does not speak of implementation, so we just mention the implementation scheme.

  1. Customize a data permission annotation, such as callPermissionData
  2. Add custom annotations to the corresponding resource request method, such as a business opportunity list@PermissionData
  3. AOP is used to capture all the data rules corresponding to the user’s role and perform SQL splicing. Finally, data filtering is realized at SQL level.

Continue to optimize

Through to the different characters in the design of the above we different data binding rules to realize the data access, but consider the following scenario: a role to see data in the range of “regional for anhui regional and group for the consumer group business data”, in this scene, in accordance with the design before we need to build two data rules:

  1. Region = Anhui Region
  2. Business Division = Consumer Division

Then establish two different roles and grant different data rules respectively. If there are too many such scenes, it is easy for the role to explode. Therefore, we extract the concept of data rule group here.

A data rule group has multiple data rules, which are connected by AND. Put an application design diagram:

This is reflected in the database design as follows:

summary

Through the design of the above 8 tables we have realized the combination of RBAC model and data permissions, of course there is still room for further optimization. For example, we can extract the corresponding dictionary table for rule fields and rule values, and let the data rule table remove the association of these dictionary fields. In this way, when configuring data rules at the application layer, the administrator does not need to manually fill in the dictionary items. In this way, the probability of data rule configuration errors is reduced.

Data permission is a relatively complex function to implement. Here we choose to extend it based on the RBAC model. If you have a better solution, please leave a message and tell me.