Confused by SharePoint security trimming? Join the club!

SharePoint only shows users the links to which they have access. Correct? Well, kind of.

When you create a list or document library in SharePoint, one option at creation is to display a link in the Quick Launch menu to the left.

The default is “Yes” and your list, in this example, will appear under the Lists heading in the Quick Launch menu.

If you then restrict access to a list, as I have done in the case of the For Admins list above, when logged in as a normal user, the link to For Admins will be security trimmed, that is, it will simply not be visible to users other than those with Admin (Owner) permissions.

However, imagine that you want to customize the Quick Launch menu and remove the default headings, such as Lists and Libraries? You can just create the links again and due to the permissions which have already been set, the security trimming will come into play, right?

So for Owners, they will see links to both lists.

And for normal users? Oops, unfortunately security trimming has not been applied:

The security trimming has been lost along the way. Users now see links that they cannot access. Though security is in no way compromised, as ordinary users will get an Access Denied error if they click the link, this is not good design or practical from a usability point of view.

So what is the solution? In a normal SharePoint site with Quick Launch navigation, it is possible to re-establish security trimmed links, by deleting the links from the Quick Launch and then re-establishing the Quick Launch display in the settings of each list (found under Title, description and navigation of the List Settings page).

But then you will be back at square one!

The only workaround is to enable the SharePoint Server Publishing Infrastructure feature, which allows for more fine-grained management of navigation and will retain security trimming when links are re-organized.

You can then use the Navigation Settings page. But wait a minute, as the Navigation Settings page is just a standard system page on the SharePoint server and it does not actually use any of the other things that form part of the SharePoint Publishing Infrastructure, perhaps we can just call the page directly and get to use it without enabling the Publishing Infrastructure.

Try putting a link to the page somewhere on a standard site with the following syntax:

http://yourserver/yoursite/_layouts/AreaNavigationSettings.aspx

You should then be able to re-organize your navigation to your heart’s content without losing any security trimming.

Advertisement

 

Setting Item Level Security on SharePoint Lists

Unfortunately, SharePoint views offer no possibility, out-of-the-box to be used to manage access rights. This is often a major headache, as SharePoint administrators regularly need to restrict visibility to certain items in a list, depending on the membership of different groups. Some use can be made of filtered views, as mentioned in a previous CDM Blog article, but real security cannot be based on such a technique, as it relies merely on hiding information rather than securing it. Audience targeting suffers from the same drawback: it is a content filtering mechanism not suitable for managing security.

The only alternative is therefore is to manage security at the item level. If done by hand, this task will rapidly become unmanageable, and so it should be implemented via a workflow. Or more precisely a series of workflows.

Imagine a simple Knowledge Base site where technical articles are added by a community of users. There is a standard SharePoint Approval Cycle which means that draft articles are only visible to their creators and the approvers group until approved. Most articles, once past the draft stage, should be visible to all authenticated users. However, there are some which need to be restricted to a certain audience for a certain period of time, for example, until a future release date, after which they can be made public.

These requirements imply two workflows, written with SharePoint Designer:

1. The first we will call InitialPermission which will look at an audience field which can contain different values. One of these may be CoE , in which case Permission levels have to be set to Zero for the Item and for a group of users, typically those that would normally have read access to articles.

   

    

   This workflow is designed to be run automatically when a new Knowledge Base article is created. The Zero permission level does not exist out of the box in SharePoint, it has to be created by hand.

 

 

1. The second workflow is used to resent the permission on the item concerned when the Audience field is set to something other than CoE (in this example), and just reverses the Item level permissions.