Sitecore access to an Item based on role

Question

I have a Sitecore application, and some of my content authors want to work on some "secret pages" that should not be available to anyone else, including other content authors. Only a few of the content authors should have access to these "secret pages" as well as page.

What I've done so far...

Let's say the item is

sitecore/content/home/mysite/myLocked-item

and the website url is:

http://mywebsite-stage.com/mylocked-item

All content Editors are part of the role sitecore\MySite Content Editors.

Since some of them need special privileges, I created a special role. Before doing so, I went to the Access Viewer and marked the myLocked-Item as Requires Login. Then I made sure that I removed the read, write, rename, create, delete, administer properties to the following roles

• Defaut/Anonymous
• Extranet/Anoymous and
• sitecore/MySite Content Editors

Now, when I log in as a content author, I am neither able to see the item in Sitecore nor am I able to see the page on the website - I am instead redirected to the Sitecore login page. This is all the expected behavior.

The next part is to make a role that grants the authors who will be editing the "secret pages" the necessary permissions to access and edit those pages.

I first created a role called sitecore\Special rights. I then went into the Security Editor and provided all rights for read, write, rename, create, delete, administer for the mylocked-item for this role.

For the last step, I went to the users who will be editing the "secret pages" and gave them the sitecore\Special rights role. The problem is that I am still not able to provide them with access.

The Content Authors who will be editing the "secret pages" are members of 2 groups:

• sitecore\Special rights
• sitecore\My Site Content Editor

Whereas everyone else is part of just one the group sitecore\My Site Content Editor.

What am I missing?

Answer 1

The Problem

The problem is that the "Deny" access right trumps the "Grant" access right. For this reason, if neither the "Deny" or "Grant" have been applied, then the "Deny" access right is assumed. It is only in this case (i.e. no access right explicitly assigned) that subsequently applying the "Grant" access right will trump the "Deny" access right. In other words, the "Grant" access right only works if there is no explicit "Deny" access right that is also assigned and conflicts with the "Grant".

The following diagram is from Sitecore's official documentation and illustrates how access rights are calculated when there are conflicts between them:

Access rights – Denied overrides Allowed.

Security accounts– Access rights assigned to a user account override access rights assigned to a role.

Item – Access rights assigned specifically on an item override access rights specified for the descendants on the parent item. Access rights assigned specifically on an item or on the descendants of an item override the Inheritance access right.

This means that explicitly assigning the "Deny" access right to a permission means that that access right will ways trump the "Grant" access right for that permission.

Solution

Rather than applying the "Deny" access right, open up the Security Editor (it is recommended that you make all security changes in the Security Editor, not the Access Viewer) and remove the "Deny" access right, as well as the "Grant" access right from each of the items in question. The roles for which you wish to allow access should be given the explicit "Grant" access right for each of the desired permissions, which will give them (and administrators, by default) access.

The Challenges with Permission Inheritance

Permission inheritance makes things tricky, here. In order to do what you are attempting, what you need to do, conceptually, is to deny inheritance for the permissions on the sitecore/content/home/mysite item (the parent item), and re-apply the permissions (with inheritance allowed) on each of the sibling items to sitecore/content/home/mysite/myLocked-item. Doing this manually would work, but it could be a lot of work and expose long-term maintenance challenges.

Alternatively, you should be able to avoid having to assign access rights on all of the siblings by explicitly denying the "Inheritance" property of the permissions for the mylocked-item and its descendants (unless they should be available for some other reason). This should save you some time and make long-term maintenance easier.

These steps are a bit tedious, but it is the way to get you what you want. Unfortunately, permissions are not all that straightforward, and though the system may seem a bit "hacky" it is actually the industry standard (OSX, Ubuntu, and Windows permissions work this way, as well, to name a few).

More Information

Unfortunately, without being able to see your content tree, the Access Viewer for each of the roles that you mentioned before applying permissions and the Security editor for each of the roles that you mentioned before applying permissions, there's not much more direct instruction that I can give you. However, I highly recommend that you thoroughly review each of the following articles from Sitecore's official security administration documentation, as they explain everything that you need to know to achieve what you are attempting:

• Assigning Access Rights
• The Inheritance Access Right

Answer 2

As Zach said the key for this to know is that a deny will override granting access. That is the reason that denying and then trying to give access with a different role (while using the role that denies) does not work. You have 2 options:

1. You can invert the logic. Remove the deny access given to the content editor role and let accessing those items be the norm for a content editor. Make a restricted content editor role and deny read access to the secret items there. Then apply this role to the editors that should not be able to see it. I don't think Zach's answer goes over this option directly. You can use this if the norm will be that content editors can see the hidden pages.
2. Deny inheritance to the items for the content editor role instead of denying read access. This will cause a "soft" read denial because the content editor no longer inherits read access to that item. Then in your special role you can explicitly grant read access.

Regardless of the choice, denying read access at the base content editor role shouldn't be done if these editors will end up inheriting that role.

Answer 3

You have setup access deny to main content editor role (sitecore/MySite Content Editors) for read, write, rename, create, delete and administrator.

Now for \Special rights, you have inherited the same role, that may be the cause of this issue - overriding the inheritance access

Can you please try the below steps:

• Create a duplicate role same as (sitecore/MySite Content Editors)
  – Without any access deny – let’s say (sitecore/MySite Content Editors Secure)
• Provide role to user - Special rights and (sitecore/MySite Content Editors Secure)