Objective:
Permissions are often an extremely complex issue, but they can also be simply expressed as a logical expression of whether the logical expression "who is doing to what (Which)" is true. For different applications, according to the actual situation of the project and the specific framework, in the maintenance, flexibility, integrity and other n more than a trade-off between the choice of a suitable solution.
Goal:
Intuitive, because the system will ultimately be maintained by the end user, the right to assign intuitive and easy to understand, it is more important, the system to achieve the painstaking implementation of the group's inheritance, in addition to the function must, more important is because it is intuitive enough.
Simplicity, including the simplicity of the concept and the simplicity of the meaning and simplicity of the function. It is unrealistic to want to use a privilege system to solve all permissions problems. Design will often change the "custom" characteristics of a relatively strong part of the judgment for the business logic, and the often the same "general" features relatively strong part of the judgment as the right logic is based on this idea.
Extensions, with the difficulty of inheriting on the extension. Group concept when supporting permissions are defined in groups while effectively avoiding redefinition
Present situation:
There are generally three types of access control methods in an enterprise environment:
1. Autonomous access control methods. At present, most of the access control modules in the information system of our country are based on the Access Control List (ACLs) in the Autonomic access control method.
2. Mandatory access control method. Military applications for multi-level security levels.
3. Role-based access Control Method (RBAC). It is an effective method to solve the unified resource access control of large enterprises at present. The two notable features are: 1. Reduce the complexity of authorization management and reduce management overhead. 2. Flexibility to support the enterprise's security policy, and the changes in the enterprise has a great scalability.
Noun:
Coarse granularity: Represents the category level, that is, only the class of the object (the type of object), regardless of the object's specific
Fixed instance. For example, user management, create, delete, for all users alike, does not distinguish between the specific object of the operation of the instance.
Fine granularity: Represents an instance level, where an instance of a specific object is considered (the instance of object), of course,
Granularity is the consideration of a particular instance after a coarse-grained object class is considered. For example, in contract management, list, delete, need to distinguish whether the contract instance is created by the current user.
Principle:
The right logic fits the business logic. That is, the privilege system aims to provide services for business logic. Considerable fine-grained permission issues are very unique and not universally meaningful, and they can be understood as part of the "business logic." For example, the requirement: "Contract resources can only be deleted by its creator, and users of the same group as the creator may modify, and all users can browse". This can be considered as a fine-grained permission problem, or as a business logic problem. Here it is a business logic problem that is not overly considered in the architecture design of the entire privilege system. Of course, the architecture of the privilege system must also be able to support such control judgments. Or, the system provides enough, but not complete, control. That is, the design principle boils down to: "The system provides only coarse-grained permissions, and fine-grained permissions are considered the responsibility of the business logic."
Again, the privilege system described here is only an "incomplete" permission system, that is, it does not provide any solution to the issue of permissions. It provides a basis and addresses the "common" (or coarse-grained) parts. On this basis, according to the "Business logic" of the unique permissions requirements, coding to achieve the remainder (or fine-grained) part of the complete. Back to the problem formula of the permissions, the general design only solves the problem of Who+what+how, the other permissions issues left to the business logic solution.
Concept:
Who: the user or subject of authority (Principal, User, Group, role, actor, etc.)
What: The object or resource (Resource, Class) to which the permission is directed.
How: Specific permissions (privilege, forward authorization and negative authorization).
Role: is a character, with a certain number of permissions.
Operator: operation. Shows how to what.
Description
User: In relation to role, users are just pure users, and permissions are separated. User is not directly related to the privilege, user must have the right to a certain resource, you have to associate through role. Solve the WHO problem.
Resource: Is the resources of the system, such as department news, documents, and other objects that can be provided to the user to access. A resource can reverse contain itself, a tree structure, in which each resource node can be associated with several specified permission categories to define whether to apply its permissions to child nodes.
Privilege: is the resource related permission. means that the permission is bound to a particular resource instance. For example, Department news release rights, called "departmental press release rights." This indicates that the privilege is a publishing authority and a publishing authority for resources such as departmental news. Privilege is determined by the creator when it is developed. permissions, including system-defined permissions and user-defined permissions user-defined permissions can specify exclusion and inclusion relationships (such as: Read, modify, manage three permissions, administrative rights contain the first two permissions). Privilege as "Delete" is an abstract noun that does not have any meaning when it is not bound to any specific Object or Resource. Publishing is a privilege for a press release, but it's pointless to just publish it. Because you don't know what the publishing object is. It is only when the release is combined with the news that the real privilege is produced. This is privilege Instance. Permission systems can extend to many different versions depending on the requirements.
Role: Is the interface between coarse grained and fine-grained (business logic), a permission framework software based on coarse-grained control, the external interface should be role, the specific business implementation can directly inherit or expand the rich role of content, role is not as a user or group of specific entities, it is the interface concept, An abstract generic term.
Group: User groups, authority assignment units and carriers. Permissions are not considered assigned to a specific user. Groups can include groups (to implement inheritance of permissions). A group can contain users, and users in a group inherit the permissions of the group. Group to implement inheritance. That is, you must specify what group the parent of the group is when you create it. In coarse-grained control, it is assumed that a user has all the operational licenses of this group as long as it belongs to a group, either directly or indirectly. On fine-grained control, in the judgment of business logic, user should only pay attention to the group directly belonging to it, and use it to judge whether "same group". Group is inheritable, for a hierarchical permission implementation, a group has directly obtained all the "permission sets" owned by its parent group through "inheritance," which, for this group, needs to be directly associated with permission creation, only that it needs to "extend" to its parent group That part of the permission. Subgroups inherit all of the permissions of the parent group, and the rules are simpler, which means easier administration. To further implement the inheritance of permissions, it is most straightforward to introduce a "parent-child relationship" on the group.
User and group are many-to-many relationships. That is, a user can belong to multiple group, and a group can include more than one user. A child group is a many-to-many relationship with the parent group. Operator is similar to the resource + privilege concept in some sense, but the resource here includes only the resource type does not represent resource Instance. Group can directly map the organization structure, role can directly map the business roles in the organization structure, more intuitive, but also flexible enough. The contribution of role to the system is essentially the provision of a relatively coarse particle allocation unit.
The group and the operator are many-to-many relationships. The relationship of the concepts is illustrated as follows:
Explain:
The definition of operator includes the resource type and method concepts. That is, the concept of what and how. The reason why what and how are bound together as a operator concept rather than modeled separately is because a lot of how makes sense for a what. For example, a publishing operation has meaning for a news object, but not for a user object.
The meaning of how is also different, specifically, for each what can define N operations. For example, for contracts such as objects, you can define create operations, commit operations, check conflict actions, and so on. It can be argued that the how concept corresponds to every business method. The actions related to the specific user identity can be defined either in the operational logic of the operation or at the operational level. For example, the browse view of the creator differs from that of the normal user's browsing view. You can define two action methods externally, or you can manipulate them within an action method based on specific logic. The specific application of which way should be handled according to the actual situation.
Such an architecture should be able to meet the functional needs of the vast majority of coarse-grained permission controls in a context that is easy to understand and manage. But in addition to coarse-grained permissions, the system will inevitably include countless specific instance of fine-grained permissions. These issues are left to the business logic to address, and such considerations are based on the following two points:
On the one hand, fine-grained permission decisions must be made to model the support information for the rights assignment on the resource before it can be implemented. For example, if the creator and the average user are asked to see different information content, the resource itself should have information about its creator. Fine-grained permissions, on the other hand, often have significant business logic dependencies. For different business logic, it often means a completely different principle and strategy of authority judgment. In contrast, coarse-grained permissions are more versatile, implement it as a schema, with more reuse value, and it is cumbersome and not necessary to implement fine-grained permissions judgments as a level of architecture, and it is simpler and more flexible to implement custom code.
So fine-grained control should be resolved at the bottom, resource when instantiated, it is necessary to specify owner and Groupprivilege in the operation of the resource is bound to determine the type of constraint: Whether it is Ownerok or Groupok or Allok. Group and role strictly separate user and group are many-to-many relationships, group is only used to classify users, does not contain the meaning of any part, but to grant user, not group. If the user needs a combination of multiple privilege that are not yet in use, the role must be added. Privilege must be able to access the resource, with the user parameter, so the permissions control is complete.
Thought:
The core of the authority system consists of the following three parts: 1. Create permissions, 2. Assign permissions, 3. Use permissions, and then the main participants in each part of the system are compared as follows: 1. Create authority-creator creation, 2. Assign Permissions-User:
1. Creator Create privilege, Creator in the design and implementation of the system will be divided, a subsystem or called modules, what should have permissions. Here is the privilege and Resource of the object statement, and did not really connect privilege with the specific Resource instance, to form a operator.
2. The Administrator specifies the association of privilege with Resource Instance. In this step, permissions are actually associated with resource instances, resulting in operator (privilege Instance). The administrator uses the basic element of operator to create his ideal privilege model. For example, create a role, create a user group, and use the
