When brought in to support existing Sitecore implementations I often find that Sitecore’s WCM security is not in a healthy place: Either it’s not configured at all (hello “admin”); or there’s a byzantine collection of obscure, stacked Roles and individual user permissions. Like almost every Sitecore feature, Security is sophisticated and flexible, but documentation about best practice is hard to find. It’s additionally complicated by the fact that a “new” Sitecore install ships with a number of security configurations that are counter-productive, and violate the rules we’ll discuss today.
What is Security?
In the context of this post, I’m talking about User Authorization within the CMS: Specifically, being able to manage the following behaviors on an item-by-item basis:
- Can the Author “see” the Item in Sitecore?
- Can they “edit” it?
- Can the author rename the Item?
- Can it be deleted?
- Can the author create a child of the current Item?
- Can the author control who can access the Item?
- If the Item exists in more than one language, which languages can the Author see? What about editing?
- Does the Author have the right to mark the Item as finished, or do they need to forward the Item for approval by a higher power?
- Can the Author advance the Item through the approval process?
- Can the Author skip the approval process altogether?
Security in this context also applies to the User’s ability to access Sitecore features:
- Can the User maintain content?
- Can the User create new types of content or define new presentation details?
- Can the user rearrange components on page?
- Can the user configure Personalization or design A/B tests?
- Can the user read reports on site utilization?
- Can the user publish content?
- and other options as defined in the manual.
Like an Ogre, or is it an Onion…
Most Sitecore developers are briefly exposed to the basic Item security flags during the developer certification process. In a lab setting, it’s not obvious that security is layers of different aspects of Sitecore’s configuration. At runtime, these layers determine what happens when the User hits the Edit button, or if they can even see the Edit button.
This concept of layers is obscured by the “Everything is an Item” design philosophy that pervades Sitecore. Developers know setting permissions inevitably means controlling the
read/write/create/delete/rename/admin/inherit
properties on an Item somewhere, but knowing what your options are can be a challenge.
Some are More Equal than Others
Like Animal Farm, there are Items, and then there are Items. Let’s identify the Layers of Sitecore Security:
- Item Access
- Field Restrictions
- Workflow Restrictions
- Language Restrictions
- Sitecore Client Features
The key to identifying these layers is to note the subtle differences in implementation when setting security on Items of a predefined system type. Let’s take a brief look:
Item Access
When setting CRUD options on plain old content Items, the Security Detail dialog offer the standard options:
- Read
- Write
- Rename
- Create
- Delete
- Admin
- Inherit
These all do exactly what they say on the tin, and apply to the Item you’re administering, and (optionally) its descendants.
Field Restrictions
Although rarely used, it is possible to limit access to specific fields on a given Data Template. When you open the Security Detail dialog on a Template Field Item, you get the following additional options:
- Field Read
- Field Write
Although they are set on the Template Item’s descendants, these two values apply to every single Item that implements the Template where this security is set.
If a user is complaining that they cannot “see” a field, or that it appears disabled to them, this is the first place to look.
Workflow Restrictions
When Editing a Workflow, Workflow State or Workflow Command Item, the following additional Security Rights are available:
- Workflow State Write
- Workflow State Delete
- Workflow Command Execute
These permissions are extremely powerful, and are unfortunately overlooked by most developers.
The -write and -delete rights will override the user’s “natural” rights to an Item when the Item is in a workflow state that implements these restrictions. This allows you to create Workflow States where junior authors are not permitted to make changes. The -command execute right allows you to create complex workflows where more senior users can skip workflow states entirely, or perhaps execute some specialized task.
Even a basic workflow should make use of these permissions to ensure Sitecore’s publishing mechanism behaves as expected.
If a user is complaining that they cannot edit an Item they previously edited, checking the Workflow State and the user’s permissions in that state is a good place to start.
Language Restrictions
Editing the seldom-touched Language Items located at
/sitecore/system/languages
exposes yet another set of specialized access privileges in the Security Details dialog:
- Language Read
- Language Write
Like the Workflow restrictions, these two privileges override the user’s “natural” security on an Item based on the context language set in the Sitecore editor. These settings are extremely useful in a globally distributed system where one language is “king” and the other languages need to be translated from the primary language of the site. Setting security appropriately gives translators read-only access to the primary language, and read/write access to their language specialty.
If a user is complaining that they cannot edit an Item, and you’ve checked Item and Workflow restrictions, this is the next place to look.
Sitecore Client Features
While technically managed by setting Item Security restrictions on Items in the “core” database, Sitecore Client restrictions are generally applied by assigning “Sitecore Client *” roles to users. This fundamental difference sets Sitecore Client security apart from the other Layers.
If a user is complaining that they cannot compose pages in Experience Editor, or they cannot Publish Items, check their Sitecore Client roles first.
Some History
The above security layers are “hard wired” into Sitecore. Field, Language, Workflow and Client Items are all “specialized” and are recognized by the Sitecore system as “more than just Items”. They have discrete and unique security permissions that apply not to themselves, but to Items that reference them.
Although the concepts of Fields, Workflow States, and Languages are as old a Sitecore itself, the specialized access rights described above are actually a fairly recent addition to Sitecore.
In earlier versions of Sitecore developers permitted editing of Items in a given Workflow State by granting the “write” permission to the Workflow State Item. There was no “workflow state write” permission. Similar settings governed Languages, etc. As you might expect, double-dipping on these core access permissions did cause issues. One cannot argue that having discrete permissions makes the system more legible.
Knowing the history of Sitecore’s access rights reveals why these layers are spread throughout the system rather than available from a central console. Should you ever need to extend security, you also know where you can “cheat” and borrow from Sitecore’s playbook.
Security Roles
We’ve identified the layers of Sitecore security:
- Item Security
- Field Restrictions
- Workflow Restrictions
- Language Restrictions
- Sitecore Client Features
We know that these layers are applied whenever the User attempts to access an Item. Obviously we do not want to set permissions for each of the layers above for every individual user in the system. We’ll assign the security restrictions to more abstract Roles which will then be assigned to Users.
Security Roles can vary from install-to-install: They are driven by content author personas, Job titles within the business, or the mechanical architecture of Sitecore itself. Here’s a few basic guidelines to ensure maximum flexibility and more importantly: easy-to-troubleshoot security.
Rule 1: Don’t Cross the Streams
Do not mix security layers within a given named Role. if a Role is used for Item Security and specifies Workflow Command Execute and stacks Sitecore Client roles, you are likely to encounter scenarios where a user has insufficient access, or worse, more permission than you intended to grant. if you keep your Roles organized by layer, changing workflow access is as simple as subscribing the user to the appropriate Workflow role. Same for granting access to Publishing features.
Consider Greta, who started out as an intern: Initially, she was only able to edit content, but could not approve it, and did not have access to publish to the CD server. Greta eventually got hired full time and was promoted to Marketing Director – Now she’s approving other people’s content and controls publishing for an entire site. If your roles are separated into Layers, this change in permissions is a three-minute exercise. If not… you’ll probably spend the afternoon checking off boxes in Sitecore.
Rule 2: Name Roles for Layers
Prefix your Roles with the name of the Layer they support:
- “Site” or “Item”
- “Field”
- “Workflow”
- “Language”
This makes it extremely easy to find a Role when you need to assign it to a User. This also ensures that all Role options appear together when searching for a Role, helping to educate admins as to the design of the system’s security. Finally, having unique Prefixes allows you to quickly take a look at a User’s Role Membership and determine if they are missing a security aspect.
Rule 3: Avoid Stacking Roles
Rule #1, forbids role stacking across security Layers. You should also avoid stacking within a single layer, unless there is a clear case of progressive permission enhancement. This rule will prevent difficult to troubleshoot traps laid by the “deny” flag in security, which sometimes cannot be avoided. It also allows you to explicitly “know” the security of a given role when inspecting Security details without unpacking membership.
Rule 4: Users Should Subscribe to at Least One Role from Each Layer
This rule has some flexibility. If you’re only supporting one Language, or you are not using Field restrictions, there’s no need for Roles supporting those layers. For the Layers you are supporting, each User should have membership from each layer. At a bare minimum this usually entails 3-6 roles:
- Item Security (usually 1 or 2 roles that grant the user access to a part of the Content Tree)
- Workflow Restrictions (just 1 role for each Workflow that the user needs to interact with)
- Sitecore Client Features (usually Authoring, Designing, and Publishing)
This rule provides a “footprint” that will quickly reveal user configuration errors. In a properly configured Sitecore install, the user will not be able to perform content entry until they have roles from all layers.
Next Steps
If you haven’t read the Sitecore security documentation recently, I recommend taking a look at all the access right flags available. I intentionally did not cover a few of the more obscure flags.
In the next post we’ll take a closer look at Item Security. Security and Sitecore Information Architecture go hand in hand – designing one without the other will lead to long term problems that are difficult to fix. We’ll look at best practices that will ensure you’re not walking the content tree toggling the “write” flag off with reckless abandon.