Sitecore Security

Sep 22, 2016

Sitecore Security is like an onion. It has layers.

CMS security can be a complex topic, but is critical to understand when you have a rich governance model that includes multiple departments, levels of approval, translation requirements, and shared content needs. This blog series will cover the important concepts that have to be adhered to when creating your Sitecore security model to ensure content authors only have access to the features, content, and approval steps appropriate to their role in the organization.

The Absolute Basics

In security, there are two concepts: authentication and authorization. Authentication is the act of proving who you are. Authorization is specifying what you’re allowed to do. We’re going to leave authentication out of this blog post series and concentrate on authorization, which is what can truly help with CMS governance design. Here’s how Sitecore authorization (or just “Sitecore security”) works:

Sitecore Security at a Glance

  • Sitecore uses Roles to specify authorization rules in the system.
  • Roles can “inherit” permissions from parent roles and elaborate further.
  • Security can be applied to all of the following features of Sitecore:
    • Data Templates (access to Items that are created from those templates)
    • Data Fields (access to the field values on Items that utilize that field)
    • Items (and their descendants in the content tree)
    • Languages (access to Item versions in a given language)
    • Workflow States (access to Item versions in a given Workflow State)
    • Workflow Actions (the right of a user to activate a given Workflow Action)
    • Sitecore Client features (access to buttons, tabs, and other aspects of the Authoring experience)
  • Users are assigned to one or more roles to grant access to any of the above.
  • When a user attempts to access an Item, their assigned roles are reviewed. All of the security scenarios above are evaluated holistically to determine what to present to the user.
The last point here is particularly important to understand. A user may have been granted “write” access to an Item, but if the Item’s current version is in a workflow state that prevents editing by that user, the Item will appear to be read-only. If Sitecore isn’t providing a user the access you expect, you have to check each of the aspects above to figure out why.

Quick Win: 7 Steps to Troubleshoot Unexpected Denied Access

The number one security-related tech support problem is “I can’t edit something.” Building on our understanding of Sitecore’s security, we can now approach the problem in a logical fashion. Here’s the checklist:

  1. Is the Item locked?
  2. Is the current Version of the Item in a read-only workflow state for the user?
  3. Does the user have “write” access to the Item’s currently selected language?
  4. Is the user a member of the “Sitecore Client Authoring” Role?
  5. Does the user have “write” access to the Item?
  6. Is the Item or any of its ancestors marked “deny inherit?”
  7. Is the Item or any of its ancestors marked “deny write?”
This list demonstrates the on-the-fly authorization layers of Sitecore and how seemingly disparate security settings can affect content authors in a variety of contexts. Thankfully, Sitecore ships with a comprehensive tool allowing you to preview user access, appropriately named “Access Viewer”.

For more information on using the Access Viewer and other Sitecore security tools, start here.

Next Step: Role Design

In the next post we’ll be looking at establishing some architectural guidelines to ensure a Sitecore solution that supports a wide range of governance needs.

Want to learn how Genuine can help you with your next digital, creative, tech or media project? Get in touch with us at