Item Level permissions

Item Level permissions

SharePoint has a robust object model supporting security at each level of the farm.  Let’s take a quick tour of some relevant methods and properties around item level reporting.

All securable objects have a method named GetUserEffectivePermissionInfo which is defined in the base class SPSecurableObject. This method returns back an SPPermissionInfo object which we can use to inspect the role definition bindings and corresponding permission levels. SPSecurableObject is imple,eented at the SPWeb, SPList, and SPLIstItem class level, hence how we assign permissions if needed at the site level.

 We can loop through the SPRoleAssignments objects via the RoleAssignments property. This will give us information about how the user is given access to the resource. This returns the Member (the account or group), the RoleDefinitionBindings (permission level). This is an excellent place to start if you are looping through each item.

 Next can look at the RoleDefinitionBindings property which returns back a collection of SPRoleDefinition objects that tell us about the type of access granted.

 Other important properties for reporting security include:

  • HasUniqueRoleAssignments, or the method returing the same thing: get_HasUniqueRoleAssignments()
  • RoleDefinitionBindings: collection of SPRole Definition objects returned.
  • IsSiteAdmin : a property of the user, indicates if a user is a Site Collection Admin ,which includes explicit permissions to everything
  • SPListItem.FirstUniqueAncestorSecurableObject: Retrieves the first unique ancestor if it has unique role assignments otherwise returns the first parent object (folder, list, or Web site) that has unique role assignments.
  • SPItem.AllRolesForCurrentUser

For a more general view of Security permissions in SharePoint, please see this TechNet article.

Library and Folder Security Gotchas

When setting up SharePoint security on sites, libraries and folders, there are quite a few options available, however not all approaches work as expected.  This article outlines some pitfalls to avoid, and best practices to keep your documents safe and sound, and lastly ensure an optimal end-user experience.

Top-down security

By far the best approach is to have the top level sites as open as possible, and gradually restrict access as needed on subsites, then libraries and finally if absolutely necessary folders.  If a library has broader access than its parent site, end-users will not be able to navigate to it.   There are two subtle problems to be aware of when violating this principle:

  • Granting broader access to Document Libraries
    When a user who does not have explicit Read access to a site accesses a document library within it, the browser and MS-Office Client will try to access Site-level information (such as the Document Information Panel, Content Types, Site columns etc) generating unnecessary end-user logon prompts.  Entering credentials will not succeed, although users can “escape” past these logons.  The better approach is to grant broader access to the site, and then lock down all other libraries.  A simpler approach I’ve used is to define a site-collection permission-level called “Site Reader” with access to pages but not documents.  This simplifies granting access and enables end users to navigate to their document libraries when fine-grained permissions are truly required.  Once you start customizing security for more than one document library it is worth asking yourself whether dedicated sites with custom permissions might be more appropriate.
  • Granting broader permissions to a folder
    Newbie administrators often try to grant broader permissions to a folder in a document library.  While the configuration seems straightforward, end-users cannot access the folder to which they have been granted read access.  The only approach that will work here is to grant the users broader access to the document library, then lock down specific folders to keep them out.

Avoid breaking inheritance

Everything within a Site Collection inherits security by default.  There are of course times that inheritance needs to be broken in order to lock down security.  Be aware that every time inheritance is broken it creates administrative overhead going forward, and is an opportunity for end-user confusion.

If you really need to give broader access to a folder, here’s how:

  1. Create a new Permission Level (details below)
  2. Assign the broader set of users to this permission level at the site level.
  3. Find the library where the site page(s) are located.  This is often called “Pages”.  Break inheritance, and add everyone as “Read” to this library.  That way users can view the landing page.

Here’s how to create the “Site Reader” permission level:
At the Site Collection level, go into “Permission Levels” under site security, and create a Permission Level called “Site Reader”, with the following permissions:

  • Use Remote Interfaces
    Use SOAP, Web DAV, the Client Object Model or SharePoint Designer interfaces to access the Web site.
  • Use Client Integration Features
    Use features which launch client applications. Without this permission, users will have to work on documents locally and upload their changes.
  • Open
    Allows users to open a Web site, list, or folder in order to access items inside that container.

Set your folder permissions.  Groups can be helpful, where a group is given the broader folder level access, and also Read access to “Pages” and Site Reader access to the site.

Not pretty, but it works…