The permissions model

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

RBAC0 model

This is the most basic and core model of permissions, including users/roles/permissions, where users and roles are many-to-many relationships, and roles and permissions are many-to-many relationships.

  • Users initiate operations and 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.

  • A role serves as a bridge between users and rights. Each role can be associated with multiple rights. If a user is associated with multiple roles, the user has multiple rights of multiple roles.

The reason why the role is added

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.

Type of the permission resource

A permission is a resource that a user can access, including page permission, operation permission, and data permission:

  • 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 permission: function buttons on the page, including view, add, modify, delete, and review. When a user clicks the delete button, the background verifies whether all permissions under the user role include the delete permission. If yes, the user can proceed to the next step.

    • Some system requirements “visible” to operation, which means if can see action button on a page, 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, can display the button; If not, hide the button. The user experience is improved to some extent, but it is optional to do so in real scenarios.

  • Data permissions: Data permissions mean that the user sees different data on the same page. For example, there are many cities and branches in the country. For example, the user login system in Hangzhou can only see the data in Hangzhou, and the user login system in Shanghai can only see the data in Shanghai. The solution is generally to associate the data with the specific organizational structure

    • For example, when the user is authorized again, if the user chooses a role and binds to the organization such as finance Department or Hefei Branch, the user will have the data rights of the 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

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.

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 responsibilities includes static separation of responsibilities and dynamic separation of responsibilities, mainly including the following constraints:

  • Mutually exclusive roles: A user can be assigned to only one role in a set of mutually exclusive roles, which supports the principle of responsibility separation.

    • Mutually exclusive roles refer to two roles whose rights restrict each other. For example, the financial Department has two roles, accounting and auditor, which are mutually exclusive roles. Therefore, users cannot have the two roles at the same time, which reflects the principle of duty separation.

  • Cardinality constraints: Limits on the number of users assigned to a role; 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 an upper-level role, a user must obtain the lower-level role.

RBAC3 model

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

User groups

Increasing of platform when user base and character types, and some people have the same properties, such as all the staff of the finance department, if directly assign roles to users, the administrator’s workload is very big, 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 are added to a user group, they can automatically obtain all the roles in the user group and exit the user group. At the same time, the roles in the user group are revoked. The administrator does not need to manually manage the roles.

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.

Models with organizations/jobs/user groups

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 a single user type, there is a one-to-one relationship between users and organizations, a one-to-many relationship between organizations and positions, and a one-to-one relationship between users and positions. There are one-to-one relationships between organizations and roles, one-to-one relationships between positions and roles, one-to-one relationships between users and user groups, and one-to-one relationships between user groups and roles. Of course, these relationships can be adjusted based on specific services. 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.