The title is a bit of a stretch, because when you look at the word “architecture,” many people think of big projects that involve distribution, high concurrency, and other lofty things.
React: vue quasar-admin: 3YAdmin: Vue Quasar-admin: vue Quasar-admin: 3YAdmin Rbac-based permission control is implemented in both projects. Because the work is back-end development, more clear authority control a management system should have the core functions, and can do general. I plan to write an article about the separation of front and back ends of management system, which is also a summary of knowledge, including vue, React,node,.NET Core and other aspects of knowledge.
The term to describe
- User (Subject) : The Subject that initiates the operation
- Object: The Object on which the operation is performed, such as an article or comment
- Permission: Used to refer to an operation on an object, such as “operation to add articles.”
- Permission code: Permission code, such as “ARTICLE_ADD” for the “Add article action” permission
Permissions can sometimes be called actions or functions. “Add a post,” for example, can be considered either an action or a feature. Objects can also be called resources.
Common permission models
- Access Control List (ACL)
- Discretionary Access Control DAC
- MAC(Mandatory Access Control)
- RBAC(Role-based Access Control)
- Attribute-based Access Control (ABAC)
Access Control List (ACL)
An ACL is the earliest and most basic access control mechanism. It is a data list that describes the relationship between users and permissions. The principle is simple: Each resource is accompanied by a list of users who can perform CRUD operations on the resource. When an attempt is made to access the resource, the list is first checked to see if the current user has access permission to perform the operation.
For example, the ACL of a file object is Alice: read,write; Bob: read, which means that Alice can both read and write to the file, while Bob can only read.
Because of the simplicity of ACLs, access control requires almost no infrastructure. However, its disadvantages are also obvious. Because of the need to maintain a large number of access permission lists, ACL has obvious performance defects. In addition, for applications with a large number of users and a large number of resources, managing access control lists (ACLs) can itself become very onerous.
In the original ACL definition, users are directly linked to permissions, and data stores the association between users and permissions. If two users have the same permission, the association between the two users and the permission needs to be stored separately, which is also the ACL defect mentioned above. To address these issues, the DESIGN of acLs has been improved so that users with the same permissions are placed in the same group, and the groups are linked to the permissions instead of the users directly linked to the permissions. And later RBAC(role-based access Control), roles and groups are similar concepts, with roles directly linked to permissions and users associated with roles.
As a result, the ACL is no longer a model of access control in which users are directly linked to permissions. It is simply an access control list. The relationship between users and rights, user groups and rights, roles and rights, and even departments and positions can be maintained in the list.
Acls are service rules in the permission system. Permission models such as RBAC need acLs to work. Acls serve permission models such as RBAC. Permission rules in other permission control systems are also called ACLs.
Discretionary Access Control DAC
The system identifies the user and then uses the Access Control List (ACL) or Access Control matrix (ACL) of the Subject. Access Control Matrix) to determine whether the user can perform any operations on it, such as read or modify. Users who have access to an object can assign access to that object to other users, so this is called Discretionary control.
Because users can voluntarily grant their own permissions to other users, the DAC model can transfer permissions arbitrarily, and users can indirectly obtain access permissions that they do not have. Therefore, the DAC model has low security and cannot provide sufficient data protection for the system.
DAC can directly use the physical model of ACL. The difference lies in that users in DAC model can assign their permissions to other users (the operation in the program is to screen out the permission list according to user ID, and construct a new permission list for users to be assigned permissions according to the list and save it).
DAC is the traditional UNIX access control model as well as the Windows file system access control model.
Windows file access permission Settings, in addition to the user, there are groups. How does this group differ from the role of the RABC model discussed later?
Stackoverflow.com/questions/7…
I don’t think it is necessary to divide it too clearly. Both groups and roles are improvements made on the original ACL model for better management and permission allocation. You can even assign authority to departments and positions if you need to.
MAC(Mandatory Access Control)
MAC was born to compensate for the decentralized DAC permission control. In the MAC design, each object has some permission identifiers, and each user also has some permission identifiers. Whether a user can operate the object depends on the relationship between the two permission identifiers, and this restriction judgment is usually strictly restricted by the system. When accessing a resource object, the system compares the permission level of the user with the security level of the resource object before deciding whether the user can access the resource object. Users cannot change the security levels of themselves or resource objects. Only a system administrator or a hypervisor can control the security levels of resource objects and users. For example, in movies and television works, we can often see that when an agent queries a confidential document, the screen prompts “Inaccessible, level 1 security clearance is required”. In this example, there is a permission mark of “Level 1 security clearance” on the document, but the user does not have it.
The MAC is great for secret agencies and other class-conscious industries, but it’s not flexible enough for services like business.
MAC can continue to use the DAC model, but with user hierarchy, such as level 1, level 2, level 3… Object resources should also be divided, such as secret, secret and top secret. When a user accesses resources, the system determines the user level based on the user level and resource access level. For example, a level-1 user can access only confidential files. If the user accesses top-secret files, the system rejects the access. This set of rules takes precedence over the DAC. If the MAC and DAC are mixed, the MAC must be checked first and then the DAC.
RBAC(Role-based Access Control)
The access control mechanism of acLs directly maintains the relationship between users and functions. The relationship is a permission list. When many users have the same function permissions, it is necessary to carry out tedious associated operations. RBAC introduces the concept of roles between users and permissions. Users are associated with roles, and the permission list maintains the relationship between roles and functions.
RBAC is the most commonly used permission control model. If some users have the same rights, you only need to create a role for these users, associate related functions with the role, and generate a permission list for the role. When a new user needs the same rights, associate the user with the role. To check or verify the operation rights of a user, query the role permission list of the user.
Of course, RBAC is not perfect. For example, if you want to set up a separate function for a user, you may need to create a separate role for that function and then associate that particular user with that role. When you want to remove a user’s specific function permission, may need to set the role of the function, the function of specific permissions removed from the current role, establish new roles and permissions associated with a specific function, and then put the new roles associated with the user (also can be directly in the specific functions of the program check operation user)
One of the more common misuses of RBAC is to use roles directly to make permission judgments. For example, only role A can delete articles.
function delPost(postId){
if(! isRole('A')) {return false; }}Copy the codeThe article can also be deleted if required for role B. You have to change the code
function delPost(postId){
if(! isRole('A') &&! isRole('B')) {return false; }}Copy the codeThe right thing to do would be to add a “delete articles” feature and associate it with the appropriate role. Judge by function, not character.
function delPost(postId){
if(! hasPermission('POST_DEL')) {return false; }}Copy the codeTo meet the requirement that only role A can perform the deletion operation, associate the deletion function with role A and add the users requiring the deletion permission to role A. If other roles also require the operation permission, associate the function with the corresponding role without modifying the code.
Based on the core of RBAC, you can also make corresponding extensions, such as role inheritance and role grouping, to simplify permission management to some extent.
Attribute-based Access Control (ABAC)
RBAC is currently the most common permission control model. However, in some cases, RBAC is not met and cannot be implemented. For example, both salesman 1 and 2 have the permission to view customer orders. When there is a requirement that salesman 1 can only view the orders of customers in Beijing, and salesman 2 can only view the orders of customers in Shanghai. This cannot be done using RBAC alone. With RBAC, it is possible to create roles by locale and then filter the data in the application based on those roles. The disadvantage of this approach is mentioned earlier, and it may be necessary to change the code every time requirements change.
In the example of the salesman viewing the order above, the region is an attribute of the order, and the requirement is to control the authority of the query range of the order based on this attribute. This permission Control method is attribute-based Access Control (ABAC), which is also called by some people as the future of permission system design.
Instead of the usual way of associating users with permissions in some way, ABAC makes authorization decisions by dynamically calculating whether one or a set of attributes meets certain conditions (simple logic can be written). Attributes are generally divided into four categories: user attributes (such as user age), environment attributes (such as current time), operation attributes (such as read) and object attributes (such as an article, also known as resource attributes), so in theory it can achieve very flexible permission control, almost to meet all types of requirements.
For example, rule: “allow all class teachers to freely enter and exit the school gate during class time” rule, wherein, “class teacher” is the user’s role attribute, “class time” is the environment attribute, “in and out” is the operation attribute, and “school gate” is the object attribute.
ABAC is very flexible, but it is also very difficult to implement. This involves dynamic execution of logic, dynamic filtering of data, and more specifically dynamic splicing OF SQL statements (ORM is used to dynamically assemble corresponding ORM query statements).
Those interested can search ABAC on Github to see if a solution is already available for different languages. Here’s one way I’ve learned to do it:
Again an example of a salesman looking at an order, extending an entity rule on top of RBAC, where an order is an entity, that is, setting a set of rules for the order. Rules can be stored in JSON, XML, or even Sql statements that can be parsed. For example, this rule in Beijing:
{
"regionId":1
}
Copy the codeShanghai Area:
{
"regionId":3
}
Copy the codeA regionId is the Id of a region in the system and a field in an order or order-related table.
To save the rule, the rule content (the JSON above) and the rule entity (the order, indicating that the rule is for the order) are required. You can also add that this rule applies to one or more of the additions, deletions, changes, and checks.
Create rules for entities and associate rules with roles. That is, associate rules in Beijing with roles in Beijing and rules in Shanghai with roles in Shanghai.
When the back end does permission verification, it first verifies according to the control mode of RBAC model (whether it has the permission to view orders), and then extracts the rules of the corresponding entity associated with the role of the user according to the current operation object (entity). The rules are then parsed and the Sql or ORM statements are dynamically concatenated.
When no locale restrictions are made (or rules are not configured), Sql can be
select userId,orderNo,createdDate from T_Order
Copy the codeIf the rule is configured, it may be parsed and spliced
select userId,orderNo,createdDate from T_Order where regionId=1
Copy the codeHere is dynamic permission control for the locale property. The actual development process, to control things is very much, look at the field control, data range control. To satisfy these complex controls, a complete set of rules needs to be formulated, and corresponding parsing programs for the rules need to be written. For example, according to the configuration rules, the final parsing may be a variety of Sql statements :<,>,=,like,in,not in, and so on.
You can see how complicated it is to actually implement ABAC. Parsing rules every time also has an impact on the performance of the program, even if the cache is used, the probability of hitting is very small, because many factors are dynamic.
Therefore, if there are not many scenarios that require permission judgment based on attributes, it is recommended to use RBAC, and then make judgment in the program is easier and less effort.
conclusion
In the early definition of ACL, it is a permission control mechanism. This mechanism directly maintains the relationship between users and functions. Functions are operations defined for objects, such as adding, deleting, modifying, and querying. The relationship between users and functions is also called permission list or access control list (ACL). Nowadays, ACL generally refers to this permission list or access control list. However, the relationship maintained in ACL is not necessarily the relationship between users and functions.
RBAC adds the concept of roles on the basis of ACL. The relationship between roles and functions is no longer maintained in the permission list or access control list. ACL can be mixed with RBAC to set permissions for roles or users, which is more flexible. With the help of the idea of roles, you can set permissions on user groups, organizations, and positions to better manage permissions. That is, you can transfer permission Settings from a single individual to a certain group.
ABAC is very flexible, but also very difficult to implement.
Refer to the article
Authority system design model analysis
Authorization Models: ACL, DAC, MAC, RBAC, ABAC