Skip to main content

2-Tier Security (Integrated Mode and UI Level)

  • 6 minutes to read

Applications with 2-Tier Security directly connect to the database (without the Middle Tier Application Server). This topic describes the following 2-Tier Security modes:

The Solution Wizard automatically enables following modes based on the application’s UI platform and ORM library:

XPO

EF Core

WinForms

Integrated

Integrated

ASP.NET Web Forms

Integrated

-

ASP.NET Core Blazor

Integrated

Integrated

Note

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.

In WinForms applications, you can use a Middle Tier application server between your application and the database server instead of client-side security. The following help topic describes how to do it: Middle Tier Security.

Integrated Mode (XPO and EF Core)

SecuredObjectSpaceProvider (XPO) / SecuredEFCoreObjectSpaceProvider<TDbContext> (EF Core) creates secured Object Spaces that incorporate security permissions and filter protected data at the ORM level. As a result, secured data is not displayed in Views and Controllers or report data sources cannot access the data.

The following sections describe how applications with Integrated Security interacts with the database:

XPO-Based Applications

Load Data from the Database

  1. The unsecure Session loads from the database objects that meet the criteria generated according to Security permissions.
  2. The secured Session copies objects from the unsecure Session. If a field value does not meet the permission criterion, it is replaced with the default value in the copied objects. Copied objects are available to users.

Save Data to the Database

  1. The secured Session copies object values that meet the Security permissions to the unsecure Session.
  2. The unsecure Session saves the passed values in original objects in the database.

EF Core-Based Applications

Load Data from the Database

  1. The internal Security service that extends DbContext loads from the database objects that meet the criteria generated according to Security permissions. This service copies the loaded objects and replaces the original field value with the default value if this field does not meet the permission criterion.
  2. The internal Security service passes copied objects to the Secured Object Space. These objects are available to users.

Save Data to the Database

  1. The secured Object Space passes object values to the internal Security service that extends DbContext.
  2. The internal Security service saves the passed values that meet the Security permissions into the database.

Important Notes

  • 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.
  • The OnSaving and OnDeleting methods of a business class can be called multiple times because Integrated Mode and Middle Tier Security use more than one Session/DbContext object. If you implement custom logic in these methods, check whether a new value is already assigned to a property. This helps you avoid incorrect results. The following article describes how to do this with XPO: XPO Best Practices.
  • Detail Views do not display changes made to an object within a transaction (for example, an auto-generated sequential number for an XPO business object) even if you saved this object in a View. These changes are made on the server only and are not automatically passed to the client application. To show these changes, reload the object. If you want to reload the object on each Save operation, override the business class’s OnSaved method. The following example demonstrates how to override this method to reload an object on the client:

    using DevExpress.Persistent.BaseImpl;
    // ...
    public class DemoObject : BaseObject {
        // ...
        protected override void OnSaved() {
            base.OnSaved();
            // 0 is the default value
            if (Number == 0) {
                Session.Reload(this);
            }
        }
    }
    
  • The Session.DataLayer property is null in the secured Session. Instead of DataLayer, we recommend that you use the View.ObjectSpace property to query and change data from the database. This technique is also recommended for non-secure applications.

    If this recommendation does not apply to your scenario, use the Session.ObjectLayer property instead of DataLayer.

    You can also execute different code on the server and client depending on the DataLayer and ObjectLayer property values. The following example demonstrates how to do it:

    using DevExpress.ExpressApp.Security.ClientServer;
    using DevExpress.Persistent.BaseImpl;
    // ...
    public class DemoObject : BaseObject {
        // ...
        protected override void OnSaving() { 
            if(Session.DataLayer != null && !(Session.ObjectLayer is SecuredSessionObjectLayer)) { 
                // Server-side code
            } 
            else {  
                // Client-side code 
            } 
            base.OnSaving(); 
        }
    }
    

UI Level Mode

We do not recommend that you use this mode in XPO-based and EF Core-based applications because applications have direct access to the database in this mode, and you can modify protected data in code (for example, in Controllers). List and Property Editors hide the protected data on the UI level only.

Application with the UI-Level Security System

Important Notes

  • List Editors sort, filter, and group data values, but display placeholder text (‘*******‘) instead of protected values.
  • Web page markup contains real values.
  • In ASP.NET Web Forms applications, the display member is always visible in a Detail View caption.
  • The appearance of a View that displays an object may change after a user modifies this object property. For example, the object has the Name property and object-level permission denies writing objects with criteria Name = Example. In this case, this object is displayed as read-only after the user saves it if the user creates an object and sets its Name property to Example.
  • Additional Modules do not take into account Security permissions. They have direct access to the database through unsecured Object Spaces and can use protected records.