Shulou(Shulou.com)05/31 Report--

This article mainly introduces the relevant knowledge of how to design a database permission system, the content is detailed and easy to understand, the operation is simple and fast, and has a certain reference value. I believe you will gain something after reading this article on how to design a database permission system. Let's take a look.

Preface to the design of authority system

Rights management is an important part of all background systems, the main purpose is to control the access of different people to resources, and to avoid risk problems caused by lack of permission control or improper operation, such as operation errors, privacy data disclosure and other problems.

1. Authority model

By far the most popular privilege design model is the RBAC model, role-based access control (Role-Based Access Control).

1.1 RBAC-0 model

RBAC-0 model

RBAC-0 model is the most basic and core model of permissions, which includes users / roles / permissions, in which users and roles are many-to-many, roles and permissions are also many-to-many.

Users are the main body of the initiating operation, which can be divided into 2B and 2C users by type. They can be users of the background management system, internal employees of the OA system, or C-side users, such as Aliyun users.

The role acts as a bridge, connecting the relationship between users and permissions, each role can be associated with multiple permissions, and a user can associate multiple roles at the same time, then the user has multiple permissions for multiple roles.

Some people may ask why users don't directly associate permissions. In a system with a small user base, such as a small system with 20 people, administrators can directly associate users with permissions, and the workload is not heavy. Just select a user and check the required permissions.

But in the actual enterprise system, the user base is relatively large, and many of them have the same permissions, which is a common access right. If the administrator gives 100 people or more authorization, the workload will be huge.

This introduces the concept of "Role". A role can be associated with multiple users, and the administrator only needs to assign the role to the user, so that the user has all the permissions under the role. This design not only improves efficiency, but also has great expansibility.

Permissions are resources that users can access, including page permissions, operation permissions, and data permissions:

Page permissions: that is, the page that the user can see when logging in to the system, which is controlled by the menu, which includes the first-level menu and the second-level menu. As long as the user has the permission of the first-level menu and the second-level menu, the user can access the page.

Operation permissions: that is, the function buttons of the page, including view, add, modify, delete, audit, etc., when the user clicks the delete button, the backend will verify whether all permissions under the user role include the deletion permission. If so, you can proceed to the next step, otherwise prompting you to have no permissions. Some systems require "visible operation", which means that if the action button can be seen on the page, then the user can operate. To achieve this requirement, the front-end needs to cooperate, and the front-end development caches the user's permission information. Determine whether the user contains this permission on the page, if so, display the button, if not, hide the button. It improves the user experience to some extent, but you can choose whether or not to do so in the actual scenario.

Data permissions: data permissions means that users see different data on the same page. For example, the Finance Department can only see the user data under its department, and the Purchasing Department only looks at the data of the Purchasing Department. In some large companies, there are many cities and branches across the country. For example, users in Hangzhou can only see data from Hangzhou while users in Shanghai can only see data from Shanghai. The solution is generally to associate data with specific organizational structure.

For example, when authorizing a user, the user selects a role and binds an organization such as Finance Department or Hefei Branch, then the user has the data rights under that role under the Finance Department or Hefei Branch.

Users, roles and permissions

This is the core design and model analysis of RBAC, also known as RBAC-0, and based on the core concepts, RBAC also provides an extension pattern. Including the RBAC-1,RBAC-2,RBAC-3 model. These three types are described below

1.2 RBAC-1 model

Image

This model introduces the concept of role inheritance (Hierarchical Role), that is, roles have superior-subordinate relationship, and the inheritance relationship between roles can be divided into general inheritance relationship and restricted inheritance relationship.

The general inheritance relationship only requires that the role inheritance relationship is an absolute partial order relationship, which allows multiple inheritance between roles.

The restricted inheritance relationship further requires that the role inheritance relationship is a tree structure to realize the single inheritance between roles. This design can group and layer roles and simplify the work of privilege management to a certain extent.

1.3 RBAC-2 model

Based on the core model, the role constraint control is carried out, and the responsibility separation relationship is added to the RBAC2 model.

It specifies the mandatory rules that should be followed when permissions are assigned to roles, or when roles are given to users, and when users activate a role at a certain time.

The separation of responsibility includes static separation of responsibility and dynamic separation of responsibility. It mainly includes the following constraints:

Mutually exclusive roles: the same user can only be assigned to at most one role in a set of mutually exclusive roles, supporting the principle of separation of responsibilities. Mutually exclusive roles refer to two roles whose respective permissions restrict each other. For example, the finance department has two roles: accountant and auditor, and they are mutually exclusive roles, so users cannot have these two roles at the same time, which embodies the principle of separation of responsibilities.

Cardinality constraints: the number of users assigned to a role is limited; the number of roles a user can have is limited; the number of access rights corresponding to a role should also be limited to control the allocation of advanced permissions in the system.

