Preface:
Permissions are often an extremely complex problem, but it is also possible to express such a logical expression: "Decision" WHO "logical expressions for how to do WHICH" is true. For different applications, it is necessary to comply with the actual conditions and specific architectures of the project, which is compliant between maintenance, flexibility, integrity, and the like.
the goal:
Intuitive, because the system will ultimately be maintained by end users, the permission allocation is more important, and the system is more important, the system has achieved the inheritance of the group, except for functionality, more mainly because it is intuitive.
Simple, including simple and simple and simple features on the number of concepts. It is unrealistic to use a permission system to solve all permissions. The "custom" characteristics that will often change often determine the business logic, and the same "general" characteristics will be more powerful as the permissions logic based on such ideas.
Extended, it is difficult to inherit in the extension. GROUP concepts are effectively avoided while supporting permissions
status quo:
For access control methods in an enterprise environment, there are usually three:
1. Autonomous access control method. The access control module currently in most information systems in our country is basically a list of access controls (ACLs) in autonomous access control methods.
2. Forced Access Control Method. Military applications for multi-level security levels.
3. Role-based access control method (RBAC). It is a valid method that is currently recognized to solve the unified resource access control of large enterprises. Its significant two features are: 1. Reduce the complexity of authorization management and reduce management overhead. 2. Flexible supporting the company's security strategy and has a lot of scalability for changes in the company.
noun:
Rough granularity: indicates the class level, that is, only the Type of Object, does not consider a special
Dedicated example. For example, in user management, create, delete, all users have a colleagues, and do not distinguish the specific object instance of the operation.
Fine granularity: Represents the instance level, that is, the instance of object is required, of course, fine
The particle size is a specific example again after considering the class of the coarse particle size. For example, in the contract management, a list, deletion, you need to distinguish whether the contract instance is created for the current user.
in principle:
Permissions logic works in business logic. That is, the permissions system uses services for business logic. It is also understood as part of "business logic" due to its extremely unique and universal meaning. For example, request: "Contract resources can only be deleted by its creator, and users can modify with the same group of the creator, all users can browse." This can be considered to be a fine-grained permission issue, or it can be considered a business logic problem. Here it is a business logic problem, not much consideration in the architecture design of the entire permissions system. Of course, the architecture of the permission system must also support such control judgments. Or, the system provides sufficient but not complete control capabilities. That is, the design principle is attributed to: "The system only provides permissions of coarse particle size, and the permissions of fine grain are considered to be the responsibility of business logic."
It needs to be emphasized again that the permission system of the presentation here is only a "incomplete" permission system, ie, it does not provide all solutions to the issue of privileges. It provides a foundation and solves those (or crude particle size) portions with "common". On this basis, based on the unique privileged needs of "business logic", the encoding is achieved to implement the remainder (or fine-grained) section is complete. If you return to the issue, the general design only solves the problem of WHO What how, and other permission issues are left to business logic.
Concept: Who: Support or subject (Principal, User, Group, role, actor, etc.)
What: Permissions For objects or resources (Resource, Class).
HOW: Specific permissions (Privilege, forward authorization and negative authorization).
Role: It is a role and has a certain amount of permissions.
Operator: Operation. Indicates how operation to what.
Description:
User: Associated with Role, the user is just a pure user, and the permissions are separated. User can't be directly related to Privilege, user wants to have permissions to a certain resource must be associated with the role. Solve the problem of WHO.
Resource: It is the resource of the system, such as departmental news, documentation, and other objects that can be provided to users. Resources can reversely contain themselves, ie a tree structure, each resource node, can define whether to define if the permission can be applied to subtots with several specified permissions categories.
Privilege: It is the permissions of Resource Related. It means that this permission is bound to a specific resource instance. For example, the release authority of departmental news is called "departmental news release authority". This shows that this Privilege is a release permission and is a release permission for the resource of department news. Privilege is determined by Creator when making development. Permissions, including system definition permissions, and user-defined privileges, user-defined privileges, can specify exclusion and include relationships (such as reading, modification, managing three permissions, administrative permissions contains the first two permissions). Privilege As "Delete" is an abstract noun, there is no meaning when it is not binding with any specific object or resource. Take the news release, the release is a permission, but just say that it is meaningless. Because I don't know what the object to be operated is. Real Privilege is only generated when the release is combined with news. This is Privilege Instance. The permission system can extend a lot of different versions depending on the demand.
Role: It is a coarse grain size and fine-grained (business logic) interface, a coarse granular control-based rights frame software, the external interface should be Role, the specific business implementation can directly inherit or expand the rich role, Role is not as User or GROUP's specific entity, it is an interface concept, abstract generality.
Group: Units and carriers of user groups, permission assignments. Permissions do not consider assigned to specific users. The group can include a group (inherited to achieve permissions). The group can contain the permissions of the user inherited within the group. GROUP To achieve inheritance. That is, what must be specified when creating the group of Parent is Group. On coarse granularity, it can be considered that as long as a user directly or indirectly belongs to a group, it has all the operation licenses of this group. In terms of fine-grained control, in the judgment of business logic, the user should only pay attention to the group directly belonging, and it is used to determine if "the same group". Group is inherited, for a grading permissions, a group has directly obtained all "permission collection" owned by his father Group through "inherit", and the Group is required to establish a direct association with permissions. It is only that it needs "extension" than its parent Group. The subgroup inherits all permissions of the parent group, the rules are simpler, which means that management is easier. In order to achieve the inheritance of permissions, the most direct is to introduce "Parental Relations" on Group. User and group are multi-to-many relationships. That is, a user can belong to multiple groups, and a group can include multiple USERs. Subroup and parent Group are multi-to-one relationship. Operator is similar to the Resource Privilege concept, but the resource here only includes Resource Type does not represent Resource Instance. Group can directly map organizational structure, and Role can directly map the business role in the organization structure, ratio
