Understand permissions and permission levels (Project Server)
Updated: September 2, 2010
Topic Last Modified: 2010-08-31
This topic provides information about access control and authorization at the site collection, site, and subsite levels.
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 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).
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).
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).
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.
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.
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.
|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.|
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.
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.
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.
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.