Best Practices For Designing SharePoint 2010 Site Permissions In Plain English

A friend, after a conference call this morning asked me to write this out since the client was still all confuddled.

Planning access control designs for the multitude of SharePoint assets available in the 2010 version is vital to implement during the planning stages of your SharePoint implementation. This includes incorporating both permission inheritance schemes as well as more fine grained permissions in order to procure the most effective scheme for relating permissions to particular scopes.

As in previous versions of SharePoint, in order to grant access to both sites as well as content within SharePoint containers permissions are applied in an orthodox manner. There are several things to take into consideration when beginning the designing process. Firstly, you have to consider how strongly security should be applied. For example, some SharePoint instances can simply lean on heavy inheritance schemes, others may have various restrictions on pieces of sensitive content and their respective containers. Secondly, permission design must heavily consider how groups and users are going to be leveraged. A group is simply a container, this is important to remember. As a container, the group really has little relevance until there is permission levels attached to the groups.

Before getting started, there are a couple pieces of inbuilt security objects in SharePoint that must be considered throughout the designing process. Firstly, there are the individual permissions and their associated permission levels. By assigning permissions to a user, you are essentially saying that a user can perform a specific action. Developers will recall these as the members of the SPBasePermissions enumeration. For example, the SPBasePermissions.BrowseDirectories and SPBasePermissions.AddDelPrivateWebParts permissions, etc. etc. etc.. Therefore, when designing the permission levels it is essential to consider the predefined permissions in SharePoint that coordinate to the related tasks that the user can perform. Since individual permissions can contain multiple permission levels, it is important to consider all the relevant actions for each user and group. In order to manage permission levels, a user must have the Manage Permissions permission, or the SPBasePermissions.ManagePermissions member.

Users and groups have to be seriously considered when designing permission schemes. Groups in SharePoint are contained and administered at the site collection level, and can either be a Windows security or SharePoint group. Groups in SharePoint have an associated default permission level, but the default permission levels are easily modified. Similiar to how managing permissions requires the SPBasePermissions.ManagePermissions member, creating groups requires the SPBasePermissions.CreateGroups member. Groups only contain utility when users are placed within the group. It is considered a best practice to use groups whenever possible and in only particular circumstances assign individual permissions to particular content.

In terms of the “things” that a user wants to access, each object is considered to be a securable object or an ISecurableObject object. This can be a list, library, document, list item, etc. By default content within the site will natively inherent the site permissions but there is lower level assignment that is always available, such as list level (container level) or item level (content level).

Understanding and designing the SharePoint security relational assignments is crucial when considering the holistic SharePoint environment. Particular securable objects can have a user or group assigned a permission level for it. On securable objects within the site, as stated before, will by default inherit the permissions from the site by default. This design can be extended by implementing unique, fine grained permissions for each securable object in SharePoint in order to more finely tailor user actions for particular content. This approach needs to be approached with the aggregate design in mind, since assigning a multitude of individual permissions can natively cause a very, very complex design. This paradigm of complexity means that the implemented design must mutually consider the permission inheritance scheme as well as the individual permission assignment scheme. As a best practice, when breaking inheritance you should try to use groups as much as possible in order to decrease the complexity of the security designs. Individual accounts, for individually assigned items can be very, very difficult to track and can cause highly visible maintenance problems.

Managing sites, as a best practice, should use inheritance as much as possible due to the trickle-down inheritance that happens by default with the permissions of all the associated items within the site. It both lessens security design complexity and makes push down changes much more effective and impacting. Under this design however, the persons with the rights to manage sub site permissions must be strongly controlled since the sets are shared. This can natively cause problems with users accessing content and both site and the sub site level. As a best practice, commonly accessed content should use a shared inheritance scheme as much as possible while sensitive content that has few associated users and groups can be broken.

From what we have talked about thus far, it is clear that determining the balance between the simplicity of managing the security for an instance as well as performance versus the need to separate sensitive content. There are a few takeaways to consider as best practices. Firstly, always follow the principles of least privilege where a user only has the required minimum permissions to execute their assignments. Since several of the inbuilt functions of SharePoint as well as the API has hooks that use the standard groups, it is best to exploit the default groups as much as possible. As stated previously, it is best as much as possibly to lean on inheritance schemes. Always carefully choose whom you elevate about the permissions of members of visitors since these correlate to the common actions of limited contribution and view rights on objects. Furthermore, members of the Owners group should be tightly controlled and monitored since they have elevated rights to execute actions such as modifying the site structure. It is important to remember that permissions and permission levels are flexible in SharePoint, permission levels for particular objects can be customized as required.


Best Practices For Unique Permissions On List And Items in SharePoint 2010

There are some general recommendations to consider when it comes to unique permissions in SharePoint 2010. They include:

  • Minimizing the use of unique permission on individual items. They will simplify list design to require more items for unique permissions.
  • When unique permissions are necessary, set them only at the list or folder level. Minimize the number of individual items that you need unique permissions for.
  • Reconsider your design for each item required with individual permissions. It may be a good idea to divide items between multiple lists so that they can be organized with other items into groups and folders. The proper access needs to be authorized for that unique permissions can be allowed on each item.

Granular permissions can affect performance and they are also very hard to manage. Therefore, you should leave them set at the defaults, you certainly don’t want to set them to where the list view threshold is exceeded. If you do so they will be blocked due to too many individual items being updated at the same time. Setting granular permissions can affect performance in many other ways too. The result is that there is a configuration limit by default to 50,000 unique permissions for each of the lists.

When you try to declare unique permissions after you reach that limit, you will be blocked from doing it. The list view threshold doesn’t have that block in place and it will allow you to continue to create unique permissions for each item but not for a query. Permissions can be inherited but also broken for the items when they are in a folder. There they will be considered one unique permission.

Every time a permission inheritance is broken then a new scope ID is developed. When you query on a view you can JOIN the scope table for that query. There is then unique access control over the list that has to be processed. When there are many unique permissions in a list then it can reduce the overall performance of the query so that isn’t recommended. The number of unique permission in a list gets bigger over time and that reduces the performance. While the limit is by default 50,000 it is ideal if you make your customized limit 5,000.