Design of RBAC User Rights Management database

http://minjiechenjava.iteye.com/blog/1759482

RBAC User Rights Management database design

Blog Category:  

• RBAC privilege Design

  Rbac

  RBAC ( role-based Access Control , role-based access control), which 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. (e.g.)

  
  
  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)

  in application system , what does the authority represent? 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 authority design, will function as a class, and the file, menu, page elements, etc. as another class, this constitutes the " user - role Span style= "Font-family:helvetica" >- permissions - resources "

  
  
  Please note that there is a column in the permission table " Permission Types " , we distinguish what kind of permission is based on its value, such as "Menu" represents the access rights for a menu, "Operation" represents the operation permissions of the function module, "FILE" represents the file modification 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 to the new things to control permissions, I just need to create a new association table " permissions XX Association table ", and determines the permission type string for this type of 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, permission table through the " permission type " and this ID to distinguish which record is under the type.

  to Here, RBAC The complete design of the extended model for the 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 The model is extended and the specific design needs to be adjusted according to the requirements of the project business. You are welcome to make critical comments!

Design of RBAC User Rights Management database