How to design a perfect rights management module

More common is our role-based access control, user roles and privileges by association. Simply put, a user has multiple roles, a role with more authority. In this way, it is configured to "user - role - permission" license model. In this model, between users and roles, and permissions between roles, often-many relationship. As shown below:

Based on this, you must first understand what role in the end is? We can understand it as a collection of a number of rights, the carrier is a privilege.

For example: a forum of "administrator", "moderator", they are all roles. But what can be done is not exactly the same, only moderator in the version management posts, users, etc., which are within the competence, if a user wants to grant these permissions, without direct grant user permissions , simply "moderator" this role can be given to the user.

But we also see the problem from the above, if the number of users is very large, you need to give each user one by one system of authorization (assigning roles), this is a very complicated matter, then you can add a user group, multiple users within each group of users, in addition to a single user authorization, the authorization may also be set to the user, so that, by a single authorization to multiple users can simultaneously grant the same permissions, then the user all the user's personal authority is the authority has the authority and that user's group and owned. User group, and user relationship below the three roles:

Usually in the application of the system of privileges which we showed it to access the menu (page-level), operational function modules (function level), the uploaded file deletion, or even a button on the page, the picture is visible, and so are all privileges category. Some rights design, the operation will function as a class, and the documents, menus, and other page elements as another class, this constitutes a "user - role - authority - resources" licensing model. In doing modeling data table, can the functional operation and integrated management of resources, that is, are carried out directly associated with permissions on the table, this may be more convenient and easy scalability. As shown below:

Of particular note here the following permissions table has a "PowerType (authority type)", according to its value to our distinguish what kind permission, it can be understood as an enumeration, such as "MENU" express access to the menu , "oPERATION" represents the operating authority functional modules, "fILE" represents permission to modify a file, "eLEMENT" represents the visibility of the control elements on the page and so on.

There are two benefits of this design:

First, you do not need to distinguish between what is permission to operate, which is a resource, (in fact, sometimes not a good distinction, such as menus, understand it as a resource it is still functional modules power?);

Second, facilitate the expansion, when the access control system to be new stuff, I just need to create a new association table "privileges XX association table" and determine the type of authority to a string of such rights.

It should be noted, permission and authority table associated table menu, menu privileges associated with the table menu table is one to one relationship. (File, page permissions point, operation, etc. The same function). Each menu is added, at the same time to have three tables each insert a record.

Thus, a menu may not be required permission association table so that the table permission table directly associated with the menu, this time, a new ID to be stored in the rights table menu, permission table through the "right type" and to distinguish this ID is which record of types. The last extension out of the complete design model as shown below:

Notice above I added an additional operation log table;

With the increasingly large system, in order to facilitate the management, if there is a need to introduce the role of the group classified management roles, with different groups of users, roles, groups not involved in the authorization.

For example: When faced with multiple subsidiaries, there are a number of departments at each subsidiary, which we can understand the role the department, a subsidiary of understanding for the role group, the role group does not participate in the distribution of competences. Further, each of the main table top to facilitate their management and search, a tree structure may be employed, such as a menu tree, the tree function and the like, of course, may not need to participate in the allocation of permissions.

Data Dictionary:

1. User table: