Common Security Concepts

This article covers Sitecore security systems, common security concepts, main terms and definitions. It also describes main security rights assignment concepts.

1. Security Domains

By default, Sitecore is configured with two security Domains described below in detail.

1.1. The Sitecore Domain - Internal Security

The Sitecore Domain handles security for the Sitecore clients. This domain stores information about content editors, administrators, developers and other members of the team who build and maintain the site.

1.2. The Extranet Domain – Site Security

The Extranet Domain defines who can access the information published on the Intranet, Extranet and/or Internet website. We will generally refer to this as extranet security regardless of what application is being built.

2. Security Concepts

The concept of users, rights and roles, described in detail below, is common for both internal and extranet security. Each security domain is similar to that of the Windows NTFS security model. One or more roles can be assigned to any user where each role contains certain rights. Security can be applied to system tabs and templates. This means that both those fields, as well as many other ones, can be assigned security settings. All items can be assigned security rights.

2.1. Users

A user is an individual that can logon to the system with the proper credentials.

2.2. Rights

Rights are a set of possible actions that can be assigned to a role on a per item basis:

Read
Gives permission to view the content of an item.
Write
Gives permission to modify the content of an item.
Rename
Gives permission to change the name of an item.
Create
Gives permission to create children of the item.
Delete
Gives permission to delete an item.

IMPORTANT: The Delete command also deletes all child Items, even if the User has been denied Delete rights for one or more of the subitems.
Administer
Gives permission to manage security on an item.

NOTE: If assigned to a non-Administrator user, additional steps are required to enable the user to see the Security field. See more information in the Standard Template section.

Rights may be explicitly allowed, explicitly denied, or inherited from a parent item. If a right is allowed for one role, but denied for another, the deny setting takes precedence. The list of available rights may not be customized.

2.3. Roles

Roles provide a mechanism for grouping users. Any given user may have one or more associated roles. Security rights may be granted or denied to individual users or roles.

2.4. Security Templates

Both the Intranet and Extranet securities use a common User template.

There are three common security templates designed:

User – defines the attributes for user description (see below)

Role – denotes item as a security role; contains only “icon” attribute for the role

Folder –primary use is role or user grouping

IMPORTANT NOTE:

All security templates are defined in the /sitecore/shell/security templates.xml file, not in content database. This means that it’s impossible to edit the templates without manual file modification, which, in turn, is highly discouraged.

The User template contains the following fields:

User
Login name
Fullname
The user’s full name
Icon
Icon for representing the user in User Manager wizard
Administrator
If checked, the user can access everything regardless of security settings
Password
The user’s password
Roles
Set of roles assigned to the user
Portrait
An icon or image which represents the user in the sitecore menu of the Desktop client

Start Url
Defines where user should be redirected after login to the Sitecore client.
Three options are available:

Mode	Start URL
Preview	/default.html?sc_mode=edit
Content Editor	/sitecore/shell/applications/content editor.html
Desktop	/sitecore/shell/default.html

CanBoost
Reserved for future use
ClientLanguage
Language of user interface of Sitecore client. Not yet implemented, reserved for future use
RegionalIsoCode
Defines regional ISO code for the user. Affects how numbers, currency, date and time are formatted
DefaultItem
Defines the item displayed by default in Content Editor
Wallpaper
Defines desktop wallpaper for the user

2.5. Template Fields and Rights

You can assign security settings to the field level. For instance, a developer may configure one role to have Read and Write access to a particular field, while another role may only have Fead access, and a third role neither Read nor Write access.

The security settings for an individual field are set in the Field Security control, which is positioned at the bottom of the Data section for a given field. Fields are edited with the Template Editor.

2.6. Standard Template

All items inherit, by default, from the Sitecore provided "Standard template". As a developer you may change security settings on particular fields on the Standard template, thereby granting or denying roles or user Read or Write access to Standard template fields.

Note that most of the Standard template fields are Denied access to the Everyone user. This means that only Administrator users may see these fields. If you want to make currently protected fields visible to non-Administrator users, you must first set the Read access right to Inherit for the Everyone user. Therefore, set the Read access right to Allow for roles and/or users that you want to be able to view the given field. Allow Write access for roles and users that should be able to modify the fields.

2.7. Masters and rights

Masters can also be assigned rights. Rights assigned to a Master indicate which users will see the Master in the New menu in the Content Editor or Preview clients.

2.8. Items and rights

Each item is assigned individual rights at the Security section accessible via the Content Editor.

2.9. Workflows

Sitecore’s workflow mechanism is imtimately interconnected with Sitecore’s security model. Security settings on workflow states influence both a given user’s access rights on items when they are in the state as well as visibility of the state in the user’s Workbox application. Access rights on individual items influence whether an item will be visible in a specific user’s Workbox.

The rules are as follows (note, you can check ”resolved access rights” in the Access Viewer):

Resolved Access Rights on a Workflow State

Read: If a user has Read access to a given state, then the state will appear in their Workbox application. The state is hidden in the Workbox if the user does not have Read access to the state.
Write: If a user has Write access to a given state, then they may have Write access to items currently in that state. If the user does not have Write access to the state, then they will not have Write access to any items in that state.
Delete: If a user has Delete access to a given state, then they may have Delete access to items currently in that state. If the user does not have Delete access to the state, then they will not have Delete access to any items in that state.

Resolved Access Rights on a Workflow Command

Read: If a user has Read access to a given workflow command, the command will appear in the Content Editor Toolbar when the item is selected. Likewise, the command will appear in the Workbox. If the user does not have Read access to the command, the command will not appear.

Resolved Access Rights on an Item

Read: A user must have Read access to an item in order to see the item in the Content Editor, Published Web Site, or anywhere else
Write: A user must have Write access to an item in order to see the item in the Workbox. Note that a user may not have Write access to an item if the item is currently checked out (locked) by another user.

3. Internal Users

The Sitecore Domain maintains information regarding the site content authors, administrators and developers. The Sitecore Domain is not associated with any kind of extranet functionality.

Internal security is defined in “Sitecore” domain by default:

<site

name="shell"

virtualFolder="/sitecore/shell"

physicalFolder="/sitecore/shell"

rootPath="/sitecore/content"

startItem="/home"

language="en"

database="core"

domain="sitecore"

content="master"

enableWorkflow="true"

xmlControlPage="/sitecore/shell/default.html"/>

<domain id="sitecore" singleInstance="true" type="Sitecore.SecurityModel.Domain, Sitecore.Kernel">

<param desc="database">security</param>

<Appearance.ShortDescription>The main Sitecore domain</Appearance.ShortDescription>

</domain>

</domains>

Internal security contains Users and Roles as described in the security introduction.

Internal Users

Internal users are defined as the users contributing content or simply maintaining the solution. Setting security restrictions for the internal users includes access to areas of the content tree, publishing rights, rights to edit, HTML editing, etc.

4. Extranet Security

Sitecore's Extranet Domain is used to login visitors to a solution (e.g. a website). It is not associated with the internal security system.

Extranet security is defined in “Extranet” domain by default:

<site

name="website"

virtualFolder="/"

physicalFolder="/"

rootPath="/sitecore/content"

startItem="/home"

language="en"

database="web"

domain="extranet"

allowDebug="true"

cacheHtml="true" />

</domain>

…

</domains>

Extranet security contains Users and Roles as described in the security introduction.