User management is the necessary management background of each product, the most basic user management as long as there are two functions of adding and deleting accounts is enough. But once users start to grow and permissions become a little more complex, we need to think hard about the logic of how users manage permissions. Avoid creating deep holes that can’t be solved if future users suddenly grow.

If you’re just looking for the source code for the user management system, go to the conclusion section at the end of the article.

1. Basic rights management system – simple and clear but can not bear complex requirements

The design of the basic permission system generally starts from the two latitude of “user-permission”, and the administrator needs to define the permission separately for each user.

The figure above shows the synology server permission setting background. Each time a new access account is added to the server, the administrator needs to configure the permission table. If the number of users in the system is dozens of up and down, the permission change is not too much, the “user – permission” permission management logic is simple and clear, very easy to use. But when the number of users in the system begins to increase, reaching thousands, tens of thousands, the limitations of this management method is exposed.

Permission design based on RBAC model – Introduce the concept of role

When the number of users reaches a certain scale, the administrator needs to modify the permissions of a group of users. In the user-permission model, it is almost impossible to do this manually. At this point, we introduce the concept of roles between users and permissions. Change the relationship between users and rights to user role association, and assign user rights in the mode of user – role – Rights association.

The advantage of introducing roles is to visualize abstract permissions. We only need to think about what permissions should be granted to each role, and then point the corresponding user to the role to complete account authorization.

1. Overview of RBAC permission model

The permission logic of “user-role-permission” is the role-based Access Control (RBAC) permission model commonly used in the industry. The core of the system is to introduce the concept of role. The role is used as the medium to make the user and permission configuration more flexible.

2. Advantages of the RBAC permission model

(1) The abstract authority is visualized, and the abstract problem is no longer considered when distributing the authority limit.

For example, a newly hired junior sales person, Xiao Zhang, opens an account with the administrator. The administrator does not need to decide whether to give Xiao Zhang the right to “view the sales volume of the department”, but only needs to direct his account to the role of “junior sales person”, which has been defined for a long time.

(2) Adjust permissions in batches

For example, sometimes the administrator authorizes the user of a certain attribute to view the data of a new service module. For example, the new live streaming function of the company requires that the operation group can operate the background of live streaming. In this case, the administrator only needs to modify the permission of the role “Operation” and then modify the account permissions of all members of the operation group.

3. Multiple application scenarios of RBAC permission model

The clear and simple management logic of RBAC permission model is well reflected in practical application. Next, we will understand the logical thinking of this permission architecture through specific examples.

(1) RBAC basic type: “user-role-Permission”

The basic concept of RBAC is user – role – permission. In this model, the relationship between users and roles, roles and permissions is many-to-many, and the user’s permissions are the sum of the permissions of all the roles to which the user belongs. User management for most products is well controlled using the RBAC basic model.

For example, Xiao Wang is the cashier of the financial department and also responsible for the storage and inventory of goods. So let’s start by creating two roles, finance cashier and Warehouse manager. Roles are very tangible and can be easily granted by administrators. Then give wang’s account to these two identities, Wang in the system to obtain the corresponding permission. The permission model logic is simple and clean.

(2) Enter the RBAC model of “level” concept – “user – role [level] – permission”

The concept of “hierarchy” is introduced, where roles have a hierarchy within them. Each level has different permissions. A higher level is backward compatible with the permissions of a lower level. That is, a higher level contains all the permissions of a lower level in a role. The introduction of the concept of “level” makes the distribution of permissions more granular.

For example, not everyone in the same department should have access to department-wide data. Therefore, we introduce the concept of “level” at this time. The department head can view the data of the whole department, the group leader of each department can only view the data of his own group, and the group members can only see their own data.

(3) user – Role [Level] – Rights [Restrictions]

In the permission control, for the sake of system security and logical flow, we not only give the account rights, but also restrict the account at the system level.

  • Roles mutex

    In some business processes, the front and back roles are check relationships, and if the same person serves as the front and back check roles at the same time, the system process may have security vulnerabilities. For example, the purchaser and the financial auditor, the purchaser declares the purchase plan, the financial auditor verifies the purchase plan. If the two characters are the same person, he can both submit and get his application approved. Then the meaning of audit is lost. At this point, we should limit procurement and financial audit to mutually exclusive roles in the system, with different roles owned by the same account at the same time.

  • Role cardinality constraint

    In the system, there are special roles that can only be filled by one person for security or liability reasons, so we want to limit the number of users for such roles to a limited number. For example, the authority administrator or department head can not be held by multiple users, only one can be removed, and then add another. Only in this way can we ensure the security of the system and the stability of the process.

  • A multi-role user can use only one role at the same time

Sometimes different roles have conflicting data or operations on the same interface. In this case, we need to limit the user to only one identity at a time. This can avoid a lot of unnecessary trouble.

The application of RBAC permission management in the actual system

RBAC permission model consists of three parts: user management, role management and permission management. User management is divided according to enterprise architecture or line of business architecture. These architectures are clear, extensible, and readable. Role management must be designed after a deep understanding of the business logic. It is generally based on the real roles of each department and then extended according to the business logic. Permission management is the reinforcement of the first two kinds of management, do too fine easy too debris, do too thick and not safe, here we need to design according to experience and actual situation.

1. User management

