Security System Overview

• Feb 24, 2022
• 6 minutes to read

This topic describes permission types that are available in the Security System by default, when the Allow/Deny Permission Policy is used. Permissions are not assigned to Users directly. Each user should have at least one Role exposing a set of assigned permissions.

• Administrative Permission
• Edit Model Permission
• Navigation Permissions
• Type Permissions
• Member Permissions
• Object Permissions
• Permissions for One-to-Many and Many-to-Many Associations
• Reference Properties Access
• Restrict Non-Persistent Types Access

Administrative Permission

The IPermissionPolicyRole.IsAdministrative option is intended to simplify the unrestricted access definition and grants all available permissions to a role.

If a role is administrative, it is impossible to deny any rights unless the administrative permission was removed.

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.

Navigation Permissions

In XAF applications, you can manage access to certain navigation items in the new Navigation Permissions tab. The Navigation Permissions is a part of the Security System that provides access to the Navigation Control items for a particular role. You can grant or deny permissions for a single navigation item or for the whole navigation group as shown on the image below.

Item permissions have a greater priority than group permissions. For instance, you can deny access to the group, but grant access for one of its items, so this item will be enabled in the Navigation Panel.

Important

Navigation Permissions influence only the Navigation Items visibility. They do not grant or deny access to business objects associated with navigation items. Instead, use Type Permissions or Object Permissions.

Note

• Navigation Permissions are not supported for individual navigation items when the Deny Permission Policy is selected. The Navigation Permissions tab is not available in this mode. However, you can specify navigation permissions for each type in the Type Permissions tab.
• If your application is created in earlier XAF versions, you need to upgrade an existing project to the Allow/Deny permissions policy. If you use Entity Framework as the ORM system, you may also need to perform a migration to specify permissions for each navigation item.
• Mobile applications do not provide a special Property Editor for modifying a navigation item list, so you can input or modify them only as a string with item names separated with a semicolon. Note that these item names cannot be validated.

Type Permissions

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

The following type of operations 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 user to save new objects.
Delete	Objects of the current type can be deleted.

Member Permissions

Member Permissions grant access to specific members of an object. The following dialog is invoked when double-clicking a record in a type permission list.

For example, users can have access to objects of a particular type and simultaneously have no access to several members of this type. For other example, it is possible to deny access to objects of a particular type and only allow access to a strict list of its members. It is possible to grant access to multiple properties with a single entry - a Members value can be a semicolon-separated list of property names. In WinForms and ASP.NET applications, the CheckedListBoxPropertyEditor simplifies the specification of a Members value (member names can be selected from the combo box).

You can also specify a criterion for a member permission entry. The entry will be active in case the current object satisfies the given criterion.

Note

• Mobile applications do not provide a special Property Editor for modifying a member name list or criterion, so you can input or modify them only as a string. Note that these property names and criterion cannot be validated.
• When a new object is created (and not yet saved), the member permissions do not affect the editors’ enabled/disabled state. However, the permissions will be correctly handled on saving. You can use the Conditional Appearance Module to disable required editors for a new object.

Object Permissions

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

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

Security System can automatically adjust the required permissions for associations. This behavior is described in the Permissions for Associated Objects topic. However, in certain scenarios, you may want to configure permissions for both sides of an association manually. This approach is described in the How to: Manually Configure Permissions for Associated Collections and Reference Properties topic.

Reference Properties Access

The Security System intelligently processes reference properties such as AssignedTo and complex reference properties such as AssignedTo.Name - the current type’s Type Permissions, the reference property type’s Type Permissions, and each member’s Member Permissions (in the property path) are considered. For example, when the SecuritySystem.IsGranted method is called to determine whether or not the current user can modify the AssignedTo.Name property, it checks the ‘Read’ operation for the current type, checks the ‘Read’ operation for the AssignedTo property of the current type, checks the ‘Read’ operation of the referenced type, and checks the ‘Write’ operation for the Name property of the referenced type. Intermediate checks for the ‘Read’ operation are required to consistently process different requests.

Restrict Non-Persistent Types Access

Non-persistent object types are not included in the type permission list and are considered accessible to everyone by default. This is done to avoid the manual assignment of permissions to objects like AboutInfo, ValidationResult, and so on. If you wish to secure certain non-persistent object types, add these types to the static SecurityStrategy.AdditionalSecuredTypes list, and these types will be available in a type permissions list.

C#

SecurityStrategy.AdditionalSecuredTypes.Add(typeof(ValidationResults));

VB.NET

SecurityStrategy.AdditionalSecuredTypes.Add(GetType(ValidationResults))

Note

Non-persistent types cannot be secured at the object level. Only type and member permissions are supported.

You can extend the default permission set. Refer to the How to: Implement Custom Security Objects (Users, Roles, Operation Permissions) topic to see an example. To learn how to implement security in various configurations, see the following topics.

• Client-Side Security (2-Tier Architecture)
• How to: Change the Client-Side Security Mode from UI Level to Integrated in XPO applications
• Middle Tier Security - WCF Service
• Run the Application Server as a Windows Service
• Permissions for Associated Objects
• Permission Policies