Securing SharePoint 2013: Understanding Authorization and Permissions - Part 1

This post is the third in a series where I introduce concepts and considerations for security in Microsoft SharePoint 2013.  These articles serve as an introduction to those new to SharePoint or to those that have SharePoint up and running but are looking at built-in features and third-party solutions to secure their sensitive information.

---

 

Authorization is an important concept to consider when securing sensitive information in Microsoft SharePoint. Looking at this concept broadly, it’s helpful to understand the differences between authentication and authorization. As mentioned, authentication is the process of determining if a user is who they say they are. Authorization is the process of determining what resources a user can access and what actions can they perform with those resources. Just because a user has access to a system doesn’t necessarily mean they should have complete access to everything within that system.

Within Microsoft SharePoint, authorization is enforced through permissions. With SharePoint 2013 there are some important new changes that are important to understand.

Understanding Permissions
The underlying permissions system within SharePoint 2013 is, in most respects, the same system it has always been. Permissions can be used to secure access to any item or document within SharePoint, as well as any container (folder, list, library, site, site collection).

A permission has 3 components:

§  An information object to which it is assigned (item, document, or container)

§  A principal (user, SharePoint group, AD group, or a claim)

§  A permission level (read, full control, contribute, design or a custom permission level)

Permissions are assigned to items, documents or containers by selecting a user or group and then selecting a permission level. For example, items or containers could have the following permissions assigned to them:

§  User John Smith has Read access to a document

§  AD Group Finance has Full Control access to a library

§  SharePoint Group Project_Team has Contribute access to a Folder

§  User Engineering_Contractor has Contribute access to a site

As an advanced feature, SharePoint 2010 and 2013 allow a permission to contain a “claim” instead of a user or group. As described earlier, a claim is a trusted user attribute that is retrieved when that user logs in. Attributes could include data like the user’s email address, their group memberships, their security clearance, etc.

A permission containing a claim would look like the following:

§  Users with the claim Security_Clearance=Secret have Read access to a document

In this example, when a user logs into SharePoint, if an attribute is retrieved about that user which contains the value Security_Clearance=Secret then the user will be granted Read access to the document. SharePoint needs to be configured for Claims Based Authentication for this to occur.

 
Hierarchical Permission Model
SharePoint 2013 continues to have a hierarchical permission model, which means permissions are organized according to a hierarchy. Permissions are initially assigned by SharePoint at the site collection level. As a result, all sites, libraries, lists, folders and content below that site collection will automatically receive those permissions. The lower level containers or items “inherit” their permissions from the level above if no specific permissions are assigned to that object.

At any level within SharePoint, a user can break permission inheritance and assign specific permissions to that level. For example, a site collection called “Demo” contains a SharePoint group called “Demo Members” which has been assigned with the Read permission. So, any member of the “Demo Members” group will have read permissions to the site collection and anything below it. The “Demo” site collection contains 3 sites, one which breaks permission inheritance so that members of the AD group “Finance_Team” has Edit permissions. As a result, all content below this site (all libraries, folders, content, etc.) will inherit the “Finance_Team” permission from their parent site, unless something below the site also break inheritance.

The following diagram illustrates this point:

Figure 1. SharePoint containers and items with broken permission inheritance.

   -Antonio