Also bask in my RBAC system (II): Introduction to system implementation principles

Reading this articleArticleIn the past, we suggest you take a look at it first. Wenzy Released" Asp.net RBAC membership framework for Visual Studio 2005Free and open-source Asp.netPermission management system" ( Http://www.cnblogs.com/wenzy/articles/504124.html My RBAC system has learned a lot from them. I would like to express my gratitude to Dr. wenzy. For the specific database modeling diagram, see the first article in this series. We will not repeat it here.

 

To implement permission verification, you must first define the specific permissions.In the absence of RBAC, some simple systems directly write down the permission definition. The entire system has several roles defined in advance and can only assign users fixed roles in use. When programming, which module requires permission verification is directly written in which moduleCodeSet the permissions that the user has in the module based on the user's role. This method is the easiest to implement, but not the most flexible, because each part involving permission control needs to write the corresponding judgment code. If a new role is added, all modules involved in permission verification need to add verification code for the new role, which is very inflexible.

A proper method is to define the total number of modules in the system before and during project programming. What permissions are involved in each module, and finally a total list of permissions is collected. You can define roles and permissions by yourself. In this way, you only need to determine whether the current user has the right to call a certain permission during programming. A common authentication module can be used to complete permission verification and simplify programming. In this example, all permissions are defined and stored in the database, and the permissions and users of roles and roles are defined and stored in the database. In this way, a certain permission is involved in use. For example, when "customer query" is used, the verification module can determine whether the current user has the right to use the permission. If yes, the user enters and exits. The disadvantage of this method is that the system requires a large number of defined permissions, which greatly increases the programming workload.

After talking about this, let's talk about the implementation principle of the system.First, the permission is defined, but the permission is not directly defined here, but through the "Resource-Operation.

first, you need to define all the resources involved in the system ( ksrbac_resources tables and ksrbac_resourcegroups table ). Such as warehouses, vehicles, goods in the sales system, and cabinets in the inventory management. Each item can be defined as a resource and can be subdivided infinitely. The concept of resource groups is introduced here. By dividing resource groups and subordinate resource groups, different resources can be classified and archived to facilitate resource management.

next, define the operation ( ksrbac_operations table). operations are the actions that can be performed on a resource. For example, warehouse operations include warehouse picking, warehouse receiving, and inventory check. vehicle operations include driving and maintenance, and product operations include adding, deleting, selling, purchasing, and returning goods.

With resources and operations, you can define permissions (Ksrbac_privilgegsTable ). The so-called permissions define the operations that can be performed on a resource, that is, the "Resource-Operation. For example, sales of goods is a permission definition, while driving a car is also a permission definition. Define the permissions according to the actual needs of the project. For example, an asset management project defines the permissions for driving cars, maintenance vehicles, and scrapped vehicles to track the vehicle lifecycle. For an office management project, only one permission for driving a car is defined, because it only cares about the use of cars and does not care about maintenance issues.

 

After the permission is defined, the role is defined (Ksrbac_rolesTable ). In this system, the definition of roles is relatively simple, because there are not many roles in a system, so the role part does not have the grouping function.

 

 

Now, the basic architecture of system permissions has been completed. Through the above data tables, you can store the permissions, roles, and permissions defined in the project.

 

After role permissions are defined, two permission verification methods are available.One is to add a user to a role and perform permissions (Privilege) During verification, first obtain the role to which the user belongs, and then grant permissions to the role (Privilege) Verification. This method is used. Because the verification object is a role, the user can only join one role, and the usage is not flexible,

The system uses another method to reduce the permission verification object to a specific user. One user can join multiple roles at the same time. When a user logs on, he/she first obtains the list of roles to which the user belongs, and then obtains authorization ( Permission ) Grant permissions to each role ( Privilege ), And ( Privilege ) To the user's permission list. In this way, you only need to determine whether the user's permission list has the specified permission ( Privilege ) To complete the verification.

For user definitions, three tables are involved here. Ksrbac_user It is a basic table that stores the most basic information such as the user's login name and password. Ksrbac_usermembership A permission table is used to store content related to permission verification. Ksrbac_userdetail A table is a basic user information table used to store user information. The basic information table defines the field content in the project according to the actual requirements, to ensure that the table can be flexibly adapted to various situations when the user data of different projects is inconsistent.

 

As mentioned earlier, the permission storage and verification mechanism is used to determine a permission during the specific programming process. that is, Program how do I know the operation permission of this module? A the operation of that module indicates the permission B what? Hard encoding is required here.

For example, when you use the product module and need to perform the warehouse receiving operation, the program will first obtain the permission to represent the "warehouse receiving operation ". ID And then use ID Compares with the user permission list to determine whether the permission list exists. ID If yes, continue to run down. If no, the system prompts that the user has insufficient permissions and does not continue. For permission ID Number, which can be queried from the database and written directly during encoding.

If you only do this step during programming, You can implement all the functions required by the system, but you still need to know the permissions when specifying permissions in programming. ID It is very inconvenient. Therefore, in practice, a permission file is defined in advance, in which the storage permission is sent using characters named after the permission name. ID Enter the permission name to obtain the permission. ID .

 

After talking about this, the implementation principles of the system are almost the same.In some cases, it is not very detailed and will be introduced in future articles. You are welcome to discuss it together.