As an IT or SharePoint administrator, you have to manage the security of your farm, including properly provisioning the service accounts and end users that require access to SharePoint. Here, we explore how permissions in SharePoint work and best practices for using them to maximize SharePoint security and adoption.
Access control relies on authentication (verifying that the user is who they claim to be) and authorization (determining what the user should have access to). SharePoint performs the authorization, but it does not perform any authentication; it relies on the underlying Internet Information Services (IIS) and authentication providers to handle that.
Since SharePoint 2010, the standard authentication has been claims-based authentication. There are different types of claims-based authentication; the industry standards are WS-Federation, Security Assertion Markup Language (SAML) and OAuth. However, Microsoft baked into SharePoint a claims engine, the Security Token Service (STS), which can understand many different authentication approaches. Out of the box, SharePoint supports standard Windows Authentication (NTLM, Basic and Kerberos), Forms Based Authentication (FBA) and SAML.
Entities that can be granted permissions
Authorization in SharePoint is controlled by permissions assigned to the following entities:
- Active Directory groups
- Roles provided by Forms Based Authentication
- SAML attributes
- SharePoint groups
- A specific user (though best practices recommend not assigning permissions at this level in SharePoint)
Objects that permissions can be granted for
SharePoint supports permissions for many kinds of objects:
- Farm
- Service application
- Web application
- Site collection
- Site
- List
- Library
- Folder
- Item
For all of these objects, you can assign permissions to the entities listed in the previous section, such as SharePoint security groups, roles, attributes or specific users. (As noted earlier, however, the best practice is to use security groups or roles for assigning user permissions instead of adding permissions directly to a user account.)
The permission assignments for an object determine whether access to it is granted or blocked. A typical SharePoint user would not, for example, have access at the farm, service application or even web application level; instead, they would be granted permissions to data at the site collection level or lower using the corresponding SharePoint permission groups.
Note that best practices also recommend avoiding assigning SharePoint item-level permissions as much as possible because it complicates management and can lead to security oversights. Often, you can simply group items in SharePoint lists, document libraries or folders that are assigned the required permissions. However, sometimes item-level permissions can be required to meet specific needs, especially in the absence of a third-party rights management solution. If custom item-level permissions are the only option to meet the business need, then administrators should limit their use to particular locations and create a strict workflow around it, documenting and reviewing when item level permissions were granted or changed and who did it.
The ability to manage permissions to SharePoint resources is primarily limited to members of the Site Collection Administrators (who can manage the root site and all its subsites) and Site Owners groups (who can manage specific subsites). However, any end user can edit permissions to the content and locations that they own.
To modify the permissions for a site collection or site, the Site Collection Administrators or Site Owners should choose “Site Settings” and edit the SharePoint permissions; lower level permissions, such as permissions to document libraries or lists, are accessible within the settings pages for those specific securable objects.
Understanding and using permissions levels
Default permissions levels
SharePoint uses permission levels to control access to objects. There are ten default permissions levels:
- Full Control
- Contribute
- Read
- Design
- Edit
- Limited Access
- Approve
- Manage Hierarchy
- Restricted Read
- View Only
Each permission level is a container for individual permissions. For example:
- The Read permission level includes these permissions: Open, View, Versions, Page, Application Pages, User Information, Create Alerts, Self-Service Site Creation, Remote Interfaces and UseClient Integration Features.
- The Contribute permission level includes all the permissions in the Read level plus View, Add, Update, Delete, Versions, Browse Directories, Edit User Information, Manage Personal Views, Add, Update or Remove Web Parts.
- The Full Control permission includes all the sub-permissions for Read and Contribute, plus extras.
Normally, end users are assigned Contribute access to the private sites they actively use and View Only access to everything else.
Custom permissions levels
SharePoint does not include every permission level an organization might require, so it enables you to customize the permissions levels and create new ones, either from scratch or by cloning an existing permission level and making permissions changes. Having tailored granular permissions sets enables you to better control what end users can do in a way without all the complications and risks of assigning permissions directly to individual users.
Customizing an existing permission level
Navigate to the “Site Settings” page and click on “Site Permissions” and click on the “Permission Levels”menu. To customize an existing permission level, click its name on the “Permission Levels” page. On the “Edit Permission Level” page, change the description and add or remove permissions as you require.
Creating a new custom permission level from scratch
To create a new custom permission level, you must be logged in as a SharePoint Farm Administrator, Site Collection Administrator or Site Owner. Navigate to the “Site Settings” page and click on “Site Permissions”. Next, click on the “Permission Levels” menu item:
On the “Add a Permission Level” page, enter the name of the new permission level and a description. Then select the check boxes next to the list, site and personal permissions that you want the new permission level to include. Last, click “Create”.
Creating a new custom permission level by cloning
To clone an existing permission level, access the same location go to the “Permission Levels” page and then click on the permission level you want to clone.
Then click the “Copy permission level” button, name the new permission level, modify it as needed, and then save it.
Understanding permission inheritance
The permission settings of an element in a site collection are passed on to the children of that element: Sites inherit permissions from the root site of the site collection, libraries inherit from the site that contains the library, and so on. Permission inheritance enables you to make a permission assignment once at a high level and have it flow through to lower levels.
As you can imagine, this model does not meet all security requirements. For example, multiple users might need access to a certain document library, but only a few of them should be able to read one of the documents in that library. Similarly, you also might need:
- Subsite permissions that differ from those for the parent site collection
- List or library permissions that vary from those of the parent site
- Folder permissions that differ from those of the parent library
- File permissions that are different from the parent library or folder
Breaking permission inheritance
Currently, the only way of achieving these goals is to break inheritance for the specific item. You edit user permissions as required, removing those permissions that are not necessary. This strategy is effective, but assigning unique permissions to specific user accounts creates management headaches and can introduce security gaps. Therefore, you should avoid breaking inheritance whenever possible.
To break inheritance for a given object, select the object where you wish to break the inheritance, choose “Stop inheriting permissions” and then remove or add users or groups as needed.
Setting SharePoint permissions correctly and managing them effectively can make or break your Microsoft SharePoint investment: Too much restriction can lead to less adoption, but unlimited access can lead to a messy environment and security issues. Getting the right balance requires carefully planning before SharePoint implementation, along with regular reviews and risk assessments thereafter to ensure the integrity and usefulness of the SharePoint farm.
