Field Security vs Security

On the SDN5-forum, Kerry Bellerose posted an extremely usefull reply where he explains what the difference is between Field Security and Security. He also explains why they have chosen to implement it that way:

The difference in setting field security from item security reflects the fact that field security is actually different from item security.
In general, users who are given read/write access to an item, automatically have read/write access to all the fields in that item.
This covers the great majority of items and fields, so it’s nice that things work this way.
On the other hand, when business rules suggest that only a limited set of people who have read/write access to an item should also have read/write access to a given field, Sitecore’s approach is designed to limit the number of security configuration changes required.
For example, lets say we have a field called Foo that Authors should not even see (even if they have read/write access to an item), the Sales People should see, but should not be change, and that Managers should be able to see and change.
When we define the field Foo, the field inherits the Read / Write access rights assigned to the user, be it Author, Sales Person, or Manager.
When we begin assigning field security to Foo for any role, however, this breaks the inheritance of access rights from item to field.  In other words, as soon as we assign field security to Foo for any given users or roles, read and write access defaults to denied for all other users and roles.
This may seem complex until you understand it, but you do understand it you can see that the following is true:

  • Generally you can ignore field security and focus on item security (assuming that having access to an item also gives the same access to fields).
  • When a limited group of users/roles should have access to a specific field, you only need to grant access to those users/roles, you never need to deny read/write access to a field (because as soon as you explicitly Allow access for anyone, everyone else defaults to Denied access).

So in our example above, to meet our business requirements, we would do the following:

  • Allow Read access on Foo for Sales People
  • Allow Read and Write access on Foo to Managers

This would implicitly deny read and write access to authors and deny write access to Sales People.
I hope this clears things up!

 Kerry Bellerose,
Solution Architect, Sitecore Corp.
Blog: kerrybellerose.blogspot.com
Web: www.sitecore.net

Thank you Kerry! For the full thread take a look here.

2 thoughts on “Field Security vs Security”

  1. You’re welcome, Alex!
    Glad to hear that my response was coherent. Actually, I must admit that I started the description several times before deciding on the final draft shown above. Some I’m especially pleased if I hit the nail on the head.

  2. Hello Alex,
    How to give security to a field in an item…I tried for giving security to an item for a particular user(through security editor) and it worked fine. But when comes to field level securty(.i.e. Read/write access) it is not working..is there approach to work out..can you please help me in this.

    For example: There are 2 users one is Admin and the other user is content editor…When logged in as admin we will give read only security access to a particular field in an item(through security editor) for content editor user. when logged in to content editor user the field should have only read access right? but it has both read,write access. Can you please help us in this
    Thanks in Advance.

Comments are closed.