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.
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.
When the Edit Model or Administrative permission is granted, the EditModel Action is available in the Tools category.
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.
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.
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.
|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 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.
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.
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.
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.
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.
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.