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
email varchar(30) Can be null email
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.