Skip to main content
.NET 8.0+

Roles and Permission Policy

  • 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 classes Built-in EF Core classes Common interfaces to support in custom classes
User Type PermissionPolicyUser PermissionPolicyUser IPermissionPolicyUser
Role Type PermissionPolicyRole PermissionPolicyRole IPermissionPolicyRole

Note that applications generated by XAF Solution Wizard 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:

PermissionPolicy

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:

PermissionsPriority

“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