Mp.weixin.qq.com/s/wepzIbJT1…

Source: cnblogs.com/iceblow/p/11121362.html

  • preface
  • 1. Permission model
  • 2. Authorization process
  • 3. The table structure
  • 4. Authority framework
  • 5. Conclusion

preface




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


Currently, I am in charge of the permission section of the company, so I am familiar with the design of the permission section. The company adopts the micro-service architecture, and the permission system is naturally independent. Other business systems include commodity center, order center, user center, warehouse system, small programs, several apps and more than a dozen systems and terminals.


1. Permission model




By far the most popular permission design model is RBAC model, role-based Access Control.


1.1 RBAC0 model

RBAC0 model is as follows:



This is the most basic and core model of permissions, which includes users/roles/permissions. Users and roles are many-to-many, and roles and permissions are many-to-many.


The userUsers who initiate operations can be classified into 2B and 2C users by type. They can be background management system users, OA system internal employees, or C-terminal users, such as Aliyun users.


roleEach role can be associated with multiple permissions. If a user is associated with multiple roles, the user has multiple permissions of multiple roles.


One might ask why users don’t associate permissions directly? In a system with a small user base, such as a small system with 20 people, the administrator can directly associate users with permissions. The workload is not large, so it is all right to select a user and check the required permissions.


However, in the actual enterprise system, the user base is relatively large, and many of them have the same permissions, which are ordinary access permissions. If the administrator grants authorization to 100 or more people, 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 can have all the permissions under the Role. In this way, the design not only improves efficiency, but also greatly expands.


permissionsResources accessible to users, including
Page permissions, operation permissions, data permissions:

  • Page permission: the page that a user can see after logging in to the system is controlled by the menu. The menu 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: is the function button on the page, including view, add, Modify, delete, and review. When the user clicks the delete button, the background verifies whether all permissions under the user role include the delete permission. If so, the user can proceed to the next step. Some system requirements “visible to operation”, meaning if the page can see the button operation, so the user can operate, in order to achieve this requirement, there is need to cooperate, the front-end front-end development of the user permission information cache, judge whether the user containing the permissions on the page, if you have, will display the button, if not, just hide this button. The user experience is improved to some extent, but it is optional to do so in real scenarios.
  • Data access: Data access is the user on the same page to see the data is different, such as the user data under the finance department can only see the department, purchasing department only look at purchasing data, in a few large companies, there are a lot of cities in China and branch, such as user login system can only see the data of hangzhou, hangzhou Shanghai users can only see the data, the solution is usually and the data For example, when the user is authorized, if the user chooses a role and binds to the organization such as finance Department or Hefei Branch, the user will have the data permission of finance Department or Hefei Branch under the role.



This is the core design and model analysis of RBAC, also known as RBAC0, which provides extended patterns based on the core concepts. Including RBAC1,RBAC2,RBAC3 models. These three types are described below


1.2 RBAC1 model



This model introduces the concept of Hierarchical Role, that is, roles have Hierarchical relationships. The Hierarchical relationships among roles can be divided into general and restricted Hierarchical relationships.


The general inheritance relationship only requires that the role inheritance relationship be an absolute partial order relationship, allowing multiple inheritance between roles. The restricted inheritance relationship further requires that the role inheritance relationship be a tree structure to achieve single inheritance between roles. This design can group and layer roles, which simplifies permission management to a certain extent.


1.3 RBAC2 model

On the basis of the core model, the role constraint control is carried out. The RBAC2 model adds the separation of responsibilities, which specifies the mandatory rules that should be followed when the rights are assigned to the role or the role is assigned to the user, and when the user activates a role at a certain moment.


Separation of dutiesIncluding static responsibility separation and dynamic responsibility separation. Mainly includes the following constraints:
  • Mutually exclusive role: A user can be assigned to only one role in a set of mutually exclusive roles, which supports the principle of responsibility separation. A mutually exclusive role refers to two roles whose rights restrict each other. For example, the financial Department has two roles, accounting and auditor, which are mutually exclusive, so users cannot have both roles, which reflects the principle of separation of responsibilities
  • Cardinality constraint: The number of users assigned to a role is limited. The number of roles a user can have is limited; The number of access permissions corresponding to a role should also be limited to control the allocation of advanced permissions in the system
  • Prerequisite role: To obtain a upper-level role, the user must obtain the lower-level role first

