expressappframework-116170-data-security-and-safety-security-system-security-object-model-permission-policy-permissions-for-associated-objects.md
This topic explains how the XAF Security System processes permissions for one-to-many associations, many-to-many associations, and reference properties.
The Security System automatically configures permissions for one side of an association if the other side is specified. You can also specify permissions for both sides of an association. For information on how to do that, refer to the following topic: Manually Configure Permissions for Associated Collections and Reference Properties.
The Security System allows users to read/write a non-aggregated associated property if you explicitly granted access to one side of the association.
For example, the Department and Contact business objects form a one-to-many relationship. The Department type implements the Contacts collection property. When you grant access to Department.Contacts , the Security System allows access to the Contact.Department property. The Security System also allows access to the default properties of associated objects, unless the properties are marked with the PersistentAlias attribute. These properties are used to identify referenced objects in the application UI.
Important
The Contact List View is displayed even if you did not allow access to this type explicitly. If such behavior is undesirable, manually prohibit access to the type.
If you specify a read permission for an aggregated collection and do not specify permissions for another side of an association, the Security System grants read permissions for the aggregated type. If you specify a write permission for the aggregated collection, the Security System allows write/create/delete operations on the aggregated type.
For example, Contact and Note business objects form a one-to-many relationship. Contact implements the Notes aggregated collection property. If you grant permissions to read the Contact.Notes collection, the Security System automatically allows users to read the Note type. If you grant write permissions for the same collection, the Security System automatically allows users to create, edit, and delete Note objects.
Important
In this example, a user can access the Note type and all its properties. If such behavior is undesirable, manually prohibit access to the type.
The Security System requires explicitly specified permissions for both sides of a many-to-many association. See the following topic for information on how to manually specify required permissions: Manually Configure Permissions for Associated Collections and Reference Properties.
Read/write permissions for a reference property in the parent object apply to all members of the linked object (except for properties of secured types). Note that if read/write permissions for the reference object or some of its members are explicitly prohibited by active security rules, these rules take precedence and override the automatically granted permissions.
For example, consider an Order business object that has a FileData reference property of the FileData type. Assume that you add permissions that allow users to read an Order object’s FileData property. If automatic permissions for reference properties are enabled, users will be automatically granted permissions to read FileData objects that are linked to Order objects. Otherwise, you would need to manually configure permissions for the FileData type.
Important
In this example, a user can access the FileData type and all its properties. If such behavior is undesirable, manually prohibit access to the type.
Template Kit generates code that enables the described behavior in new projects. To enable it in projects created by older versions of the wizard, set the SecurityStrategy.AutoAssociationReferencePropertyMode setting to AllMembers.
File: MySolution.Blazor.Server/Program.cs, MySolution.Win/Program.cs, MySolution.WebApi/Program.cs
public static int Main(string[] args) {
// ...
DevExpress.ExpressApp.Security.SecurityStrategy.AutoAssociationReferencePropertyMode =
DevExpress.ExpressApp.Security.ReferenceWithoutAssociationPermissionsMode.AllMembers;
}
To explicitly disable this behavior, set the SecurityStrategy.AutoAssociationReferencePropertyMode setting to None:
File: MySolution.Blazor.Server/Program.cs, MySolution.Win/Program.cs, MySolution.WebApi/Program.cs
public static int Main(string[] args) {
// ...
DevExpress.ExpressApp.Security.SecurityStrategy.AutoAssociationReferencePropertyMode =
DevExpress.ExpressApp.Security.ReferenceWithoutAssociationPermissionsMode.None;
}
The AssociationPermissionsMode enumeration lists modes that determine how the Security System processes permissions for associated objects. To change the mode, set the SecurityStrategy.AssociationPermissionsMode property to one of the following values:
|
Value
|
Description
| | --- | --- | |
Auto
|
The default mode. This mode does not process criteria in permissions for the ‘Many’ association’s side but works faster than ExtendedAuto. If you have criteria in these permissions, set permissions on both sides of an association or use the ExtendedAuto mode.
| |
ExtendedAuto
|
This mode handles all scenarios but is slower than Auto. If this mode slows down your application, set permissions with criteria on both sides of the association.
| |
Manual
|
Use this mode to configure permissions for both sides of the association. Refer to the How to: Manually Configure Permissions for Associated Collections and Reference Properties topic for more information on this approach.
|
Use the SecuritySystem.IsGranted method to check whether a member, a type, or an object has permissions that allow a user to execute or prevent a user from executing an operation.
The Security System makes a permission request for the specified member and checks if this member is a part of an association (see IMemberInfo.IsAssociation). If this condition is satisfied, the IsGranted method returns one of the following values; otherwise, the Security System checks the next condition (step 2).
If an association was not found at the first step, the Security System checks if the member has explicitly specified permissions. If this condition is satisfied, the IsGranted method returns one of the values listed below; otherwise, the Security System checks the next condition (step 3).
If an association was not found at the first step and the member does not have explicitly specified permissions, the Security System checks if the specified member is a default property (see XafDefaultPropertyAttribute). If this condition is satisfied, the Security System makes a permission request for all associations in the class that contains this member; otherwise, it checks the next condition (step 4). The IsGranted method returns one of the values listed below:
If no condition in any previous step was met, the Security System checks_ if the class that implements this member is used in another class as a type of an aggregated collection_. The IsGranted method returns one of the values listed below:
Note
The Security System does not process permission requests for the association’s Navigate operation.
See Also
Manually Configure Permissions for Associated Collections and Reference Properties