Understand permissions and permission levels (Project Server)

This Office product will reach end of support on October 10, 2017. To stay supported, you will need to upgrade. For more information, see , Resources to help you upgrade your Office 2007 servers and clients.

 

Topic Last Modified: 2010-08-31

This topic provides information about access control and authorization at the site collection, site, and subsite levels.

  • Site security elements

  • Assigning permissions

  • Fine-grained permissions and permission inheritance

Site security elements

Regardless of what type of site you are creating, the security for your site includes five elements: permissions, permission levels, users, groups, and securable objects.

  • Permissions

    Permissions grant the ability to perform specific actions. For example, the View Items permission grants users and groups the ability to view items in a list. Farm administrators can control which permissions are available for the server farm by using the User Permissions for Web Application page in Central Administration (to open this page, on the Application Management page, under Application Security, click User permissions for Web application).

    For information about available permissions, see Default permissions and permission levels (Office SharePoint Server).

  • Permission level

    A permission level is a predefined set of permissions that grants permission to users or groups to perform related actions. The default permission levels are as follows: Read, Contribute, Design, and Full Control. For example, some of the Read permission levels are the View Items, Open Items, View Pages, and View Versions permissions, all of which are needed to read documents, items, and pages on a SharePoint site. Permissions can be included in multiple permission levels. Permission levels can be customized by anyone assigned to a permission level that includes the Manage Permissions permission.

    For information about default permission levels and which permissions are included in them, see Default permissions and permission levels (Office SharePoint Server).

  • User

    A user is a person who has a user account that can be authenticated through the authentication method used for the server. You can add individual users and directly assign one or more permission levels to each user. Because it is inefficient both administratively and computationally to directly maintain the permissions for individual user accounts (except in very small organizations), you should only assign permissions on a user basis as an exception. We recommend that you generally assign permissions to groups rather than users.

    For more information about user account types, see Default permissions and permission levels (Office SharePoint Server).

  • Group

    A group is a group of users. A group can be a Windows security group (such as Department_A) that you add to the site, or a group can be a SharePoint group such as Site Owners, Site Members, or Site Visitors. SharePoint groups are assigned a default permission level, but the permission level for any group can be changed as needed. Anyone assigned a permission level that includes the Create Groups permission (included in the Full Control permission level by default) can create custom SharePoint groups.

  • Securable object

    Users or groups are assigned a permission level for a specific securable object: site, list, library, folder, document, or item. By default, permissions for a list, library, folder, document, or item are inherited from the parent site or parent list or library. However, any user or group that is assigned a permission level for a particular securable object that includes the Manage Permissions permission can change the permissions for that securable object. By default, permissions are initially controlled at the site level, with all lists and libraries inheriting the site permissions. Use list-level, folder-level, and item-level permissions to further control which users can view or interact with the site content. At any time, you can return to inheriting permissions from a parent list, the site as a whole, or a parent site.

Assigning Permissions

You can assign a permission level to a user or group for a specific securable object (site, list, or item). Individual users or groups can have different permission levels for different entities.

Note

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 (see the next section), 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.

Fine-grained permissions and permission inheritance

You can use fine-grained permissions (permissions on a list or library, on a folder, or on an item or document level) to control more precisely what actions users can take on your site. The following entities are available for permission assignments:

  • Site   Controls access to the site and any objects that inherit their permissions from the site.

  • List or library   Controls access to the list and all folder and items in the list that inherit their permissions from the list.

  • Folder   Controls access to the folder itself and any items in that folder that inherit their permissions from the folder.

  • Item or document   Controls access to a specific list item or a document.

Permission inheritance and fine-grained permissions

By default, permissions within a site are inherited from the site. However, you can 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. For example, you can edit the permissions for a document library, which breaks the inheritance from the site. However, the inheritance is broken for only the particular securable object and anything within the object that inherits from it; the rest of the site's permissions are unchanged. You can make a securable object either more or less accessible than the parent site. You can return to inheriting permissions from the parent list or site at any time.

Permission inheritance and subsites

Web sites are themselves securable objects to which permissions can be assigned. You can configure subsites to inherit permissions from a parent site, or you can create unique permissions for a particular site. Inheriting permissions is the easiest way to manage a group of Web sites. However, if a subsite inherits permissions from its parent, any changes to permissions must be made on the parent site. If you want complete control over the subsite permission, you should select Use unique permissions when creating the subsite.

Security scopes

The maximum number of unique security scopes set for a list should not exceed 1,000.

A scope is the security boundary for a securable object and any of its children that do not have a separate security boundary defined. A scope contains an Access Control List (ACL), but unlike NTFS ACLs, a scope can include security principals that are specific to Product Short Name. The members of an ACL for a scope can include Windows users, user accounts that are not Windows users (such as forms-based accounts), Active Directory groups, or SharePoint groups.