Enterprise Management system front-end separation Architecture Design Series one permission model chapter

The previous time with Vue and react wrote two back-end management system Templates Vue-quasar-admin and 3YAdmin. RBAC-based permissions control is implemented in two projects. Because the job is back-end development, it is clear that the authority to control a management system should have the core functions, but also can be common. intends to write about the management system front-end separation of the article, but also to do a summary of knowledge, which will involve vue,react,node,.net core and other aspects of knowledge.

Term description

• User (Subject): The principal initiating the operation
• Object: Refers to an object, such as an article or comment, that the action is directed against.
• Permissions (Permission): Used to refer to an action on an object, such as "add an article action"
• Permission code: The code name of the permission, for example, "Article_add" to refer to the "Add Article action" permission

Permissions can sometimes also be called actions or functions. For example, "add an article", you can think of it as an action, you can think it is a function. Objects can also be called resources.

Common Permissions Model

• ACL (Access control list)
• DAC (discretionary access control) (Autonomous access controls)
• MAC (Mandatory access Control) (Mandatory access controls)
• RBAC (role-based access Control) (role-based access controls)
• ABAC (attribute-based access Control) (attribute-based access controls)

ACL (Access control list)

ACLs are the first and most basic type of access control mechanism, which is a list of data used to describe the relationship between users and permissions. Its rationale is simple: each resource is provided with a list of users who can perform CRUD operations on the resource. When attempting to access this resource, the list is first checked for access to the current user, which determines whether the current user can perform the appropriate action.

For example, an ACL for a file object is alice:read,write; Bob:read, which means Alice can read and write to the file, and Bob can only read it.

Because of the simplicity of the ACL, it can complete access control with little or no infrastructure required. But at the same time its shortcomings are also very obvious, because of the need to maintain a large number of access lists, ACL performance has obvious flaws. In addition, for applications with a large number of users and many resources, managing the access control list itself becomes a very heavy task.

In the first ACL definition, the user is linked directly to the permission, and the data stores the relationship between the user and the permission. If the permissions of the two users are the same, then it is necessary to store the two users and permissions of the association, but also the above mentioned ACL defects. In order to solve these problems, there are improvements to ACL design, users of the same permissions are placed in the same group, groups and permissions are linked, no longer the user directly linked to permissions. and later RBAC (role-based access control), roles and groupings are similar concepts, roles are directly linked to permissions, and users are associated with roles.

Therefore, now generally say ACL, is no longer a user directly and permissions linked to a rights control model, it is considered a simple access control list. The list maintains the relationship between the user and the permissions, or the user group and permissions, or the relationship between roles and permissions, even departments, positions, etc. equal to the permissions.

An ACL is a business rule in a permission system. RBAC and other permissions model to use ACL to work, ACL services to RBAC and other permissions model, other rights control system of the permission rules are called ACLs.

DAC (discretionary access control) (Autonomous access controls)

The system will identify the user and then determine whether the user is able to operate on it based on the information of the Permission Control List (Subject) of the Manipulated object (acl:access control lists) or the permission control matrix (acl:access control). such as reading or modifying.
A user with object permissions can also assign the object's permissions to other users, so it is called "autonomous (discretionary)" control.

Because the user can autonomously grant their own permissions to other users, so the DAC model can be arbitrarily passed permissions, users can indirectly obtain the access rights that do not have, so the DAC model security is low, can not give the system adequate data protection.

The DAC can directly use the physical model of the ACL, except that users in the DAC model can assign their own permissions to other users (the action in the program is to filter out the list of permissions based on the user ID, construct a new list of permissions for the user to assign permissions to, and save)

The DAC is the traditional UNIX access control model and the access control model of the Windows file system.

Windows has a set of file access permissions, in addition to users, there are groups. What is the difference between this group and the role of the RABC model to be talked about later?

Https://stackoverflow.com/questions/7770728/group-vs-role-any-real-difference

I don't think it's necessary to divide it too clearly, whether it's a group or a role, to better manage and assign permissions to improve on the most primitive ACL models. If necessary, you can even assign permissions to departments, positions.

