SharePoint Permissions Management – SharePoint Role Assignment

This blog has been prepared by our dear friend Agnes Molnar, a SharePoint Server MVP. We will post it in two parts, this is the first part and we are sure it will be interesting and useful.

Security is always one of the most critical points in any Content Management System. Knowing who I am and what I can see or do in the system is essential. This sounds obvious but actually it’s always very complex—in SharePoint 2013 as well.

SharePoint Security Steps

When talking about security, we can identify two major steps in every system: authentication and authorization.

• Authentication is the process when the system identifies me, gets answer to the question “Who are you?”, and verifies if you really are who you say you are.
• Authorization is the process of verifying what you can see or do, or in other words —“you are permitted to do what you are trying to do.” Authorization always presupposes successful authentication.

As SharePoint does role based on access control, the next thing to be aware of and understand is the role assignment. SharePoint role assignment has three main components in SharePoint:

• User or Group – the person or group of persons who gets the role.
• Security Scope – the subject
• Permission Level – the level of permission(s) the user or group is assigned to the subject.

Let me show you some examples:

• “Jeff needs to edit this document.”
  • User: Jeff
  • Security Scope: this document
  • Permission Level: edit
• “Chris has to change the settings of this list.”
  • User: Chris
  • Security Scope: this list
  • Permission Level: change the settings (admin)
• “HR and Marketing have to be able to read everything on this site.”
  • Groups: HR, Marketing
  • Security Scope: this site
  • Permission Level: read
• “Why Gary can see these files in ‘Search’?!”
  • User: Gary
  • Security Scope: these files
  • Permission Level: read

SharePoint Role Assignment

In SharePoint, there are several levels of available security scopes. These levels are organized into a well-defined hierarchy; therefore, we have a very clear inheritance — by default, all the permission settings are inherited from the parent level to its children.

These levels are:

• Site
• List/Library
• Folder
• Item/Document

It’s also worth noting that we have permission inheritance by the site hierarchy as well, by default; every site inherits the role assignment from its parent.

In this case, using the default settings, every list and document library inherits the role assignments from the site (and the site inherits from its parent site), as well as the folders, subfolders and items inside. These settings can be, for example:

• Group Marketing has contribution (read or write) access to everything;
• Group Sales has read access to everything;
• Jeff, Joe and Jim have contribution access to everything (regardless of their group membership).

If you use the default settings (inheritance) on each level, these groups will have read (Marketing) and contribution (HR) access to every list and library, every folder and subfolder, every item and document. For example, if you have a document library “Campaigns” with a folder for each year (2013, 2012 etc.), the Marketing group, Jeff, Joe, and Jim can add new documents, open and edit the existing ones, while the members of the Sales group will be able to read these documents but not modify them.

But of course, you can break this inheritance by defining custom SharePoint role assignment, on any level. In this case, you have the default role assignment on the site level (either set on this site or inherited from its parent site), but it’s not inherited to, and below the folder where you create the custom role assignment.

For example, let’s say we have the very same role assignment on site level:

• Group Marketing has contribution (read or write) access to everything;
• Group Sales has read access to everything;
• Jeff, Joe and Jim have contribution access to everything (regardless of their group membership).

But you have a specific folder in the document library “Campaigns” for the current year (2014) where you want the group ‘Sales’ to have contribution access as they might have to add or modify the current documents. In this case, you have to break the permission inheritance. The default role assignment after this will be identical with the current settings, but you can change it according to your needs:

• Group Marketing has contribution (read or write) access to everything;
• Group Sales has contribution (read or write) access to everything;
• Jeff, Joe and Jim have contribution access to everything (regardless of their group membership).

Of course, you can do this on any level. On one hand, this is good as you can have as custom and complex permission settings on your content as you want. On the other hand, it’s a very big challenge and might be a huge risk due to its complexity.

Note: In SharePoint 2013 and Office 365, it’s very simple to share documents or even folders, lists and libraries with your colleagues. This makes the end users’ lives much easier, but can be a real challenge for the administrators.

SPDockit is a great solution that can be very useful during the SharePoint permissions management process. Use it to explore or create many useful and very detailed SharePoint permissions reports.

Continue reading part two…