I have been working with a lot of clients since my last post and have come to the realization that security is still a pain point for many when it comes to SharePoint.  The thing that has left the deepest impression when it comes to this topic is the fact “despite everyone saying that security is the greatest concern,” it turns out security is placed as an after thought.  A lot of this has to do with the lack of understanding what security is and how it works.  This post is going to try and give an executives explanation to the following.  For all of you out there on different versions of SharePoint, this is version agnostic, meaning, this can be taken to heart no matter what the version of SharePoint is.

• High level explanation of the SharePoint object model
• Categories of any site you could create in the eyes of security
• Site Collection vs. sub site
• Tie it all together

SharePoint Object Model (High Level)

One thing I have learned working with different level management from directors to your High C’s (CEO, CIO, etc.)  is they appreciate the breaking down of SharePoint objects and what it means to security.  Most people (I know I am one of them are visual) so I have created a image of how the objects related to each other.  See the image of concentric squares below.

Use the image on the left to visually understand what I am going to attempt to explain.  Each box represent an object in the wonderful world of SharePoint.  The larger the box, the larger the object.  The smaller the object… well you get the idea.  The parent child relation starts from the outside and works its way to the inner.  The web application is the only object that does not have a parent object.  The item object is the only object that does not have a child object under it.

What is all this parent/child stuff I am talking about?  That is a good question.  Just like my father, I have dark brown hair.  Looking back at what we learned in junior high science class, I have dark brown hair because I inherited my fathers dark brown hair genes.  In SharePoint, when it comes to security, the child can inherit the exact same security as its parent.  For example, the intranet you go to every day that is on SharePoint has security.  Everyone in the company can SEE the intranet, but not make changes to it.  Only a very few individuals have the ability to make changes to the intranet.  If you created a sub-site underneath the Intranet and told it to inherit the permissions of its parent, that would mean, it would not be just a copy of the permission of the parent, but the permissions of the parent itself.  So the same few people who could make changes to the intranet, will be able to make changes to  this new sub-site.  The same people that had permission to view the intranet, would be able to view this new sub-site.

SharePoint will allow you to change permissions of any object you see in the image of concentric squares.  This in itself is not a difficult concept to grasp, however, it does have other ramifications you should know about that could add complexity on the maintenance of the security over time.  We will get into this when we come to the section “Tie It All Together”  For right now, understand that you can give unique permissions to any object in image to the left.  The largest two boxes, web application and site collection are allowed to have their own unique permission set without breaking inheritance.  The site collection is the smallest object that has its own unique security schema without cutting ties from its parent.

Site Categories in the Eyes of Security

As you can see from the table below, there are four types of sites.  Two of which are almost identical except for the fact one has an expiration date.  (See Team and Project in Table 1)  Please understand, I know these are generalizations and there can be an infinite possibility of permutations and variations of security.

Table 1

Site Collection vs. Sub Site

One of the questions comes up constantly.  Should we use a sub-site or a site collection?  The answer is yes.  There are different times you will use both, both have their own place in the world of SharePoint.  Understand this is from my point of view, through observations that have been made over time at multiple clients that span mom and pop shops of a handful of employees to Fortune 500 companies with over 35,000 employees.  I see things very black and white when it comes to security in SharePoint, and yet have seen and even worked in several shades of grey.  I will try and put a table together of the trades offs on a site collection vs. sub site at the end of this section.

Site Collection

A site collection as you recall from the section labeled SharePoint Object Model, is the smallest object with the ability to have a unique security schema without breaking inheritance.  A site collection is an island unto itself, meaning, there is no way to get to it without a link or knowing the URL.  If one would look at a SharePoint intranet, there could be dozens of site collections beyond the one housing the intranet you may not even be aware of.  Think of it like a cloaked Klingon battle ship.  Unless you know its there, or it lets you know its there with a happy greeting of lasers, phasers and other weapons, it is out of site and mind. Lets face it, seclusion is certainly a strong proponent of security.  Prisons, such as Alcatraz are proof of that.

