The one thing in SharePoint which is sure to create new frown lines on the troubled brow of any SharePoint Newbie is Permissions.

When I first started with SharePoint my first thought on digging in to the whole permissions issue was “What the holy heck is this all about then?”

Permissions – well surely we just decide what we want a user to be able to do and then – give them permission to do it, right?

Wrong!

In this series of articles we are going to try and give you a basic run down on how SharePoint permissions work, why they work that way, and some suggestions for best practice in setting up permissions.

Basic Principles

So, having established that simply assigning permissions relating to objects to users is not the way things are done in SharePoint lets now look at how we should do things.

If you only take away one thing from these articles it should be this:

Thou Shalt Not Assign Permissions on an Individual Basis.

Now, there are always good reasons to break any rule, and there will be times when you want to break this one, but before you break it lets try to understand why the rule exists and how we apply it.

It is actually possible to assign individual permissions, for individual objects, to individual users – exactly as shown in the diagram above, but that way chaos lies.  So this is how it should be done.

So what we should be doing is putting users into groups, organizing permissions into levels and assigning permission levels for particular objects to groups.

Defining the Terms

Lets first put some definitions on the terms we will be using.

Users

Users are anyone who may be using your SharePoint site, from administrators through site owners and contributors, to people from outside your organization who may have permission to visit your SharePoint site.

Groups

Groups are simply groups of users, often defined in terms of shared job function e.g. the HR group or the Marketing group, or by participation in a project – the Christmas Party Committee group.  A user may belong to more than one group.  For example, within Pentalogic I belong to the Marketing Group and the Management Group.

SharePoint comes with a set of pre-defined groups to which you can assign users, but likely as not these are not going to be all that useful to you, so you will need to set up your own groups.

Why assign permissions to groups rather than individual users? If we don’t use groups, every user has to have their permissions assigned individually. And that’s not just once. We’d potentially need to do it for each user for each site. What if we have 200 users and introduce a new site? No, it’s generally a lot easier, safer and less error-prone to define a group for each type of user then add new users to the group. It’s also a lot easier when people leave the company or no longer need to access our SPF installation. We just take them out of the relevant group or groups. Or when people get promoted or change job role – rather than looking for all the many individual items they are going to need permissions for simply assign them to the appropriate group for their new role.

Permissions

Permissions give the ability to do something within SharePoint – eg.  “Edit List Item” or “Create Team Site” Permissions fall into 3 main areas:

1. List Permissions
2. Site Permissions
3. Personal Permissions

Permission Levels

Permission Levels are a pre-defined set of permissions, covering list, site and personal permissions.

SharePoint has default permission levels which may well prove more useful than its default groups.  The default permission levels are a coherent set of permissions across the three areas.

You do also have the ability to define your own custom Permissions levels.

Why use permission levels rather than individual permissions? Permission levels are usually defined to correspond to the needs of a particular type of user. For example, the Contribute permission level includes nearly 20 individual permissions, and these have been chosen to support the requirements of a contributor to a site. It would certainly take some time and effort to assign those individual permissions to a few dozen users or groups.

Objects

Objects – a SharePoint site, list, library, wiki, or indeed even an individual list item or document – so really the “things” within SharePoint.

Assign Permissions

Assign Permissions – the Permission level, assigned to a SharePoint Group, in relation to a particular SharePoint Object.  This is the glue that brings the two sides of the equation – the user groups and the permission levels together.

Inheritannce

A permission level assigned to a SharePoint Group in relation to a particular Object will, by default, be inherited by all subordinate objects.  So, if we assign the Marketing Group the Permission Level “Full Control” in relation to the Marketing Team Site, the Marketing Group will, by default have full control over all objects within the Marketing Team Site, including lists, libraries, wiki’s, pages and list items.

You may choose to break inheritance within the SharePoint hierarchy – but this again is not generally thought of as best practice as breaking inheritance makes the whole business of administering permissions so much more complicated.  So this is something you should only do when you fully understand the implications.

So, that about covers the “What?” of SharePoint Permissions, and touches on the “Why?”  in the next instalment we are going to look at the practical “How?” of managing permissions, and in part 3 we will look at breaking the rules – why and when you might choose to do this.

Tags: SharePoint, SharePoint 2010, Terminology