MAC (Mandatory access Control) (Mandatory access controls)

The Mac was born to compensate for the problem of too fragmented DAC permissions control. In the design of the Mac, each object has some permissions identified, each user also has some permissions to identify, and whether the user can manipulate the object depends on the relationship between the identity of the two sides, this limit is usually determined by the system hard limit. When accessed, the system first compares the user's access permission level and the resource object's classification, and then determines whether the user can access the resource object. Users cannot change the security level of themselves and resource objects, and only system administrators or management programs can control the level of resource objects and users. For example, in the film and television works, we often see agents in the search for confidential documents, the screen prompts need to "inaccessible, require a first-class security permission", in this case, the file has a "primary security license" permission to identify, and the user does not have.

Macs are ideal for confidential institutions or other highly rated industries, but for similar business service systems, they are not flexible enough to apply.

The Mac can continue to use the DAC model, but to rank users, such as level one, level two, level three ... , the object resources should be divided, such as confidential, secret and top secret. When users access resources, according to the level of user level and resource access to make judgments, such as a level of users can only access confidential documents, if access to the highest confidential documents, the system will be rejected. This series of rules takes precedence over the DAC, and if the Mac is mixed with a DAC, verify the Mac and then check the DAC.

RBAC (role-based access Control) (role-based access controls)

In the access control mechanism of ACL, the relationship between user and function is directly maintained, and this series of relationships is a list of permissions. When a lot of users have the same function permissions, it is necessary to carry out cumbersome association operations. RBAC is the concept of introducing roles between users and permissions. A user is associated with a role, and the permissions list maintains the relationship between roles and functions.

RBAC is the most common permission control model currently used. When some users have the same permissions, they only need to build a role for those users, associate the appropriate functionality to the role, and generate a list of permissions for the role. When a new user needs the same permissions, associate the user with the role. When checking or verifying the user's operation permissions, a list of permissions for the role to which the user belongs can be queried.

