Back to Devexpress

Roles and Permission Policy

expressappframework-116172-data-security-and-safety-security-system-security-object-model-permission-policy.md

latest4.8 KB
Original Source

Roles and Permission Policy

  • Oct 24, 2025
  • 2 minutes to read

The Allow/Deny Permission Policy determines Security System’s behavior when there are no explicitly specified permissions for a specific type, object, or member.

The application’s administrators can allow access to all data within the application for a specific role and simultaneously deny access to certain data types or members. They can also deny access to all data for a role and only allow access to a specific list of objects or members.

Note

You should upgrade an existing project to the Allow/Deny Permissions Policy if you created an application in XAF v16.1 or earlier. If you use the Entity Framework as the ORM system, you may also need to perform a migration to switch from the obsolete Deny to the Allow/Deny policy.

The Permission Policy uses the following security user and role types:

Built-in XPO classesBuilt-in EF Core classesCommon interfaces to support in custom classes
User TypePermissionPolicyUserPermissionPolicyUserIPermissionPolicyUser
Role TypePermissionPolicyRolePermissionPolicyRoleIPermissionPolicyRole

Note that applications generated by Template Kit use the ApplicationUser class (found in SolutionName.Module\BusinessObjects\ApplicationUser.cs) to store user data. This class extends PermissionPolicyUser and implements the ISecurityUserWithLoginInfo interface required to store user login information in applications with multiple authentication methods.

The PermissionPolicyRole classes expose the IPermissionPolicyRole.PermissionPolicy property:

You can use this property to assign “deny all”, “read-only all”, or “allow all” default Permission Policies to each role, and explicitly specify the Allow or Deny modifier or leave it blank for each operation.

The Security System checks whether access to an object’s property is allowed on several levels. The following image shows the levels in priority order:

“Member Permission by Criteria” has the highest priority and the Security System processes it first. The Security System uses explicit permissions at this level to determine whether access is allowed. If the role does not have any explicit permissions on this level, the Security System processes permissions at the next level according to the scheme above.

The “Role’s Permission Policy” has the lowest priority and is used only when type, object, and member permissions are not explicitly specified.

See Also

Permissions for Associated Objects

Manually Configure Permissions for Associated Collections and Reference Properties

Merging of Permissions Defined in Different Roles

Assign the Same Permissions for All Users of an Active Directory Group