C # permission Control

Preface:
Permissions are often an extremely complex issue, but they can also be expressed simply as a logical expression that determines whether the logical expression "who performs how operations on what (which)" is true. For different applications, You need to weigh n solutions, such as maintainability, flexibility, and integrity, based on the actual situation of the project and the specific architecture, and select a suitable solution.
Objectives:
Intuitive, because the system will eventually be maintained by the end user, and the intuitive and easy-to-understand permission assignment makes it very important. The system has worked tirelessly to implement group inheritance, in addition to functional requirements, more importantly, it is intuitive enough.
Simple, including the simplicity of concept, quantity, meaning, and functionality. It is unrealistic to use a permission system to solve all permissions. In the design, part of the frequently-changed "Custom" features are judged as the business logic, this idea is based on the logic of determining the parts that often share the "General" characteristics as the Permission Logic.
Scalability. The group concept can be defined in groups while effectively avoiding redefinition.
Status quo:
There are generally three access control methods in the enterprise environment:
1. Autonomous access control method. At present, the access control module in most information systems in China is based on the access control list (ACLs) in the autonomous access control method ).
2. Forced access control method. It is used for military applications with multiple levels of security.
3. Role-Based Access Control (RBAC ). It is currently recognized as an effective solution to centralized resource access control for large enterprises. The two major features are as follows: 1. Reduce the complexity of authorization management and reduce management overhead. 2. flexible support for enterprise security policies and great scalability for enterprise changes.
Terms:
Coarse granularity: indicates the class level, that is, only the type of the object is considered, not a specific feature of the object.
Instance. For example, in user management, creation and deletion are treated equally for all users, but do not differentiate the specific object instances for operations.
Fine Granularity: indicates the instance level, that is, the instance of the specific object needs to be considered.
A specific instance is considered only after a coarse-grained object category is taken into account. For example, to list and delete a contract, you must determine whether the contract instance is created by the current user.
Principles:
The permission logic works with the business logic. That is, the permission system provides services for the business logic. A considerable number of fine-grained permission issues are extremely unique and have no universal significance. They can also be understood as part of the "business logic. For example, the requirement is: "The contract resource can only be deleted by its creator, users in the same group as the creator can be modified, and all users can browse ". This can be considered as a fine-grained permission issue or a business logic issue. Here it is a problem of business logic, which should not be considered too much in the entire permission system architecture design. Of course, the permission system architecture must also support such control judgment. In other words, the system provides sufficient but not full control capabilities. That is, the design principle is: "The system only provides coarse-grained permissions, and fine-grained permissions are considered to be the responsibility of business logic ".
It should be emphasized again that the permission system described here is only an "incomplete" permission system, that is, it does not provide all solutions to the permission issue. It provides a foundation and solves the "common" (or coarse-grained) parts. Based on this, according to the unique permission Requirements of the "business logic", the remaining (or fine-grained) part of the code is complete. Back to the permission issue formula, the general design only solves the problem of who + What + how. Other permission issues are left to the business logic.
Concept:
WHO: Permission owner or subject (principal, user, group, role, actor, etc)
What: the target object or resource (resource, class ).
How: specific permissions (privilege, positive authorization and negative authorization ).
Role: a role with a certain number of permissions.
Operator: operation. Indicates how to operate on what.
Note:
User: Related to role. The user is only a pure user, and the permissions are separated. A user cannot be directly related to privilege. To have permissions on a certain resource, the user must be associated through role. Solve the WHO problem.
Resource: system resources, such as department news, documents, and other objects that can be provided to users for access. A resource can contain itself in a tree structure. Each resource node can be associated with a number of specified permission categories to determine whether to apply its permissions to subnodes.
Privilege: Permission for resource related. This permission is bound to a specific resource instance. For example, the publishing permission of a department news is called "Department news publishing permission ". This indicates that the privilege is a publishing permission and is a publishing permission for resources such as department news. Privilege is determined by the Creator during development. Permissions, including system-defined permissions and user-defined permissions. You can specify exclusion and inclusion relationships (for example, read, modify, and manage three permissions) between user-defined permissions and user-defined permissions, management permissions include the first two permissions ). Privilege, for example, "delete", is an abstract term and makes no sense when it is not bound with any specific object or resource. For news publishing, publishing is a type of permission, but publishing is meaningless. Because I don't know what objects can be operated on by publishing. A real privilege is generated only when publishing and news are combined. This is the privilege instance. The permission system can generate many different versions based on different requirements.
Role: it is a coarse-grained and fine-grained (business logic) interface. A permission framework Software Based on coarse-grained control should provide a role interface, A specific business implementation can directly inherit or expand the content of a rich role. A role is not like a specific entity of a user or group. It is an interface concept and an abstract generic name.
GROUP: user group, the unit and carrier of permission allocation. Permissions are not assigned to specific users. A group can contain groups (to inherit permissions ). A group can contain users who inherit group permissions. Group must be inherited. That is, you must specify the group in which the parent of the group is created. In terms of coarse-grained control, it can be considered that as long as a user directly or indirectly belongs to a group, it will have all operation permits for this group. In terms of fine-grained control, in the judgment of the business logic, the user should only pay attention to the group it directly belongs to, to determine whether it is "same group ". A group can be inherited. For a hierarchical permission implementation, a group has directly obtained all the "permission sets" owned by its parent group through "inheritance". For this group, you need to establish a direct association with the permission. It is only the part of the permission that needs to be "extended" than its parent group. The Sub-group inherits all permissions of the parent group, and the rules are easier to manage. To further implement permission inheritance, the most direct thing is to introduce the "parent-child relationship" on the group ".
The relationship between user and group is many-to-many. That is, a user can belong to multiple groups, and a group can include multiple users. The relationship between a Sub-Group and its parent group is many-to-one. Operator is similar to the concept of resource + privilege in a sense, but here the resource only includes the resource type and does not represent the resource instance. The Group can be directly mapped to the organizational structure, and the role can be directly mapped to the Business Roles in the organizational structure, which is intuitive and flexible enough. The contribution of role to the system is essentially a allocation unit of coarse particles.
The relationship between group and operator is many-to-many. The relationships between concepts are shown as follows:
Explanation:
Operator includes the concepts of resource type and method. That is, the concept of what and how. The reason why we bind what and how together as an operator instead of separately modeling and then establishing association is because many of the ways make sense for something. For example, a publishing operation is meaningful to news objects and meaningless to user objects.
The meaning of how is also different. Specifically, N operations can be defined for each of the actions. For example, for objects such as contracts, you can define creation operations, submission operations, and check for conflicting operations. We can think that the concept of how corresponds to every business method. Actions related to a specific user identity can be defined either in the operational business logic or at the operational level. For example, the browser view of the Creator is different from that of a common user. Two operation methods can be defined externally or processed according to the specific logic within an operation method. Which method should be used based on the actual situation.
Such an architecture should be able to meet the functional needs of most coarse-grained permission control functions with ease of understanding and management. However, in addition to coarse-grained permissions, the system will certainly include numerous fine-grained permissions on specific instances. These problems are left to the business logic to solve. Such considerations are based on the following two points:
On the one hand, fine-grained permission judgment can be achieved only by modeling the support information for permission allocation on resources. For example, if the creator and the common user are required to see different information content, the resource itself should have the information of its creator. On the other hand, fine-grained permissions often have considerable business logic relevance. Different business logics often mean completely different permission judgment principles and policies. In contrast, coarse-grained permissions are more universal and can be implemented as an architecture with more reuse value. However, implementing fine-grained permission judgment as an architecture is cumbersome, and it is not that necessary. Code It is more concise and flexible.
Therefore, fine-grained control should be implemented at the underlying layer. During resource instantiation, the owner and groupprivilege must be specified to determine the constraint type when operating on the Resource: whether it is ownerok, groupok or Allok. The group and role should strictly separate the relationship between the user and the Group. The Group is only used for User Classification and does not contain the meaning of any role. The role is only granted to the user, not the group. If you need a combination of multiple privilege types that are not yet available, you must add a new role. Privilege must be able to access the resource with the USER parameter, so that the permission control is complete.