Permission is a common basic function in the daily office system. In the system with permission module, it defines which resources login users can operate and which resources they cannot operate. The permission module can effectively control the specific operations of people with different identities who participate in the system. It can be said that a mature back-end system cannot do without a relatively perfect permission management system.
Permission management mode
RBAC model
RBAC model (Role-based Access Control: Role-based access control (RBAC96) model is a relatively early model of permission implementation, which was put forward in the multi-user computer period. RBAC96 model proposed by The Information Security Technology Laboratory (LIST) of George Mason University in the United States is the most representative model, and has been widely recognized.
RBAC believes that the process of authorization can be abstractly summarized as: Whether Who can access What How and determine whether this logical expression is True is the process of solving, that is, transforming the permission problem into Who, What and How, Who, What and How constitute the access triplet. For specific theories, please refer to RBAC96.
The composition of RBAC
In the RBAC model, there are three basic components: users, roles, and permissions. The relationship between them is shown in the figure below
[ImG-HVQ5LYHX-1601285004610)(imgkr.cn-bj.ufileos.com/361aa5f7-30…)]
- User: Each User is identified by a unique UID and is granted a different role
- Role: Different roles have different rights
- Permission: Access Permission
- User-role mapping: Mapping between users and roles
- Role-permission mapping: mapping between roles and permissions
For example, administrators and common users are granted different permissions. Common users can only modify and view personal information, but cannot create or freeze users. Administrators are granted all permissions, so they can do all operations.
[Img-UF47ZQbZ-1601285004611] [Img-UF47ZQbZ-1601285004611]
RBAC model classification
Base model RBAC0
RBAC0 is the foundation on which many products can build permission models. In this model, we assign permissions to roles and roles to users. Users and roles and roles and permissions are many-to-many relationships. The permissions of a user are equal to the sum of the permissions of all roles.
[Img-koh1APPH-1601285004612)(imgkr.cn-bj.ufileos.com/f1a4d061-77…)]
Here’s an example:
For example, if we make an enterprise management product, it will be very troublesome to assign permissions to each user according to the traditional permission model, and it is impossible to modify user permissions in batches. At this point, you can abstract several roles, such as sales manager, financial manager, and marketing manager, and assign permissions to these roles and then assign roles to users. In this way, you only need to modify the relationship between a user and a role or the relationship between a role and a permission to assign or modify permissions in the future, which is more flexible and convenient. In addition, if a user has multiple roles, for example, Mr. Wang is responsible for both sales and marketing, then Mr. Wang can be given two roles, namely sales manager and marketing manager, so that he has all the permissions for both roles.
Role layering model RBAC1
RBAC1 builds on RBAC0 and introduces the concept of inheritance in roles. In simple terms, roles can be divided into several levels, and each level has different rights to achieve more fine-grained rights management.
[Img-qSPXDYIC-1601285004614)(imgkr.cn-bj.ufileos.com/ece7b895-9c…)]
Here’s an example:
Based on the previous RBAC0 example, we found that the sales manager of a company may be divided into several levels. For example, in addition to the sales manager, there is also the deputy sales manager, and the deputy sales manager only has part of the authority of the sales manager. At this point, we can adopt the RBAC1 hierarchical model to divide the role of sales manager into multiple levels, and assign a lower level to the deputy sales manager.
Role constraint model RBAC2
RBAC2 also builds on RBAC0, but adds restrictions on users, roles, and permissions. These restrictions can be divided into two categories, namely Static Separation of Duty (SSD) and Dynamic Separation of Duty (DSD). Specific restrictions are shown below:
[External link image transfer failed, the source station may have anti-theft mechanism, it is recommended to save the image directly upload (IMG-ppz1TiAR-1601285004615)(imgkr.cn-bj.ufileos.com/9d61cf6c-bc…)]
Here’s an example:
For example, if a user is assigned the role of sales manager, he cannot be assigned the role of financial manager. Otherwise, he can enter the contract and review the contract by himself. For example, some companies are very important to the promotion of the role, a salesman to be promoted to sales manager, must be promoted to sales director, at this time the use of prerequisites.
Unified model RBAC3
RBAC3 is a combination of RBAC1 and RBAC2, so RBAC3 includes both role layering and restrictions that can be added.
[Img-M5YIukib-1601285004616] [Img-M5YIukib-1601285004616]
Case practice ~RBAC0 model core table structure
Through the above analysis, it can be seen that there are four models of RBAC, and the last three are extended from the RBAC0 basic model. Here, the design of the RBAC0 table of the basic model is mainly considered. After having the basic table structure, it can be upgraded on the basis of it.
Entity correspondence
The mapping between users, roles, and resource entities is described as follows
[ImG-38RUMFO9-1601285004617)(imgkr.cn-bj.ufileos.com/a330d167-78…)]
Users here for many, the corresponding relationship between character entity role relationship is same to the corresponding relationship between resources and so on the physical design increase user role entity between user and role, will be broken down into a many-to-many relation between one-to-many, similarly, split out the roles and resources many-to-many relation between entity object permissions entity in the middle.
Table structure design
From the analysis of the entity mapping relationship above, the permission table design is divided into the following five basic table structures: user table (T_USER), role table (T_ROLE), T_user_role (user role table), resource table (T_module), and t_permission table. The table structure relationship is as follows:
[Img-yxeWWXSM-1601285004617] [Img-yxeWWXSM-1601285004617]
| t_user | The users table | |||
|---|---|---|---|---|
| field | The field type | Field limits | The field | |
| A primary key | id | int(11) | Since the increase | The primary key id |
| user_name | varchar(20) | Is not empty | The user name | |
| user_pwd | varchar(100) | Is not empty | The user password | |
| true_name | varchar(20) | Can be null | Real name | |
| varchar(30) | Can be null | |||
| phone | varchar(20) | Can be null | The phone | |
| is_valid | int(4) | Can be null | Valid state | |
| create_date | datetime | Can be null | Creation time | |
| update_date | datetime | Can be null | Update time |
| t_role | Character sheet | |||
|---|---|---|---|---|
| field | The field type | Field limits | The field | |
| A primary key | id | int(11) | Since the increase | The primary key id |
| role_name | varchar(20) | Is not empty | The role of | |
| role_remarker | varchar(100) | Can be null | Role of note | |
| is_valid | int(4) | Can be null | Valid state | |
| create_date | datetime | Can be null | Creation time | |
| update_date | datetime | Can be null | Update time |
| t_user_role | User role table | |||
|---|---|---|---|---|
| field | The field type | Field limits | The field | |
| A primary key | id | int(11) | Since the increase | The primary key id |
| user_id | int(4) | Is not empty | The user id | |
| role_id | int(4) | Character id | Character id | |
| create_date | datetime | Can be null | Creation time | |
| update_date | datetime | Can be null | Update time |
| t_module | Resource table | |||
|---|---|---|---|---|
| field | The field type | Field limits | The field | |
| A primary key | id | int(11) | Since the increase | Resource id |
| module_name | varchar(20) | Can be null | Resource name | |
| module_style | varchar(100) | Can be null | Resource style | |
| url | varchar(20) | Can be null | Resource URL address | |
| parent_id | int(11) | Is not empty | Upper-layer Resource ID | |
| parent_opt_value | varchar(20) | Is not empty | Permission code of the upper-layer resource | |
| grade | int(11) | Is not empty | The hierarchy | |
| opt_value | varchar(30) | Can be null | Access code | |
| orders | int(11) | Is not empty | Order no. | |
| is_valid | int(4) | Can be null | Valid state | |
| create_date | datetime | Can be null | Creation time | |
| update_date | datetime | Can be null | Update time |
| t_permission | Permissions on the table | |||
|---|---|---|---|---|
| field | The field type | Field limits | The field | |
| A primary key | id | int(11) | Since the increase | The primary key id |
| role_id | int(11) | Is not empty | Character id | |
| module_id | int(11) | Is not empty | Resource id | |
| acl_value | varchar(20) | Is not empty | Access code | |
| create_date | datetime | Can be null | Creation time | |
| update_date | datetime | Can be null | Update time |
Module partition
Table structure design can be seen: there are three main tables (T_user, T_role, t_module), function is divided into three modules:
User management
-
Maintain basic user information
-
User Role Assignment
Role management
- Maintain basic role information
- Role authorization (assigning menus for roles to operate)
- Role authentication (Verifying the permissions of roles)
Resource management
- Resource Information Maintenance
- Menu output dynamic control
extension
Rbac-based extension – user groups
Based on the RBAC model, it can be extended to make it more suitable for our products. For example, add the concept of user groups, assign roles to user groups, and add users to user groups. In this way, the user has all the rights of the user group in addition to its own rights.
[ImG-0AKSGS8K-1601285004618)(imgkr.cn-bj.ufileos.com/c115fb92-66…)]
Here’s an example:
For example, we can view a department as a user group, such as sales department and Finance Department, and assign roles to the department so that all users in the department have department permissions. The concept of user group can easily authorize group users without affecting the role permissions that users already have.