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
Looks promising - will parent/child roles then be supported by the permissionpolicyrole?
Dear Andrey,
Thanks for letting us know this major improvement. Honestly, I was struggling with slow performance of XAF web as I have hundreds of Business Objects and complex/multiple security roles for users, with what you have detailed in this article looks like you have hit the head of the nail, this is brilliant stuff and I am very much eager to see receive v17.2
Great job and it truly indicates the commitment DevExpress is having towards XAF.
Hello,
@Martin Praxmarer - DevExpress MVP - I've created a separate ticket on your behalf (When will parent/child roles be supported by the PermissionPolicyRole). I will answer you there.
@MohammedFarooq Thanks for your interest. I've answered you in a separate private ticket.
Thanks,
Andrey
I also love the new features! Can't do any testing myself though but wanted to express my appreciation for all your effort towards XAF!
Do you plan to develop some diagnostics tool that allows administrators to verify how the security settings work out in practice for different users? This is an issue of growing importance for us because of all anti data leak and data privacy laws. How can we show management that the right security settings for each web portal user are in place? Or does this question deserve an own ticket?
Thank you!
Willem
@Willem: Thanks for your feedback. My team and I would be happy to hear from you once you have had an opportunity to practically test this in your real project. Please keep us informed when you have a chance to.
I've created a separate ticket on your behalf for the second part (T561660: Testing security permissions for different users). Yes, it is almost always better to discuss different problems in separate tickets. It is easy to use the https://www.devexpress.com/ask service to start a new discussion (you can add it to the Favorites bar of your web browser). Thanks for your understanding and cooperation.
@Dennis I would like to try the new version please.
@Alex: I've provided you with the preview installation in a separate private ticket. Feel free to provide your testing results there. Thanks for your help.
@Dennis I would also like to try the new version please.
@Michail: I've provided you with the preview installation in a separate private ticket. Feel free to provide your testing results there. Thanks for your help.
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.
@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.