Permission System Overview!

Permission System Overview
 

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 object is considered, not a specific instance of the object. 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 a specific object needs to be considered. Of course, the fine granularity is to consider a specific instance only after the coarse-grained object category is considered. 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, moreover, it is not necessary to use custom code to implement it more concisely and flexibly.
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.

Thoughts:
The core of the permission system consists of the following three parts: 1. create permissions. 2. assign permissions. 3. then, the main participants in each part of the system are as follows: 1. create permissions-create creator, 2. permission assignment-Administrator assignment, 3. permission-user:
1. creator creates a privilege. creator is divided during system design and implementation. What permissions should a sub-system or module have. Here, the object declaration of privilege and resource is completed, and privilege is not really linked with a specific resource instance to form an operator.
2. Administrator specifies the association between privilege and resource instance. In this step, the permissions are actually associated with the resource instance and the operator (privilege instance) is generated ). The Administrator uses operator as a basic element to create an ideal permission model. For example, operations such as creating roles, creating user groups, assigning users to user groups, and associating user groups with roles are completed by administrators.
3. the user uses the permissions assigned by the Administrator to use various subsystems. As a user, administrator has a permission model that is suitable for management and maintenance. As a result, the programmer only needs to answer a question, that is, what permissions can be used to access any resources, that is, the operator mentioned above. Providing operator for programmers means putting armor on the system. The administrator can follow his wishes to establish the desired permission framework and add, delete, and manage the relationship between resource and privilege. You can set the roing between user and role on your own. (If creator is regarded as the inventor of basic, Administrator is the user of basic, and he can do some script-based programming.) operator is the most important part of the system, and it is a bond, A link between programmer, administrator, and user.

Use a function module as an example.
1. Create role functions and assign roles:
1. If you want to create an employee management module (resources), this module has three functions: add, modify, and delete. Each of the three functions is assigned an ID, which is called the function code:
Emp_addemp, emp_deleteemp, emp_updateemp.
2. Create a role, add the above function code to the permissions of this role, and save it to the database. Roles include system administrators and testers.
3. Create an employee account and assign one or more roles to the employee. For example, this employee can be either a company administrator or a tester. In this way, when he logs on to the system, he will only see the modules that he has permissions.
2. Add the identity information to the session.
Log on to the database to check whether the employee exists. If yes, search for the employee's permission information based on the employee's Sn and add all the employee's permission information to a hashmap, for example, put the above emp_addemp and so on in this hashmap. Save the hashmap in a userinfobean. Finally, put the userinfobean in the session so that the system can obtain the identity information of the user at any time during the entire program operation.
3. Make different display based on the user's permissions.
You can compare the permissions of the current employee with the "function ID" assigned to the menu to determine whether the current user has the permission to open the menu. For example, if the hashmap that saves employee permissions does not have any of these three IDs, the menu will not be displayed. If the employee's hashmap has any ID, the menu will be displayed.
For a news system (resouce), assume that it has such a function (privilege): View, publish, delete, modify; assume that for deletion, some "news system administrators can only delete those published before January 1, January, while super administrators can delete all such restrictions, which belong to business logic rather than user permissions. That is to say, the permission is responsible for whether to delete permission. As to which content can be deleted, it should be determined based on userrole or usergroup (of course, when assigning permissions to userrole or usergroup, the above two business logic should be included ).
A single user can have multiple roles, but at the same time the user can only use one role to enter the system. Roles can be divided by department or organization based on the actual situation. The number of permissions assigned to a role depends on the permissions assigned to the system administrator. The key to user-role-permission is role. A user logs on to the console using the user and role attributes (because a user can have multiple roles, but can only assume one role at a time). The user's permissions are obtained based on the role, perform initialization after logon. The trick is that a user can only log on with one role at a time.
Dynamically create different groups for different "Roles". Create a separate group for each project. Create a new group for the new project. The permission judgment should be controlled in commercial methods. For example, different users have different "operation capabilities" (coarse-grained control should meet the requirements ), different users have different "visible regions" (reflected in the permission data for the operated object, whether to allow access by the current user, this requires permission control when modeling business data ).

Scalability:
With the basic framework of user/permission management, the concept of WHO (user/group) will not need to be extended frequently. The change may be due to the introduction of new what (New Resource Type) or new how (new operation method) in the system ). In the three basic concepts, extension only on permission is not enough. In such a design, permission essentially solves the problem of how, that is, the "what" operation. So what is the definition at what level? It is more appropriate to define permission at the Business Method level. For example, publishing, purchasing, and canceling. Every business method can mean an "action" performed by the user ". It is defined at the business logic level. On the one hand, it ensures the "purity" of the data access code, and on the other hand, it is "sufficient" in terms of functionality. That is to say, the lower level, the free access to data, the higher level, and the finer control of permissions.
Determine the appropriate levels of permission definitions. Further, we can find that permission actually implies the concept of what. That is to say, what operations will be a complete operator. For example, the "publish" operation implies the "publish" concept of "information", while the "publish" operation is meaningless for "commodities. Similarly, the "purchase" operation implies the "purchase" concept of "commodities. The binding here is also reflected in a large number of general operations with the same name. For example, you need to distinguish the two operations with the same name "Delete" and "delete information.
The ability to provide a permission system is extended in the concept of operator (resource + permission. The proxy mode is a very suitable implementation method. The implementation is roughly as follows: In the business logic layer (EJB Session Facade [stateful sessionbean]), obtain the methodname of the business method, and then retrieve operator Data Based on classname and methodname, then, based on the operator information and the user information saved in stateful, determine whether the current user has the operation permission for this method.
In the EJB mode, an application can define a clear business hierarchy, while a business may mean different views. When multiple views correspond to one business logic, for example, swing client and JSP client access the business implemented by the same EJB. Application permissions on the business layer provide centralized control. In fact, if the permission system provides the query capability, it will find that the permission can no longer be understood at the view level. It only needs to control the interface based on the query results.

Flexibility:
Group and role are only a means to assist in implementation and are not necessary. If the system has many roles and one-by-one authorization violates the "simple and convenient" purpose, the group is introduced to form a group with the same permissions for centralized authorization. The same is true for role. It is a set of operator types to simplify operations on multiple operators.
Role frees specific users and groups from permissions. A user can assume different roles to achieve the flexibility of authorization. Of course, group can also implement similar functions. However, in actual business, group division is divided by administrative organization structure or business functions. If a user is forcibly added to different groups for permission management, the management complexity may occur.
Domain Application. To make the authorization more flexible, you can abstract the where or scope, called domain. The real authorization is performed within the domain range, and the specific resource is divided into different domain. For example, a news agency has two major branches in China and abroad, and both have different resources (sports, life, and current affairs and politics ). If the permission rules for all Chinese news are the same, the permission rules for all foreign news are also the same. You can create two domains, authorize them separately, and then associate all kinds of news with different domains and be controlled by permissions on the domains to simplify them.
The permission system should also consider separating functional authorization from resource authorization. Many systems only have permission control over the maintenance of system data (resources), but do not have permission control over system functions.
It is best to manage permission systems hierarchically rather than centrally. Most customers want different departments to be able to manage only the internal transactions of their departments, rather than a centralized administrator or Administrators Group. Although you can add people from different departments to the Administrators group, they have excessive permissions and can manage system resources rather than department resources.
Forward authorization and negative authorization: it is assumed that the subject does not have any permissions at the beginning, and then the permission is granted as needed. This is suitable for systems with strict permission requirements. Negative authorization assumes that the subject has all permissions at the beginning, and then revokes some special permissions.
Permission calculation policy: users, groups, and role in the system can be authorized, and permissions can be divided into positive and negative permissions. A set of policies are defined when the user's permission is calculated.
The system should have an accessservice for centralized permission management, responsible for permission maintenance (business administrator, security management module) and use (end user, each function module ), this accessservice must consider both general and special permissions. Although there can be many specific implementations, such as using the proxy mode, these proxies should be made dependent on accessservice. The function of each module calls accessservice to check whether there are corresponding permissions. Therefore, permission management is related to all functional modules of the system rather than the security management module. Developers of each function module should be familiar with the security management module. Of course, they should also be familiar with the security rules of this module from the business perspective.

Technical implementation:
1. form-based authentication, which is commonly used. However, when a user arrives at a resource that is not authorized to access, the Web Container sends out an HTML page and requires the user name and password to be entered.
2. a servlet sign in/sign out is used to process all requests in a centralized manner. The disadvantage is that the application must handle all requests by itself.
3. Use filter to prevent users from accessing some unauthorized resources. The filter intercepts all requests/response,
Then put a token that passes the verification in the user's session, and then the filter determines whether to allow response each time based on the token.

This mode is divided:
Keeper: filters or unified servlet.
Authenticator: Use JAAS to implement it on the web.

User qualification storage LDAP or database:
1. The Keeper intercepts and checks each protected resource. First, check whether this user has created a login session. If not, check whether there is a global session related to authenticator?
2. If there is no global session, this user is directed to the sign-on page of authenticator, requiring the user name and password.
3. authenticator accepts the user name and password and verifies the user through the user's qualification system.
4. If the verification succeeds, Authenticator creates a global login session and directs the keeper to create a login session for the user in his web application.
5. authenticator and keepers jointly share cookies, or use tokens in the query characters.