Overview: Permissions

Permissions are special rules associated with items. Тhey determine whether a user can execute an action with an item.
Each action can be granted (allowed) or denied to a specific user or role. In ASP.NET terminology, users and their roles are called Principal.

Permissions in Sitefinity CMS are inheritable. This enables you to make a permission assignment to a user or role once and have this permission applied to each of its child items. If you want to customize permissions of an inheriting child item, you must break the inheritance. This way, you can modify the child item's permissions. This behavior can reduce complexity and time needed for managing the security of the system.
The root object at the permissions inheritance hierarchy is Security Root, which is instantiated per provider.

You manage permissions on Permissions page.

To open the Permissions page, in the main menu in the upper part on the screen, click Administration » Permissions.

Each permission has Deny and Allow values for a specific action. If neither the Allow, nor the Deny is set, the user is implicitly denied the permission. By default, no values are set for the Allow and for the Deny. The default behavior is to deny a permission, unless it is explicitly allowed. Explicit denial takes precedence over explicit grant on the same action.

Explicit Deny always has precedence over implicit or explicit Allow, while implicit Deny does not have precedence over explicit Allow.

EXAMPLE: If a permission for a role is not set, by default, it is implicitly denied. However, if a user is assigned to a role and the same permission is explicitly allowed to the user, the user is granted this permission.

User permissions do not have precedence over role permissions.

EXAMPLE: If a role is explicitly denied a permission, a user that is assigned to the role will always be denied this permission, regardless of whether the same permission is explicitly granted to the user or not. if a regardless of whether it is applied to the role or the user.

This is why, if a certain permission for a given user is not set in one role and explicitly set in another role, the permission is assigned to the user - the user inherits the Allow or Deny for this permission. 

Another example of Sitefinity's hierarchical model can be seen in Sitefinity's structure of pages, as depicted in the following diagram. At the top of the hierarchy are the pages that serve as roots for the backend and for the frontend hierarchies. When multiple sites are managed by the multisite module, each site has its own frontend root page. Every top page in Sitefinity CMS, either on the frontend or on the backend, inherits from its respective root page, each child page inherits from its parent page, and so on.

In order to modify the permissions of an item, which inherits permissions from a parent item, you must first break the permissions inheritance. This operation clones the inherited permission from the parent item to the inheriting item, which enables you to modify them locally. You do this by clicking the Break inheritance button on the permissions screen:

You can revert the broken permissions inheritance by clicking Inherit permissions from parent. Restoring permissions inheritance clears the customized permissions of the specified item and replace them again with the permissions of its parent:

When you retrieve and display a collection of items, both on the frontend and the backend, for performance optimization, the system does not take into account the View action of each specific item. The setting that controls this behavior is Enable filtering queries by view permissions. When enabled, the view permissions are evaluated when fetching items collections. For more information, see Change filtering by View permissions.

NOTE: Enabling filtering queries by View permissions is a performance costly operation.

EXAMPLE: If you have a permission to Create or Modify an item, you are also implicitly granted the permission to view it, even if the View permission is not explicitly granted to you. You will not be granted View permission, only if the View permission is explicitly denied to you.

To deny permissions to users and roles for accessing a module, navigate to Administration » Permissions and set permissions for the respective module on Access <module name> module.

For dynamic modules, navigate to Content » <Dynamic module name> and click Permissions, set permissions for the module on View <dynamic module name> backend link.

For easier management and separation of actions per context, permissions are logically grouped into permission sets. For example, the View permission for a blog post is not the same View permission for comments on that post, but the blog post supports both View permission actions separately in two different permission sets.

EXAMPLE: The General permission set consists of permissions for general CRUD operation actions, such as view, create, edit, delete, change owner and change permissions. The Pages permission set consists of actions specific for pages, such as Edit content, and Modify title and properties.

Sitefinity CMS has roles created by default, which have certain permissions assigned to them. For example, Authors, Editors, or Designers. You can delete these roles if you do not need them. To view the permissions assigned to each default role, in the main menu, click Administration » Roles. To view the permissions of a default role, click its Permissions link. If a role has permission for a certain action, the system displays  in column Allow.