Of course, RBAC is not perfect, for example, if you want to set a feature permission for a user individually, you may need to create a separate role for the feature permission, and then associate a specific user to the role. When you want to remove a specific feature permission for a user, you may need to reset the function permissions of the role, remove the specific feature permissions from the current role, create a new role and associate a specific function permission, and then associate the new role with the associated user (or you can verify the user directly in a specific function's program)

Here is a more common use of the error in RBAC: That is, directly using the role to do the right to judge. For example, only role a can make a fuss about a delete operation.

function delPost(postId){    if(!isRole('A')){        return false;    }}

You can also delete an article if the requirement is role B. Then you have to modify the code

function delPost(postId){    if(!isRole('A')&&!isRole('B')){        return false;    }}

The correct way to do this is to add the "delete article" feature to associate this function with the appropriate role. Judgment is judged by function rather than by character.

function delPost(postId){    if(!hasPermission('POST_DEL')){        return false;    }}

For the requirement "only role a can make a fuss", associate the deletion function to role A, and then add the user who needs the permission to the role a. When other roles need this permission, the function is linked to the corresponding role, no need to modify the code.

In the core of RBAC, we can also do some extension, such as role inheritance, role grouping and so on, which are all to simplify the rights management work to some extent.

ABAC (attribute-based access Control) (attribute-based permission control)

RBAC is currently the most common model of permission control. However, in some cases, RBAC is not sufficient and can not be achieved. For example, salesman 1 and salesman 2 are part of the role of the salesman, have to view the customer order permissions. When there is a requirement, salesman 1 can only view the Beijing area of the customer's orders, salesman 2 can only view the orders of customers in Shanghai. This is not possible with RBAC alone. With RBAC, it is possible to create roles in a sub-region and then filter the data in the program according to the role, as mentioned before, and it may be necessary to modify the code every time the requirements change.

Above the salesman view the example of the order, the region is an attribute of the order, the demand is for the region attribute to do the order of the query scope of the permission control. This kind of permission control is ABAC (attribute-based access Control) (attribute-based permission controls), and some people call it the future of the rights system design.

Unlike the common way in which users are somehow associated with permissions, ABAC is empowered by dynamically calculating whether a property or a set of properties satisfies a certain condition (simple logic can be written). Properties are generally divided into four categories: User attributes (such as user age), environment attributes (such as the current time), manipulation properties (such as Read) and object properties (such as articles, also known as resource attributes), so it is theoretically possible to achieve very flexible permissions control that can meet almost all types of requirements.

For example, the rule: "Allow all class teachers in class time free access to school" this rule, wherein, "class teacher" is the user's role attribute, "Class time" is the environment attribute, "in and out" is the operation attribute, and "gate" is the object attribute.

ABAC is very flexible, but the implementation is very difficult. This involves the dynamic execution of logic, data dynamic filtering, and more specifically, dynamic splicing of SQL statements (using ORM is the dynamic assembly of the corresponding ORM query statement).

Interested in searching for ABAC on GitHub, see if there are existing solutions available in different languages. Let's talk about one of the ways I've learned to achieve this:

Or the salesman to view the example of the order, on the basis of RBAC, the expansion of an entity rule, the order is the entity, that is, set a series of rules for the order. The rule storage format can be either JSON or XML, or even SQL statements that can be parsed. such as Beijing, the rule:

{    "regionId":1}

Shanghai:

{    "regionId":3}

regionIdIs the ID of the corresponding area in the system, and is also a field of the order or order related table.

When this rule is saved, the content of the rule (which is the JSON above), the rule entity (i.e. the order, which indicates that the rule is for the order) is necessary. can also be added to this rule is applicable to add or remove changes in one or more.

Create the rules of the entity and associate the rules with the role, that is, the rules of the Beijing region are linked to the Beijing regional role, and the Shanghai regional rules relate to the role of Shanghai.

When the backend does the permission check, it is verified by the RBAC model (whether the Order View permission is available), and then the rules of the corresponding entity associated with the user's role are taken out according to the current action object (that is, the entity). Then parse the rules, dynamically splicing SQL or ORM statements.

Without a regional limit (or no rules configured), SQL may be

select userId,orderNo,createdDate from T_Order

The rules are configured, and the parsing of the stitching may be

select userId,orderNo,createdDate from T_Order where regionId=1

This is the property for the region to achieve dynamic permissions control. The actual development process, to control things is very much, view the control of the field, data range control. To meet these complex controls, you need to develop a complete set of rules and a corresponding parser for the rules. For example, according to the configured rules, the final parsing may be a variety of SQL statements: <,>,=,like,in,not in and so on.

It can be seen how complicated it is to truly abac the ground. Every time to parse the rules, the performance of the program is also affected, even using the cache, the probability of hit is very small, because many factors are dynamic.

Therefore, if you need to do permissions based on attributes to judge the scene is not many, or the proposed use of RBAC, and then the program to make a more convenient judgment.

Summarize

ACL early definition is a kind of authority control mechanism, this mechanism directly maintains the relationship between the user and the function, the function is to target the object definition of some operations, such as adding and deleting changes and so on. The list of relationships between a user and a feature is also known as a permission list or access control list, which is now referred to as ACL, which is generally referred to as the permission list or access control list, but the relationship maintained in the inside is not necessarily the relationship between the user and the function, and the relationship between roles and functions is maintained in RBAC.

RBAC joins the concept of the role on the basis of ACLs, which is not the relationship between the user and the function, but the role and function. ACLs can be mixed with RBAC, can set permissions on the role, or directly to the user to set permissions, more flexible. With the idea of the role, you can set permissions on user groups, organizations, positions, and so on, so as to better manage permissions, that is, to transfer permission settings from a single individual to a class of combinations.

ABAC is very flexible and very difficult to achieve.

Reference articles

Analysis of the design model of authority system

Authorization Models:acl, DAC, MAC, RBAC, ABAC

Enterprise Management system front-end separation Architecture Design Series one permission model chapter