Shulou(Shulou.com)06/02 Report--

This article shows you how to use the RBAC model to design a permission system, the content is concise and easy to understand, can definitely make your eyes bright, through the detailed introduction of this article, I hope you can get something.

Preface

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.

At present, the company is in charge of authority, so I am familiar with the design of authority. The company adopts micro-service architecture, so the authority system is naturally independent. Other business systems include commodity center, order center, user center, warehouse system, Mini Program, multiple APP and more than a dozen systems and terminals.

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 RBAC0 model

The RBAC0 model is as follows:

This is the most basic and core model of permissions, which includes users / roles / permissions, in which users and roles are many-to-many, and 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 you will be prompted to have no permission. 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 the data that users see on the same page is different. 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, Hangzhou users can only see Hangzhou data when logging into the system, while Shanghai users can only see Shanghai data. The solution is generally to associate data with a specific organizational structure. For example, when a user is authorized, the user chooses a role to bind to an organization such as Finance Department or Hefei Branch. Then the user has the data rights under the Finance Department or Hefei Branch under that role.

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 RBAC2 model

Based on the core model, the role constraint control is carried out, and the responsibility separation relationship is added to the RBAC2 model, which specifies the mandatory rules that should be followed when the permission is assigned to the role, or when the role is given to the user, and when the user activates 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 RBAC3 model

The most comprehensive rights management, which is based on RBAC0 and integrates RBAC1 and RBAC2

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 employees in the finance department, if they directly assign roles to users 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, they can automatically obtain all the roles of the user group and exit the user group. At the same time, the roles under the user group are revoked, and there is no 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 it is a C-side system, such as Taobao merchants, merchants also have a set of 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 user groups 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 or cross-position.For example, an e-commerce background management system has a group buying activity management role. we can set up a group buying user group, which can include the backstage developers of the R & D department, the operators 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 organizational structure

Common organizational structures are shown in the following figure:

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:

4. Permission framework

Apache Shrio

Spring Security

Permission system can be said to be the most basic and complex in the whole system. In the actual project, we will encounter multiple systems, multiple user types, and multiple use scenarios, which requires specific analysis of specific problems, but the core RBAC model is unchanged, we can expand on it to meet the needs.

Finally, if you think this article is helpful to you, you can like it. Thank you for your support.

The above content is how to use the RBAC model to design a permission system, have you learned the knowledge or skills? If you want to learn more skills or enrich your knowledge reserve, 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.