RBAC rights management system: things from business flow to data flow to prototype display

After working on B-end products for so long, the biggest feeling is that B-end products have complex business relationships. Everything is forewarned, so before planning the function of a module, we need to sort out the business relationship inside the module. In this article, I will take the most mature background management system of the ERP system as an example, starting from the top-level business analysis, then going to the underlying data relationship, and finally explaining it through the prototype.

1. Business process

ERP system, Enterprise Resource Planning, enterprise resource planning. As the name suggests, first of all, what are the enterprise resources? We have seen Kingdee, UFIDA, SAP and other ERP systems, when the system is deployed, the implementation consultant will always mention one word first: background management system. The background management system is also used by users. When it comes to the background management system, there must be a word called authority. Rights management is mainly to avoid the problem of data leakage caused by lack of rights control. So, the problem we need to solve is:

Which user in which department has which permissions?

To solve this problem, we have to mention a model: RBAC (Role-Based Access Control) permission control model
Therefore, we need to focus on three key words: user, role, and permission.

A background management system can basically abstract six tables about users, roles, and permissions:

1. Department table; a company can have multiple departments;
2. User table; a user can belong to multiple departments;
3. Role table; a system has multiple roles, which are generally divided into system administrator administrator and ordinary user user;
4. User-role table; user-role table, that is, a user can have multiple roles, storing the mapping relationship between users and roles;
5. Permission table; permissions are divided into page permissions, data permissions, and operation permissions;
6. Role-permission table; which page permissions, data permissions, and operation permissions each role can have.

When it comes to departments, there is actually a concept called user group . When there are many users, it will be very troublesome for us to assign roles to each user individually. All users under a department can be granted a role.

2. Data flow

In the previous part, we analyzed the business and main functions of each step. In this step, we mainly analyze the flow of underlying data. For clarity, this part directly uses Navicat for ER modeling.

It is recommended that every B-end product manager learn about UML modeling tools, which is very helpful for business analysis at work.

Each table is very similar, mainly id and name. In particular, the sys_role_user table, uid and rid are respectively associated with the sys_user table and the sys_role table by establishing foreign keys. Similarly, the sys_role_permission role permission table is also established through foreign keys.

PS: As a product manager, you only need to understand that permissions are realized through the underlying six tables, and you don't need to pay attention to specific database operations. But as a developer, you must understand how each table is built and abstract the database model from the product business.

3. Functional Prototype

According to the previous analysis, we first sort out the mind map of the entire background authority management system:

1. Organizational management
   Organizational management is mainly to build the company's organizational structure, B-end products, especially large ERP systems, etc., the first thing is to solve the company's organizational structure. It involves the bottom layer, which is the department table we mentioned earlier. (sys_dept)
2. Personnel management
   Organizational management To establish a hierarchical relationship between departments, it is necessary to introduce employee information. It involves the bottom layer, which is the personnel table we mentioned earlier. (sys_user)
3. Rights management
   Rights management is mainly divided into three categories: organization administrator authorization, role authorization, and user direct authorization.
   (1) For large companies, organization administrator authorization, that is, department leader authorization;
   (2) role authorization, that is, user-associated roles, and unified authorization to a certain role; (sys_role_user);
   (3) direct user authorization, for company scale Smaller, users can be directly authorized.

Permissions are mainly divided into:
function permissions, field permissions, and data rules. That is, the page permissions, data permissions, and operation permissions we mentioned earlier.

4. The license manages
   the B-end system, and the usage is limited. General companies will sell licenses. In layman's terms, how many permissions can log in to the system.
   Assignment of rights and assignment of permissions are indispensable.
   Permission allocation: users can log in to the system with their account and password;
   authority allocation: after login, what functions can be used depends on the authority assigned to the user by authority management.

Login Page

Home

The prototype here only shows a navigation, and the specific prototype content is not displayed one by one.

This blog post briefly analyzes how the RBAC permission management model is implemented in actual business. Any ideas are welcome to discuss.