Rethinking SharePoint's Security Model, Pt.1

The SharePoint permission model is great.

By great, I mean large... difficult to comprehend and to manage.  Even for someone with a firm grasp on how inheritance works and how permission assignments are put together, managing permissions on a large site with broken inheritance can be a major challenge.

When it comes to tracking down errant permission assignments, even the experts, SharePoint developers and administrators, are more likely to use scripts to generate security matrices and assignment reports than to use the out-of-the-box permission management pages.

In this post I'm going to discuss the deficiencies that irk me most with the security model and propose a method by which we can make the interface for managing security more intuitive. In a follow-up blog post I will show you one method by which you can implement this interface yourself.

  • Challenges With the SharePoint Security Model

Arguably, there are several deficiencies with the security model in SharePoint, many of them involving SharePoint groups (you cannot nest groups, you cannot use groups between site collections, et al.) but I'm going to focus specifically on the permission management interface, and how permission assignments are presented to and managed by the site owner.

1. Inheritance Without An Interface

Inheritance Is Good: The SharePoint security model uses a tree-like inheritance structure that is pretty robust and which can conform to most scenarios. Permissions are granted to a site, which then carries down to subsites, to lists and libraries, to folders, and to items and documents.

It makes sense! Let me assign permissions at the top and I don't have to worry about anything underneath unless it has to be different!

What's the Problem: The unfortunate side effect of this approach is that there is no high-level overview of your site's security.

You want to review security throughout your site? Visit the permission management page for your site and you'll only see permissions assigned to the site itself. Presumably that permission carries down to everything else within the site, with some exceptions.

Where are those exceptions? Why aren't they displayed on this page?

SharePoint 2007: In SharePoint 2007 you got a big shrug from Microsoft and a bunch of vendors tugging on your sleeve promising you that they can make security management better if you'll just sign here.

Sharepoint 2010: In SharePoint 2010 the story gets a little better: we'll now get a fat yellow bar at the top of the permission management page, reminding us that this page isn't quite, er, comprehensive. Clicking the link that it quietly offers brings up a list of all lists or libraries that have broken permission inheritance; I call this the unique permissions list.

What's wrong with the Unique Permissions List: While the yellow bar and the unique permissions list are much better than nothing, they illustrate the shortcomings of the permission model, or, at least, of the permission management model. There's no single page that lets you see how permissions are assigned on your site.

You might have dozens of lists with broken permission inheritance, and each one of them will have its own permission management page in addition to the top-level permission management page for your site. The unique permissions list is an index of all the relevant permission management pages on your site, but they must still be accessed and reviewed individually.

Oh, and on the same page as the unique permissions list you'll see a list of all lists/libraries that inherit permissions from the parent site but which just might contain items or folders with broken permissions, but nobody knows for sure. You might think this is a blessing until you realize the implication: none of the lists on the unique permissions list will warn you if permissions on items or folders within them have been broken a third or fourth time. You'll have to manually check every item in every list if you want to know for sure.

Now you can see why administrators and developers have to run scripts to find out what security assignments have been made on a site.

2. Limited Access

One of the more mind boggling concepts to come out of the permission inheritance model is the permission level of "Limited Access."

Where Limited Access comes from: Grant any person or group access to a specific resource--a list/library, folder, or item/document--without granting them access at the container site, and voila! They'll now appear on the permission management page with "Limited Access."

You can't edit their access to remove limited access, or for that matter, directly grant limited access to someone who doesn't have it. You can remove their access entirely at the site level, but this can have unintended consequences.

What is Limited Access: So what is this Limited Access? You can think of it as a flag set on the container (by container, I mean a site, list, or folder)  to indicate that the specified person or group has access to some unspecified resource at a deeper level within the container.

Limited Access is actually a bit more complicated than that, and might more accurately be compared to the "traverse" access that can be granted on a directory in a traditional file system, but the direct, effective permissions granted from an end-user perspective are still zilch, zip, nada.

It does not indicate they have any form of general access to the container itself. So... it's a permission level that grants no permission.

What's wrong with Limited Access: Here's the worst part: if you REMOVE that user's Limited Access at the container level, the user will lose access to any location where they've been directly granted access. Or maybe that's the best part, if your critical permission management scenario is removing someone's access after they've already had it.

In any case, the reverse is not also true; if you remove their access to the specific resource, they will retain Limited Access on the parent site. What devilry is this?!

What else is wrong with Limited Access: So maybe now we get to the real worst part: Limited Access, by being included in the parent site's permissions, is also pushed down to all child resources that inherit permissions from the parent.

If you then break inheritance on some item, it'll keep that Limited Access permission assignment attached to it, even if it makes absolutely no sense and carries no meaning!

For this reason, I generally advise site owners to just IGNORE limited access when they see it, but to never remove it without good reason. Unfortunately this can lead to permission management pages that are cluttered with meaningless Limited Access assignments.

Encouraging Mistakes: In addition to making the permission management page more intimidating, an overabundance of Limited Access assignments makes it much too easy for site owners to make mistakes, either by removing permissions that seem unnecessary or by granting permissions inadvertently.

The classic example is that of the user trying to make her site Read Only by clicking the checkbox to select all permission assignments, then editing them all at once so they all have Read access. While this would be reducing permissions for anybody who had more than read, it is also increasing access for anyone who had only Limited Access before.

This could be especially dangerous in tandem with the SharePoint Publishing Infrastructure feature, which creates a "Style Resource Readers" group with All Authenticated Users inside of it, and gives that group Limited Access on the site by granting it direct access to the Style Library.

3. Grouping of Security Boundaries

One Size Fits All Security: The tree-like structure of the permission inheritance model encourages a monolithic security model.

All lists and libraries that inherit permissions from the site can be managed en masse by managing the permissions of the site itself, so you have one "standard" set of permissions. Everything that does not conform to that standard is considered a one-off deviation, and gets its own permission management page.

What's wrong with monolithic security: You cannot group these deviations together... say, for example, you wanted to have a set of lists to which site visitors could freely contribute, like a survey and a discussion board. No, sir, you'll have to manage the permissions on the survey and discussion board separately.

This may seem like a minor issue, but it has a huge impact on the way site owners understand their sites. Without any way to logically group and manage permissions that deviate from the site's default permissions, more decisions will be made with less knowledge, introducing inconsistency and complexity into the site's permissions.

This can render even the admin/developer permission-reporting scripts impotent, since they'll produce complex reports that cannot be easily explained and summarized.

  • Okay, so it's broken. How do we fix it?

How can we approach SharePoint security management differently to minimize these issues? I believe the most significant impact will come from a different permission management interface.

A good interface for managing security should conform to the following:

  • It should include all broken and inherited permission assignments within a site on a single page, rather than splitting out every broken list/library to its own
  • It should hide the Limited Access permission level assignments to reduce clutter and confusion
  • It should allow lists and libraries to be grouped together into security boundaries based on their permission assignments

It happens I've whipped up something with the JavaScript client-side object model that more or less meets the above requirements!

I'll be providing it as an example in a follow-up post, so stay tuned.

Add comment

  • Comment
  • Preview

Recent Comments

Comment RSS

Post History

<<  July 2020  >>

View posts in large calendar