RBAC permission design instance

Implement User permission management in the Business System

The permissions in the B/S system are more important than those in the C/S system. The C/S system has special clients, therefore, the access permission detection can be implemented through the client or through the client + Server Detection. in B/S, the browser is already available on every computer, if you do not set up a complete permission check, an "invalid user" is likely to be able to easily access all functions in B/S through a browser. Therefore, the B/s business system requires one or more permission systems to detect access permissions, so that authorized users can use the authorized functions normally and legally, unauthorized "illegal users" will be completely "rejected ". Next let's take a look at how to design a permission system that can meet the needs of most B/S Systems for User Function permission control.

Requirement statement

• Personnel with different responsibilities should have different system operation permissions. An excellent business system is the most basic function.

• You can assign permissions to a group. For a Business System of a large enterprise, it is time-consuming and inconvenient to require the Administrator to assign System Operation permissions to its employees one by one. Therefore, the system puts forward the concept of "group" operations, including those with the same permissions in the same group, and then assigns permissions to the group.

• The permission management system should be scalable. It can be added to any system with permission management function. Like components, they can be repeatedly reused. Instead of re-developing a management system, we need to re-develop the permission management part.

• Meet the functional permissions in the business system. In traditional business systems, there are two types of permission management: one is the management of functional permissions, and the other is the management of resource permissions, function permissions can be reused, while resource permissions cannot.

About Design

With the help of noahweb's action programming concept, in the design stage, the system designer does not need to consider the design of the program structure, but starts from the program process and database structure. To meet the requirements, the design of the database can be described as important. Both the concept of "group" operations and the reusability of the entire permission management system all lie in the design of the database.

Let's first analyze the database structure:

First, the action table (hereinafter referred to as "permission table"), the gorupmanager table (hereinafter referred to as "Management Group Table"), and the master table (hereinafter referred to as "personnel table "), are three entity tables, which record "permission" information, "Management Group" Information and "Personnel" Information in turn. For example:

The relationship between the three tables is many-to-many. One permission may belong to multiple management groups at the same time, and one management group may also contain multiple permissions at the same time. In the same way, a person may belong to multiple management groups at the same time, and a management group may also contain multiple members at the same time. For example:

Since there is a many-to-many relationship between the three tables, it is best to use the other two tables for interaction between them. The two tables are mapped, namely the "Actiongroup" table (hereinafter referred to as "permission ing table") and the "mastergroup" table (hereinafter referred to as "Personnel ing table "), the former maps the interaction between the permission table and the management group table. The latter maps the interaction between the personnel table and the management group table. For example:

In addition, a table is required to control the permission columns in the left-side menu during system running, that is, the "permission column table", such:

Based on the above analysis, we design the database structure, such:

Click here to view the field design of the permission management system data table.

In order to be able to perform a good analysis, we split the database structure diagram. The role of the three entity tables is very clear. Now let's take a look at the role of the two ing tables.

A permission ing table is as follows:

First, let's take a look at the field associations between the permission ing table and the management group table and the permission table.

Look at the red circle in the figure. first look at the association of the gorupid field. This association method is shown in the actual database:

As shown in, the "super administrator" groupid in the management group table is 1, so the permission of the "super administrator" is 1 in the permission ing table.

Use the groupid field Association to check the permissions that a management group can perform. However, the detailed information about these permissions is found by the association of the action field.

The action field is associated with the database as follows:

Through this association, the detailed information about the permissions in the permission ing table is queried. In summary, we know the permissions that a management group can execute and the details of these permissions.

Maybe you will ask, why not use the actionid field to associate? Because:

• The ID field in the permission table may be changed after multiple database operations.
• The permission ing table only records the permissions that a management group can execute.
• Once the ID in the permission table is changed, the record in the permission ing table is changed.
• Permissions that can be executed by a management group are not expected to be executed.

Considering the above situation, the action field should be used for association, because:

• In the permission table, the ID may change, but the action field cannot change under any circumstances.
• The action field recorded in the permission ing table will not change.
• The permissions that a management group can execute will not go wrong.

The staff ing table is as follows:

Let's take a look at the field associations between the personnel ing table and the management group table and the personnel table, such:

Look at the red circle in the figure. first look at the association of the groupid field. This association method shows in the database as follows:

The groupid of the "super administrator" group is 1. Let's look at the staff ing table. Admin belongs to the super Administrator group, and administrator belongs to the super Administrator group.

This association method is used to find out who is in a management group. Like above, the detailed information of a person is queried by association of the ID field (masterid field in the person ing table.

The ID field (masterid field in the personnel ing table) is associated with the database in the form:

A person may belong to multiple "management groups" at the same time. In the middle, the Administrator belongs to two "management groups" at the same time ". Therefore, there will be two administrator records in the personnel ing table.

This association method can be used to query the details of the personnel in the Management Group. In combination, you can know who is in a management group and the detailed information of this person.

Combined with the permission table and permission ing table mentioned above, the "Group" operation is implemented as required, such:

In fact, the management group table only records the basic information of the Group, such as the name and group ID. Details about the personnel in a group and the permissions that can be executed by the Group are recorded in the personnel table and permission table. The two ing tables actually record the people in a group and the permissions they can perform. Through the convergence of two ing tables, the interaction between the three entity tables can be achieved, thus completing the "Group" operation mentioned in the requirement.

Let's take a look at the interaction between the permission column table and the permission table. The field associations between the two tables are as follows:

The two tables are associated with the actioncolumnid field. The association method in the database is as follows:

With this association method, we can clearly see which shard of the permission in the permission table belongs.

Now, the database structure is clear, and the function of assigning permissions and "group" operations have been implemented. Next we will analyze the reusability of the permission management system mentioned in the requirement.

Why can a system built using this database design method be reused?

• The three entity tables record the three decisive elements in the system. "Permission", "group", and "person ". These three elements can be added at will without affecting each other. Regardless of the type of business system, these three decisive elements will not change, which means that the structure will not change, but only the data.
• The two ing tables record the relationship between the three elements. However, these relationships are completely created manually. When you need to change, you only need to perform operations on the records in the database without modifying the structure.
• The permission sub-table records the sub-columns displayed during system use. Whether you want to add a column, modify the column or reduce the column, it is just an operation record.

To sum up, the system can be completely reused to design a database and can withstand the "change" test.

Summary:

The focus of this system is that the three entity tables firmly grasp the core components of the system, and the two ing tables perfectly map the interaction between the three entity tables. The difficulty lies in understanding the work of ing tables, recording the relationships, and implementing the concept of "group" operations. The overall system design is based on the ability to "reuse" in different MIS systems to meet the functional permission settings of different systems.

Appendix:

Field Design of permission management system data table

Let's take a look at the database table design of the permission management system, which is divided into six tables, for example:

Action table:

The action table records all the actions in the system and their descriptions.

Actioncolumn table:

The actioncolumn table records the action columns. When the system is running, the left-side menu bar provides several different functions, each of which is a column, and each column is added, in this table, an additional record is added. Correspondingly, a new machine column is added in the left-side menu bar.

Actiongroup table:

The Actiongroup table records the group of the action.

Groupmanager table:

The groupmanager table records information about the management group. Each time you add a management group, a record is added here.

Mastergroup table:

The mastergroup table records the Administrator's Management Group. Because an administrator may belong to multiple groups at the same time, there may be multiple records about an administrator in this table.

Master table:

The master table records the information of all administrators. Each time an administrator is added, a record is added to the table.

RBAC permission design instance