Wednesday, November 05, 2008

Designing and Implementing a Security Model in SharePoint

V3 of SharePoint made some huge steps in the granularity of how you can set permissions on content stored in a site, most notably the ability to lock down individual items in a list or library.

So If you’ve ever tried to lock down a SharePoint site collection you may have had a hell of a time trying to understand how best to design a security model and then implement it.

Below I’ve attempted to outline an approach which may help you get going, its broken down into 4 main areas.

 

  1. How Permissions Work
  2. How to ‘Stop Inheriting Permissions’ to create your own.
  3. Initial Planning before you begin
  4. Some Gotchas and other Recommendations.

 

How Permissions work in SharePoint

When you create a new site collection in SharePoint there are 3 main groups that are created – Site Visitors, Site Members and Site Owners where you add users.
Additional to this is 3 main permission sets – Read, Contribute and Full Control which control your level of access.

Basically a site group gets assigned a permission set like below.

Sharepoint Group Site Permission
Site Visitor Read
Site Member Contribute
Site Owner Full Control

There are other groups and permissions which I haven't mentioned, but to keep it simple these are the 3 that are consistent in both WSS and MOSS. Also, you can create your own SharePoint Groups and Site Permissions which is common practice.

Now, take an average site collection where you’ll have a top level site and a collection of subsites (ala a site collection) you will run into scenarios where you’ll want to lock down sites, content within sites and even individual files within libraries – all of which is possible and the best way I feel is to ‘Stop Inheriting Permissions’ (or detaching) at the level required and either customise the existing sharepoint groups, or create your own as needed.

Detaching permissions at a site level: Goto Site Actions –> Site Settings –> Advanced Permissions –> Permission Levels (in the toolbar)
The url should be http://YOURSITE/YOURSUBSITE/_layouts/role.aspx

Edit the permission level in the toolbar and you’ll be prompted like so.

sitepermissions

At a list/library level: Goto the list or library settings –> Permissions for this library.

Click on the ‘Edit Permissions’ in the toolbar.

listpermissions 

 

And at a file/folder level: Goto ‘Manage Permissions’ on the file by either the dropdown menu or when viewing the properties of the file/list.

itemlevelpermissions

 

Its also important to know where the same SharePoint or AD group can be leveraged off elsewhere in your site collection, for this its best to look at the overall picture first.

Initial Planning – “getting the overall picture”

I’d highly recommend that you draw up your site collection in a site map style in Visio. From there detail each of the areas where content needs to be locked down or other site permissions need to be applied. It will help draw out the where similarities may exist and help you plan what groups of people need access and where. It then becomes a way to discuss this security model with your IT department, as you will want to leverage off existing Active Directory Groups where possible.

Once you have this plan in place you’ll be a good position to start configuring SharePoint with the unique permissions. The best way I feel to achieve this is to ‘stop inheriting’ permissions at the level you require – whether that’s at a site, list/library or file/folder level.

Breaking Group and Permission Inheritance – “some gotcha’s”

When you stop inheriting permissions you need to be mindful of an apparent bug in SharePoint which happens at a site level detach/re-attach. If you break permissions at a file level and then restore everything goes back to normal (as expected). When done at a list/library level the library returns to normal but keeps any unique permissions that may be applied at a file/folder level (again as expected). When however you attach/re-attach at a site level the change cascades down and overwrites any custom permissions at a list/library or file/folder level (not expected :)). – hopefully that makes sense, as its not consistent and can cause some real heartache if you’ve spent time customising some libraries in a site.

Also, you can ‘detach' site permissions at a site level which allows you to customise the specifics of what a permission group can do. An example might be that you want to lock down the ‘Read’ permission group so they can’t view old versions of files. This is fine, just be aware that if you ‘re-attach’ the permissions back that it will cascade the change down for groups as well (as described above)

Active Directory - “leverage it, don’t redesign it”

Be careful not to try to implement your security model from AD alone. It could create an unnecessary burden on your IT department who in most cases, shouldn’t be owning SharePoint. There is still a balance here, but a general rule to follow is that you shouldn't be creating lots of AD groups for the sole purpose of using them in SharePoint. AD needs to be leveraged across your entire organisation (in an MS world) so it could quickly get out of control if every application took the AD approach to configuring security.

In recommending this approach, I’m mindful that some Business scenarios would actually apply to IT owning all the security access for SharePoint and it can make sense for system administrators to try to control SharePoint solely from AD.. after all, its easier to look in AD and understand where uses have access.

Item Level Permissions - “use folders and/or workflow”

If you’re looking to lock down items within a document library then use Folders to set permissions. If you put your documents in those folders they will inherit those permissions – just like the file system. This is a far more manageable & intuitive approach then setting the permissions on each item.

Locking down lists like tasks, calendar, wiki’s, blogs etc is a little harder as you can’t use folders. Every list in SharePoint allows you to lock down items to the creator which usually suffices for most requirements. ie ‘users can only read and/or edit their own items’  check the list settings –> Advanced Settings for your options.
Alternatively, I’ve used workflow to lock down items after they’ve been created. A scenario might be that a user fills out a list form and one of the metadata columns is their department. You can then use a workflow to trigger and lockdown the item to the department group only, another example is to simply lock down a form from the user after they’ve submitted it. These kinds of workflow actions where you set permissions on items are not in the default install of SharePoint, you can grab them on CodePlex with the useful SharePoint Designer Workflow Actions.

 

Additional Links
- Data Security Risks

Happy permission setting :)

3 comments:

Laurie S said...

Hi Tim

Strangely familiar :)
It's going to be very useful recap for me, thanks

Tim W said...

Hey Laurie,

Yeah it was fresh in my mind so I put the post together on the plane home..
hope the intranet launch is going well.

Cheers,
Tim

Urvish Gohil said...

Hi,
Managing individual permission was done by me in past but now when I really want to use it, I just forgot it. Thanks for those screenshots. Got it in a few seconds. :)

Thanks,