- 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.
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 users and roles types:
|Built-in XPO classes||Built-in EF Core and EF 6 classes||Common interfaces to support in custom classes|
The PermissionPolicyRole classes provide 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 an 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 has not 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.