Implementing Item-Level Security in SharePoint 2010 and 2007

Once you have spun up a new Document Library in SharePoint, you will want to give users permission to access the library.

Adding users is relatively straightforward. However, determining the permissions that should be granted to each user on a per item basis requires understanding and planning.

9 out of 10 times, every SharePoint implementation targeting variety of audiences needs security to be trimmed, to give customized user access levels to items in Lists and / or Libraries.

Overview:

Have you ever been in a situation, where item level security was achieved by stepping into each document one at a time in order to setup permissions for the documents, or when security was defined by creating separate document libraries or separate folders containing documents that are appropriate for certain groups of users?

If yes, then you obviously understand the painstaking process one has to go through by following these approaches. And if you are looking for a way out, then you have come to right place…

Item level security is extremely powerful as it gives you the ability to filter which items / documents users can see.

As you probably are aware, Item Level Permissions feature is readily available OOTB in SharePoint 2007.

But as seen from the screen above, there is no way of obtaining fine grained permissions on a per item basis OOTB. Also, this feature was made available only for lists, not document libraries.

This article will focus on taking you through an effortless design to help you succeed in taming Item Level Security, so that you can achieve the desired functionality with true security and no obscurity.

Alright, for folks out there in the ecosystem who have a 2007 build of SharePoint, we will write some Custom Code that could be used in an Event Handler or a workflow to achieve the functionality.

For others who prefer a no-code approach and have already installed SharePoint 2010 – welcome to the era of code-less solutions. This post will glorify how SharePoint 2010 has over simplified accomplishing this feature.

Basically, the idea is to have a one-stop shop here, for information on how to implement Item Level Security in both, 2007 and 2010 versions of SharePoint.

Note: For simplicity and ease of understanding this article, we would base our examples and discussions to ‘Lists’ or ‘Document Libraries’ interchangeably. Nevertheless, this implementation could also be extended onto either one of those.

So let’s get going then. We will start off by designing the SharePoint 2010 model of the feature and follow this up with a Custom Coded 2007 version.

Implementing Item Level Security in SharePoint 2010:

As said before, Microsoft has magnificently improved the newest version of SharePoint Designer – 2010. So power users can now create robust solutions, without much developer intervention.

In this section, we will glorify the power of SPD 2010 and how it comes to rescue in designing the solution for Item Level Security. We will create workflow activities (which can be customized even further) using the workflow designer inside SPD 2010 to achieve the desired functionality.

Insight:

We will create a workflow, wire it to a list, configure some no-code logic and have the workflow trigger on item created/changed. The rest is taken care by SharePoint behind the scenes.

Simple right…..Let’s showcase the same here….

Design:

Assuming that you have already created a document library, here is what we are going to do:

  • Navigate to the document library. From the ribbon, select Library Permissions

  • You will be directed to the ‘Permission Tools’, where in select Stop Inheriting Permissions, so that you can manage the permissions on the items in the library

  • After you select ‘Stop Inheriting Permissions’, if the ribbon looks like the one below, wherein you are able to grant permissions ….then we are on the right track to jump onto SPD 2010

  • Fire up SPD 2010 and navigate to the Site
  • Select the List Workflow option and navigate to your library

  • Create a new workflow and wire it up to the document library

  • Create an Impersonation Step and then delete the existing Step 1 (The default step that comes with the creation of the workflow).

As we are tinkering with permissions on the list item, there is a need to run in the context of higher privileges and the Impersonation Step provides the required privileges to run in the context of the workflow author. This is one of the key and powerful features provided by SPD 2010.

Below is a quick example, the details of which will be explored shortly:

The Impersonation Step provides a variety of workflow actions that could be performed on a List Item. The various list actions provided could be seen below:

  • As an example, let’s try to use one of the workflow actions to design our solution for Item Level Security – Remove Permissions.
  • In the Impersonation Step select Remove these Permissions
  • And then select these permissions to add the User and the Permission Level

  • After you Click Add, you will be directed to a dialog, wherein you will be prompted to choose a User / multiple users (can be groups as well) and the permissions to remove.

  • Alright, so lets choose the users and add them to the Selected Users list

  • Now that we have chosen the users / groups, lets select the permissions to remove

  • Select the permissions to be removed from the Current Item

  • Go back to the workflow settings page in SPD 2010 and change the start options of the workflow to run on:
    • Item Created
    • Item Changed

  • That’s it…Publish the workflow and the magic begins…..

As you have seen, we have just touched upon the realm of the exciting powerful features offered by SPD 2010. We used workflow designer inside of SharePoint Designer, to create a List workflow that will trim the permissions based on the logic added, on an item created or changed event.

SPD 2010 carries tons of features and functionality to tapped OOTB. Reusable workflows feature is one of the major improvements over the predecessors of SPD 2010 and one of my favorites.  Reusing workflow activities was virtually impossible in SPD 2007, with repeatable steps needed to perform for every list based on the content type, needing similar features.

Furthermore, with features like Site Workflow, Nested Logic, Task Process Designer, Integration with Visio and Visual Studio 2010, just to name a few – designing workflows with SPD 2010 has never been simpler and so powerful.

12
0 Comments  (click to add your comment)
Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.