Administering Security

Ideally, security should be administered on as few content items as possible. For ease of administration, developers should endeavor to apply security to high-level items and use inheritance to determine security for child items. It is optimal if you can administer security on just a few content items in a site with thousands of total items.

This is preferred to setting security on individual content items on an ad hoc basis. In an ad hoc scenario, large-scale changes to security permissions are impossible without scripting or manual updates.

This suggests several possible configurations for your site. In the following example, the content tree is designed for ease of extranet administration:

I. Home
  a. Products
  b. About Us
  c. Secure
    i. Secure Content Item A
    ii. Secure Content Item B

Here, all content that requires extranet login is stored under the Secure node. Administration of the site for extranet users is reduced to editing security settings on a single node, i.e. Secure.

Adding Sitecore security (i.e. for content authors and editors) may complicate things. Imagine, for example, that there are multiple categories of secure items which are edited by different roles. In this case, your content tree should be optimized for both Extranet and Sitecore domain administration:

I. Home
  a. Products
  b. About Us
  c. Secure
    i. Secure Category A
      1. Secure Content Item A
    ii. Secure Category B
      1. Secure Content Item A

In this example, extranet security is still administered on the “Secure” node, while Sitecore security is administered on the “Secure Category A” and “Secure Category B” nodes.

Consider the following additional complication: you may encounter requirements that a parent item and its children have different security requirements. Imagine in the following example that one set of permissions applies to the Products landing page and another set of permissions apply to the products themselves:

I. Home
  a. Products
    i. Product A
    ii. Product B

We can imagine that the Product Manager role is allowed to edit product descriptions themselves, but the Marketing role is allowed to edit the Products landing page. If the products are all set to inherit their permissions, they will effectively be inheriting the Marketing permissions. This can be remedied by setting permissions on each individual Product, in the Product master or in the template standard values. The most flexible solution among the three is to set the security settings on the template standard values. This prevents security settings from being placed on individual content items, which poses the greatest administrative challenge.

Another option is to create an additional sub-item, perhaps based on the Folder template:

I. Home
  a. Product Landing
    i. Products [folder]
      1. Product A
      2. Product B

Security in this case can be administered on the Products item, with separate security permissions placed on the Product Landing item.

In some cases, it becomes difficult to follow this security administration model. For example, imagine a scenario with four possible roles, any combination of which could be applied to a single content item. Specific security permissions may be entirely driven by editorial decisions. In these cases you may need to resort to masters, templates or security presets to manage entirely ad hoc security permissions.