Source: https://blog.csdn.net/rocher88/article/details/43190743
These are some well-designed RBAC permissions management I found online. I
don't know. For example, the RBAC user permissions of Sina, Sohu, Netease, Baidu, Alibaba, and Taobao are all designed and developed by this fine-grained RBAC. Or encapsulate the table box data of user groups, role groups, permission groups, operation groups, resource groups, etc. into tool classes. Persistence once passed a database view View or joint query to convert fine-grained designs into coarse-grained ones. operation. Developers don't need to pay attention to these finer things, only need to pay attention to coarse particles, such as: users and roles and menus and operations. Other button operations such as once, delete, change, difference, pagination, and whether the file can be uploaded are all included in the entity tool class that encapsulates these operations! ! !
RBAC permission management
extension accessmenufile
RBAC (Role-Based Access Control, role-based access control), is that users associate with permissions through roles. Simply put, a user has several roles, and each role has several permissions. In this way, an authorization model of "user-role-authority" is constructed. In this model, there is a many-to-many relationship between users and roles, and between roles and permissions. (Pictured below)
What is 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 administrator" and "moderator" are roles. Moderators can manage posts in the board, can manage users in the board, etc. 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 the user.
When the number of users is very large, it is very cumbersome to authorize (authorize roles) for each user of the system one by one. At this time, users need to be grouped, and each user group has multiple users. In addition to authorizing users, you can also authorize user groups. In this way, all the permissions possessed by the user are the sum of the permissions possessed by the user and the permissions possessed by the user group to which the user belongs. (The following figure shows the relationship between user groups, users and roles)
In the application system, what is the performance of permissions? The operation of the function module, the deletion and modification of the uploaded file, the access to the menu, and even the visibility control of a button or a picture on the page can all belong to the scope of authority. In some permission designs, functional operations are regarded as one category, and files, menus, and page elements are regarded as another category, which constitutes an authorization model of "user-role-permission-resource". 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 easy to expand. (See the figure below)
Please note that there is a column of "Permission Type" in the permission table. We distinguish which kind of permission it is based on its value. For example, "MENU" indicates the access authority of the menu, and "OPERATION" indicates the operation authority of the function module. , "FILE" indicates the modification permission of the file, "ELEMENT" indicates the visibility control of page elements, etc.
There are two advantages to this design. First, there is no need to distinguish which are permissions operations and which are resources (in fact, sometimes it is not easy to distinguish, such as menus, should we understand it as resources or function module permissions?). Second, it is easy to expand. When the system wants to control the authority of new things, I only need to create a new association table "authority XX association table", and determine the authority type string of this kind of authority.
It should be noted here that there is a one-to-one relationship between the permission table and the permission menu association table, and the permission menu association table and the menu table. (Files, page permission points, functional operations, etc. are the same). That is, each time a menu is added, a record must be inserted into each of the three tables at the same time. In this way, the permission table can be directly associated with the menu table without the permission menu association table. At this time, a new column of ID for saving the menu must be added to the permission table. The permission table is distinguished by the "permission type" and this ID. Which record under the type.
At this point, the complete design diagram of the extension model of the RBAC permission model is as follows:
As the system becomes larger and larger, role groups can be introduced to manage roles by classification for the convenience of management. 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 linked to the district bureau, and the district bureau can be used as a role group here, and it does not participate in the allocation of authority. In addition, in order to facilitate the management and search of the above main tables themselves, a tree structure can be used, such as a menu tree, a function tree, etc. Of course, these do not need to be involved in authority assignment.
Another different RBAC user rights management design:
RBAC-based rights design model
Rights analysis document
RBAC-based rights design model:
1 RBAC Introduction
RBAC model is currently the most widely accepted rights model.
The NIST (The National Institute of Standards and Technology) standard RBAC model consists of four component models, which are the basic model RBAC0 (Core RBAC) and the role classification model RBAC1 (Hierarchal RBAC). ), the role restriction model RBAC2 (Constraint RBAC) and the unified model RBAC3 (Combines RBAC) [1]. The RBAC0 model is shown in Figure 1. 
Figure 1 RBAC 0 Model
RBAC0 defines the smallest set of elements that can constitute an RBAC control system
in RBAC, including users (USERS), roles (ROLES), target objects (OBS), operations (OPS), permissions Permissions (PRMS) five basic data elements, permissions are assigned to roles, not users, when a role is assigned to a user, the user has the permissions contained in the role. Session sessions are the mapping between users and sets of active roles. The difference between RBAC0 and traditional access control is that adding a layer of indirection brings flexibility. RBAC1, RBAC2, and RBAC3 are all extensions of RBAC0 successively.
RBAC1 introduces the inheritance relationship between roles
The inheritance relationship between roles can be divided into general inheritance relationship and restricted inheritance relationship. The general inheritance relationship only requires that the role inheritance relationship is an absolute partial order relationship, allowing multiple inheritance between roles. The restricted inheritance relationship further requires that the role inheritance relationship is a tree structure.
The RBAC2 model adds responsibility separation relationship
. The constraints of RBAC2 stipulate the mandatory rules that should be followed when permissions are assigned to roles, or roles are assigned to users, and when users activate a role at a certain time. Responsibility separation includes static responsibility separation and dynamic responsibility separation. Constraints together with the user-role-permission relationship determine the access permissions of users in the RBAC2 model.
RBAC3 includes RBAC1 and RBAC2
, which provide both the inheritance relationship between roles and the separation of responsibilities.
Create a role definition table. Determine the role in the current system.
Because of the problem of inheritance, the role reflects a tree structure. 
2 Permission design:
configure resources and resource operations: Here resources can be defined as a general resource model. Provides a common resource unified interface.
Database ER diagram: 
Relationship diagram: 
3 Analysis:
It can be seen from the above class diagram and ER diagram. The entire authority can be abstracted into five objects.
OrgBean : used to describe the org model.
Role : Used to describe the role.
Permission : Used to describe permissions.
Resource : Used to describe resources.
Operation : Used to describe the operation.
Among them, Permission includes the aggregation of Resource and Operation, and the resource and operation constitute permissions.
Both Role and Permission are self-contained. Because of inheritance of permissions by design.
The resource Resource may also have a tree structure, and the resource must also be self-contained.
Idea:
The core of the permission system consists of the following three parts: 1. Create permission, 2. Assign permission, 3. Use permission, and then, the main participants of each part of the system are compared as follows: 1. Creation permission - Creator, 2. Distribution Permissions - Administrator assignment, 3. Use permissions - User:
1. Creator creates Privilege, Creator will divide when designing and implementing the system, what permissions should a subsystem or module have. What is done here is the object declaration of Privilege and Resource, and does not really link Privilege with a specific Resource instance to form an Operator .
2. Administrator specifies the association between Privilege and Resource Instance. In this step, permissions are really linked to resource instances, resulting in Operator ( Privilege Instance ). Administrator uses the basic element of Operator to create his ideal permission model. For example, create roles, create user groups, assign users to user groups, associate user groups with roles, etc... These operations are all done by Administrator.
3. User uses the permissions assigned by Administrator to use each subsystem. Administrator is a user, and in his mind there is a permission model that is more suitable for his management and maintenance. Therefore, the programmer only needs to answer one question, that is, what permissions can access what resources, which is the operator mentioned above. When a programmer provides an operator, it means putting armor on the system. The Administrator can build the authority framework he wants according to his wishes, and can add, delete, and manage the relationship between Resource and Privilege by himself. You can set the corresponding relationship between the user User and the role Role. (If the Creator is regarded as the inventor of Basic, the Administrator is the user of Basic, and he can do some scripted programming) Operator is the most critical part of this system, it is a link, a link between Programmer, Administrator, The link between users.
4 Permission API
getPermissionByOrgGuid(String orgGuid)
By passing in an org's Guid, you can get those access permissions that the current org object has.
getSourcePermissionByOrgGuid(String orgGuid, String resouceGuid)
returns the access permission of the current resource to the current resource by passing in a Guid of an org and a Guid of a resource.
getPermissionByResourceGuid(String resource)
By passing in the Guid of a resource, get those permission definitions under the current resource.
havingHeritPermission(String orgGuid , String resouceGuid) : Boolean
passes in an orgGuid, the resource GUID, and checks whether the changed OrgGuid has downward inheritance permissions for the resource. Here inheritance is the inheritance of resources. That is, if you have permission to the parent column, you can inherit the permissions to the child columns under the parent column.
havingPermission(String orgGuid , String resourceGuid) : Boolean
to determine whether an Org has permission for a certain resource.
The above is the coarse-grained permissions API. The following are fine-grained permissions:
getOperationByPermission(String permissionGuid)
Get all valid operations of the permission through the Guid of the permission.
getOperationByGuid(String permissionGuid, String resourceGuid)
obtains all valid operations under the resource through the Guid of the permit and the Guid of the resource.
screeningOperationByGuid (String permissionGuid , String resourceGuid , String orgGuid)
obtains the effective operation of Org on this resource through permission , resource , and the Guid of org.
hasOperation(String operationGuid) : boolean
Returns whether it has the operation authority through the passed in operationGuid.
5. The realization of authority:
1. Forms authentication, which is commonly used, but when the user arrives at a resource they are not authorized to access, the web container
issues an html page asking for a username and password.
2 . Use Filter to prevent users from accessing some unauthorized resources. Filter will intercept all Request/Response ,
and then place an authenticated ID in the user's Session, and then Filter will rely on this ID to decide whether to release Response each time.
This mode is divided into:
Gatekeeper: Take the way of Filter or unified Servlet.
Authenticator: Implemented by yourself using JAAS in the web.
Filter interception only intercepts whether the user has access to this page or this resource. The real interception after display is done inside the application.
Do display interception provided API, tag both ways.