Design Scheme for extending RBAC User Role Permissions

Role-Based Access Control (RBAC) is used to associate users with permissions through roles. 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 permissions 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 the 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 access, 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, and files, menus, and page elements as the other type, thus forming the "user-role-permission-resource" Authorization Model. 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 menu access permission, "operation" indicates the operation permission of the function module, "file" indicates the file modification permission, and "element" indicates the page element visibility control.

There are two advantages of this design. First, there is no need to distinguish between permission operations and resources (in fact, it is sometimes difficult to distinguish between 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 items, 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, each time you add a menu, you have to insert a record to each of the three tables at the same time. In this way, you do not need to associate the permission menu with a table, so that the permission table can be directly associated with the menu table. 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.

The complete extension model of the RBAC permission model is shown below:

 

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

The above is an extension from the basic RBAC model. The specific design should be adjusted according to the project business needs. You are welcome to make comments!

 

Design Scheme for extending RBAC User Role Permissions