Middle Tier Security with EF Core
- 4 minutes to read
If you use client-side security mode in a WinForms application, a user can find the connection string in the application’s configuration file and access the database directly. This means that the user can bypass the Security System implemented in your application.
To prevent unauthorized data access, we recommend that you implement a Middle Tier Security server. Such a server acts as a WebSocket service between the client application and the database server. In this case, clients cannot access the database directly and your middle-tier layer enforces security settings. The diagram below illustrates this configuration.
Application Architecture Basics: Middle-Tier Security
The following image shows how a WinForms application with the Middle Tier Security interacts with the database:
Load Data From the Database
An application queries data through an Object Space that uses the client EF Core DbContext.
The Client DbContext uses the Remote Database Provider developed by DevExpress to access data. This database provider does not query a database directly, but serializes the query and redirects it to the Middle Tier Security server.
The server receives the query, deserializes this query, and executes it in the server DbContext.
The secured DbContext on the server processes the query and returns the result.
The server serializes the objects returned by the DbContext and adds them to the response sent back to the client.
The Remote Database Provider in the client DbContext deserializes the obtained objects and attaches them to the client DbContext.
Save Data to the Database
The application saves changes through an ObjectSpace that communicates with the client EF Core DbContext.
The Client DbContext uses the Remote Database Provider to save data. The Remote Database Provider serializes the query and redirects it to the Middle Tier Security server.
The list of changes that should be saved to the database arrives to the server, and the server deserializes it.
The Middle Tier Security server fetches unchanged versions of the objects affected by the query, applies the specified changes to these objects, and uses the server DbContext to save their modified versions to the database. The DbContext on the Middle Tier Security server side uses the XAF Security System, so the server can only save changes that are permitted by security rules.
If the Audit Module is enabled, the audit history is saved by the Middle Tier Server through the auditing DbContext.
The server serializes object properties that may have changed after the object was saved to the database (for example, auto-generated keys) and returns them to the client.
The Remote Database Provider deserializes the server’s response and, if required, applies the generated values to the client DbContext.
Middle Tier Service and XAF Security System
The EF Core DbContext on the Middle Tier Security server side uses the XAF Security System that imposes the following restrictions on read and write operations:
When data is loaded from the database, the client receives only the data that the current user is authorized to view.
When data is saved to the database, only objects that the current user is authorized to edit are saved.
Limitations
The Middle Tier Security’s architecture imposes certain limitations compared to integrated security mode:
Direct execution of SQL queries is not supported.
The Object Space is not used when business objects are instantiated on the server or saved to the database. For this reason, objects that implement the IXafEntityObject and IObjectSpaceLink are processed on the Middle Tier Security server with the following limitations:
- Business objects do not have access to the IObjectSpace service. If you execute custom logic in property setters or anywhere else in the object’s implementation, you should always check if the IObjectSpaceLink.ObjectSpace property value equals
null
. - IXafEntityObject.OnCreated(), IXafEntityObject.OnLoaded(), and IXafEntityObject.OnSaving() lifecycle methods are not triggered for business objects.
- Business objects do not have access to the IObjectSpace service. If you execute custom logic in property setters or anywhere else in the object’s implementation, you should always check if the IObjectSpaceLink.ObjectSpace property value equals
We do not guarantee compatibility between a WinForms client and Middle Tier Security server at the data transfer protocol level if they use XAF assemblies of different versions.
The Security System displays the default property value instead of its actual value if access to a property is denied. These values may match. Use the SecuritySystem.IsGranted method to determine which value is displayed.
If you use custom permission requests, custom logon parameters, or other types that should be serialized (for example, non-persistent objects), use the static WebApiDataServerHelper.AddKnownType method to register them before a data server is initialized. Register these types on the server and client. Do not use this method to register business classes.