Prerequisite role: that is, if a user wants to obtain a superior role, he or she must first obtain the role at the next level.

1.4 RBAC-3 model

The most comprehensive rights management, which is based on RBAC-0, integrates RBAC-1 and RBAC-2.

1.5 user groups

When the user base of the platform increases and the types of roles increase, and some people have the same attributes, such as all the employees in the finance department, if the users are assigned roles directly, the workload of the administrator will be very large.

If users with the same attributes are classified into a user group, the administrator directly assigns a role to the user group, and each user in the user group can have the role. After other users join the user group, you can automatically obtain all roles of the user group and exit the user group. At the same time, the roles under the user group are also revoked, without the need for the administrator to manage the roles manually.

According to whether the user group has a superior-subordinate relationship, it can be divided into superior and subordinate user groups and ordinary user groups:

User groups with superior and subordinate relationships: the most typical examples are departments and positions, perhaps most people do not associate departmental positions with user groups. Of course, user groups can be expanded, departments and positions are often used in internal management systems, if they are C-side-oriented systems. For example, the merchants on Taobao have their own organizational structure, such as purchasing department, sales department, customer service department, logistics department, etc., some people have customer service authority, some people have access to shelves, and so on, so the user group can be expanded.

Ordinary user group: that is, there is no relationship between superiors and subordinates, and it has nothing to do with organizational structure or positions, that is to say, it can be cross-departmental and cross-position. For example, an e-commerce background management system has a group purchase activity management role, we can set up a group purchase user group, which can include the background developers of the R & D department, the operation staff of the operation department, the personnel of the procurement department, and so on.

Each company will be related to the organization and position, the following focus on these two.

1.5.1 Organization

Common organizational structures such as

We can associate the organization with roles, and after users join the organization, they will automatically get all the roles of the organization without the need for the administrator to grant them manually, which greatly reduces the workload. At the same time, users only need to adjust the organization when they are transferred. Roles can be adjusted in batches.

Another role of an organization is to control data permissions and associate roles with the organization, so that the role can only see the data permissions under that organization.

1.5.2 position

Assume a position in the finance department

There will be multiple positions under each organizational department, such as director, accountant, cashier and other positions in the finance department, although they are all in the same department, but the authority of each position is different, the higher position has more authority.

The director has all authority, and the accountant and cashier have partial authority. Under special circumstances, one person may have more than one job.

1.6 Model with organization / position / user group

Based on the above scenario, a new permission model can be designed, as shown below:

Organization / position / user group

Many-to-many and one-to-one relationships may change depending on the complexity of the system.

In the case of a single system and a single user type, there is an one-to-one relationship between user and organization, one-to-many relationship between organization and position, one-to-one relationship between user and position, one-to-one relationship between organization and role, one-to-one relationship between position and role, many-to-one relationship between user and user group, one-to-one relationship between user group and role, of course, these relationships can also be adjusted according to specific business. Model design is not dead, and this piece can be removed if the mini system does not require user groups.

In the case of a distributed system and a single type of user, the permission system will become very complex, so a concept of "system" is introduced here. At this time, the system architecture is a distributed system, and the permission system is independent, which is responsible for the permission control of all systems. Other business systems, such as commodity center, order center, and user center, each have their own roles and permissions. Then the permission system can configure the roles and permissions of other systems.

In the case of a distributed system and multiple user types, such as Taobao, its user types include internal users, merchants, ordinary users, internal users logging in to multiple background management systems, and merchants logging in to the merchant center, which do access control. If you are an architect, how do you design it? God can leave a message and communicate in the comment area.

two。 Authorization process

Authorization is to grant roles to users, which can be divided into manual authorization and approval authorization according to the process. The permission center can configure both of them at the same time, which can improve the flexibility of authorization.

Manual authorization: the administrator logs in to the permission center to authorize the user, which can be divided into two ways according to which page to authorize: add a role to the user and add a user to the role. To add a role to a user is on the user management page, click a user to grant a role, and you can add multiple roles for the user at a time; to add a user to a role is to click a role and select multiple users on the role management page. Achieve the purpose of granting roles to a batch of users.

* * approval authorization: * * that is, if a user applies for a job role, the user can apply for the role through the OA process and then be approved by the superior, and the user can have the role without the need for the system administrator to grant the role manually.

3. Table structure

With the above permission model, it is not difficult to design the table structure. The following is the table structure under multi-system. The simple design mainly provides ideas:

4. Permission framework

Apache Shrio

Spring Security

This is the end of the article on "how to design a database permission system". Thank you for reading! I believe that everyone has a certain understanding of the knowledge of "how to design a database permission system". If you want to learn more knowledge, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.