The user in user management is every employee in the enterprise. They have their own organizational structure. We can directly use the enterprise department architecture or business line architecture as the clue to build the user management system.

2. Role management

When designing system roles, we should have a deep understanding of the corporate architecture, the business architecture, and then design the roles and the levels within the roles according to the requirements. The general role is relative to the user is fixed, each role has its own clear permissions and restrictions, these permissions are determined in the system design, and then will not change easily.

(1) Automatically acquire base roles

When an employee joins a department, the employee’s account is automatically added to the basic role of the department and has the corresponding basic rights. This operation is to ensure system security and reduce a large number of manual operations by the administrator. Enable new employees to use the system quickly and improve work efficiency.

(2) Temporary role and expiration time

They are not part of the company and are only there to support the company at a certain time. At this point, we need to set up temporary roles to deal with the temporary employees who may work across multiple departments.

If the security level of the company is high, such an account has a fixed expiration time by default. When the expiration time reaches, you need to review the account again before restarting it. Avoid temporary accounts forgotten in the system due to the imperfect process, causing security risks.

(3) Virtual role

A level in a department role can grant the same permission to employees at the same level. However, some employees need to invoke the rights other than the role level for work reasons. Different employees at the same level have different permissions. This is beyond the level of the character and reasonable permissions granted, we can set the virtual character. This avatar integrates all the permissions needed to do the job, and then assigns it to a specific employee. In this way, you do not need to adjust the organizational structure and corresponding roles, and you can also meet the permission requirements of special situations at work.

(4) Black and white list

  • Whitelist: Some users do not own the top roles in a department, but need to be granted high-level rights outside the roles due to business requirements. In this case, you can design a whitelist and add the required users to the whitelist. In the security process, we only need to design the security process for the white list to audit the special users in the white list, so as to monitor the users with special rights and reduce security risks.
  • Blacklisting: A common blacklisting scenario is when an employee who has made a mistake is still on the job, but can no longer be given any company privileges. In this case, you cannot cancel the role association or disable the account completely. In this case, you can set a blacklist to enable the user to log in to the account and view basic information. However, most of the key rights of the user are restricted by the blacklist.

3. Rights management

Permission management is generally restricted from three aspects. Page/menu permissions, operation permissions, data permissions.

(1) Page/menu permission

For users who do not have permission to operate, the corresponding page entry or menu option is directly hidden. This approach is simple, quick, and straightforward, and is very efficient for permissions that are less security-sensitive.

(2) Operation rights

Operation permission refers to whether different users can add, delete, modify and check the same set of data. Read-only browsing data for some users, editable data for others.

(3) Data permission

For the high security requirements of the rights management, only from the front limit hidden menu, hide the edit button is not enough, but also need to do restrictions on the number of interfaces. If a user attempts to illegally edit data that is not under his or her permission, the server recognizes, records, and restricts access.

Four, user management system authority design in more practical details

1. Super administrator

The super administrator is an account used to start and configure the system. This account should be hidden after the system is configured and the administrator is created. The super administrator account has all permissions in the system and can check the data of various departments. Improper use of the super administrator account may cause security risks in system management.

2. How to handle mutually exclusive roles

If a useful role and a role to be added are mutually exclusive, a message is displayed indicating that the administrator cannot add a new role because the roles are mutually exclusive. To add a role, cancel the previous role before adding a new role.

3. User management permission system design must be simple and clear

In the design of the permission system, must clear the thinking, everything is simple, can not add redundant roles and permission logic, must not add. Because with the expansion of the company’s business, the rights and roles will also increase, if the initial design ideas are not rigorous, the rights system will be infinitely chaotic with the expansion of the business, then it is too late to sort out the rights. So the initial design must be clear, simple and clear, can avoid the subsequent very much unnecessary trouble.

4. No prompt page

Sometimes employee A will directly share the page he is working on with employee B, but employee B may not have the right to view it. At this point we should consider adding an “unauthorized prompt page” here to avoid a rude 404 page that employee B thinks is a system error.

How to quickly build a user management system

User rights management system, although the design is complex, but as long as the logical product, page design is completed, the use of hand tools, soon can complete the construction and deployment of the management system.

I recommend you try the Karacloud, which is a set of tools that help back-end programmers solve problems like database access, API calls, and front-end components that can be dragged and dropped to quickly build an internal enterprise.

I used Karayun to build a set of user rights management system according to the ideas of this article, which took only one day. I have generated the user management system built in Karayun into a template. You only need to register with Karayun for free, and then you can quickly copy my template to your account, apply it immediately, access your own data, and complete the deployment.

Karat Cloud can easily access common databases and apis, and data interconnection can be completed with simple configuration.

Vi. Extended data

1. Quickly build the user management system back-end tool – Karayun

2. Common permission system model

  • Access Control List (ACL) Permission Control List
  • Role-based Access Control (RBAC) Role-based permission Control
  • Attribute-based Access Control (ABAC) Indicates attribute-based permission Control
  • Policy-based Access Control (PBAC) Indicates policy-based Access Control

3. RBAC model document proposed by George Mason University

Vii. The author of this article

Jiang Chuan, co-founder of Kalayun, B-side product manager, focuses on the implementation and construction of enterprise internal efficiency tools

Personal wechat: HiJiangChuan, welcome to communicate with me on wechat.