3

I have a role which is inheriting for other roles (one of which is sitecore\Designer). The role now has all access rights to Templates and its sub items.

Now I want to reduce the access rights such that the role will only have "Read" access to Templates and all it's sub items.

I have tried:

1) to tick X/Deny on the "Inheritance" column of Templates and then to tick Allow for the "Read" column of Templates, didn't work

2) to tick X/Deny on the "Inheritance" column of Templates and then to tick Allow for the "Read" column of all subitems, seemed to work at first but then stopped working

Note that I would like to apply settings to roles only and not directly to users. And avoid explicit denial.

How can I achieve this narrowing down of security?

  • 3
    I have always found setting up access trickier than you it seems. My approach is to try and avoid explicit deny as explicit deny overrides explicit allow. If you use implicit deny and use explicit allow it makes roles more combinable and flexible. Also using the access viewing on a user with that role(s) will quickly tell you which role is stopping them from accessing something. Hope that helps a little – JKerny Aug 16 '18 at 2:21
  • Have you tried checking permissions set using the Access Viewer? It's always easier to "build up" the permissions/security and add permissions using role inheritance. – jammykam Aug 16 '18 at 2:56
  • @jammykam yes, the question wasn't clear enough so I made it clearer, in Access Viewer I can see that I have most access rights (minus Administer) to templates and its sub items as a result of inheritance which leads back to the role sitecore\Designer. I would prefer to not change this design and instead limit it. And as JKerny mentioned, by avoiding explicit denial. It seems like my only choice is Inheritance denial, but I don't know how it behaves exactly. – goamn Aug 16 '18 at 3:57
  • 1
    Although generally speaking Denying access is a bad practice, breaking inheritance the way you have is not the same thing. Denying inheritance access still allows you to grant read without denying for those inherited roles and you can see the same thing in the linked Stackoverflow post, so don't agree about explicit Deny for inheritance. The problem is more to do with the way that the permissions are set on the Designer role for Children only, and imo you have your permissions set up the wrong way - it's easier to build up rather than reduce. – jammykam Aug 16 '18 at 5:24
  • That's probably the better way, but I am still interested to know if the other way is possible (as they are all already setup). – goamn Aug 16 '18 at 6:58
1

It looks like the setup of roles was correct, however the way permission was given was incorrect. I will detail the correct way here as I don't think it's very clear from google searches currently.

First of all, sitecore\Sitecore Client Users is the minimum necessary for a new user to be able to login, the new custom role should implement this or any role that inherits from it (such as sitecore\Content Editor).

Now to stop all base permissions: go to the custom role and allow read for the top level "sitecore" item AND deny read for descendants. This can't be achieved on the GUI table, you must instead click the button Assign on the top bar.

Now from here you can build up. As a rule of thumb, you should mostly allow read/write for the item only (such as the webpage) via the Assign button and not allow read/write for descendants (no need to deny, just leave the tick/cross empty for the descendants). Since you have read denial set on the top level sitecore item, it will flow down to all children. The reason for allowing read for the webpage only and not descendants: so that child webpages don't automatically get the read permission. Then you can do a full read permission on the Page Content item of that webpage.

This has solved most of my requirements/issues. Then I got a mysterious issue with 2 very similar roles that should behave the same but they don't. The folders Layout, System and Templates were showing in one and not the other. I installed the Security Rights Reporting module to see if there was a difference causing this (https://github.com/jbluemink/Sitecore-Security-Rights-Reporting), running it on both users and both custom roles. Nothing came up. Then I came across this page (https://doc.sitecore.net/sitecore_experience_platform/content_authoring/the_editing_tools/the_content_editor/customize_the_content_editor), the difference was that while logged in to the user, you can hide hidden items in the content editor (log in to user > Content Editor > top left Red menu button > Application options > Untick Hidden items).

Hope this helps someone!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.