RBAC Rights Management System

Permission control should be divided into 3 categories:

1. Menu level

2. Page element level

3. Data level

RBAC Introduction

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, between the user and the role, between roles and permissions, is generally a many-to-many relationship. 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: An OA system, "Administrator", "CFO", "cashier" are all roles. Administrators can manage the organizational settings of the system, the users within the managed system, and so on, which are permissions. To grant these permissions to a user, you do not need to grant permissions directly to the user, and you can assign the role "Administrator" to that 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 group of OA system of the Rights Management module, the role is hanging under the branch, and the branch here as a role group, it does not participate in the allocation of rights. 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.

Sometimes you need to add one or two permissions for a single user, it is not worthwhile to design a "role" for this user, so the design needs to consider: You can either assign permissions to users through roles, or assign permissions directly to users.

Many systems do not directly assign permissions to users, but in the actual application of the software, if you are completely based on the "role" for people to assign permissions, you will find the role of repeated, redundant permissions are many, so repeatedly define a variety of "roles", rather than designed to directly assign permissions to people.

Rights Management is basically divided into the following steps:

1. Define permissions-Define roles-"Assign roles to people (or assign permissions directly), which is a process of assigning permissions;"

2, define the protected resources-"protected resources" to specify the authorized rights, this is an authorization process;

3, the application requests the "protected resources"-"protected resources" to match the authorized rights of the person to hold the rights-"matching success, allowing access to resources, matching failures, not allowing access to resources, this is a certification process."

The above three processes are typical of the "Operation Permissions" process.

On the "page element" control, most of the current rights management system, the use of "custom permission tag" to control the display of page elements or not.

I always think: in fact, with the "Custom permission tag" to control the display of the page elements, and directly in the view of the use of the program logic is the same, and did not do "flexible configuration", when the permission code changes, or the change in the meaning of the permissions, or to move the page label, so there is no difference with writing dead

If the page element is assembled into JSON, or other formatted data through the server, and then returned to the view layer for rendering, then it is possible to "flexibly configure the permissions of the page element", which can be displayed through the database definition of those buttons.

"Server-side assembly view layer components, return to view layer rendering", although this mode has achieved "flexible configuration of page element permissions", but sacrificed a lot of things, such as increasing the complexity of the server, making the page design More "programmer", rather than "art" and so on.

As for the most critical "data permissions", that is, the people to the data read depth control, is a more complex process.

For the "depth of data" control, need and business integration is very close, that is: in the program to read data, such as "list" page, the first to determine whether the current lander has "read any depth of permission", if not, do not read the limit, if there is, the current login is not the department head, if yes, Read all the data in this department recursively, and if not the supervisor, read only its own data.

"Data Depth" control, fine design, should be more general and more flexible.

The following is a partial data model of my "permission control":

Of course, the data model is not the key, just save the user-permission relationship is OK,The key to design is to find the right control point.

Interface level: A custom label can be implemented

URL level: Filter can be implemented

Back-end method level: AOP can be implemented

Data level: Good design +AOP can achieve

Even if there is no good design, for different needs, in the control point to write the interception processing class on the line, just repeat the code problem

the key to permissions is to find control points, intercept, and do what you want to do.

Robot fetch Source: Go to the original website

The original address: RBAC Rights Management System

RBAC Rights Management System