Site security: secure down or secure up?

I’m sure most of you are aware of how flexible SharePoint is in terms of securing content. There are several permission levels that can be created. Users can be assigned to a group, or directly to a particular permission level. And you can grant people permissions to nearly all artifacts within SharePoint, from the site collection down to the individual document or list item. So with all this flexibility, there are often several ways an organization could secure a certain solution on top of SharePoint. That’s the beauty (and sometime challenge). It’s important to understand the long-term implications of choosing a particular architecture or design.

So with this in find, there is often a could and should viewpoint on a SharePoint solution. A customer of mine recently emailed me a great example of a solution that could be implemented in one of several ways. This is a common scenario where a typical SharePoint site is in use by a team but then the site owner needs to share a small slice of that content to a particular group of people (that don’t and shouldn’t have read access to the rest of the site). More details are written up below (big thanks to my customer – I love working with people who can lay out the scenario and layout the steps to reproduce, what they expected, and what actually happens. This helps a ton!)

A site (collection) owner decides to create a library in their site that is to be accessible to an audience other than the Members and Visitors of the site.  She creates a custom group, and places the desired users into it.  At this point, this group has access to nothing in the site (i.e., no selection is made from the listed Permission Levels of the New Group form-page).  Now she goes to the library and alters permissions on that to allow the custom group to have some level of access to it (the degree of access doesn’t matter here).  At this point, the group has access only to that library, and nothing else in the entire site.  This is precisely what the owner wants.  She doesn’t want them even seeing the homepage or any other content in the site; just the one library.  And she provides the library’s URL to those users, via email, so that they can jump directly to it.  All good, so far.

Now, one of those users follows the link in the email and finds themselves at the list or library.  But because of the amount of content there, let’s say, the user can’t see what they’re looking for.  So they resort to the search function, using a search term that they know is associated to the item they’re looking for, and using either the This Site: or This Library: search scope.  Instead of seeing the search results page, they see Access Denied.  …Problem!

This is because the members of this custom group only have access to the one library and nothing else in the site…including the site’s own search results page (_layouts/OSSSearchResults.aspx).  However, the site owner cannot set permissions on that page, to give that group read access to it –it doesn’t reside in the site.  The only way to give that group access to the search results page is to give them read-access to the entire site, but that lets them see content that the site owner can’t allow them to see.  She could alter permissions on all the other lists in the site to revoke that group’s access (YUCK!!), but she can’t hide the homepage from that group, since she doesn’t have access to that file either.  (It’s not a Publishing site, so the default.aspx page does not reside in the site’s Pages library.)

From my perspective, this is a design flaw in the product.  It seems to me that the search results page that each Team site has should be accessible by all authenticated users, or to all users listed through the site collection, and let permissions on the content determine what appears there.  That would resolve the problem with this scenario.

A different approach

First of all, I can definitely appreciate the scenario, and how a site owner could head down this path. You CAN take the approach described above where security is set fairly tight at the top level but then becomes more open as you go deeper in the SharePoint containment hierarchy. SharePoint doesn’t block you from doing this. BUT as a general recommendation I’d suggest doing the opposite, for exactly the described issues. Certain resources or services are provided at the site level so if you make security too tight on the site and try to open it up then you run into strange behaviors (beyond just the scenario described above). 

What I typically tell site owners is that securing at the site and then making it less restrictive with a document library is similar to locking a file cabinet and then giving access to one specific file folder in the cabinet. A colleague of mine in Chicago gave the analogy of dropping a user on a desert island. The user can get to that island of information (in the case above a document library) but they have no idea how they got to the library and no clear option for navigating away from the library. I really like this analogy. It highlights how this is a really bad user experience, in my opinion.

So I’d propose a different approach. Here are a few options:

Option 1: The site owner could give these users visitor perms on the site and secure other lists and libraries. This works when the number of lists and libraries is only a handful. Otherwise, it can be very tough to manage. If you have 20 libraries and 20 lists, this is a pain. But if you are set on keeping it all in one site and allowing for search this is the best bet. And these ‘restricted’ users could still have access to the main page. Content would be security trimmed and you could use audience targeting as well.

Option 2: Create a sub-site. This is very easy to do and generally a much better experience for end users. This is my favorite option. I think this is a better option long-term in terms of both management and user experience.

Option 3: One final option that I proposed (but didn’t seem to work in my testing) is to tweak the permission levels to give these ‘restricted’ users access to application pages.

Hope this helps as you think through your site design!