1. The meaning of authority management
Ensure safety: avoid misoperation, man-made sabotage, data leakage, etc.
Data isolation: Different permissions can see and operate different data without interfering with each other.
Clear responsibilities: different roles handle different affairs, refine responsibilities, standardize and simplify processes.
Second, the general design idea of the authority management system
A subject (subject ie user) of an object (object that is, resources) need to implement some sort of operation (operation), the system management control of such operations is access control.
1. Permission classification
- Operation Permission
API Permission
Menu Permission
Button Permission - data permission
The so-called operation authority is whether the user has the authority to perform a certain operation, such as whether you can approve your attendance. The specific manifestation is whether the user can see a certain menu or button, and whether the user can call a certain api (eg. for some involved The api of the user information is used for the user's login verification).
The so-called data authority is whether the user has access authority to certain data, for example, a log menu, ordinary users can only see their own operation records, and the administrator can see all user operation behaviors. The specific manifestation is When the user has operation authority, it does not mean that he has the authority to view or modify all data.
2. Access control authority model
Access control authority models are: ACL, DAC, MAC, RBAC, ABAC
2.1 ACL Access Control List
Specify which operations the resources can be performed by which entities
ACL, access control list, through the access control list to maintain the mapping relationship between users and resources. ACL contains three elements: User, Resource, and Operation. For each resource, a list is configured to record which users can perform which operations on this resource. When the system attempts to access this resource, it will check whether there is any operation authority for the current user in this list. If so, you can perform the operation, otherwise it will be rejected.
ACL access control list is widely used in routers and Layer 3 switches. It can filter data packets on the interface according to the set conditions, allowing them to pass or discard. With the help of access control lists, users can effectively control access to the network, thereby ensuring network security to the greatest extent.
Application scenarios: routers, firewalls, file systems
2.2 DAC autonomous access control
DAC specifies which subjects can perform which operations on resources. At the same time, subjects can grant resource and operation permissions to other subjects.
DAC is an implementation of ACL, emphasizing flexibility. Pure ACL, permissions are uniformly assigned by the center administrator, lacking flexibility. In order to strengthen flexibility, on the basis of ACL, the DAC model decentralizes authorization, allowing users with permissions to grant permissions to other users autonomously.
The traditional Linux access control method is DAC autonomous access control.
DAC idea: The process and its executing user have the same authority.
For example: Process A, executed as root user, process A has root user permissions.
Another example is Windows file permissions. 
Discretionary access control is a relatively loose access control. The access permissions of a subject are transitive. It emphasizes autonomy, and decides the access strategy by itself, but its security risks also come from autonomy.
2.3. MAC mandatory access control
The Mandatory Access Control model (MAC, Mandatory Access Control) was born in order to make up for the problem of over-dispersion of DAC authority control.
a. Specify which operations the resource can be performed by which types of subjects b. Specify which operations the
subject can perform on which levels of resources
When a user performs an operation, a and b must be satisfied at the same time before the operation is allowed.
In MAC access control, subjects and resources are given a certain security level. Users cannot change the security levels of themselves and resources. Only the administrator can determine the user's access authority. Different from the DAC model, MAC is a multi-level access control strategy. Its main feature is that the system enforces mandatory access control on users and accessed resources. The system assigns different security level attributes to users and resource objects in advance. During access control, the system first compares the security level attributes of the user and the resource object, and then determines whether the user can access the resource.
The mandatory access policy of MAC assigns a security access level to each user, process and file, namely:
- Top Secret level (Top Secret, generally marked as T)
- Secret level (Secret, generally marked as S)
- Confidential level (Confidential, generally marked as C)
- Unclassified (Unclassified, generally marked as U)
MAC is very suitable for confidential organizations or other industries with strong hierarchical concepts. But for similar commercial service systems, because of its excessive emphasis on confidentiality, management is not flexible enough to be suitable.
2.4 RBAC role-based access control
The following picture is from 1.3-What ANSI RBAC is
At present, most of the most common permission design models are RBAC models, Role-Based Access Control . The basic idea of the RBAC model is to assign access permissions to certain roles, and users can obtain the corresponding permissions owned by the roles by playing different roles.
2.4.1.RBAC0
RBAC0 is the basic model of role-based access control, which only contains the core three elements, users, roles, and permissions. Other versions are expanded on the basis of RBAC0.
Each role will be associated with a series of resource permissions (many-to-many), and each user will be associated with some series of roles (many-to-many), so that you can easily control the resources that users can access
2.4.2.RBAC1
Hierarchical Role, role inheritance.
Introducing the concept of parent-child roles, the so-called role inheritance means that child roles can inherit the permissions of the parent role, which is the model of RBAC1.
2.4.3.RBAC2
Static Separation of Duties is static separation of duties, which is used to limit the user's permissions within the normal range, and SSD constraints will be applied during role assignment .
Because of roles and roles, there may be conflicts between permissions and permissions, such as cashiers and accountants, athletes and referees. An employee cannot be both a cashier and an accountant, and an operator cannot be both an operator and a referee.
Static separation of duties means that users cannot be assigned conflicting roles at the same time to prevent users from exceeding the reasonable level of authority for their current positions. Simply put, it is to avoid conflict between the two roles. If the employee already has the role of cashier, then when the employee is assigned the role of accounting, it will be prompted that the role conflicts and the operation cannot be performed. That is to say, when the role is assigned, it will be checked. Regardless of whether there is an inheritance relationship between roles, verification is required.
2.4.4.RBAC3
Dynamic Separation of Duties is also dynamic separation of duties. Mandatory constraints are functions that can be used together at any point in time. DSD constraints can be used to implement strict controls in the multi-step approval process. Generally, DSD constraints are applied when the role is activated.
Dynamic separation of duties means that conflicting roles can be given to a user at the same time, but users cannot activate their own conflicting roles at the same time in a session, and can only choose one of them.
When a user logs in, or after a successful login, the user will be asked to choose a role, such as the role of a cashier. During the running session, the user cannot choose the role of accountant to operate, and can only log out and log in again.
2.5 ABAC attribute-based access control
Different from the common way of associating users with permissions in a certain way, ABAC makes authorization judgments by dynamically calculating whether one or a group of attributes meet certain conditions.
Attributes are generally divided into four categories:
- User attributes (such as user name)
- Environmental attributes (such as current time)
- Operational attributes (such as read or write)
- Object attributes (also called resource attributes, such as an article)
The control granularity of ABAC is finer than that of RBAC. In theory, it can realize very flexible permission control, which can meet almost all types of needs.
The user carries its own attribute values including subject attributes, resource attributes, and environment attributes, and then sends a request to the resource. The authorization engine will make a judgment based on the attributes carried by the subject, and then give the user a rejection or consent result, and the user can then Access to resources or access denied.
For example, the rule: "Allow all class teachers to freely enter and exit the school gate during class time", where "class teacher" is the user's role attribute, "class time" is the environmental attribute, "in and out" is the operational attribute, and "school gate" is the object Properties too. In order to achieve convenient rule setting and rule judgment execution, ABAC usually has configuration files (XML, YAML, etc.) or DSL to cooperate with the rule parsing engine.
3. The realization of data permissions
Data authority is to control the data that users can see, and users who meet a certain condition can only see the corresponding data resources under that condition.
Access control authority is to control whether a user can access a certain resource.
Data authority is to further filter out the data that the user can see according to certain rules after the user has the access control authority.
It is often used to control the data visibility of users in a certain department. For example, users can only view the data of their own department.
Data authority has two main functions:
(1) In order to solve the problem of data security, the
higher the user's level in the enterprise, the more data content can be seen, preventing a large amount of confidential data from being viewed or leaked by ordinary employees.
(2) Avoid vicious competition. It is
common in the sales department of enterprises. The customer resources accumulated by sales managers will not be easily shared with other sales managers.
Common solutions are:
- The simplest: directly add the corresponding Where condition to the SQL code to filter the data, suitable for scenarios with small projects
- Intercept the sql executed by the business, and then automatically splice the data filter conditions, but it is only suitable for a single application. In a distributed scenario, it is difficult to filter the data of cross-service calls
- At the Controller layer, through AOP, the user's visible data is filtered out according to the given data rules, that is to say, all the data is queried first, and then the visible data is filtered according to certain rules
These two articles Data General Design rights management rights and data rights design - based on data permissions EntityFramework design: one design concept also provides a more general data authorities for design ideas can go and see interest , The general idea is to more flexibly control the user's data permissions by configuring role data filtering rules.
3. Common solutions for access control permissions
The permission model we use in our work is mainly based on RBAC, or an extension based on RBAC. The common practice is to add additional restrictions on the user or resource side
1. Standard scene (API, menu, button)
This is the most basic scenario, which is the RBAC0 model.
Generally designed into 5 tables: user table, role table, permission (resource) table, user-role table, role-permission table
API permissions : All requests to users need to be verified by API permissions (can be achieved through aspects or filters)
1) First obtain the user's role set A, and then obtain the set B with the API permissions according to the requested API. If there is an intersection, it means that there is permission.
2) Get the user's role set, and then get all its authorized API set A, and determine whether the requested API is in the set A
Menu permission : first query the set of roles according to the user, and then obtain the corresponding menu list to form the menu tree, and then return to the front-end rendering
Button permissions : According to the user's role, you can get all its authorized button set B. When the page is rendered, it is determined whether the button is displayed or hidden according to whether the button is in the set B.
2. Introducing the group
In order to better manage users and group users into categories, the concept of groups can be introduced.
In actual situations, we know that a group can also have its own role information and permission information. For example, a QQ user group, a group can have multiple users, and a user can also join multiple groups. Each group has its own authority information. For example, viewing group sharing. QQ groups can also have their own role information, such as ordinary groups, advanced groups, and so on.
After introducing the concept of a group, the role that a user has is the union of the set of roles owned by the user and the set of roles owned by the group to which the user belongs. In this way, you want to give all users in a user group the permissions of a certain role , Just need to assign the corresponding role to the group
3. Role inheritance
In order to improve the convenience of authorization, we can also provide the functions of role replication and role inheritance, that is, roles can be copied and inherited, which is the model of RBAC1 mentioned earlier.
The copied role can have the same permissions as the copied role; and for role inheritance, the child role can inherit the permissions of the parent role (similar to inheritance in java).
4. Introduce functional modules
The previous resources are divided into three categories: API, menu, and button; but many resources are related before, and the related resources can be aggregated into functional modules, which is more convenient for us to allocate resources.
We can also regard the menu as a kind Function module, you can also authorize the menu separately
5. Multi-application authorization center
If multiple services need to design a permission system, then the permission service can be independent and let it provide permission management for multiple applications.
Each service that needs to be managed can be regarded as an application, and each application can have its own users, roles, and resources. At the same time, a user can also belong to multiple applications.
The permission service can not only maintain the permissions of other applications, but also maintain the permissions of the permission service itself.
Reference materials:
1.3-What ANSI RBAC is
permission system design model analysis (DAC, MAC, RBAC, ABAC)