Part I was a brief tutorial on Sitecore’s security layers. Let’s briefly list them again:
- Item Security
- Field Restrictions
- Workflow Restrictions
- Language Restrictions
- Sitecore Client Features
Of these layers, Item Security requires the most architectural planning, because Item Security is all about what you’re doing with Sitecore, not how Sitecore works. We’re going to be talking about Content Tree design, typical Content Author roles, and reducing your risk of carpal tunnel syndrome.
Content Tree Design
The legibility of your security design depends largely on your organization of the content tree. Let’s take a quick look at some archetypal content scenarios:
- One or more “site maps” where the structure of the site’s URLs is maintained.
- Items that specifically represent “pages” on sites and contain presentation details.
- Items of a specific type (bios, news articles, products, etc…) that will be referenced by other Items.
- Meta information, like a tag tree, the options of a pick list, or a collection of “settings” that are used at runtime.
- Items used for Navigation Menus
- A traditional “blog” with categories and tags
- Items that represent page fragments (Rendering data sources) where the page fragment is unique to the page it appears within.
- Items that represent “reusable” or “globally available” page fragments.
Where these Items live depends on some Security scenarios. The following questions will provide content tree design constraints.
- Do different teams manage different sites?
- Is site administration top-down or local control?
- Is there “global” content that is available to all sites in an install?
- Who manages “global” content? Is it an exclusive group?
- Within a site, who can create new pages? Who can adjust URLs?
- Who is allowed to make changes to Primary Navigation, or add a link to the Fat Footer?
Inheritance is King
We want to be able to use the Inherit Access Right wherever possible to allow the automatic flow of security privileges from the root of the install down to the branch and leaf Items. Whenever we need to limit privileges, we will use a “gatekeeping” Item where we can deny the Item Inherit right, resetting security from that Item through its descendants.
Helix got it Right
When considering groups of content authors, the Helix concepts of Tenant and Site serve well as content security brackets.
- Tenants are business subdivisions that are responsible for a certain set of content and one or more Sites.
- Sites are the logical construct that groups together not just the website itself but any meta information that is unique to that particular website.
Examples of Tenant Content
- Press releases
- Products
- Tag clouds
- Campaign content
- Contact information
Examples of Site Content
- Site pages
- Primary Navigation items
- Reusable calls to action
- Blog posts
Guidelines for Helix semantics
- Even if your install only has one website, consider having a node in the content tree that aggregates all content under the context of that “site”.
- You can have multiple Site nodes in your install without a Tenant if your sites do not share content or security concerns.
- If any part of your organization supports multiple Sites within your Sitecore installation, you need a Tenant.
- If Two (or more) Sites share content, store that content at the Tenant level if possible.
Following these rules should produce some obvious Security Role boundaries, every Tenant and Site gets their own set of Security Roles. Security Access Rights are granted on the Tenant and Site Items for their respective Roles.
Jumping Gaps
Note that if we set access rules on Template or Site Items, their descendants will inherit those rules, including some descendants that probably shouldn’t. In the examples above, we might want the “write” right to apply to the /home page of a site, and to individual Widgets or Navigation Items, but not to the /widgets or /navigation folder themselves, which are “mechanically necessary” and should never be modified. Use the “Protect Item” feature to allow your security to pass through these important Items without having to set security rights on each of them.
The above screenshot shows a Protected Item, and where the toggle for protection is located. Note that you have to be an Admin user in order to protect (and un-protect) Items. It goes without saying that Content Authors should never, ever run as Admin.
Role Design
Now that we’ve established security “control nodes” in the content tree, it’s time to start identifying groups of users and the rights each group should have over these discrete branches of the content tree.
Rule #1: Use Prefixes to produce consistent role names
Roles for Tenant-level access should start with the word “Tenant” Roles for Site-level access should start with the word “Site”. If you have discrete user groups for particular content types, you can prefix the name of the role with the Content Type the role will maintain. I like to make sure that the Role, Content Type, and Folder where security is applied all match. (ex: Press Release Editor)
After the appropriate Prefix, the Role Name should include the name of the Tenant or Site where it applies, assuming that security will be set at that node in the Content Tree. (ex: “Site [yourSiteNameHere] Editor”)
Rule #2: For a given Tenant or Site, consider Role Stacking from least-privileged to most-privileged.
We talked about avoiding Role Stacking in Part I, but this is the exception. Here we’re going to stack roles with increasing authority, because it significantly reduces the burden of setting security on Items. It also reduces the complexity of assigning roles to users.
Rule #3: Design Roles around Page Security
| Role Name | Page Access Rights |
| Tenant X Reader | read, inherit |
| Tenant X Editor | read, write, create, inherit |
| Tenant X Owner | read, write, create, rename, delete, inherit |
| Site X Reader | read, inherit |
| Site X Editor | read, write, create, inherit |
| Site X Owner | read, write, create, rename, delete, inherit |
In the table above, the Owner role is a member of the Editor role, which is a member of the appropriate Reader role.
Obviously, if you don’t have Tenants, there’s no need to create the tenant levels.
Pages tend to be the central Items in Sites, and thus make a good anchor point for security. The layers above are based on years of security requests from clients based upon several facts:
- Marketers generally want explicit control over URLs, thus the Item Rename rule should be given only to users who understand the consequences of renaming an Item.
- Deleting a Page item usually requires a matching 301 or 302 redirect rule somewhere, thus page deletion should not be available as a casual option.
- Junior members of the editing staff will often be asked to start new pages, thus the Create right must be granted to even the most basic editors.
- In a multi-site scenario, it is often useful or required for an author on one site to reference content in another site, even if they do not explicitly control that content. The Reader role provides a convenient shim to achieve this need without adding any other privilege.
- In a multi-site scenario with dozens of sites and highly silo’d teams, limiting the visible content tree to sites that are relevant to a particular user is key, thus the explicit Reader roles allow developers to default to “show no sites without permission” which not only cleans up the user experience but provides tighter security.
Rule #4 Be Frugal about adding Roles for Meta
Aside from Page Items, Tenants and Sites will contain a bevvy of meta information: products, navigation constructs, categories, pick list Items and the like. Do they all require Security Roles to manage? It depends. Here’s some guidelines:
- If the Items in question are all located within a given folder under a Site or Tenant, apply access rights using the Site and Tenant roles described above.
Example: Header and Footer navigation tend to have their own Content Items due to the way they are organized on page. While junior authors would not have access to modifying the header & footer of a page, the Site Owner role should have full CRUD access to the SiteName/Navigation folder’s contents.
- If the Items in question are maintained by a group of people that transcend Tenant and Site borders but are not members of the Tenant or Site groups consider creating a unique Security Role for them.
Example: Press Releases on a multi-site installation are administered by corporate communications, even though they are scattered across various Locale-specific sites. In this case, a Press Release Editor role enforces Locale autonomy while allowing CorpCom access to all press releases regardless of Tenant or Site.
- If the Items in question are scattered throughout the content tree, and are not at a fixed location, consider creating a Security Role for that content, and assign it to the Standard Values of that Content Template.
Example: Legal disclaimers vary in count and content from site-to-site in a global install with many websites. Having a discrete Legal Disclaimer item with a unique Legal Disclaimer Editor Role may be a useful way of approaching the security issue.
Of the above scenarios, the first is by far the most common. Resist the temptation to create piles and piles of Content Type specific Roles. It’s better to centralize the content in question and apply security to the containing folder, or better yet, ensure the content falls under the jurisdiction of a Tenant or Site.
Next Steps
Item Security can be an absolute bear if you don’t leverage security inheritance where possible. The rules described in this post will create a clean set of Roles with obvious, graduated access rights that will scale gracefully.