Security (Access Control & Authentication)

• Jan 30, 2023
• 8 minutes to read

This topic describes the Security System’s permission types. Configure permissions in a role and assign it to a user. Each user should have at least one role. The Security System checks permissions for each role and determines access rights as described in the following topic: Merging of Permissions Defined in Different Roles.

To see the Security System in action, refer to the SecurityDemo XAF application. This demo application is available in the %PUBLIC%\Documents\DevExpress Demos 21.2\Components\eXpressApp Framework\SecurityDemo folder.

Note

The Security System also supports non-XAF .NET applications. As a registered DevExpress.com user, you are entitled to a free copy of .NET Role-based Access Control & Permission Management API powered by Entity Framework Core (EF Core) and DevExpress eXpress Persistent Objects(XPO) ORM tools. For more information on this offer, refer to the following pages: .NET App Security API (Role-based Access Control) – Free Offer from DevExpress | GitHub examples, Technical FAQ, or tutorial videos.

Administrative Permission

The IPermissionPolicyRole.IsAdministrative option grants all available permissions to a role.

You cannot deny any rights for a role with the Administrative Permission.

Edit Model Permission

The IPermissionPolicyRole.CanEditModel option allows users associated with the current role to use the Model Editor.

When the Edit Model or Administrative permission is granted, the EditModel Action is available in the Tools category.

Permission Policy

The Permission Policy determines the Security System’s behavior when a specific type, object, or member does not have explicitly specified permissions. Refer to the following topic for more information: Permission Policy.

Navigation Permissions

In XAF applications, you can manage access to navigation control items in the Navigation Permissions tab. You can grant or deny a permission for a single navigation item or for the entire navigation group as shown in the image below:

Item permissions have a greater priority than group permissions. For instance, if you deny access to the group, but grant access for one of its items, this item is enabled in the navigation control.

Important

Navigation permissions manage the visibility of the navigation control’s items. They do not grant or deny access to navigation items’ associated business objects. Use Type permissions or Object permissions to manage access to these objects.

Note

If you created an application in XAF v16.1 or earlier, you should upgrade the application’s project to the Allow/Deny Permissions Policy to enable the Navigation Permissions tab. If you use the Entity Framework as the ORM system, you may also need to perform a migration to specify permissions for each navigation item.

Type Permissions

The Type Permissions tab specifies access to all objects of a particular type. The image below illustrates the PermissionPolicyRole Detail View.

The following operation types can be granted or denied:

Operation	Description
Read	Objects of the current type are readable. To make an object read-only, allow the Read operation and deny the Write operation.
Write	Objects of the current type are editable.
Create	New objects of the current type can be created. Note that granting Create without Write does not allow a user to save new objects.
Delete	Objects of the current type can be deleted.

Object Permissions

Object permissions grant access to object instances that fit a specified criterion. The following image illustrates the Object Permissions tab in the Type Operation Permissions dialog.

Member Permissions

Member permissions grant access to specific members of an object. Double-click a record in a type permission list to invoke the following dialog:

For example, users can have access to objects of a particular type and simultaneously have no access to several members of this type. For another example, it is possible to deny access to objects of a particular type and only allow access to a strict list of its members. You can set a Members value to a string that is a semicolon-separated list of property names. In WinForms and ASP.NET Web Forms applications, the CheckedListBoxPropertyEditor simplifies the specification of a Members value (select member names in the combo box).

You can also specify a criterion for a Member permission entry. The entry is active when the current object meets the criterion.

Note

• In ASP.NET Core Blazor applications, you can input or modify a criterion only as a string. XAF validates this criterion before it saves a Member Permission record.
• When you create a new object, Member Permissions do not affect the enabled/disabled state of its editors until you save the object. To disable specific editors for a new object, use the Conditional Appearance Module.
• Member Permissions affect non-persistent properties at the UI level only. If you deny access for a particular non-persistent property, XAF hides its editor from the UI, but you can access its value in code.

Action Permissions

The Security System allows you to prohibit execution of both custom and XAF system Actions. Click the Denied Actions tab and specify Actions to be hidden from the UI. The image below illustrates the Role Detail View that shows this tab.