What does this mean?  In order to ensure a unique security schema for a specific site, the site collection is the best choice.  It will be able to utilize or disallow SharePoint features, allow for a potential non-IT employee to be the owner, have its own recycle bin, its own quota and more.  This being said, the downside to its seclusion is you will need a plan how to allow your casual browsers/employees find the site collection if they lose the link, forget to hit ‘add to favorites’ or delete the email that welcomes them to the site collection.  The navigation is specific to the site collection itself only.  Anywhere outside the site collection including that phenomenal navigation your corporate communications department put together will not be there natively.  Create a feature to force that navigation to be uniform across, build it manually for each site collection, decide to have every site collection utilize its own unique navigation within reason as long as a link is available to go back to the home page of the intranet.   These are the paths that you could choose from.  There is no wrong choice as long as one is made.

Sub-Site

A sub-site is a part of a site collection, the navigation of a sub-site is tied directly into its parent.  You even have the option to use the global (top) navigation of the parent so its uniform.  When first created, you have the choice to dictate if the sub-site is going to share the same security as its parent or break the inheritance.  The sub-site is listed in the View all Contents page of the parent site.  You are able to use several out of box bubble up web-parts to consolidate like item objects in a single view at the parent level.  This is most certainly not available to cross site collections.  I find the time to use a sub-site is when the security is exactly the same or a sub-set of users of its parent site.  For example, I would create a sub-site in the HR department site for the director and CFO.  This sub-site will contain documents, that are so sensitive in nature, only these two by company by-law will allow them to have access rights to them.  This is an appropriate business case to break permission inheritance.

Tie It All Together

Largest Common Denominator

When giving out permissions you want to try and figure out the largest common denominator and give sweeping permissions in relation to that common denominator.  The easiest site to explain this to is your intranet.  The largest target denominator is the site collection that the Intranet (definition of intranet here is all employee facing pages of company approved information in a strictly controlled environment) is contained.  The largest common denominator in this example is every employee of the company must be allowed to see (read-only) all the pages contained within the main Intranet.  Giving permissions easily to achieve this is to add <domain>/Domain Users security group to the Readers SharePoint security group. (read-only)  This covers the largest portion of the population with the needed permission set.  For the few who actually own the content and need permissions to make changes to it will be added (perhaps individually) into the “Designers” or “Site Owners” SharePoint Security groups to obtain that elevated set of permissions.  Simplicity should be the goal, but not the absolute when giving permissions by the largest common denominator.

Inheritance Breaker!

One of the greatest and worst features about SharePoint is the ability for every object you saw in the image above with concentric squares have its own unique security schema.  The thing that has plagued most every company that has had SharePoint up to this point is security when first released was an afterthought. “After all we can just break security and give unique permissions to object X.”  Though that is true there is a price you must pay for every inheritance break that is rarely thought about.  The difficulty for maintaining that security schema increases by N+1, where N = the number of inheritance breaks you can find in a single Site Collection.  As much as I despise underlining to try and force a point, it is absolutely necessary here.  Making the security bend to your will to accommodate your needs is easy, but maintaining it is a much different story.  An example is needed here.  You are working on your team site.  This site has over time become quite large and gone through several owners.  You don’t realize there are 86 breaks in inheritance.  A new employee is added to your team.  They are supposed to have rights to every item in your site collection.  You know of 67 inheritance breaks, so you go to each one and add them manually.  A deadline comes close and the new employee is told to go to a document, but they don’t have rights.  Finding the place where the inheritance was broken to get them those rights become arduous and painful.  Avoid the breaking of inheritance like the plague (as I should avoid clichés like the plague).

That being said, there is ALWAYS an exception to every rule and the one I just told you of not breaking inheritance if at all possible is no different.  There will be times a business case is presented that will deem the usage of inheritance breaking necessary.  The key words in the previous sentence are “Business Case”.  When you have a solid business reason behind the breaking of inheritance, the maintenance issues spoken of in the previous paragraph becomes secondary to the need.

Planning your Security

After I have said all of this, I want to encourage you to plan your SharePoint solution around a Security Centric approach.  This will in the end allow you to have a much more simplistic security schema in place that will in turn allow you to be able to comfortably manage it.  Understand, over time, even the best security schema ever created that even extra-terrestrial beings will come and try to copy, will over time deteriorate.  Security should be constantly in the back of your mind, not your end users mind. (Not that it usually is)