1.4 RBAC3 model

The most comprehensive permission management, based on RBAC0, RBAC1 and RBAC2 are integrated

1.5 user group

When the platform user base increases and role types increase, and some people have the same attributes, such as all the employees of the finance department, if the role is directly assigned to users, the workload of the administrator will be huge.


If the same user classification of attributes to a certain group of users, so the administrator directly assign roles to the user group, user groups in each user can have the role, after other users to join groups of users, can automatically get all the role of user groups, exit the user groups, at the same time also revoked the user role under the group, no administrator manual management role.


User groups can be classified into user groups with upstream and downstream users and common user groups based on the relationship between the upstream and downstream users:
  • User groups with a supervisor relationship: The most typical example is departments and positions, which most people probably don’t associate with user groups. User groups can be expanded, of course, department and position is often used in the internal management system, if it is for C of the system, such as taobao merchants, businessmen itself also has a set of organizational structure, such as purchasing department, sales department, customer service, logistics department, etc., some people have the authority of the service, some people hold on authority and so on, so the user groups can be expanded
  • Ordinary user groups: there is no hierarchy, and organization structure, position it doesn’t matter, that is to say, can cross department, cross position, for example, a certain electric business background management system, have spell group activity management role, we can set up a group of spell user group, the group can include r&d background developers, operations, operating personnel, purchasing personnel and so on.
Every company involves organizations and positions, and these two are highlighted below.


1.5.1 organization

The common organizational structure is as follows:



We can associate organizations with roles. After users join the organization, they will automatically acquire all roles of the organization without the administrator’s manual authorization, which greatly reduces the workload. Meanwhile, when users change positions, they only need to adjust the organization and their roles can be adjusted in batches.


Another function of an organization is to control data permissions. By associating a role with an organization, the role can see only the data permissions of the organization.


1.5.2 position

Assume the position of finance department as shown below:



There are multiple positions under each organization department. For example, the financial Department has director, accountant, cashier and other positions. Although they are all in the same department, each position has different authority, and the higher position has more authority. The director has all authority, and the accountant and cashier have some authority. In special cases, one person may wear more than one job.


1.6 Models with organization/position/user group

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





The many-to-many and one-to-one relationships may vary depending on the complexity of the system,
  • In the case of a single system and the user type single, users and organizations is a one-to-one relationship, organization and the position is a one-to-many relationship, the user and position is a one-to-one relationship, organization and role is a one-to-one relationship, the position and role is a one-to-one relationship, users and user groups is more on relationship, user groups and roles is a one-to-one relationship, of course, these relationships can also undertake adjustment according to the specific business The whole. Model design is not dead, if the small system does not need the user group, this can be removed.
  • Distributed system and user type single case, permission system will become very complicated here, here is introduced a concept of “system”, the system architecture is a distributed system, independent authority system, responsible for all the access control system, other systems such as center of commodities, orders for the center, the user center, each system has its own role and rights Limit, then the permission system can configure roles and permissions of other systems.
  • In the case of a distributed system with multiple user types, such as Taobao.com, its user types include internal users, businesses, ordinary users, internal users logging in to multiple background management systems, and businesses logging in to the business center. How should you design it as an architect? God can leave a message in the comments section!
2. Authorization process




Authorization is to grant roles to users. It can be divided into manual authorization and approval authorization. The permission center can be configured with both types to improve authorization flexibility.


  • Manual authorization: The administrator can log in to the rights center to authorize users in either of the following ways: Add a role to a user or add a user to a role. To add a role to a user, click a user to grant a role on the user management page. You can add multiple roles to a user at a time. To add users to a role, click a role on the role management page and select multiple users. In this way, users can be assigned roles in batches.
  • Approval and authorization: When a user applies for a role, the user applies for the role through the OA process and the role is approved by the superior. The user does not need to be manually granted the role by the system administrator.


3. The table structure




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


4. Authority framework




  • Apache Shrio
  • Spring Security
You can use one of these frameworks in your project, and their pros and cons and how to use them will be covered in more detail in a later article.

5. Conclusion




Permissions system is arguably the most foundation, the system can also be very complicated at the same time, in the actual project, will have multiple systems, multiple user types, multiple usage scenarios, which requires specific analysis, but the core RBAC model is the same, we can based on the extended to meet the demand.


Finally, if you find this article helpful, please click “like”. Thanks for your support!