Detailed graphic explanation of RBAC user rights management database design in thinkphp

RBAC (Role-Based Access Control, role-based Access Control) means that users are associated 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, there is generally a many-to-many relationship between users and roles, and between roles and permissions. (As shown below)

What is the role? It can be understood as a collection of a certain number of permissions and a carrier of permissions. For example: in a forum system, "super administrator" and "moderator" are roles. Moderators can manage posts in the forum, manage users in the forum, etc. These are permissions. To grant these permissions to a user, you do not need to grant permissions directly to the user. You can give the user the "moderator" role.

When the number of users is very large, it is very cumbersome to authorize (grant roles) to each user of the system one by one. At this time, you need to group users, and each user group has multiple users. In addition to authorizing users, you can also authorize user groups. In this way, all the permissions a user has are the sum of the permissions owned by the user personally and the permissions owned by the user group to which the user belongs. (The figure below shows the relationship between user groups, users and roles)

In the application system, permissions are expressed What? Operations on functional modules, deletion and modification of uploaded files, access to menus, and even visibility control of a button and a picture on the page are all Can fall within the scope of authority. Some permission designs will treat functional operations as one category, and files, menus, page elements, etc. as another category, thus forming a "user-role-permission-resource" authorization model. When doing data table modeling, functional operations and resources can be managed in a unified manner, that is, they are directly associated with the permission table, which may be more convenient and scalable. (See the picture below)

Please note that there is a column "Permission Type" in the permission table, we will take the value according to its value To distinguish which type of permission it is, for example, "MENU" means the access permission of the menu, "OPERATION" means the operation permission of the function module, "FILE" means the modification permission of the file, and "ELEMENT" means the permission of the page element. Visibility control etc.

There are two advantages to this design. First, there is no need to distinguish which are permission operations and which are resources (in fact, sometimes it is not easy to distinguish, such as the menu, should it be understood as a resource or a function module permission?). Second, it is convenient for expansion. When the system wants to control permissions on new things, I only need to create a new association table "Permission XX Association Table" and determine the permission type of such permissionsString .

It should be noted here that the permission table and the permission menu association table, the permission menu association table and the menu table are all in a one-to-one relationship. (The same applies to files, page permissions, functional operations, etc.). That is to say, every time a menu is added, a record must be inserted into each of these three tables at the same time. In this way, the permission menu association table is not needed and the permission table is directly associated with the menu table. At this time, a new column must be added to the permission table to save the ID of the menu. The permission table passes the "permission type" Use this ID to distinguish which record it is under.
Here, the complete design diagram of the extended model of the RBAC permission model is as follows:

As the system becomes larger and larger, 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 Permission Management module of a certain power grid system, roles are hung under the district bureau, and the district bureau can be used as a role group here, and it does not participate in permission distribution. In addition, in order to facilitate the management and search of each main table above, a 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 expanded from the basic RBAC model, and the specific design must be adjusted according to the needs of the project business.

The above is the detailed content of Detailed graphic explanation of RBAC user rights management database design in thinkphp. For more information, please follow other related articles on the PHP Chinese website!