Role-based Access Control (RBAC) is used to associate users with rights Based on roles.
Simply put, a user has several roles, and each role has several permissions. In this way, a user – role – permission authorization model is constructed. In this model, the relationship between users and roles, roles and permissions is generally many-to-many. (As shown below)
What are the roles? It can be understood as a set of certain number of permissions, the carrier of permissions. For example, in a forum system, “super administrator” and “moderator” are roles. The moderator can manage the posts in the version, can manage the users in the version, etc., these are permissions. To grant these rights to a user, you do not need to grant the rights directly to the user. You can grant the role of Moderator to the user.
When the number of users is very large, it is cumbersome to authorize the system for each user individually. In this case, you need to group users, with multiple users in each user group. In addition to authorizing users, you can also authorize user groups.
In this way, all permissions of the user are the sum of the permissions of the user and the permissions of the user group. (The following figure shows the relationship among user groups, users, and roles.)
What do permissions look like in an application system? The operation of function modules, the deletion and modification of uploaded files, the access to menus, and even the visibility control of a button or a picture on the page can all belong to the scope of permissions.
Some permissions are designed in a user-role-permit-resource authorization model, with functional operations as one category and files, menus, and page elements as another. While in the data table modeling, the unified management of functional operations and resources, that is, are directly associated with the permission table, which may be more convenient and easy to expand. (See below)
Note that there is a column of “Permission types” in the permission table, which are distinguished according to their values. For example, “MENU” indicates the permission to access menus, “OPERATION” indicates the permission to operate function modules, “FILE” indicates the permission to modify files, and “ELEMENT” indicates the visibility control of page elements.
There are two advantages to this design.
First, there is no need to distinguish between permissions and resources (in fact, sometimes it is difficult to distinguish, such as menus, which is interpreted as resources or function module permissions?). .
Second, convenient extension, when the system to new things for permission control, I only need to establish a new associated table “permission XX associated table”, and determine the permission type string of this kind of permission.
It should be noted that the permission table and the permission menu association table, and the permission menu association table and the menu table are one-to-one relationships. (File, page permission points, function operations, etc.). That is, for every menu added, a record must be inserted into each of the three tables simultaneously.
In this way, the permission table can be directly associated with the menu table without the permission menu association table. In this case, a new column must be added to the permission table to save the ID of the menu. The permission table can distinguish which record under the type by the “permission type” and this ID.
Up to this point, the complete design diagram for the extended model of the RBAC authority model is as follows:
As the system becomes larger and larger, you can introduce role groups to manage roles. Different from user groups, role groups do not participate in authorization.
For example, in the permission management module of a power grid system, a role is attached to a district office, which can be regarded as a role group and does not participate in permission allocation. In addition, in order to facilitate the management and search of the main table itself, tree structure can be used, such as menu tree, function tree, etc., of course, these do not need to participate in permission allocation.
The above is an extension of the basic RBAC model, and the specific design should be adjusted according to the needs of the project business. We welcome your criticism!
Author: Little Sparrow
Link: www.cnblogs.com/zwq194
