One of the main features in sensenet is its complex - yet easy-to-use - permission system. You can set permissions on every Content in the Content Repository to restrict user access and to fine-adjust the actions available on specific Content for different users. The sensenet permission system uses a model based on permission inheritance with allow and deny rules.
The permission system in sensenet is a mixture of three permission features:
Before we go through the different permission models, we have to know the items we are working with. In sensenet there are 3 types of identities you can set permissions for on a content.
A user represents a single person. It is a content itself that can be created, modified or deleted the same way as other content.
To manage users as an administrator, please go to the /Root/IMS folder in Content Explorer.
Users can be synchronized from Active Directory to let them sign in automatically using their Windows account. All users reside under a domain and they must have a unique name and login name inside that domain so that the system can identify them correctly upon login.
A group is a content in the Content Repository that cannot have physical children but has a Members Reference Field that can contain users or other groups.
Because a group may have other groups as a member, group membership works in a transitive way: if a user is a member of GroupA and GroupA is a member of GroupB, the user is also considered a member of GroupB. This means all the permissions set for GroupB will be relevant for the user.
When you set permissions for a group, that setting will be taken into account in case of every single member user when they log in to the system. This is why it is advisable to set permissions for a group (or organizational unit) instead of individual users: when a new user comes in or leaves the company, you do not have to bother with permission settings: you just have to add them to a group or remove them from one.
Groups and group memberships can also be synchronized from Active Directory.
There are two types of groups in sensenet:
There are also a couple of Special and built-in groups and users in sensenet that worth noting - please review them before you start working with the permission system.
Organizational units work the same way in terms of permission settings as groups: all users under an org unit will receive the permissions set for the org unit. The difference is in the structure: org units do not have members but child elements (users, other org units or even subfolders), so they can be used to build a tree structure (for example of departments) in the Content Repository. This means users are placed physically under org units, so they cannot be under two org units at the same time (except of course in the same hierarchy, for example sub-department).
Organizational units can also be synchronized from Active Directory.
The following apply to declarative permissions in sensenet:
Besides using a simple GUI to define declarative permissions it is also possible to work with permissions programmatically. This can be useful when you want to restrict access to a certain function for a defined set of users/groups/organizational units. sensenet provides a simple API to check permissions in the following aspects:
Programmatic permissions are defined at development time, but of course it is always possible to implement permission checks in a flexible, configurable way. Read more info on using programmatic permissions in the Permission API article.
Within an organization roles are created for various job functions. The permissions to perform certain operations are assigned to specific roles. Members of staff (or other system users) are assigned particular roles, and through those role assignments acquire the permissions to perform particular functions. Since users are not assigned permissions directly, but only acquire them through their role (or roles), management of individual user rights becomes a matter of simply assigning appropriate roles to the user’s account; this simplifies common operations, such as adding a user, or changing a user’s department. See more info about the role-based security concept here:
In sensenet there are different approaches to assign roles and many role based security problems can be solved with declarative permissions (see above) that makes role based permission handling in sensenet flexible and easy-to-use. The following approaches can be used to define role based permissions:
The sensenet role-based permission model comes with the following features:
When an action request arrives (e.g. edit or delete), the sensenet application model handles it: for every content an application will be resolved to serve that content. The permission on the application can restrict whether the request can be served or not (e.g. does the user have RunApplication permission? Are there required permissions on the content defined by the application - e.g. Delete permission required by the Delete app).
You can read more about the application framework in sensenet here:
An important implication of the application model on permissions is the following: since applications (smart pages, etc.) are also content in the Content Repository, users need to have permissions on those, too. So when rendering a content/action, the users need to have permissions on both the content and the application. Example: if a user tries to upload a document to a document library, then the user needs See, Open, Save and most importantly Add new permissions on the document library and also Run Application permission on the Upload action, which can be found at /Root/(apps)/Folder/Upload. Read more about applications and permissions here:
There are some special cases when users need to have special permissions to be able to access a feature or a service. Such service for example is the REST Api that handles requests for the content picker or the tree in the Content Explorer. These permissions are controlled by content under the /Root/System/PermissionPlaceholders folder and in some legacy cases the /Root/System/WebRoot folder.
The following types of built-in permissions are defined in the system. These permissions are not customizable:
Permissions are inherited, so giving access to manipulate permissions of a single Content may result in allowing implicit access to influence permissions of other Content in that subtree as well.
The names of the permissions are internationalized. Resource file is: /Root/Localization/PortalResources.xml. In the file the permission names are prefixed with ‘Permission_’.
There may be certain constraints when setting a specific permission on a Content. For example it is not possible (and not rational) to give Save permissions for a user, when the user is not allowed to see the given Content. These kinds of permission constraints are handled by the portal both in GUI and in API level. The former means that the permission editor UI provides handy mechanisms to automatically show and set the required permissions for you. See the following article for details:
In sensenet every content is stored in a huge tree with a single root. When you set a permission on a high level item (close to the root), e.g. a site or a workspace, it will be inherited by its children. This way you do not have to set permissions on every subfolder or document, because all content inherit permissions from their parent.
Inherited permissions cannot be changed (without breaking the inheritance, see below) therefore their checkboxes are grayed out. But you can set additional permissions for the same identity (e.g. grant Open permission to someone who already has See permissions inherited).
Of course (as an exception) you may set local only permissions that are not propagated to children, see the ‘local only permissions’ section below for details.
You may decide to change some permissions inherited from above - e.g. you inherited an Open permission for a user that you do not want to allow in a subtree. In that case you can break permission inheritance on a content. That means all the inherited permission entries will be copied to the current content and from than on you will be able to change them (usually remove one or more). The new permission set (even if it contains less entries than the inherited) will be the one that is used in that subtree.
If possible break permissions in exceptional cases only, because it makes permission administration more complicated. The Permission Overview UI may help you work with a complex permission structure.
One of the most powerful features of the permission system in sensenet is the permission inheritance. There are cases however when you do not want child content to inherit a permission entry. For example you want to allow certain users to see a content (e.g. a Content List) but you do not want them to be able to see content that were added to that list. A typical use case for this is when you allow Visitors to Open and Add content to a Form but you do not want them to be able to open any items added to the form by others. In this case you would set a local only (in other words not inherited) permission entry on the Form for Visitors. The advantage of this construct is that you do not have to break inheritance on the content (in this case the Form), which means any permission entries set on the tree above will still be inherited by child content. As you can see on the image below you can mark the permission entry as ‘local-only’ when you add it on the set permission page. Every local-only permission entry is clearly marked on this page. You can even set inherited an local-only entries for the same users or groups side-by-side.
When you set permissions for an identity, you can either allow that user or group to access a certain feature or deny it.
Deny is always stronger than allow.
If you set a deny permission for a certain user, it does not matter if she has allow permission inherited from above or through a group membership - she will not be able to access that feature. You can only make deny permission disappear on lower levels only if you break permission inheritance on a subfolder and remove the deny permission there.
It is advisable to set as few permissions on higher levels (closer to the root) as possible and allow access on subfolders instead of allowing everything on the root and use deny to hide something later. Think of working with local only permissions (see above) too to let users see certain content in the tree but not their child items.
The built-in permission set can be extended with 17 custom permissions. These permissions are by default hidden from the UI and have no effect on permission checks but a builder or developer can easily bring custom permissions into the set of effective permissions. To learn more about using custom permissions read the following article:
Is something missing? See something that needs fixing? Propose a change here.