Authorization design (preliminary draft)
1. Preface:
Authorization management is often an extremely complicated issue, but it can also be simply expressed as a logical expression: determine whether the logical expression of "Who performs How on What (Which)" is true. For different applications, it is necessary to compare N multiple solutions such as maintainability, flexibility, and completeness according to the actual situation and specific structure of the project, and select the appropriate solution.
2. Goal:
intuitive, because the system will eventually be maintained by the end user, the intuitive and easy-to-understand distribution of permissions is more important and simple, including the simplicity of the number of concepts, the simplicity of the sense, and the simplicity of functions. It is unrealistic to use a permission system to solve all permission problems. In the design, it is based on this idea that the frequently changing part with stronger "customization" characteristics is judged as business logic, and the frequently identical part with stronger "general" characteristics as authority logic is based on this idea.
3. Status Quo:
There are generally three types of access control methods in a corporate environment:
1. Autonomous access control methods: At present, most of the access control modules in information systems in our country basically rely on autonomous access control methods. Access control lists (ACLs) in the
2. Mandatory access control method: used for military applications with multi-level security levels.
3. Role-based access control method (RBAC): It is currently recognized as an effective method to solve the unified resource access control of large enterprises. Its two notable features are: 1. Reduce the complexity of authorization management and reduce management overhead. 2. It flexibly supports the security strategy of the enterprise, and has great scalability to the changes of the enterprise.
4. Noun:
Coarse-grained: Represents the category level, that is, only the type of object is considered, and a specific instance of the object is not considered. For example, in user management, creation and deletion are treated equally to all users, and the specific object instances of operations are not distinguished.
Fine-grained: indicates the instance level, that is, the instance of object needs to be considered. Of course, fine-grained is to consider the specific instance after considering the coarse-grained object category. For example, in contract management, list, delete, it is necessary to distinguish whether the contract instance is created by the current user.
5. Principle:
Permission logic matches business logic. That is, the authorization system aims to provide services for business logic. Quite a few fine-grained permissions issues are extremely unique and have no universal meaning, and they can also be understood as part of the "business logic". For example, the requirement: "a contract resource can only be deleted by its creator, users in the same group as the creator can modify it, and all users can browse it". This can be considered a fine-grained permissions issue, or it can be considered a business logic issue. Here it is a business logic issue, which should not be considered too much in the architecture design of the entire permission system. Of course, the architecture of the permission system must also be able to support such control judgments. In other words, the system provides enough but not complete control capabilities. That is, the design principle boils down to: "The system only provides coarse-grained permissions, and fine-grained permissions are considered the responsibility of business logic."
Permission formula: Who+What(Which)+How is the problem, where we implement What and part of the permissions problem of Which (coarse-grained and fine-grained, to a certain extent), and other permissions problems are left to the business logic to solve
6. Concept:
Who: The owner or subject of the permission (Principal, User, Group, Role, Actor, etc.)
What: The object or resource (Resource, Class) for which the permission is directed.
How: Specific permissions (Privilege, positive authorization and negative authorization).
Role: It is a role with a certain number of permissions.
Operator: Operation. Indicate the How operation to What.
7. Explanation:
User: Related to Role, the user is just a pure user, and the permissions are separated. User cannot be directly related to Privilege. If User has permission to a certain resource, it must be associated through Role. Solve the Who problem.
Resource: It is the resources of the system, such as department news, documents and other objects that can be provided to users for access.
Privilege: is the authority of Resource Related. It means that this permission is bound to a specific resource instance. For example, the publishing authority of departmental news is called "departmental news publishing authority". This shows that the Privilege is a publishing authority, and it is a publishing authority for resources such as departmental news. Privilege is determined by Creator during development. Privilege such as "delete" It is an abstract noun, and it has no meaning when it is not bound to any specific Object or Resource. Take news releases as an example, release is a kind of authority, but it is meaningless to just say that it is released. Because I don't know what the release can operate. Only when publishing and news are combined, will a real Privilege be produced. This is the Privilege Instance.
Role: It is a coarse-grained and fine-grained (business logic) interface, 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 content of Role. Role is not like User or The concrete entity of the Group is an interface concept, an abstract general term.
The definition of Operator includes the concepts of Resource Type and Method. That is, the concepts of What and How. The reason why What and How are bound together as an Operator concept instead of separately modeling and then establishing associations is because many Hows are meaningful for a certain What. For example, publishing operations are meaningful to news objects, but not to user objects.
8. Idea:
The core of the permission system consists of the following three parts: 1. Create permission, 2. Assign permission, 3. Use permission, then, the main participants of each part of the system are compared as follows: 1. Create permission-Creator creation, 2. .Assign authority-Administrator assignment, 3. Use authority-User:
1. Creator creates Privilege, Creator will divide when designing and implementing the system, a subsystem or called a module, what permissions should it have. What is done here is the object declaration of Privilege and Resource, and it does not really link Privilege and specific Resource instances to form Operator.
2. The Administrator specifies the association between Privilege and Resource Instance. In this step, the authority is really linked to the resource instance, resulting in an Operator (Privilege Instance). Administrator uses the basic element of Operator to create his ideal permission model. For example, creating roles, creating user groups, assigning users to user groups, associating user groups with roles, etc.... These operations are all done by Administrator.
3. User uses the authority assigned by Administrator to use each subsystem. Administrator is a user. In his mind, he has a permission model that is more suitable for him to manage and maintain. Therefore, the programmer only needs to answer one question, which is what permissions can access which resources, which is the Operator mentioned above. The programmer providing the Operator means putting the armor on the system. Administrator can build the permission framework he wants according to his wishes, and he can add, delete, and manage the relationship between Resource and Privilege. You can set the corresponding relationship between User and Role by yourself. (If you regard Creator as the inventor of Basic, Administrator is the user of Basic, and he can do some script-style programming) Operator is the most critical part of this system, it is a link, one is tied to Programmer, Administrator, The link between users.
Any network or stand-alone program that involves multiple users with different permissions will have permissions management problems. The most prominent is the MIS system.
What I want to talk about is the database design and implementation of MIS system authority management. Of course, these ideas can also be promoted and applied, for example, to manage different levels of user authority in the BBS.
Authorization design usually includes three parts: database design, application programming interface (API) design, and program implementation.
These three parts are interdependent and inseparable. To achieve a complete authority management system, the feasibility and complexity of each link must be considered, and even execution efficiency must be considered.
We categorize the permissions, firstly for data access permissions, usually four types of entry, browsing, modification, and deletion, followed by functions, which can include all indirect data access operations such as statistics. In addition, we may also Access to certain fields in some key data tables is restricted. In addition, I can't think of another permission category.
A perfect permission design should have sufficient scalability. That is to say, the addition of new and other functions to the system should not bring major changes to the entire permission management system. To achieve this goal, firstly the database design is reasonable, and secondly Application program interface specification.
Let's discuss database design first. Usually we use a relational database, and permission management based on Lotus products is not discussed here.
The permission table and related content can be described by six tables, as follows:
1 Role (ie user group) table: includes three fields, ID, role name, and description of the role;
2 User table: includes three or more Fields, ID, user name, description of the user, and others (such as address, phone, etc.);
3 Role-User Correspondence Table: This table records the correspondence between users and roles. A user can belong to multiple roles , A role group can also have multiple users. Contains three fields, ID, role ID, user ID;
4 Restricted content list: This table records all data tables, functions and fields that need to be distinguished and restricted by permissions and their descriptions, including three fields, ID, name, and description;
5 Permission list: This table records all the data to be controlled Permissions, such as entry, modification, deletion, execution, etc., also include three fields, ID, name, and description;
6 Permission-Role-User Correspondence Table: Under normal circumstances, we make the following provisions for the permissions of roles/users, The role has the permission that is expressly permitted, and all others are prohibited. The user inherits all the permissions of the role to which it belongs. All permissions within this range are permitted except for the express prohibition, and all permissions outside the scope are prohibited except for the express permission. The design of this table is the focus of authority management, and there are many design ideas. It can be said that each has its own merits, and it cannot be said that a certain method is good. In this regard, my opinion is to find a suitable one that can solve the problem based on my personal situation.
Let me talk about the first and easiest way to understand. Design five fields: ID, restricted content ID, permission ID, role/user type (boolean field, used to describe whether a record record is role permission or user permission), Role/user ID, permission type (boolean field, used to describe a record to indicate whether to allow or prohibit)
Well, there are these six tables, according to Table 6, we can know whether a certain role/user has or forbid Permissions.
In other words, this design is enough, we have fully realized the required functions: roles and users can be customized separately, and it is also quite extensible. For example, if new functions are added, we only need to add one or more Records are sufficient, and the application program interface does not need to be changed, which is quite feasible. However, in the process of program implementation, we found that using this method is not very scientific. For example, when browsing the permissions owned by a user, you need to query the database multiple times (even recursively), which is extremely inconvenient. So we need to think of other ways. Everyone who has used the Unix system knows that the Unix file system divides the file operation permissions into three types: read, write, and execute, which are identified by three codes 1, 2, and 4, and the user has both read and write permissions for files. It is recorded as 3, which is 1+2. We can also use a similar approach to solve this problem. The initial idea is to modify the permission list and add a field: identification code. For example, we can identify the entry permission as 1, the browsing permission as 2, the modification permission as 4, the deletion permission as 8, and the execution permission as 16. In this way, we can easily put together the permissions described in several records through the method of permission accumulation. For example, suppose a user ID is 1, the corresponding restricted content ID of the inventory table is 2, and the role is specified at the same time. If the type is 0 and the user type is 1, we can describe the user's authority to enter, browse, modify, and delete the inventory table as: 2,15,1,1.
It's really simple, isn't it? There is even a more radical way. Add a column to the restricted content list and define the identification code. In this way, we can even use a simple record to describe all the permissions that a user has to all content. Of course, the premise of this is to limit the amount of content to a relatively small amount, otherwise, hehe, the number of n-th powers of 2 increases but the amount is amazing, and it is not easy to analyze.
On the surface, the above method is sufficient to achieve the purpose of implementing functions and simplifying the complexity of database design and implementation, but there is a drawback in doing so. The list of permissions we involve is not independent of each other but dependent on each other, such as modifying permissions. In fact, it includes browsing permissions. For example, we may simply set the user’s access to the inventory table to enter + modify + delete (1+4+8=13), but in fact, the user has (1+ 2+4+8=15), that is, in this scheme, 13=15. So when we call the API to ask whether a user has the browsing permission, we must determine whether the user has the permission to modify the data table. Therefore, if the inclusion relationship between the permissions cannot be fixed in the program, the application program interface cannot be used. Simply make a judgment. But this contradicts our goal of "sufficient scalability".
How to solve this problem? I thought of another way to set the identification code, which is to use prime numbers. We might as well set the basic logo codes for entry, browsing, modification, deletion, and execution as 2, 3, 5, 7, and 11. When the permissions contain each other, we set its logo code to two (or Multiple) The product of basic mark codes. For example, you can set the mark code of the "modify" function as 3*5=15, and then multiply all the permissions to get the final permission identification value we need. In this way, when we ask whether the user has a certain authority, we only need to decompose the final value into prime factors. For example, we can define a user with the authority to enter+modify+delete the inventory table as 2*15*7=2 *3*5*7, which means that the user has the right to enter + browse + modify + delete the inventory table.
Of course, the premise of using the above method for the permission list is that the number of records in the permission list is not too many and the relationship is not very complicated. Otherwise, the machine will be fooled by just parsing the permission code:)