February 09, 2017
When working with security in Sitecore you work with two main applications: the Security Editor and the Access Viewer. On the surface, these tools look similar, but they play very distinct roles. Let's review each application as well as how they are leveraged.
If you haven't already, see Sitecore Security Part 1: Custom Roles and Permissions for an overview of the permissions required for a Content Author to edit content.
Security Editor
Sitecore's Security Editor is used to assign permissions to Sitecore items by navigating the Sitecore content tree. Below is a screenshot of the main Security Editor interface.
There are several ways to secure content using Sitecore's Security Editor:
- Using the Roles and users selector in the ribbon you can identify the role or user you want to secure, then click directly into the grid to apply the permissions
As you can see in the screenshot, expanding the content tree will allow you to see where permissions are explicitly assigned in the grid to the selected role or user. - If you double-click on the item in the content tree on the left, a security dialog will open. This dialogue allows you to edit or view all explicit permissions assigned to the item, not just the permissions assigned to the selected role or user.
Note: As an honourable mention, you can also access this same dialog via the Assign button in the Security ribbon of the Content Editor interface (assuming you have the proper permissions to see it of course).
Sitecore's Security Editor is only one part of the picture in that it allows you to assign permissions and it shows you where permissions are explicitly assigned. To complete the picture, we need a mechanism to view how these explicit permissions are actually manifested. This is the gap that Sitecore's Access Viewer bridges.
Access Viewer
Sitecore's Access viewer is a read-only view of your security implementation. It is used to see how your security implementation is manifested by displaying the security permissions in the Sitecore content tree for a selected user or role. Its main purposes are:
- To confirm your security permissions are manifested as expected;
- To troubleshoot user or role access issues if your permissions are not working as expected.
Here is a screenshot of the main Access Viewer interface.
In the screenshot, you can see that the sitecore\ContentAuthor user has read access all the items shown in the grid while write/rename/create/delete has been granted to the Home node and its children. It is important to note that unlike the Security Editor, the Access Viewer grid shows the culmination of all of the selected role/user's permissions as realized by the combination of role membership and explicit permissions.
Why is this important? Since users rarely belong to a single role we must be able to identify the root cause of permission issues should one role adversely affect another role. Access Viewer therefore becomes the tool to allow you to diagnose permission issues when they arise.
To take this a step deeper, if you are interested in seeing how a user has gained a certain implicit or explicit permission (or for that matter, been denied a certain permission), you can click directly on the permission itself and the right rail will populate with additional forensic information. For example, if you were interested in how the sitecore\ContentAuthor user inherited write access to the Home node, simply click on the write permission in the grid and you will see the right rail reveal additional information:
In this example, you can see that the text in the right rail notes that write access was obtained via explicit item:write access to the sitecore\Author role, a role that sitecore\ContentAuthor is a member of. This statement is reinforced by the image below the statement which reveals that the sitecore\Author role has been granted explicit write permissions on the Home node.
In contrast, by reviewing the Administer privilege of the Home node (a permission the ContentAuthor user has not been granted), the Access Viewer reports that the user does not have this privilege because it has not been granted explicit permission, nor does it belong to a role that grants those permissions.
Up to this point, we've been reviewing an item that is not in workflow. If you've read my article about Content Author editing permissions, you'll understand that workflow permissions also factor into a Content Author's ability to edit content.
To see how this is manifested in the Access Viewer, let's use Sitecore's Sample Workflow. We'll grant Workflow State Write access to the Draft state of the workflow for the ContentAuthor user, but leave the user without permissions on the Awaiting Approval state.
With the Home node in the Draft state, the Access Viewer now reveals additional information about workflow when you audit a specific permission:
In this case, the ContentAuthor user can edit the item because they have sufficient item and workflow permissions to do so.
However, if we now move the Home node to the Awaiting Approval state, the Access Viewer information changes:
The security statement notes that they don't have workflowState:write access and subsequently, you do not have the ability to edit the item.
In Conclusion
As you can see, if you are going to be working with security in Sitecore you'll need to become very familiar with these two tools as they work hand-in-hand to allow you to assign and troubleshoot security permissions.
