Thursday, September 9, 2010

The SharePoint Security Model

SharePoint "Users" (also known as Security Principals) may be either Active Directory users or Active Directory groups.  These "Users" are contained in SharePoint "Groups."  SharePoint Groups are mapped to a permission level for a "Securable Object."  The mapping of groups to permission levels occurs at various "Scopes".  Although any site, subsite, list, library, folder or item is a securable object, not every object creates a scope.

Users make up Groups.  Users cannot be created; they can only be added to groups.  Users come from Active Directory, or somewhere more exotic (like a custom SQL database).  Groups are like folders that contain users.  You may create, delete and modify groups.  You may remove users from groups; you may also remove a user from all groups in the site collection.  Whenever you change group membership, the effect is felt across the entire site collection.  You cannot be a Team Site Owner in one site and not be a Team Site Owner in another site.

Permissions are contained in permission levels.  Permissions cannot be created; they can only be added to permission levels.  There are 33 permissions; they include such privileges as Edit Items, Create Alerts, Create Subsites and Manage Permissions.  Permission levels are like folders that contain permissions.  You may create, delete and modify permission levels.  You may remove a permission from any permission level.  Whenever you change the contents of permission levels, the effect is (by default) felt across the entire site collection.  Contribute shouldn't contain Delete Items in one site and also not contain Delete Items in another site.

 For SharePoint 2010, these links demonstrate how to

By default, there is only one scope: the site collection; all child objects inherit permissions from this object.  All groups (and technically, SharePoint Users, too - but don't give permissions to SharePoint Users!) that have a permission level for a securable object make up an ACL.  So, an ACL is a list of all groups that have a permission level for a securable object.  

  Breaking the inheritance of permissions for a subsite, or list/library, or folder, or item, creates a new ACL and a new scope. 

Software Threshholds:

  1. You should not exceed 1000 ACLs per list.  This refers to nested ACLs, or, 1000 unique scopes on child objects and grandchild objects and great-grandchild objects, etc.  Obviously, this is a very large limit, but a chain of uniquely secured folders and subfolders in a list will add to your nested ACLs.
  2. You should not exceed 5000 (2000 in SharePoint 2007) security principals per scope.  This includes Users who are members of SharePoint Groups!  If you have a large organization, make sure to only add users who are Active Directory groups (e.g., DOMAIN\accounting_managers).
  3. You may have up to 5,000 security principals in a SharePoint Group, and 10,000 groups in a site collection.

Warning, the effects of exceeding these limits are dire:
  • Over 1000 ACLs per list will degrade farm performance.
  • Over 2000/5000 security principals per ACL will cause the failure of indexing of items in the scope and all items below that scope.
  • Most importantly, SharePoint groups are expanded into security principals when applying the second limit, above.  If all the groups in a scope, combined, contain over 2000/5000 SharePoint Users, the threshhold is exceeded.

   References to limits of 200 scopes per site and 100 rules per scope are for Search Scopes, not security scopes.


Harry said...


We setting up SP2010 farm and are considering using Titus Labs Metadata Security (Titus-MDS) product to control access at the item level. Does the "scoping" limits you referring to, apply to secure list items using meta tags. Specific to our project, we will have the basic domain groups (contributor, reader, etc), with each user having a set of attributes which define the content they can see/acccess. FOr example - User A is a law enforcemnet officer a the state-level, he is PCII certified and a U.S citizen. His profile would appear as such - user A = Contributer+LE+PCII+US.

At the list-level we delete all SP permissions and apply pre-configured MDS configured permissions. When a user uploads a file/creates a list item, they will mark the doc/item with the apppropriate metatags. Users will only be able to view items that are tagged with metadata that matches their profile.

Would each user-to-item association be consdiered a seperate scope?

Thanks for your time. WE are having a hard time wrapping our heads around this "scopeing" issue.

Frank Migacz said...


I contacted Titus Labs to ask what effect their solution had on these limitations. I have not heard back from them.

A scope is a particular child object (site, subsite, sub-subsite, library, folder, subfolder, etc.) that has unique permissions. Obviously this is a very LARGE limit, and I wouldn't worry about that.

At each scope, however, is an ACL (permission list - the "double-headed green arrow"). There can only be 2000 or 5000 such arrows in a scope. This means, only 2000 or 5000 objects can be mapped to a permission level in a single scope.

How I would write the Titus Labs solution would be in a way that when a user is tagged with an "attribute", they get a special mark on their user profile. When a piece of content is tagged with an attribute, the content has a special mark mapped to it. When any and every SharePoint page loads, content (SPItem objects) is hidden unless any of the user's attributes match an attribute of the content.

This would make pages a bit slower to render, but it would make permissions easier to manage.

I'd like to remind you that Titus Labs could have taken any number of approaches in designing their product.

Again, bring these concerns up with the vendor - they are usually happy to demonstrate this stuff.