Shulou(Shulou.com)06/01 Report--

This article mainly explains "how to expand RBAC". The content of the explanation is simple and clear, and it is easy to learn and understand. Please follow the editor's ideas to study and learn "how to expand RBAC".

RBAC (Role-Based Access Control, role-based access control) is that users are associated with permissions through roles.

To put it simply, 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, there is generally a many-to-many relationship between users and roles and between roles and permissions. (as shown below)

What's the role? It can be understood as a collection of a certain number of permissions, the carrier of permissions. For example: a forum system, "Super Admin", "moderator" are roles. Moderators can manage posts within the version, users within the manageable version, and so on. These are permissions. To grant these permissions to a user, you do not need to grant permissions directly to the user, you can assign the role of moderator to that user.

When the number of users is very large, it is very cumbersome to authorize each user of the system one by one. At this point, you need to group users, and there are multiple users in each user group. In addition to authorizing users, you can also authorize user groups.

In this way, all the permissions a user has is the sum of the permissions that the user has and the permissions that the user belongs to. (the following figure shows the relationship among user groups, users and roles)

What is the expression of permissions in the application system? The operation of the functional module, the deletion and modification of the uploaded file, the access to the menu, and even the visibility control of a button or picture on the page can all belong to the scope of permissions.

Some permission designs take functional operations as one category and files, menus, page elements, etc., as another category, thus forming a "user-role-permission-resource" authorization model. When modeling the datasheet, the functional operations and resources can be managed uniformly, that is, they can be directly associated with the permission table, which may be more convenient and scalable. (see figure below)

Please note that there is a column of "permission type" in the permission table, and we distinguish which kind of permission according to its value, such as "MENU" represents the access permission of the menu, "OPERATION" represents the operation permission of the functional module, "FILE" represents the permission to modify the file, "ELEMENT" represents the visibility control of page elements, and so on.

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, such as menus, as resources or functional module permissions. ).

Second, it is easy to expand. When the system wants to control the permissions of something new, I just need to establish a new association table, "permissions XX Association Table", and determine the permission type string of this kind of permissions.

It should be noted here that there is an one-to-one relationship between the permission table and the permission menu association table, and between the permission menu association table and the menu table. (files, page limit points, functional operations, and so on). That is, for each menu you add, you have to insert a record into each of the three tables at the same time.

In this way, there is no need for the permission menu association table, and the permission table can be directly associated with the menu table. At this time, a new column of ID used to save the menu must be added in the permission table. The permission table distinguishes which record under this type by "permission type" and this ID.

At this point, the complete design diagram of the extended model of the RBAC permission model is as follows:

With the increasing size of the system, in order to facilitate management, role groups can be introduced to classify and manage roles. Unlike user groups, role groups do not participate in authorization.

For example, in the authority management module of a power grid system, the role is hung under the regional bureau, and the regional bureau can be regarded as a role group here, it does not participate in the allocation of permissions. In addition, in order to facilitate the management and search of the above main tables, we can use tree structure, such as menu tree, function tree, etc., of course, these do not need to participate in permission allocation.

Thank you for your reading, the above is the content of "how to expand RBAC", after the study of this article, I believe you have a deeper understanding of how to expand RBAC, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.