Permission system summary
Foreword: Permissions are often an extremely complex problem, but it is also possible to express such a logical expression: Decision "WHO" logical expressions for WHICH-performing how are 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.
Objective: Intuitive, because the system will eventually be maintained by end users, the intuitiveness and easy understanding of permission assignment is more important, and the system has worked hard, and the inheritance of the group, in addition to 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: For access control methods in an enterprise environment, there are usually three types: 1. Autonomous access control methods. 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.
Name: Coarse granularity: Indicates the class, that is, considering the Type of Object, regardless of an object's specific instance. 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: Representation level, that is, the instance of objects, of course, the fine grain is a specific example after considering the class of 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.
Principle: Permissions logic cooperate with 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: Preder 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: With role, users are just pure users, 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.
Groups can directly map organizational structures, and Role can directly map the business role in the organizational structure, which is more intuitive and flexible. Role's contribution to the system is essentially provided with a distribution unit comparing the crude particles. GROUP and Operator are multi-to-many relationships. The relationship between the concepts is shown below: Explanation: The definition of Operator includes Resource Type and Method concept. That is, what and how concept. The reason why WHAT and HOW is bound to be used as an Operator concept rather than separate modeling, because many how to make something for a WHAT. For example, the release operation makes sense to the news object, and there is no meaning to the user object. The meaning of how itself is also different. Specifically, n types of operations can be defined for each WHAT. For example, for the object of the contract, you can define a creation, submit an operation, check conflict operation. It can be considered that how concept corresponds to every business method. Among them, the operations associated with specific user identity can be defined in the operational logic of the operation, or may be defined at the operating level. For example, the creator's browsing view requires different contents of the browsing view of the ordinary user. Two operation methods can be defined externally, or may be processed according to the specific logic within one operation method. Which way of specific use should be processed according to the actual situation. Such an architecture should be able to meet the functional needs of most of the coarse granular permission control in the case of easy understanding and management. However, in addition to coarse granular permissions, there will be countless fine-grained permissions for specific instances in the system. These issues are resolved to business logic, which is based on the following two points: On the one hand, the permissions of fine-grained permissions must be implemented in support information that must be allocated on the resource. For example, if the creator and ordinary users see different information content, the resource itself should have information on its creator. On the other hand, the permissions of fine-grained levels often have considerable business logic correlation. For different business logic, often means completely different privileges and strategies. In contrast, coarse granular permissions are more versatility, and it is achieved as an architecture, more reused value; and the permissions of fine particle size are cumbersome, and it is not necessary. It is more concise and flexible to achieve customized code. Therefore, fine-grained control should be resolved under the bottom layer, and Resource is instantiated, you must specify Owner and Groupprivilege to determine the type of constraint when operating the resource: OWNEROK or GROUPOK or allok. Groups should be multi-to-many relationships with Role strictly separation of User and Group, and Group is only used to classify users, and does not contain any Role; Role is only granted User, not Group. If the user needs a combination of various Privilege, it is necessary to add ROLE. Privilege must be able to access the resource, with the user parameter, so permission control is complete.
Thought: The core of the permission system consists of the following three parts: 1. Create permissions, 2. Allocate permissions, 3. Use permissions, then the main participants of the system are as follows: 1. Create permission - Creator creation, 2. Assignment Permissions - Administrator assignment, 3. Use permissions - User: 1. Creator creates Privilege, Creator will divide, a subsystem or a module when designing and implementing a system, what permissions should be there. Here, this is the object declaration of Privilege and Resource, and it does not really contact the Privilege to the specific Resource instance to form an Operator. 2. Administrator Specifies the association of Privilege and Resource Instance. In this step, the permissions truly associated with the resource instance, producing Operator (PrivileGe Instance). Administrator uses Operator's basic elements to create his ideal permission model. For example, create a role, create user groups, assign users to user groups, associating user groups and roles, etc. ... These operations are done by Administrator. 3. User uses the permissions assigned by Administrator to use each subsystem. Administrator is a user, there is a more suitable model for him to manage and maintain in his mind. So, as long as the programmer answers a question, what is the permissions can access what resources, that is, the Operator that said. The programmer provides Operator means wearing a helmet to the system. Administrator can establish his hoped permission framework in accordance with his will, delete, manage Resource and Privilege relationships. You can set the correspondence between users and roles Role. (If Creatrator is as a Basic inventor, Administrator is Basic's user, he can do some script programming) Operator is the most critical part of this system, it is a link, a department in Programmer, Administrator, Between User.
Use a functional module to give examples. One. Establish a role function and assign it: 1. If you want to do an employee management module (ie, resources), this module has three features, namely, addition, modify, delete. Assign these three functions each assigned an ID, this ID called function code: EMP_ADDEMP, EMP_DELETEEMP, EMP_UPDATEEMP. 2. Create a role (Role), add the above function code to this role's permissions and save it into the database. The roles include system administrators, testers, etc. 3. Establish an employee's account and assign one or several roles to this employee. For example, this employee can be either company administrators or test staff. This way he logs in to the system will only see the modules he owns permissions. Two. Add identity information to the session. When logging in, look for this employee in the database, if there is, if you exist, then find the employee's permission information according to the employee's SN, put all the permissions information of the employee into a HashMap, such as putting the above EMP_ADDEMP, etc. Hashmap. Then save the HashMap in a UserInfobean. Finally, put this UserInfobean in the session, so that the system can obtain the identity information of this user at any time during the operation of the program. three. Different from the user's permissions. You can compare the privilege of the current employee and "function ID" assigned to this menu to determine if the current user has permission to open this menu. For example: If you don't have any one of these three IDs in the HashMap of the employee permissions, then this menu will not display, if there is any ID in the employee's HashMap, this menu will be displayed. For a news system, it is assumed that it has a function (Privilege): view, release, delete, modify; assume that "the news system manager can only delete the release of January, and super administrators can Delete all such limits, which belongs to the business logic, not the user rights range. That is to say, the permission is responsible for the permission to delete the permission, as for which content can be deleted should be determined according to userrole or usergroup (Of course give UserRole The or usergroup allocation should contain two business logic). One user can have a variety of roles, but the user can only enter the system with a role. The division method of the role can be divided according to the actual situation, according to the department or institution Divided, as for how much permissions of the role, this is to see how much the system administrator gives him. User-Role-permission is the role. When the user logs in, the user and role are logged in (because A user can have a variety of roles, but can only play a role at the same time), obtain the user's permissions according to the role, after logging in to initialize. This skill is to log in with a single role. For different groups of different "roles", each project creates a separate group. For new projects, create new groups. In the permission judgment, it should be controlled in business methods. For example: different The user's "operational ability" is different (coarse granularity should be able to meet the requirements), and the "visual area" of different users is different (reflected in the authority data of the object being operated, whether the current user is allowed, this It is necessary to consider privilege control when business data modeling is required).
Scalability: With the basic framework of user / permission management, the concept of WHO (user / group) will not often be extended. Change may be to introduce new What (new resource type) or new HOW (new way of operation). That is in three basic concepts, it is not enough to extension on Permission. In this design, Permission is substantially solved in the problem, that is, the operation of "how". So which level is defined in this "how"? Definition of Permission is appropriate in the "Business Method" level. For example, release, purchase, and cancel. Each business method can mean a "action" that the user is going. Defining at the level of business logic, on the one hand, the "purity" of the data access code is guaranteed, and on the other hand, it is also "sufficient". That is to say, for a lower level, free access data, the higher level, more fine control permissions. Determine the right level defined by Permission, further, and it is possible to find that Permission actually implies the concept of what. That is, how the WHAT will be a complete Operator. For example, "release" operation, implies the "information" "release" concept, and it is meaningless to publish the operation for "goods". Similarly, "purchase" operation implies the "purchase" concept of "goods". The bindings here also reflect the operation of a large number of commonly used names, such as, requires different operations that distinguish between "product deletion" and "deletion of information". Different operations with "delete". The extension capability of providing permission systems is to extension in the concept of Operator (Resource Permission). The Proxy mode is a very suitable implementation. The implementation is approximately as follows: in the business logic layer (in EJB Session Facade [Stateful SessionBean], acquiring the MethodName of the business method, retrieve the Operator data according to ClassName and MethodName, and then determine the current user according to the user information saved in this Operator information and STATEFUL Does the operation permission of this method are available. Applying In EJB mode, you can define a very clear business hierarchy, and a business may mean different views, when multiple views correspond to a business logic, such as the Swing Client, and JSP Client access the same Business is implemented by EJB. Applying rights on the business layer to provide centralized control capabilities. In fact, if the permissions system provides query capabilities, then it will be found that the view hierarchy is already not understanding permissions, it only needs to control the interface according to the query results.
Flexibility: Group and Role, just a means of assisting achievements, not required. If there are many Role of the system, authorize the "simple and convenient" purpose, then introduce the GROUP, form the ROLE of the permissions to set a Group for centralized authorization. Role is the same, is a collection of Operator, is to simplify the operation of multiple Operator. Role liberates specific users and groups from permissions. A user can assume different roles to achieve licensed flexibility. Of course, Groups can also achieve similar functions. However, in the actual business, the Group is more divided into administrative organizational structures or business features; if the permission management is forcibly to join a different group, it will lead to the complexity of management. Domain application. In order to authorize more flexible, you can abstract WHERE or Scope, called Domain, the real authorization is in the range of Domain, and the specific Resource will be divided into different Domain. For example: a news organization has two major branches of China, and there are different resources in both branches (sports, living, and current affairs). If all domestic news rights rules are the same, all foreign news rights rules are the same. Two domains can be established, authorized separately, and then use all kinds of news from different domains, and are controlled by the permissions on the domain. Permission systems should also consider separating functional licenses with resource-based authorization. Many systems only have permission control for data (resources) in the system, but no permission control for system functions. The permission system is preferably hierarchical instead of centralized management. Most customers want different departments to manage transactions within their sectors, rather than anything that requires a concentrated Administrator or Administrators group to manage. Although you can add people from different departments to the Administrators group, but their permissions are too much, you can manage the entire system resources rather than the resource of the department. Positive authorization and negative authorization: Positive authorization assumes that the subject does not have any permissions, and then grant permissions as needed to provide a strict system. Negative authorization assumes that the subject has all rights and then retrieves some special permissions. Permission calculation strategy: User, Group, and role in the system can be authorized, permissions can have a positive and negative points, define a set of strategies when calculating the user's payings. There should be an AccessService, which should have a centralized administrative privilege, the maintenance of privileges (Business Administrators, Security Management Modules) and Usage (end users, each function module), which should consider general permissions and special permissions at the time of implementation. Although there are many implementations, such as using Proxy mode, these proxy should be made dependent on AccessService. An AccessService is called in each module function to check if there is a corresponding permissions. Therefore, rights management is not a matter of security management modules, but there is a relationship with the functional modules of the system. The developers of each function module should be familiar with the security management module, of course, it is also necessary to familiarize with the security rules of this module.
Technology implementation: 1. Form-type authentication, this is common, but when the user reaches a resource that is not authorized to access, the web container issues an HTML page to request the username and password. 2. A servlet Sign IN / Sign OUT to centrally process all request, the disadvantage is that the application must be handled by the application. 3. With Filter to prevent users from accessing some unauthorized resources, Filter will intercept all request / response, then place a verification through the identifier in the user's session, and then Filter rely on this identity to determine whether to release Response. This mode is divided into: GateKeeper: Take a Filter or Uniform Servlet. Authenticator: Using Jaas yourself in the Web.
User Qualification Storage LDAP or Database: 1. Gatekeeper intercepts checking each reached protected resource. First check if this user has a login session that has already created. If not, Gatekeeper checks if there is a global and authenticator related session? 2. If there is no global session, this user is directed to the AUTHENTICATOR SIGN-ON page, requiring username and password. 3. Authenticator accepts username and password, verifying users through the user's qualification system. 4. If the verification is successful, Authenticator will create a global login session and guide Gatekeeper to create a login session for this user in his web application. 5. Authenticator and Gatekeepers share cookies or use tokens in the Query characters.
