Recently, a permission system needs to be designed in the project, and the data is collected. There are two main technologies in the permission system: ACL (Access Control List) and RBAC (Role-Based Access Control). The former is to directly associate users with permissions, and organize these users through groups. The user permissions of the windows system should belong to this category (to be confirmed). The latter isolates users and permissions through roles, and grants permissions to roles, and a user is an instance of a role.
The advantage of ACL is that it can directly set permissions for users. The permission settings are more flexible, and each user can be completely different, but this also increases the complexity of the administrator's permission settings. RBAC is more convenient for user management. The detailed description and comparison of the two will not be long-winded here. There are many related materials on the Internet.
Below is what I did.
Design requirements:
1. Permission control by project;
2. The project is divided into different groups, such as instrument group, DCS group, etc., each group uses different system modules;
3. There are different positions under each group, such as instrument selection, sample maintenance, etc. Personnel in different positions have different permissions to use different functions under the system module corresponding to the group.
The second corresponds to the Group of RBAC, and the third corresponds to the Role of RABC. This part draws the following database ER diagram.
This structure is usually the general structure of RBAC, which is easier to understand. As can be seen from the ER diagram, authority assignment is based on roles, which is the most important feature of RBAC. At the same time, it can be seen from many materials that RBAC generally only achieves functional-level permission control, and it is difficult to achieve more fine-grained data control, such as row data, or even field operation permission control.
The following requirements have puzzled me for a long time.
1. For different personnel (role instances) of the same position (role), the data created by all personnel in the position can be queried, but only the data created by themselves can be modified or deleted;
2. For data not created by yourself, only some fields of the data can be accessed.
In fact, the first item is the access control based on the row data, and the second item is the access control based on the field. To satisfy these two terms, three data tables were added, resulting in the ER diagram below.
The " authority category" data table is equivalent to an enumeration variable, including four values: project, group, role, and individual. For example, the authority category of the operation authority of a "sample maintenance-deletion-sample" (role-operation-function) belongs to "Individual", then a row of sample data can only be deleted by the creator of the data; if the data is "role", then the data can be deleted by all the personnel who maintain the role of the sample. In this way, the first requirement can be satisfied.
The above is only the initial idea of doing this permission design by myself, it has not been verified or coded. Welcome to make a brick!