Plan site permissions (SharePoint Server 2010)

Applies to: SharePoint Foundation 2010, SharePoint Server 2010

This article helps you plan access control at the site collection, site, subsite, and site content (list or library, folder, item or document) levels. This article also describes the concepts about permission inheritance and fine-grained permissions.

This article does not address planning the security of your entire server or server farm. For more information about planning other aspects of security, such as authentication methods and authentication modes, see Plan authentication methods (SharePoint Server 2010).

In this article:

• About site permissions

• About permission inheritance

• Plan for site permissions

• Plan for permission inheritance

• Worksheet

Introduction

You can control access to site and site content by assigning permissions to users or groups for a specific site or site content at the following levels within a site collection:

• Site

• Library or list

• Folder

• Document or item

Before developing your plan for site and content access, you should consider the following questions:

• To what granularity do you want to control permissions for the site or site content? For example, you might want to control access at the site level, or you might need more restrictive security settings for a specific list, folder, or item.

• How do you want to categorize and manage your users by using SharePoint groups? Groups do not have any permission until they are assigned a permission level for a specific site or for specific site content. When you assign permission levels to SharePoint groups at the site collection level, by default, all sites and site content inherit those permission levels.

For more information about using groups to help manage permissions, see Choose security groups (SharePoint Server 2010).

About site permissions

You should understand the following concepts before designing your permissions plan.

• Permissions   Permissions grant a user the ability to perform specific actions. For example, the View Items permission allows a user to view items in a list or folder, but not to add or remove items. Permissions can be granted to individual users at site or site content levels.

  For information about available permissions, see User permissions and permission levels (SharePoint Server 2010).

• Fine-grained permissions   Fine-grained permissions are unique permissions on securable objects that are at a lower level in a site hierarchy, such as permissions on a list or library, folder, or item or document. Fine-grained permissions allow for greater granularity and customization of user permissions in a site collection.

• Permission level   Permission levels are collections of permissions that allow users to perform a set of related tasks. For example, the Read permission level includes the View Items, Open Items, View Pages, and View Versions permissions (among others), all of which are needed to view pages, documents, and items in a SharePoint site. Permissions can be included in more than one permission level.

  Permission levels are defined at the site collection level and can be customized by any user or group whose permission level includes the Manage Permissions permission. For more information about customizing permission levels, see Configure custom permissions (SharePoint Server 2010).

  The default permission levels are Limited Access, Read, Contribute, Design, and Full Control. For information about default permission levels and the permissions included in each level, see User permissions and permission levels (SharePoint Server 2010).

• SharePoint group   A SharePoint group is a group of users that are defined at site collection level for easy management of permissions. Each SharePoint group is assigned a default permission level. For example, the default SharePoint groups are Owners, Visitors, and Members, with Full Control, Read, and Contribute as their default permission levels respectively. Anyone with Full Control permission can create custom groups.

• User    A user can be a person with a user account from any authentication provider supported by the Web application. We recommend that you assign permissions to groups rather than users, although you can directly grant individual users permissions to a site or specific content. Because it is inefficient to maintain individual user accounts, you should assign permissions on a per-user basis only as an exception.

• Securable object    A securable object is a site, list, library, folder, document, or item for which permissions levels can be assigned to users or groups. By default, all lists and libraries within a site inherit permissions from the site. You can use list-level, folder-level, and item-level permissions to further control which users can view or interact with site content. You must first break the permission inheritance before you change or assign permissions for that securable object. You can resume inheriting permissions from the parent list or site at any time.

You can assign a user or group permissions for a specific securable object. Individual users or groups can have different permissions for different securable objects. The following diagram illustrates the relationships among permissions, users and groups, and securable objects.

About permission inheritance

Permissions on securable objects within a site are inherited from the parent object by default. You can break inheritance and use fine-grained permissions — unique permissions on the list or library, folder, or item or document level — to gain more control of the actions users can take on your site. For more information about the best practices for using fine-grained permissions, see Best practices for using fine-grained permissions

Stopping inheriting permissions copies the groups, users, and permission levels from the parent object to the child object, and then breaks the inheritance. When permission inheritance is broken, all permissions are explicit and any changes to parent object do not affect the child object. When you remove a user’s permissions, that change will affect the child object. We propagate the delete regardless of the status of inheritance. If you restore inherited permissions, the child object will inherit its users, groups, and permission levels from the parent again, and you will lose any users, groups, or permission levels that were unique to the child object.

For ease of management, use permission inheritance wherever possible.

Plan for site permissions

When you create permissions, you must balance the ease of administration and performance against the need to control access to individual items. If you use fine-grained permissions extensively, you will spend more time managing the permissions, and users may experience slower performance when they try to access site content.

Use the following guidelines to plan site permissions:

1. Follow the principle of least privilege: Users should have only the permission levels or individual permissions they need to perform their assigned tasks.

2. Use standard groups (such as Members, Visitors, and Owners) and control permissions at the site level.

   • Make most users members of the Members or Visitors groups. By default, users in the Members group can contribute to the site by adding or removing items or documents, but cannot change the structure, site settings, or appearance of the site. The Visitors group has read-only access to the site, which means that they can see pages and items, and open items and documents, but cannot add or remove pages, items, or documents.

   • Limit the number of people in the Owners group. Only those users you trust to change the structure, settings, or appearance of the site should be in the Owners group.

3. Use permission levels rather than assign individual permissions.

Plan for permission inheritance

It is much easier to manage permissions when there is a clear hierarchy of permissions and inherited permissions. It becomes more difficult when some lists within a site have fine-grained permissions applied, and when some sites have subsites with unique permissions and others with inherited permissions. As much as possible, arrange sites and subsites, and lists and libraries so they can share most permissions. Separate sensitive data into their own lists, libraries, or subsites.

For example, it's much easier to manage a site that has permission inheritance as described in the following table.

However, it is not as easy to manage a site that has permission inheritance as shown in the following table.

Worksheet

Use the following worksheet to fill in your site hierarchy, and then list the permissions needed at each level of the hierarchy and any permission inheritance.

-
Site and content security worksheet (https://go.microsoft.com/fwlink/p/?LinkID=213970&clcid=0x409)

See Also

Other Resources

Resource Center: Security and Authentication for SharePoint Server 2010