Role access control (RBAC) introduces the concept of role, in order to isolate the user (action subject, subject) and privilege (permission, indicating an operation on the resource, operation + resource ). As a proxy layer between a user and privilege, role decouples the relationship between permissions and users. All permissions should be granted to role rather than user or group. Privilege is a permission granule consisting of operation and resource, indicating an operation of resource. For example, delete news. Role-privilege is the relationship between role-to-role, which is the core of permissions. The two major features of Role-Based Access Control (RBAC) are: 1. the changes between roles and permissions are much slower than those between roles and users. This reduces the complexity of authorization management and management overhead. 2. flexible support for enterprise security policies and great scalability for enterprise changes. There are five roles in our system that need to access different content. 1.1 determine the objects to be operated by the role 1.1.1 using tables in the database as resources in this system there can be two solutions to define the objects to be operated by the role, one solution is that the role is directly associated with the tables in the database. That is to say, the relationship between the role and the table can be displayed when a table is created, but this design has a poor control, after the system is completed, it is stored in front of the customer in the form of a page. Is the content displayed on each page only related to one table in the database? If there is a relationship with multiple tables, you must first determine all permissions of a role of a specific user on these tables and then process the specific presentation layer; this method requires more judgment when requesting a page, which is equivalent to adding another database in the role page, that is, the relationship between roles, databases, and pages, it is obviously very troublesome to do this in a system with few database operations. 1.1.2 using pages as resources another way of defining resources in the system is to use pages as resources. When pages are used as resources, we can use an Asp.net built-in object session to store the role as soon as it is opened, and then the user will use this session to query the role permission table in the database when requesting the page, to determine whether the role has the permissions to perform various operations on the page. Of course, a user may have several roles and only needs to generate several more sessions to store the role. The advantage of this is that it is easier to determine when a user requests a page. 1.1.3 Resource Selection summary of the above two solutions I chose pages as resources, mainly because the system does not perform as many database operations as in his system. 1.2 as one of the core permissions, operation description operations generally include four types of operations: add, delete, modify, and query. The key issue lies in how to reflect these four operations in the database, there are still two solutions. First, you can use these four operations as four fields to indicate whether a subject has certain operations. Second, you can put these four operations in one field and use four binary numbers, A specific operation counts the binary data to 1. In this way, the permission operation looks clear and clear, and only one field is used to query the role permission table, without four fields, operation will be reduced a lot. 1.3 For a brief description of roles and users, a system will use its user base. In this group, there will certainly be many users with the same power to the system, therefore, users with the same power are divided into a role. In this way, the number of roles will certainly be less than the number of users. Therefore, in the future maintenance of large user data, you can simplify the maintenance process to user role management and role permission management. 1.4 after analyzing the basic data table of the system on user permissions, the basic data table required by the user management module of the system is displayed. 1. user information table 2. role info table 3. user Role Relationship table 4. role permission relationship table 5. permission object description in the table above, each table uses an idnumber as the primary key of the table. The relationship between users and roles is many-to-many, the relationship between roles and permissions is also many-to-many. The specific fields in each table are not listed at the moment. 1.5 analyze the basic data table. Assume that a user logs on to the system and the user is a legal user, after logging on to the user, you can determine the role of the user based on the user role table (This role can be either a role or multiple roles ); then, based on the role permission table, you can determine that the user has the right to perform a specific combination operation on those pages. In a narrow sense, permission management has enough of these five tables, but there is a function tree in our system. The nodes in the tree are displayed based on the permissions of specific roles, that is to say, you have to add a table function tree data table, which associates the page object with the node of the tree. Of course, not all pages correspond to a node, not all nodes must correspond to one page. I have analyzed the table design problem of this function tree in the hierarchical database design. I will not detail it here. I am using the parent node and child node design method. After logging on to the user, the user can find the corresponding page that can be operated and exists in the function tree node. Can this show the tree smoothly? It seems that there is still a small problem to solve! Because a user may correspond to several roles, several roles may obviously have the same operation power on the same page. If the page is a node of the function tree, after a user logs in, he/she must display the tree and try to remove the same node. In the background code, we can do this. The specific practice is to put the page ID numbers of all roles corresponding to a user into a datatable (a specific object in ado.net, is equivalent to a table), and then remove the duplicate page, that is, the page with the same ID number, then, search for the parent node of these pages in the function tree data table to generate a function tree. (two methods are used to generate the function tree: Deep traversal and wide traversal. This chapter will not discuss it ). Of course, we can create a table in the database that corresponds to the role function tree node. In this way, we can find non-repeated nodes in this table to generate a tree, which reduces a lot of background logic, it brings great convenience. 1.6 Summary of the permission management module: The permission management module of the system has a total of seven data tables: 1. user information table 2. role info table 3. user Role Relationship table 4. role permission relationship table 5. permission object description table 6. function tree data table 7. role function tree node table 1.7 Analysis of RBAC model the National Institute of Standards and Technology (NIST) Standard RBAC model consists of four component models, the four component models are the basic model rbac0 (core RBAC), The Role classification model rbac1 (hierarchal RBAC), and the role restriction model rbac2 (constraint RBAC) and the unified model rbac3 (combines RBAC ). The above sections mainly talk about rbac0. We can see from the actual use and the other three models of RBAC, in the RBAC model, role design is highly scalable and flexible. There are not many types of roles involved in the system, so the inheritance and restriction relationships of roles are not considered. However, many users think that the node duplication of the function tree can also be solved by the inheritance and restriction of roles. However, because there are not many nodes in the function tree, there are less than 20 nodes in total, so the rbac3 model is not used. Of course, this model also has some extensions. After reading some articles, I think the following points can better extend the RBAC model. 1. User Group authorization function. 2. Role type function. This function is not very important. To create a type table, each role can belong to a role type, which is easy to express and hierarchical. This function is mainly used to display the presentation layer. 3. Role priority function. You can define a priority table to give each role a priority level. when processing a role's request, the table is sorted into a linked list based on the role's priority level, the role requests in the linked list can be dynamically adjusted based on different priorities. When the system processes a role request, each time a role request is obtained from the first of the team, the first pointer of the team is directed to the next role request. 4. Role lifecycle function. This function can specify the role's survival time, which can be specified by the user or determined based on a certain condition. 5. The role dynamically changes the permission Function Based on the responsibility chain. In a chain of responsibility, a client program sends a request, which is passed along the chain of responsibility. each node in the chain will process the request in sequence. If the node cannot process the request, the request is forwarded to the next node of the responsible chain. Alternatively, each node in the responsible chain processes the request. In the process of processing, the role permissions dynamically change as needed. 6. The role dynamically changes permissions based on the status. There may be multiple states in an application. For example, in a word processing program, when the state of a file is read-only and the state of a file is readable and writable, its functions are different, then, the role needs to dynamically change the permission set based on this state change to meet the requirements of this application. Of course, the existence of a model does not mean that any design must apply a certain model, but it just gives us some good inspiration and a set of mature methodologies, after all, these are just engineering models, not mathematical or physical theorems. We will design them based on actual needs and reasonably consider some scalability. In combination with these models, we will certainly be able to design a system that meets our needs.
