Fine-grained permission reference for SharePoint Server 2013
Applies to: SharePoint Foundation 2013, SharePoint Server 2013
Topic Last Modified: 2013-12-18
Summary: Learn about the potential impact of fine-grained permissions on performance and the complexity of maintaining a SharePoint 2013 environment.
By default, permissions within a site are inherited from the site. However, fine-grained permissions is when you break this inheritance for any securable object that is at a lower level in the hierarchy by editing the permissions (creating a unique permission assignment) on that securable object.
|We recommend that you use fine-grained permissions only when a business case justifies it. Fine-grained permissions can increase the cost to manage a deployment. Because it is inefficient to maintain permissions for individual users, we recommend that you use group permissions as much as possible. Particularly if you are using fine-grained permissions, you should use groups to avoid having to track permissions for individual user accounts. Because people can move in and out of teams and change responsibilities frequently, you might not want to track all of those changes and continually update the permissions for uniquely secured objects.|
In this article, the terms web and site equate to the SPWeb object, and site collections equate to the SPSite object. In addition, the term fine-grained refers to permission on a list, library, folder, item, or document that restricts actions that users can complete. Fine-grained permissions enable you to customize user permissions in a site collection. For more information, see SPWeb and SPSite.
This section describes the SharePoint permissions scope system. For more information about how to plan site security, see Plan site permissions in SharePoint 2013.
A permission level contains a set of individual permissions, for example, View Items or Create Alerts. Permission levels can be assigned to an individual user, groups of users, or security groups by using a predefined permission level or a user can create a custom permission level. The set of permissions can be changed even within the predefined permission levels.
A SharePoint group is a site collection-wide object that can hold other security principals, such as Windows user accounts, non-Windows users (for example, forms-based accounts), and Active Directory groups.
A scope is the security boundary for a securable object and any of its children that do not have a separate security boundary defined. The scope contains an Access Control List (ACL), but unlike NTFS ACLs, a scope can include SharePoint-specific security principals. The members of an ACL for a scope can include Windows users, non-Windows users (such as forms-based accounts in SharePoint Products and Technologies or claims-based accounts in SharePoint 2013), Active Directory groups, SharePoint groups or other scopes.
There is no maximum number of scopes that can be created in a parent scope. But after you have created 1,000 scopes, a code path that requires additional Microsoft® SQL Server round trips to analyze the scopes before rendering a view is used. When there are 1,000 or fewer scopes, only one roundtrip is required. In SharePoint 2013, the limit of number of scopes returned before switching to a different algorithm is based on a query throttle limit that has a default value of 5,000. This value, even at default, can be large enough to significantly detract from performance.
In SharePoint 2013, you can use the SPRoleAssignmentCollection.AddToCurrentScopeOnly method to assign roles. For additional information about role assignments, see SPRoleAssignmentCollection.AddToCurrentScopeOnly (http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.sproleassignmentcollection.addtocurrentscopeonly.aspx).
A securable object is an object that can have an ACL assigned to it. In SharePoint 2013, you can use the SPSecurableObject class. For additional information about securable objects, see SPSecurableObject class (http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.spsecurableobject.aspx).
If a securable object does not have a unique scope, the object inherits the scope of its parent. When an object inherits from its parent, no scope is created for the object. Instead, when a security check is made, it verifies only against the parent object. In the simplest environment, this scope is at the root web of the site collection that contains the item. When an item or container is changed to have unique membership, its inheritance is broken, which means that a new scope is created for that item and, by default, for any of its children that inherit its permission scopes.
The following diagram shows an object hierarchy for a document library, in which all objects but one inherit their scope from their parents. Each numbered gold hexagon represents a permissions scope. All child objects in a container inherit from that parent scope unless they have their own unique permissions scope.
When a security principal is added to the scope of an item with unique permissions, the security principal is immediately added by using the Limited Access permission level to each unique permission scope in the hierarchy above the item until a parent web with unique permissions is located.
The reason to add the user to the scopes with Limited Access is to allow enough access to the object hierarchically above the uniquely permissioned item so that the Object Model (OM), master pages, and navigation can display when the user attempts to navigate to the item. Without the Limited Access permissions at the parent scopes, the user wouldn't be able to successfully browse to or open the item that has unique permissions.
The following diagram shows how the hierarchical depth of scopes can affect the work that is required to add Limited Access users to parent scopes. The larger the number of unique scopes above the item, up to and including the uniquely permissioned web, the larger the number of additions that must occur. The diagram shows a simplified representation of a physical structure that has unique scopes defined at every level from the web down to individual items. As in the previous diagram, each differently numbered gold hexagon represents a unique permission scope, and all child objects within that container inherit from that scope unless they have their own unique permissions scope. The chain of Limited Access promotion is shown using red arrows.
The diagram also includes the set of unique scopes and the Limited Access membership additions that must occur on each parent scope, represented by separate boxes within the scope. No additional programming is required to add unique scopes when a security principal is added to an object scope with unique permissions that is below a web with unique permissions.
When a security principal with the Limited Access permission level is added to a parent scope, no check is made to see whether the security principal is already in the parent scope. A security principal that already has access to the parent scope is added again with Limited Access permissions, regardless of its existing permissions on the parent scope.
When a security principal is removed from the Limited Access permission level at a parent scope, each instance of that security principal within every child scope is removed from the Limited Access permission level, regardless of whether the security principal has Limited Access or a wider set of permissions at the child scopes.
A binary ACL performs rapid comparisons of a user token to determine whether the user should have access to the object covered by the scope. A binary ACL is calculated when the membership of a scope changes. This includes when a new limited access member is added. The binary ACL takes more time to calculate as the membership becomes larger, and access to the objects will be blocked until the ACL can be recalculated.
Although there is no explicit size limitation on a binary ACL other than the maximum size of an image column in SQL Server, some services can’t accept an ACL that is larger than 64KB. In this case, the number of security principals in the binary ACL may grow very large, but should be limited because of performance and interoperability considerations. For information about limitations in image column sizes in SQL Server, see ntext, text, and image (Transact-SQL) (http://msdn.microsoft.com/en-us/library/ms187993.aspx).