RBAC permission management

Role-Based Access Control (RBAC) is a role-based access control. Simply put, a user has several roles and each role has several permissions. In this way, the authorization model of "user-role-permission" is constructed. In this model, the relationship between users and roles and between roles and permissions is usually many-to-many. (For example,)

What is a role? It can be understood as a set of a certain number of permissions and the carrier of permissions. For example, in a forum system, "Super administrator" and "moderator" are all roles. The moderator can manage the posts in the version and users in the version. These are permissions. To grant these permissions to a user, you do not need to directly grant the permission to the user. You can assign the "moderator" role to the user.

 

When the number of users is very large, it is very cumbersome to authorize (assign roles) each user in the system one by one. In this case, you need to group users. Each user group has multiple users. In addition to user authorization, you can also grant permissions to user groups. In this way, all the permissions of a user are the sum of the permissions of the user's personal permissions and the permissions of the user's user group. (Relationship between user groups, users, and roles)

In the application system, what are the permissions displayed? Operations on functional modules, deletion and modification of uploaded files, menu FAQs, and even visibility control of a button or image on the page can all belong to the scope of permissions. Some permissions are designed to take functional operations as one type, while files, menus, page elements, and Other types form the Authorization Model of "user-role-permission-resource. When modeling a data table, you can manage both functional operations and resources in a unified manner, that is, directly associate the data table with the permission table, which may be more convenient and scalable. (See)

Please note that the permission table has a column "permission type". We can identify the type of permission based on its values, for example, "menu" indicates the "allow" permission for the menu, "operation" indicates the operation permission of the function module, "file" indicates the permission for modifying files, and "element" indicates the visibility control of page elements..

 

This design has two advantages. First, there is no need to distinguish between permission operations and resources (in fact, it is sometimes difficult to distinguish them, such as menus. Do you think of them as resources or functional module permissions ?). Second, it is easy to expand. When the system wants to control permissions for new things, I only need to create a new association table "permission XX Association table ", and determine the permission type string for this type of permission.

 

Note that the permission table and permission menu Association Table, permission menu Association table, and menu table are one-to-one relationships. (File, page permission, and function operations are the same ). That is, every join? For a menu, you have to insert a record to each of the three tables at the same time. In this way, you can associate the permission table directly with the menu table without having to associate the permission menu. In this case, you must add a new column in the permission table to save the menu ID, the permission table uses the "permission type" and the ID to identify which record is of the type.

 

Here, the complete design of the RBAC permission model extension model is shown as follows:

As the system grows, to facilitate management, you can introduce role groups to manage roles by category. Different from user groups, role groups are not subject to authorization. For example, in the permission management module of a power grid system, the role is attached to the local authority, and the local authority can be used as a role group here. It does not grant permissions. In addition, in order to facilitate the management and search of the above main tables, you can use a tree structure, such as the menu tree and function tree. Of course, these do not need to be assigned permissions.

RBAC permission management