"Role-based private permission management" Model and Its Application in enterprise permission management

Software security has always been an old and difficult issue during software projects. Restrictions on the use of software are essential functional modules and problems that have to be solved in software development. Generally, software permission management is based on roles. However, role-based permission management has some drawbacks, such, the same role must grant new permissions for individual functions to another user. However, this permission is a function permission with a higher security level, so it cannot quickly meet the requirements, it is necessary to create a new role and re-authorize the role and permissions, resulting in a role increase due to the permission issues of a certain user; if you need to use this other user, you need to create a new role and grant new permissions to the new role, for example, if you want to use this user for half a year, the role of this user needs to be adjusted again, resulting in inconvenience caused by some phenomena to the user's use and the garbage role generated in the database. To solve this problem, I designed the following permission management model-role-based private permission management.

The role-based private permission management model has the following advantages in enterprise management:

1) supports unlimited Management of menu functions. Menus are recursive during design, which theoretically supports unlimited menu directories;
2) supports unlimited Department management. It is also recursive;
3) easily manage the public permissions of each department. If we regard a department as a role, the Department permission is the role permission;
4) easily adjust the private permissions of individual users. With the management of private permissions, you can easily manage the permissions of individual roles;

(1) first, let's look at the entities involved in enterprise software permission management: employees, departments, and functions
(2) Draw relationships between entities using powerdesigner

(Figure 1)

Function <--> Department: A function can be used by 0 or more departments, while a department can use multiple functions or not.
Function <--> EMPLOYEE: one employee can use 0 or more functions, and one function can be used by 0 or more employees;
Department <--> EMPLOYEE: the inclusion relationship is simple;

(3) Eliminating the conversion of many-to-many relationships into relational entities and eliminating code dependencies:

(Figure 2)

(4) Add the affiliation between departments and the inclusion relationship of the menu function:

(Figure 3)

(5) Add the attributes of each object to the role-based private permission management conceptual model:

(Figure 4)

(6) physical database model conversion:

(Figure 5)

Finally, generate a database script and import it into the database to generate the database. The fields, primary keys, and foreign key relationships in each table are shown in figure 5.