The application of RBAC permission model

Role access Control (RBAC) introduces the concept of roles in order to isolate the user (that is, the action body, Subject) and privilege (permissions, which represent an operation on Resource, that is, Operation+resource). Role acts as a proxy layer for users (user) and permissions (Privilege), decoupling permissions and user relationships, and all authorizations should be given role rather than directly to user or group. Privilege is a permission particle, composed of operation and resource, representing a operation to resource. For example, a delete operation for news. Role-privilege is the many-to-many relationship, which is the core of authority. The two notable characteristics of role-based access control (RBAC) are: 1. The change in roles/permissions is much slower than the changes between roles/user relationships, reducing the complexity of authorization management and reducing administrative overhead. 2. Flexibility to support enterprise security policies, and the enterprise changes have a great scalability.

In a project of civil Engineering Management, a permission model is studied. The general requirement is to divide the user into "site users" and "HQ users". Users at Headquarters can make new projects to view the progress and budget of existing projects, and the site users are responsible for the construction and entry of project progress, completion of the progress, accounting records.

In the software system, there is clearly no headquarters, the site of the user's points. Only records with different permissions on the same user table. The following database model has user users, role roles, and resource resources of three objects. They have many-to-many relationships, so there are two additional tables to join.

Role is to give a group of resources to the object, the user through the association role to obtain accessible resources, users can be decoupled from specific permissions, and the user and role of many-to-many relationships, you can flexibly give a user multiple role (such as head office Manager, can also be a field command), A role resource can also be easily paid to multiple users. The general system's permission model is roughly the same.

I thought it would be enough to design a permission model here, but I found the problem when I designed the project table below. The project may be parallel to several projects at the same time, and one person will be different role in different projects. For example, Zhang San is the manager role in Project 1, and in Project 2 it may be just the leader. Therefore, this particular project permission model must include a link to project.

Therefore, it is necessary to associate a project_id foreign key to the project table in the User_to_role intermediate table, associating the user's role with the project in this place. The same user and role have other constraints, only need to add foreign keys in the User_to_role table, without affecting the above permission mode