The following is taken from jdon (http://www.jdon.com/jive/Article.jsp?forum=46&thread=7309) Permission system summary (collection, finishing) Lie Wenlong http://www.jdon.com Jun 2, 2003 7:34 PM Reply Preface: Permissions are often an extremely complex problem, but it can also be simplified as such a logical expression: "Decision" WHO "logical expressions for WHICH-based HOW" 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. 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. The Group concept is effectively avoided while supporting permissions to avoid redefine: For access control methods in an enterprise environment, there are usually three: 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 to divide, a subsystem or a module when designing and implementing a system, what permissions should be made. 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. Scalability: The basic framework of user / privilege management, the concept of WHO (user / group) does not often need to scale. Change may be introduced in the system New What (new resource type) or new How (new operation mode). In three basic concepts, it is not enough to extension on Permission. In this design, Permission is substantially solved with how to work. That is, it means "how" what is "how"? What is the definition of the definition of the Permission definition in the "business method" level, such as release, purchase, cancel. Every business method can It means that the user's "action" is defined at the level of business logic, on the one hand, guarantees "pureness" of the data access code, and on the other hand, it is also "sufficient". That is, the lower Level, free access data, to a higher level, more fine control permissions. Determine the right level defined by Permission, and further, you can find Permission It 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. Re: Permission system summary (collection, finishing) Published: Jun 3, 2003 5:24 PM
Reply to the publisher: Iceant Post article: 464 / Registration time: 2002-10 Good job. Now We need a mailmentation
Re: Permission system summary (collection, finishing) Published: Jun 3, 2003 8:31 PM
Reply to the publisher: Lie Wenlong published articles: 14 / Registration time: 2003-06 Here's prawns are very admired, see alone, inspiration. Recently, I have read the Workflow documentation that is translated by paste, I look forward to more and better Dongdong.
Re: Permission system summary (collection, finishing) Published: Jun 4, 2003 12:24 AM
Reply Poster: Liujt Post article: 1 / Registration time: 2003-06 For the first time I log in, I have been able to read the documentation of the relevant authority of Lie Wenlong collected, benefited a lot! Good stuff. . . J road, there is a place
Re: Permission system summary (collection, finishing) Published: Jun 4, 2003 1:18 AM
Reply Poster: Tyrones published article: 59 / Registration time: 2002-08 I personally do permission management, fast for a month, so much, I have set up too much, marked, I will watch it again,
RE: Permission system summary (collection, finishing) Published: Jun 12, 2003 5:22 PM
Reply to the publisher: angus_han Post article: 4 / Registration time: 2003-04 Mark, I hope to see the corresponding sample code
Re: Permission system summary (collection, finishing) Published: Jun 15, 2003 12:03 PM
Reply to the publisher: Desert First Fairy published article: 5 / Registration time: 2003-05 Ask: I designed the data like this? ? Data Design: Basic Thoughts: Priviled, Role, Group,: User Permissions and ROLE: Privildge GroupGroup: User GroupUser_Info: Store various information about users User_right: User's permissions PRIVILED: Specific Permissions Table User_info : ID Int, Auto_increment, index user_id varchar ............ user_right (and not directly related to the priviledge occur, a user may have multiple roles) ID user_id Group_id varchar Role_id_group Varchar (with a "/" character separating) role: ID Role_id Priviledge_group VARCHAR (with "/" separated) Group: id group_id role_id_group priviledge: (two-stage tree structure) ID priviledge_id privile_name Parent (Parent)
Re: Permission system summary (collection, finishing) Published: Jun 16, 2003 8:38 PM
Reply Posted by: Cao Xiaoqi published article: 15 / Registration time: 2002-11 Open Source Redsaga ACL is under development, will not be available.
Re: Permission system summary (collection, finishing) Published: Jun 17, 2003 1:36 AM
Reply Poster: Dreamaster published article: 11 / Registration time: 2003-04 Well, give a suggestion: The concept of account should be added in the system, one can have different accounts, permission to bind the account, I don't know you The user said that the user is my account, my understanding, the user should be specific, such as an employee in the enterprise. Users can act as different roles are implemented by using different accounts, an account can be associated with multiple ROLE, but the assignment of their permissions should be calculated according to two different strategies: 1, pay the collection 2, the collection set
Re: Permission system summary (collection, finishing) Published: Jun 17, 2003 1:24 PM
Reply to: Green Tree Posts: 13 / Self: Zhuhai / Registration time: 2003-05 is wrong, this is not very troublesome, users remember so many accounts are tired. The same user can have multiple characters, and one role selection page can appear when logging in, and use the role access system after selecting a role. Our project is so real. The user has an account, the account is unique to identify a user, because there may be a redempt name. Re: Permission system summary (collection, finishing) Published: Jun 17, 2003 4:30 PM
Reply to: Dreamaster published article: 11 / Registration time: 2003-04 I said that the user name is entered when the login system is entered, this can't be unique, the only user ID in the system, if used What if the account uniquely identifies a user, then what if this user wants to change the account? For example, if you can assign someone a temporary account, let him visit some resources, this account will automatically make waste in a certain time, how do you deal with?
Re: Permission system summary (collection, finishing) Published: Jul 2, 2003 6:17 PM
Reply to the publisher: doisy Post article: 2 / Registration time: 2003-07 I still don't understand the difference between Group and Role is not the collection of some authorities?
Re: Permission system summary (collection, finishing) Published: JUL 8, 2003 7:39 PM
Reply to: jianxing Post article: 1 / Registration time: 2003-07 General understanding, in the RBAC category, Role refers to a set of users and a set of permissions, and Group refers to a group of users. > I still don't understand the difference between Group and Role>> Isn't a collection of some authorities?
Re: Permission system summary (collection, finishing) Published: Jul 7, 2003 3:11 PM
Reply to the publisher: Skysea002 Post article: 1 / Registration time: 2003-07 The article is very good and give me some useful info.
Re: Permission system summary (collection, finishing) Published: JUL 15, 2003 1:58 PM
Reply Poster: Menzy Post article: 1 / Registration time: 2002-12 Good article, indeed comprehensive, expanding the field of view
Re: Permission system summary (collection, finishing) Published: Jul 16, 2003 7:49 PM
Reply to the publisher: Status Post article: 4 / Registration time: 2003-07 good text!
Re: Permission system summary (collection, finishing) Published: Jul 21, 2003 6:28 PM
Reply Poster: 4 / Registration time: 2003-07 We now do the project, develop considerations are many, very sufficient; 1) System authority 2) Data item rights 3) Business objects related permissions but finally feel too Complex, operability is poor; so a practical security permission system is not just considering these technical levels!
Re: Permission system summary (collection, finishing) Published: Jul 22, 2003 1:32 PM
Reply Poster: Hitweis Posts: 4 / Registration time: 2003-06 About role-based rights management, there is a problem to ask you. In one project, permission has operation permissions and data privileges, according to an example: For example, there are three operations for a large company's financial statements, and there are three operations for the report: create, delete, and view. The company is large, divided into different regional A1 area A-area A2 headquarters - Region B - Region B1 area B2, such as employees EMP1 and EMP2, EMP1 only have area A1 report, EMP2 has region A1 report all permissions If the above authority is to establish two ROLLE, one is the view rights Role1 of the A1 report, one is all the permissions Role2 of the A1 report, and then gives EMP1 and EMP2 respectively, if this is, Isn't it necessary to define a lot of characters to achieve various functions! I don't know if my understanding is right, please advise, thank you! RE: Permission system summary (collection, finishing) Published: Jul 22, 2003 1:35 PM
Reply Poster: Hitweis Posts: 4 / Registration time: 2003-06 Sorry, the above picture did not show the level, it should be: ------------- Region A1 ------ Region A - Region A2 Headquarters -------- Region B - Region B1 ------------- Regional B2
Re: Permission system summary (collection, finishing) Published: Jul 22, 2003 3:15 PM
Reply to the publisher: zXpado Post article: 4 / Registration time: 2003-07 Not suitable, this is entangled with business and function permission, and does not reach the effect. It is recommended to do data permissions in a specific business.
Re: Permission system summary (collection, finishing) Published: APR 13, 2004 3:22 PM
Reply to the publisher: Tanik Post article: 8 / Registration time: 2004-04 Suggested data permission to do in specific business
