Detailed Explanation of Authority System Design
Role-Based Access Control (RBAC for short) refers to the authorization of users' related permissions through their Role, which realizes flexible access control. Compared with granting users' permissions directly, RBAC is simpler, more efficient and extensible.
Problems and Present Situation of the Old Authority System
In the past, Zhuanzhuan Company did not have a unified authority management system. The authority management was developed by each business or used the authority system of other businesses. The disunity of authority management brought many problems:
Each business makes wheels repeatedly, which leads to high maintenance cost Each system only solves some scenario problems, the scheme is not universal enough, and there is no reliable authority management scheme when selecting new projects Lack of unified log management and approval process, it is very difficult to trace authorization information
Based on the above problems, the company started to build a unified authority system at the end of last year, with the goal of developing a flexible, easy-to-use and safe authority management system for all businesses.
Design mode of industry authority system
At present, there are two mainstream permission models in the industry, which are described below:
** Role-based access control (RBAC) ** ** Attribute-based access control (ABAC) **
RBAC model
** Role-Based Access Control (RBAC) ** refers to the flexible access control by authorizing users' related permissions through their Role, which is simpler, more efficient and extensible than granting users' permissions directly.
A user can have several roles, and each role can be assigned several permissions. Thus, the authorization model of "user-role-permissions" is constructed. In this model, there is a many-to-many relationship between users and roles, roles and permissions.
Describe it with a diagram as follows:
Schematic diagram of RBAC permission model
When using RBAC模型, users are given different roles based on their common responsibilities and needs by analyzing their actual situation. This relationship between 用户 \-> 角色 \-> 权限 allows us to get the required permissions from the granted roles instead of managing individual user permissions separately.
Take a simple scenario (Gitlab's permission system) as an example. There are three roles in the user system: Admin, Maintainer, and Operator. These three roles have different permissions. For example, only Admin has the permission to create and delete code repositories. If we grant a user the role Admin, he has both ** Create a code repository ** and ** Delete the code repository ** permissions.
Through RBAC模型, when there are multiple users with the same permission, we only need to create a role with the permission, and then assign different roles to different users. Later, we only need to modify the permissions of the roles, and then we can automatically modify the permissions of all users in the roles.
ABAC model
** Attribute-Based Access Control (ABAC) ** is a more flexible authorization model than RBAC模型. Its principle is to dynamically judge whether an operation can be allowed through various attributes. This model is widely used in cloud systems, such as AWS, Alibaba Cloud and so on.
Consider permission control in the following scenarios:
Authorize someone to edit a specific book When a document belongs to the same department as the user, the user can access the document When the user is the owner of a document and the status of the document is draft, the user can edit the document People from Department A are prohibited from accessing System B until 9:00 in the morning It is forbidden to access the A system as an administrator in places other than Shanghai Users have permission to operate on orders created before 2022-06-07
It can be found that the above scenario is difficult to achieve with RBAC模型, because RBAC模型 only describes what the user can do, but the conditions of the operation and the data of the operation, RBAC模型 itself does not have these restrictions. But this is precisely the advantage of ABAC模型. The idea of ABAC模型 is to dynamically calculate whether users have permission to operate based on users, attributes of accessed data and various environmental factors.
Principle of ABAC Model
In ABAC模型, whether an operation is allowed or not is determined by dynamic computation based on object, resource, operation and environment information.
** Object **: The object is the user currently requesting access to the resource. User attributes include ID, personal resource, role, department and organization membership, and so on ** Resources **: A resource is an asset or object to be accessed by the current user, such as a file, data, server, or even an API ** Operation **: An operation is what a user attempts to do to a resource. Common operations include "read", "write", "edit", "copy" and "delete" ** Environment **: The environment is the context of each access request. Environment attributes include time and location of access, device of object, communication protocol, encryption strength, and so on
During the execution of the decision statement of ABAC模型, the decision engine will dynamically calculate the decision result according to the defined decision statement and combining the factors such as object, resource, operation and environment. Whenever an access request occurs, the ABAC模型 decision system analyzes whether the attribute value matches the established policy. If there is a matching policy, the access request will be passed.
Design idea of new authority system
According to the business status of Zhuanzhuan, RBAC模型 meets most business scenarios of Zhuanzhuan, and the development cost is far lower than that of ABAC模型, so the new permission system is implemented based on RBAC模型. For the business system that can't be satisfied, we chose not to support it temporarily, which can ensure the rapid landing of the new permission system and make the business use faster.
The standard RBAC模型 completely abides by the link 用户 \-> 角色 \-> 权限, that is, the user's authority is completely controlled by the role he has, but this will have a disadvantage, that is, adding a role to the user's authority must lead to low efficiency in actual operation. Therefore, on the basis of RBAC模型, we have added the ability to directly add permissions to users, that is to say, we can add roles and permissions to users directly. End user permissions are a combination of owned roles and permission points.
** Permission Model of New Permission System **: User final permissions = permissions brought by the role owned by the user + permissions independently configured by the user, which are combined.
The new permission system scheme is as follows:
New authority system scheme
First of all, all users of the group (including external users) are managed uniformly through the function of ** Unified login and registration **, and at the same time, they are connected with the organizational structure information module of the company, thus realizing the consistency of information of the same person in all systems, which also provides feasibility for subsequent authority management based on organizational structure. Secondly, because the new authority system needs to serve all the business of the group, it needs to support multi-system authority management. Before the user carries on the authority management, needs to select the corresponding system first, then configures the ** Menu permissions ** and ** Data permissions ** information of the system, establishes each authority point of the system. _ PS: Specific description of menu permissions and data permissions, described in more detail below. _ Finally, create different roles under the system, and configure permission points for different roles. For example, the role of store manager has the operation authority of shop assistant and the data viewing authority of our store. After configuring this role, it is only necessary to add this role to the store manager in the future, so that he can have the corresponding authority.
After the above configuration is completed, the user's rights management can be carried out. There are two ways to give users permissions:
Select the user first, and then add permissions. This method can add any role or menu/data permission point to users. Select roles first, and then associate users. This method can only add roles to users, and cannot add menu/data permission points separately.
The specific design schemes of these two methods will be explained in detail later.
Authority management of authority system itself
For the permission system, it is necessary to design the permission management of the system itself first, that is, to manage "who can enter the permission system and who can manage the permissions of other systems". For the users of the permission system itself, they can be divided into three categories:
** Super administrator **: You have all the operation permissions of the permission system, and you can perform any operation of the system itself, and you can also manage the management operations of the application system with access permissions. ** Permission operation user **: A user with a super administrator role for at least one connected application. The operations that the user can perform are limited within the scope of the application system authority. Permission operation user is an identity, which does not need to be assigned, but is automatically obtained according to rules. ** Ordinary users **: Ordinary users can also be considered as an identity, except for the above two categories of people, the rest are ordinary users. They can only apply for access to the system and access to the permission application page.
Definition of permission type
In the new permission system, we divide permissions into two categories, namely:
** Menu function permissions **: Includes directory navigation for the system, access to menus, and permissions for buttons and API operations ** Data permissions **: Includes query scope permissions that define data. In different systems, it is usually called "organization", "site", etc. In the new permission system, it is uniformly called "organization" to manage data permissions
Classification of default roles
Three default roles are designed in each system to meet the basic rights management requirements, as follows:
** Super administrator **: This role has all the permissions of the system, can modify the configuration such as role permissions of the system, and can authorize other users. ** System administrator **: This role has configuration capabilities such as authorizing other users and modifying role permissions on the system, but the role itself does not have any permissions. ** Authorized administrator **: This role has the ability to authorize other users. However, the scope of authorization does not exceed the authority you have.
For example: Authorized administrator A can add permissions to user B, but the added range is less than or equal to the permissions that user A already has.
After this distinction, ** Have permissions ** and ** Have the ability to authorize ** are separated, which can satisfy all the scenarios of permission control.
Design of Core Module of New Authority System
The overall design idea of the new authority system is introduced above, and the design of the next core module is introduced respectively
System/menu/data rights management
There are the following steps to access a new system to the permission system:
Create a system Configure menu function permissions Configure data permissions (optional) Create the role of the system
Among them, steps 1, 2 and 3 are all completed in the system management module, and the specific flow is as follows:
System access flow chart
Users can add, delete, modify and check the basic information of the system, and the only distinction between different systems is 系统编码. At the same time, 系统编码 will also be used as a prefix for menu and data permission coding, which ensures the global uniqueness of permission coding.
For example, if the encoding of the system is test_online, the menu encoding format of the system is test_online:m_xxx.
The system management interface is designed as follows:
System management interface design
Menu management
The new permission system first categorizes menus as 目录, 菜单 and 操作, as shown in the following figure
Menu management interface
They respectively represent the following meanings:
** Directory **: Refers to the top level directory in the application system, usually to the right of the system Logo ** Menu **: Refers to the multi-level menu on the left side of the application system, usually below the system Logo, and is also the most commonly used menu structure ** Operation **: Refers to a series of parts of a page that can be defined as actions or page elements, such as buttons, interfaces, etc.
The menu management interface is designed as follows:
Design of menu management interface
There are also two ways to use menu permission data:
** Dynamic menu mode **: In this mode, additions and deletions of menus are completely taken over by the permissions system. That is to say, if the menu is added to the permission system, the application system will increase synchronously. The advantage of this mode is that modifying menus does not require items to go online. ** Static menu mode **: The addition and deletion of menus is controlled by the front end of the application system, and the permission system only controls the access rights. In this mode, the permissions system can only identify whether the user has the permissions of the current menu, and the specific display control is determined by the front-end according to the permissions data.
Role and user management
Role and user management are the core modules that can directly change user rights. The whole design idea is as follows:
Role and User Management Module Design
The key point of this module design is to consider batch operation. Whether associating users through roles or adding/deleting/resetting permissions to users in batches, the scene of batch operation needs to be designed by the system.
Authority application
In addition to adding permissions to other users, the new permissions system also supports users to apply for permissions independently. In addition to the conventional approval process (application, approval, viewing), this module has a special function, that is, how to let users choose the permissions they want. Therefore, in the design of this module, in addition to directly selecting roles, it also supports reverse selection of roles through menu/data permission points, as shown in the following figure:
Permission application interface
Operation log
System operation logs can be divided into two categories:
** Operation pipelining log **: User-viewable and searchable log of key operations ** Service Log Log **: Log logs generated during the running of system services, in which the information amount of service Log is larger than that of operation pipeline Log, but it is inconvenient to search and view. Therefore, the permission system needs to provide the function of operation pipelining log.
In the new authority system, all the operations of users can be divided into three categories, namely, adding, updating and deleting. All modules can also be enumerated, such as user management, role management, menu management and so on. After clarifying this information, a log can be abstracted as: Who\ (Who) at what time\ (When) did what to which modules of Who\ (Target). In this way, all the records are put into storage, and it is convenient to view and filter the logs.
Summary and prospect
So far, the core design ideas and modules of the new authority system have been introduced and completed. The new system has a large number of business access and use inside the transfer, and the authority management is much more convenient than before. As a basic system of each company, the flexible and complete design of authority system can help the future business development to be more efficient.
The following two articles:
[Design and Implementation of Unified Authority System (Backend Implementation)] (http://bbs.tamanyuan.top) [Design and Implementation of Unified Authority System (Front-end Implementation)] (http://bbs.tamanyuan.top)
Reference
Select the appropriate permission model: https://docs.authing.cn/v2/guides/access-control/choose-the-right-access-control-model.html
评论区