Configuration and validation of EntityFramework-based permissions

1. Overview

This article mainly introduces the authority system of the company's existing system framework, and the description of some extension functions. Currently this permission system is based on role building (RBAC), in principle, the system does not allow the user, the organization and other objects to assign permissions to the situation.

2. Classification of permissions

The permissions for all representations in the current system can be categorized into two categories:

One is to describe whether an object or action is visible, which we call function permissions (authority). For example, the visibility of menus, whether user-added buttons are visible, whether user-added methods are available, and so on;

The other is to describe the scope of the visible object or the scope of the action, which we call Data permissions (Permission). For example, a list of underage users, restrictions on data operations within administrative regions.

Note, here authority and Permission is not to take English original intention, just for the program to simplify the permission object naming, the actual corresponding should be function Permission and Data Permission.

2.1. Function permissions

The definition of functional permissions can usually be serialized into a database. Therefore, when you design a database table, it has a relationship with the user, the role:

Permissions and roles, roles, and users are many-to-many relationships that require the creation of an intermediate table to store.

2.2. Data permissions

The definition of data permissions is difficult to serialize into a database in most cases. Therefore, when you design a database table, you only need to record its relationship with the role:

3. Implementation process

From the user's point of view, they only care if the system is configured to conform to the actual business logic, and a small number of users are actively involved in the configuration process.

3.1. Configuration

Configuration mainly do two things, one is to define permissions, the second is authorization.

There is no difference in the authorization of functional permissions and data permissions, which can be easily understood as data changes to role2authority and role2permission tables from a data table;

Menu permissions are a representation of functional permissions.

3.1.1. Definition of functional permissions

But the definition has the big difference, the function permission can be defined in the situation that does not determine the management object, moreover from the actual situation, the system function or the interface setting is not completely and the system management object one by one correspondence, the function permission more situation is to the system demand description.

For example, we plan to add the Project object management function to the system, so we can quickly add a menu permission to the authorities table. To control whether users can access the Project Object Management page project.html, at which point the project.html page may not have been developed yet, but it does not affect the definition of permissions. On the other hand, the action defined by this permission may involve more than just an engineering object, but a combination of actions performed by multiple object operations;

3.1.2. Definition of data permissions dynamic definition

The definition of data permission, currently only implements the predefined, that is, the definition of the coding phase. The options that the data rights authorization interface sees are the content of the encoding presets.

If you want to dynamically define data permissions at run time, for example, a departmental project in project permissions, its definition is that the currently logged-on user can view the project in this department, which is a scope limit for the project object. Using SQL statements, you can describe the

SELECT *  from WHERE OrgId=(SELECTfromWHERE Id=@UserId)

Here you can create a permissions table in the database and name the conditional part of the SQL statement above Departmental Projects , and given the number 3002, into the table, and then set up the foreign key relationship between the permissions table and the Role2permissions table to realize the dynamic configuration of data permissions, but the specific operation down, will find a lot of problems.

First of all, the conditional syntax is changed when querying the table, and secondly, the dynamic configuration needs to have the configuration interface, it is unsafe to input SQL statements on the interface, and the user probably does not understand the SQL syntax; in some administrative permission frameworks, it is also possible to simplify the definition process by using the conditional Expression Builder, which is the direction to try.

In the system described in this article, the data layer uses the EntityFramework framework, so SQL syntax cannot be used to dynamically define data permissions. Perhaps after you have a good understanding of lambda expressions, you can try to establish a lambda expression through text to enable dynamic definition of data permissions.

Pre-defined

A lambda description is used for the departmental Project permission system

Formula = Oper = (Pro = Pro.Organizations.Contains (oper.organization));

Where Oper is the user parameter, Pro is the project parameter. The predefined contents of data permissions are stored in the class and a new Class library project is established for this purpose, called the permission library. When the system needs new data permissions, it can only modify the permissions library, generate the deployment file, replace some files in the runtime environment to achieve the purpose of data permissions configuration.

The above expression formula is just a property of the data permission object. The data permission name can be defined as a departmental project , numbered 3002, which corresponds to the PermissionID in the Role2permissions table, enabling the role to be authorized.

3.2. Verify the 3.2.1. Validation of functional permissions

For the B/s system described in this paper, the function authorization can be divided into two different implementations of server and client.

First, the server implementation needs to intercept all requests, and according to the user's role in the session, the requested resource, one by one to match the permission definition rules, to achieve validation.

For example, all handler interfaces inherit from a parent class and are validated in the parent class.

The implementation of the client is to hide a menu or button that the user does not have permissions for. For pages that use the background scripting language, it is easy to control using the set of permissions under the user's role, whereas the plain HTML front section allows you to first hide all elements that involve permissions, and then use Ajax to get a collection of permissions that shows the elements that can be accessed.

It is important to note that server-side validation must be implemented to ensure the reliability of the privilege system.

3.2.2. Validation of data permissions

Unlike functional permissions, data permissions are primarily control over the data range, so the validation process is eventually implemented at the system data layer. There are two implementations: one is read-only validation, the other is read-write verification, and each has advantages and disadvantages.

Read-only authentication in the following way:

This is an API query method, where condition, vercondtion, attcondition are data permissions for three objects, through this query method, the user will only get the project object and sub-object data that he can view.

Similarly, paged query, view query and other query methods, in addition to the user input conditions, but also to join the Permissionmanager provide the data permission conditions, and ultimately to the business layer query. The disadvantage of this approach is that the user may use data other than the query permission to forge the modification and delete operations.

Read/write verification in addition to the Query method needs to add additional permission conditions, modification and deletion must first be data readability query validation. As a result, the security of read-write authentication is the highest, but performance is much worse than read-only queries.

3.2.3. Some details

conditional Merging , Predicatebuilder is a tool specifically for lambda conditional expression merging. Typically data permission conditions and user query criteria should use an and operation.

centrally manage the validation of data permissions , the way in which the API method uses Permissionmanager to obtain data permission conditions is flawed, for example, requiring all coders to understand the process of permission validation, as well as omissions that could cause data operations to be uncontrolled. For systems that use the EF framework, consider integrating the permission validation process in DbContext.

the specific validation process , creating a common validation method, using the current user as a parameter, returns the filter condition of the related object. Because data permissions are based on objects, it is best to use generics for this validation method. The method parses all the roles of the user, and the Data permission authorization number under each role, and extracts all relevant lambda representations from the predefined library according to the authorization number for the OR or combination. The method of composition depends on the processing strategy of multiple role permissions coincidence.

4. Legacy issues

Finally, despite this, there are still some unresolved issues with the development of permissions based on the EF framework. For example, the dynamic definition of data permissions, the efficiency of permission read and write validation issues, the centralized validation of data permissions, etc., hope that they have time to continue to improve.

This article is only published in the blog Park, reproduced please indicate the source.

Configuration and validation of EntityFramework-based permissions