KB Article T559861
Visible to All Users

Security permissions processing mechanism optimization and other important changes in XAF v17.2+

We have reworked XAF’s permission processing algorithm. It is now faster and ships with improved ways to extend existing permission functionality (thus simplifying code maintenance). Below is the list of the main improvements:
1. Built-in caching system
This mechanism helps avoid repeated permission calculations for different objects. We’ve improved performance by as much as 30% (see sample configuration below) and reduced security system overhead to less than 10%. Scrolling operation overhead has been eliminated fully. Sample configuration:
    - ListView displaying 10k complex objects (each object includes multiple associated reference and collection properties.
    - 3 security roles with complex permission for all object types
2.  Accelerated Middle-Tier configuration
Data is secured on the server, but permission information is passed to the client along with data, so that UI updates are done without extra requests and the client application works faster. When you create a new application with the Solution Wizard 17.2+, the wizard adds the new Middle Tier code automatically. However, if you want to get the benefits of the new approach for an existing project, you'll need to update the Middle Tier Security implementation in your code. Refer to the How to migrate to the new Middle-Tier implementation after upgrading to XAF v17.2+ article for more details.

3. Independent role processing and role merging modes
The new permission processing algorithm executes permission checks for each role independently. This eliminates complex merging of permissions between several roles and improves performance when a user has many roles assigned.

In the 17.2.5 minor update, the new SecurityStrategy.RolesMergingMode property is added. It specifies how the Security System determines if a user can perform a specific operation when this user has multiple roles with different permission sets. The available modes are listed in the RolesMergingMode enumeration. By default, a user can execute an operation if it is allowed in any role assigned to this user (the GrantedInAnyRole mode). You can set the RolesMergingMode property to GrantedInAllRoles to make the behavior stricter and demand that an operation should be allowed in all roles.

You can change the RolesMergingMode value in the Application Designer.

4. Reworked sub-system of permissions checking for associated objects
For better reliability and flexibility, we have introduced three permission handling modes for associated objects:
Auto:
The default and fastest mode. It relies on simplified permission processing for associated collections. If you have criteria in permissions for the 'Many' side of the association, use the ExtendedAuto or Manual modes (manually set permissions to both sides of the association).
ExtendedAuto:
This mode does not have usage limitations like Auto, but is slower. In case of noticeable performance problems in this mode, use the Manual mode (manually set permissions to both sides of the association).
Manual:
This mode provides atomic control and allows you to manually set permissions to both sides of the association, as described at How to: Manually Configure Permissions for Associated Collections and Reference Properties.

To change the mode, use the SecurityStrategy.AssociationPermissionsMode property:

5. Permissions for base and descendant types
Previously, the security system considered permissions from descendant types by mistake. With v17.2, it only considers permissions for a specific type and its base types (set permissions to both sides of an association). To help illustrate, imagine a base class Person and its descendant Employee:

C#
public class Person { ... } public class Employee : Person { ... }

There are two object-level permissions configured for these business classes:
 -  A 'read' operation is allowed for a Person object with Name = "John";
 -  A 'read' operation is allowed for an Employee object with Name = "Sam"

Old behavior:
 -  A 'read' operation for both types and objects with Name = "John" or Name = "Sam" is allowed, which is non-obvious.
New behavior:
 -  A 'read' operation for the Person object with Name = "John" is allowed.
 -  A 'read operation for the Employee with Name = "John" or Name = "Sam" is allowed.

NOTE: The old behavior was incorrect and should no longer be used. If you're currently using the old behavior, we highly recommend that you switch to the new mechanism and update your permissions accordingly. For backward compatibility, it is also possible to disable all aforementioned improvements by setting the SecurityStrategy.UseOptimizedPermissionRequestProcessor  property to False.

See Also:
Controller creation performance optimization v17.2 Preview

Show previous comments (9)
DevExpress Support Team 7 years ago

    I've updated the third section (Independent role processing and role merging modes). In the 17.2.5 minor update, the SecurityStrategy.AssociationPermissionsMode property is added.

      In 17.2.5, why is the new permission not available when it added by the Updater class?
      If you are new to your own permissions is no problem, but in the updater of this class automatically new permissions will not take effect.

      Dennis Garavsky (DevExpress) 7 years ago

        @he dandan:
        I've created a separate ticket on your behalf (T600540: Questions on the new permissions processing mechanism). It has been placed in our processing queue and will be answered shortly.

        Disclaimer: The information provided on DevExpress.com and affiliated web properties (including the DevExpress Support Center) is provided "as is" without warranty of any kind. Developer Express Inc disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. Please refer to the DevExpress.com Website Terms of Use for more information in this regard.

        Confidential Information: Developer Express Inc does not wish to receive, will not act to procure, nor will it solicit, confidential or proprietary materials and information from you through the DevExpress Support Center or its web properties. Any and all materials or information divulged during chats, email communications, online discussions, Support Center tickets, or made available to Developer Express Inc in any manner will be deemed NOT to be confidential by Developer Express Inc. Please refer to the DevExpress.com Website Terms of Use for more information in this regard.