Extended RBAC User Role Permissions design scheme

RBAC (role-based access control, role-based access controls) is where users are associated with permissions through roles. Simply put, a user has several roles, and each role has several permissions. In this way, a "user-role-permission" authorization model is created. In this model, there are many-to-many relationships between the user and the role, and between roles and permissions. such as

What is a character? A set of permissions that can be understood as a certain number of permissions for the carrier. For example: A forum system, "Super Administrator", "moderator" are the roles. Moderators can manage posts in the edition, users within the managed 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, and the "moderator" role is assigned to the user.

When the number of users is very large, to give each user of the system to authorize (delegating roles), is a very trivial matter. At this point, you need to group users, with multiple users in each user group. In addition to the user authorization, you can also give the user group authorization. In this way, all of the permissions that a user has is the sum of the permissions that the user has personally owned and the permissions that the user's user group has. (Association of user groups, users, and roles)

What do permissions represent in the application system? The operation of the function module, the deletion of the upload file, the access to the menu, and even a button on the page, the visibility of a picture control, can belong to the category of permissions. Some rights design, the function operation as a class, and the file, menu, page elements, etc. as another class, so as to form a "user-role-permissions-resources" authorization model. In the data table modeling, the function and resources can be unified management, that is, directly related to the permission table, which may be more convenient and extensible. See

Please note that there is a column "permission Type" in the permission table, we distinguish what kind of permission according to its value, such as "menu" to indicate the access permission of the menu, "operation" means the function module's operation permission, "file" to indicate the file Modify permission, "ELEMENT" Represents the visibility control of a page element, and so on.

The benefits of this design are two. First, there is no need to distinguish between what is permission operations, which are resources, and (in fact, sometimes not a good distinction, such as a menu, to understand it as a resource or function module permissions?). ）。 Second, it is convenient to expand, when the system wants to control the new things, I just need to establish a new association table "Permission XX association table" and determine the permission type string of such permission.

It is important to note that the permission table and the Permissions Menu Association table, the Permission Menu Association table and the menu table are all one-to-a-kind relationships. (File, page permission point, function operation, etc.). That is, each time you add a menu, you have to insert one record into each of the three tables. In this way, you can not need the Permission Menu Association table, the Permission table and the menu table directly associated with, at this time, a new column in the permission table to save the menu ID, the permission table through the "permission type" and this ID to distinguish between the type of which record.

Here, the full design of the extended model of the RBAC permission model is as follows:

With the increasing of the system, in order to facilitate the management, role groups can be introduced to classify the roles, unlike the user groups, role groups do not participate in authorization. For example, a power grid system in the Rights Management module, the role is hanging in the district bureau, and the district board here as a role group, it does not participate in the allocation of permissions. In addition, in order to facilitate the management and lookup of the above main table itself, can adopt tree structure, such as menu tree, function tree, of course, these can not need to participate in the permission assignment.

Above, is from the basic RBAC model expands, the concrete design must make the adjustment according to the project business need. You are welcome to make critical comments!

Extended RBAC User Role Permissions design scheme