The Security System marks built-in Actions as non-secure and hides them in the Denied Actions tab. The NonSecureActionsInitializing event allows you to customize a list of non-secure Actions. Add custom or remove system Actions from the NonSecureActions collection to manage whether they are available in the Denied Actions tab.

Note that Action Permissions hide Actions unconditionally. If you want to change Action visibility dynamically, use the Conditional Appearance or State Machine Module functionality, set TargetObjectsCriteria, or create custom rules that depend on criteria or object/UI changes in Controllers.

Permissions for One-to-Many and Many-to-Many Associations

The Security System automatically configures permissions for one side of an association if the other side is specified. The Permissions for Associated Objects topic describes this behavior. You can also specify permissions for both sides of an association. Refer to the following topic for more information on this technique: How to: Manually Configure Permissions for Associated Collections and Reference Properties.

Reference Properties Access

To determine whether access to reference properties such as AssignedTo and complex reference properties such as AssignedTo.Name is allowed, the Security System checks the current type’s Type permissions, the reference property type’s Type permissions, and each member’s Member permissions (in the property path). For example, when the CanWrite<T>(SecurityStrategy, String) method is called to determine whether the current user can modify the AssignedTo.Name property, the Security System checks the following operations:

• the ‘Read’ operation for the current type
• the ‘Read’ operation for the AssignedTo property of the current type
• the ‘Read’ operation of the referenced type
• the ‘Write’ operation for the Name property of the referenced type

Restrict Non-Persistent Types Access

The Security System allows you to configure Type Permissions for persistent types only. Non-persistent objects are not secured and users can access them. If you want to protect a non-persistent object type, add this type to the static SecurityStrategy.AdditionalSecuredTypes collection and configure a Type permission for this type.

The following examples show how to add the non-persistent MyClass type to the AdditionalSecuredTypes collection.

WinForms

C#

using DevExpress.ExpressApp.Security;
// ...
public partial class MainDemoWinApplication : WinApplication {
    static MainDemoWinApplication() {
        SecurityStrategy.AdditionalSecuredTypes.Add(typeof(MyClass));
    }
    // ...
}

VB.NET

Imports DevExpress.ExpressApp.Security
' ...
Partial Public Class MainDemoWinApplication
    Inherits WinApplication
    Shared Sub New()
        SecurityStrategy.AdditionalSecuredTypes.Add(GetType([MyClass]))
    End Sub
    ' ...
End Class

ASP.NET Web Forms

C#

using DevExpress.ExpressApp.Security;
// ...
public partial class MainDemoWebApplication : WebApplication {
    static MainDemoWebApplication() {
        SecurityStrategy.AdditionalSecuredTypes.Add(typeof(MyClass));
    }
    // ...
}

VB.NET

Imports DevExpress.ExpressApp.Security
' ...
Partial Public Class MainDemoWebApplication
    Inherits WebApplication
    Shared Sub New()
        SecurityStrategy.AdditionalSecuredTypes.Add(GetType([MyClass]))
    End Sub
    ' ...
End Class

Blazor

C#

using DevExpress.ExpressApp.Security;
// ...
public partial class MainDemoBlazorApplication : BlazorApplication {
    static MainDemoBlazorApplication() {
        SecurityStrategy.AdditionalSecuredTypes.Add(typeof(MyClass));
    }
    // ...
}

Note

Non-persistent types support only the Type and Member permissions, and the Security System applies these permissions only at the UI Level. Refer to the Client-Side Security (2-Tier Architecture) - UI Level Mode topic for more information about this mode and its limitations.

Check Security Permissions in Code

The following help topic describes how to check if a user has a specific role or has permission to perform a specific operation: Determine if the Current User Has Specific Permissions.

Refer to the following topics for more information on security customization:

• How to: Implement Custom Security Objects (Users, Roles, Operation Permissions)
• How to: Implement a Custom Security Operation that Can be Permitted at the Type Level
• How to: Implement a Custom Security System User Based on an Existing Business Class