Log In
Home
Support
Demos
Documentation
Blogs
Training
Webinars
[Expand]General Information
[Expand]WinForms Controls
[Expand]ASP.NET Controls and MVC Extensions
[Expand]ASP.NET Bootstrap Controls
[Expand]WPF Controls
[Expand]Xamarin Controls
[Expand]Windows 10 App Controls
[Expand]Document Server
[Expand]Reporting
[Expand]Report Server
[Expand]Dashboard
[Collapse]eXpressApp Framework
 [Expand]Fundamentals
 [Expand]Getting Started
 [Collapse]Concepts
  [Expand]Application Solution Components
  [Expand]Business Model Design
  [Expand]Application Model
  [Expand]UI Construction
  [Expand]Extend Functionality
  [Expand]Data Manipulation and Business Logic
  [Collapse]Security System
    Security System Overview
    Passwords in the Security System
    Client-Side Security (2-Tier Architecture)
    Middle Tier Security - WCF Service
    Middle Tier Security - .NET Remoting Service
    Run the Application Server as a Windows Service
    Security Permissions Caching
    Permissions for Associated Objects
    Permission Policies
  [Expand]Localization
  [Expand]System Module
  [Expand]Extra Modules
  [Expand]Debugging and Error Handling
  [Expand]Filtering
  [Expand]Application Life Cycle
 [Expand]Design-Time Features
 [Expand]Functional Testing
 [Expand]Deployment
 [Expand]Task-Based Help
 [Expand]Frequently Asked Questions
 [Expand]API Reference
[Expand]CodeRush
[Expand]Cross-Platform Core Libraries
[Expand]Tools and Utilities
 End-User Documentation

Security System Overview

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.

Expanded 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.

Expanded 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.

Expanded 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.

Expanded 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. 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

  • 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.

Expanded 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.

Expanded 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.

Expanded 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.

Expanded 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.

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.

How would you rate this topic?​​​​​​​