Security for SharePoint 2010 Document Sets

Whew...April is a busy month.  Not a big month for vacations I guess.  I've been away from the blog for a few weeks.  One of the things we were working on is planning for the next release of our Metadata Security for SharePoint product.  We are having a good look at SharePoint 2010 to make sure we can port to that platform and over time take advantage of the additional features of 2010.

But you probably didn't come to hear me talk about how busy things are.  One thing that was interesting that we came across when we were doing our SharePoint 2010 planning was the new Document Sets feature.  Document Sets basically allow you to manage a number of documents as a single entity. You can apply workflow to the whole set, or you can apply specific information management policies to the set, things like Retention, Auditing, etc.  So this makes management of related documents easier as there is no need to manage the documents individually if they are similar. The concept is somewhat similar to folders, but you can't apply information management policies to folders by themselves. A Document Set is actually a SharePoint Content Type under the covers.  But there are a number of new tools for Document Sets that provide advantages over a standard content type, such as a customizable home page, workflows, ability to send all the documents in a Document Set together (SharePoint will zip them together in a package).

In terms of setting up Document Sets I'm not going to go over that here.  There seems to be a number of good blogs out there that cover this.  Liam Cleary does a nice job of explaining how to configure Document Sets in his blog - SharePoint 2010 User Experience - Document Sets.

In regards to security, you can apply security to a Document Set as a single entity, similar to what you could do with Document Libraries or Folders.  So if you have a bunch of documents that are grouped into a Document Set, (for example an RFP response, or all documents related to a merger etc) it may make sense to apply security directly to that document set, making the security slightly different from the parent library.  This is fairly easy to do.  You right click on the Document Set as shown below, and select Manage Permissions. In the example below, we have created a Document Set called Merger, which contains all the documents related to a recent merger with XYZ Company.  Since these merger documents are very sensitive we will want to apply special permissions to the Document Set.

(Click to see larger image)
 

Once we are in the permissions dialog we can break the inheritance with the parent library

Once the inheritance is broken, we can go ahead and configure the specific permissions we want for the document Set.

After setting the permissions, all the documents in the document set will inherit these permissions.  So we are done.
 

Typically all the documents in a Document Set will share the same metadata as they are all related.  As a result, we can also automatically set the specific permissions for the Document Set using the Titus Labs Metadata Security product.  Using this product, the administrator would define the metadata rules and desired permissions (for example, if metadata = merger, set permissions to x y and z).  So we achieve the same thing as setting the permissions manually except the process is done automatically so if you have a lot of documents or document sets to configure this will be done very quickly.

Comments

[Aide SharePoint]

Hi,

Quick note to let you know that is a great article and that the link to the post "SharePoint 2010 User Experience - Document Sets" is broken and could be updated to this link : http://www.helloitsliam.com/Lists/Posts/ViewPost.aspx?ID=211

Thanks

[Charlie]

Thanks Liam,

I've fixed the link...Charlie

[John]

If a large number of documents require unique permissions, don't you run into the SharePoint limits as prescribed by Microsoft? For instance, no more than 1000 security scopes and no more than 50k unique permissions per list.

[Antonio]

Good question. The TITUS SharePoint Security Suite has been designed to work well within the limitations and recommendations which Microsoft imposes on libraries/lists within SharePoint. The limits you describe are important, but must be understood in the context of other SharePoint recommendations.

For example, the max limit of 50,000 unique permissions on a library refers to the # of unique users or groups configured to access items within that library. So, if you have configured an Active Directory (AD) group with 1000 users to have Read access to an item within the library, that consumes only 1 of these 50,000 unique permissions. If you configure a specific user to have Full Control over a document in a library, that would consume another of these. For you to reach this particular limit you would have to configure 50,000 unique users or unique AD groups to have access to items within the library. We’ve seen in practice, even in large enterprises, that SharePoint content is spread across multiple libraries logically and you don’t typically have 50,000 unique individual user accounts or groups individually configured on items within the same library. If by chance you did run into this, using multiple AD groups are a recommended way to organize access rights on such a large library and they are supported by TITUS SharePoint products.

The 1,000 security scope recommendation, put very simply, refers to the number of items in a list that break inheritance. It is in fact a recommendation and not a hard limit. This one is very dependent on the size of SharePoint farm (servers, memory, CPU, # of web front ends, etc). We have seen Microsoft documentation which describes 5,000 scopes as a recommendation, and other documentation contradicting it describing 1,000 scopes as the recommendation. For example, please see this Microsoft support article: http://support.microsoft.com/kb/2420771.

Some of the other recommendations and limitations SharePoint has which are important are:
- If using groups, use AD groups to assign permissions and avoid SP groups. AD groups are much faster/efficient for SP to process. TITUS Metadata Security supports both, but we pass on Microsoft’s recommendation here of using AD groups with our product.
- SP2010 has a variable called the List View Threshold which controls the number of items that any SharePoint SQL query can return, but ultimately affects the number of items that can be viewed at the root level of a library or a folder (default value is 5,000, can go as high as 50,000, but is dependent on farm size).

With this in mind, the limits/recommendations described by Microsoft are in fact high when put into practice, or they fall in line with other limits on how much content you can put into a library (root level) or folder. Overall, we recommend customers have a well structured SharePoint farm, sized appropriately, and that content be organized appropriately with various libraries, folders and lists.

Using TITUS Metadata Security for SharePoint, administrators can automate permissions assignment and management on both folder and items. We recommend using Metadata Security to automatically apply item-level permissions to your sensitive content based on its metadata, and then automatically apply permissions to folders for other content. We work with customers to ensure that SharePoint limits/recommendations are respected and that permissions management becomes automated and consistent across the farm using TITUS products.