SharePoint 2013: Architectural Trade Offs

Introduction

When planning for deploying SharePoint 2013 based Enterprise workloads, it should be done with the consideration / awareness of impact of various architectural decisions what we make.

As SharePoint 2013 is a flexible platform providing lots of options in terms of configuration of the existing OOB features and development of custom development solutions to address specific business functional needs, care should be taken when making a particular decision and its impact on overall solution.

Even though SharePoint is a matured product, the effectiveness of various business capabilities such as Enterprise Social, Enterprise Search, BI, Document Management, Web Content Management, and Enterprise Content Management that will be delivered based on it, in terms of addressing the business requirements depends on architecture planning.

Effectiveness here means performance, security, up-time and other architectural qualities like Scalability, Reliability etc.

This article analysis “Security”, one of the key architectural “Quality of Service” attribute across the different planning scenarios, usually performed as part of SharePoint 2013 architectural planning activity.

Architectural Trade-offs - Primer

Quality of service attributes are to be analyzed and prioritized during the time of architecture planning to address non-functional requirements of a solution. Not all the attributes carry equal weightage and sometimes there will be situations where planning is to happen based on prioritization. Sometimes, in search of rationale for a decision made, priority can be highlighted

In this article, we will see some of the scenarios in SharePoint 2013 demanding the architectural trade-offs to be made and we will see mainly from the perspective of Security.

More on architectural trade-offs

Enterprise Search

Enterprise Search

When it comes securing the content that is searched, we have various options based on how content sources are secured. If the content items in the content sources are tagged with ACLs (list of users & groups who has at least “Read” access on the content item), it will be applied at the time of crawling and will be embedded into the search index. In some cases, situation may invite custom development at the time of crawling to make sure that ACL info for the content is embedded into the search index so that access restrictions will get reflected in the search results that is generated in response to the end user search query.

SharePoint 2013 BCS / Custom connectors helps in augmenting claims (also called “Security Descriptors” in the BCS context) / ACL info with the indexed objects into the search index. This is called as either crawl time security trimming or early binding. As long as search index has ACL info, SharePoint will depict only those relevant items in the search result, for which a user has access in the content sources.

Other option available is called query time security trimming or late binding, where each item in the search result generated will be checked for access restrictions in the content sources. This will happen in real time in response to the query fired by the end user

Each of these has options its own advantages / disadvantages.

In case of early binding, it will increase index storage requirement due to the need to store ACL information   and also, any change in ACL will not reflect immediately; when there is a change in ACL, index is to be re-processed. That too, when the index is huge due to high volume of content, it will take time for re-indexing affecting the server performance and resources. Also, in accordance to that, there will be latency in the ACL getting reflected in the search result affecting the agility and reliability of the system.

In case of late binding, it will have significant impact on the performance in terms of end user query response. Also, due to real time check of the access restrictions, it will impact performance of the Authentication / Authorization security systems like Active Directory.  But agility of the system will not get impacted as ACL change will reflect in real time on the search result.

Logical Architecture – Web Applications, Site Collections

Different options are available for achieving isolation for security purposes. It can be achieved at different levels such as Web Application, Application pool, site collection, list, document library etc. Web Application provides highest level of isolation and greater security. But at the same time, it will also invite additional resources and hence would impact the performance & scalability of the farm

When no. of web applications is anticipated to grow beyond the supported number, next available option is site collection level isolation. Site collections will not invite resources as multiple web applications. Having more web applications will increase operational overhead and hence results in complex Maintainability

Site, Lists & Document libraries hierarchy planning  

A SharePoint site collection or objects within a site collection (sub-site, lists / libraries, folders, items within a list or library) can be secured by granting permissions to users or groups. By default, permissions will get inherited in site hierarchies from top level (site collection) to the bottom level (an item in list or library) called “Permission Chain”.

In case of a document library, security permissions are shared across all the documents in a document library. If there is a need to share different permission levels to different group of documents, then folders can be used. Permission level of a folder is shared across all the documents of that specific folder. Say for example, if a user / group are assigned a “Delete” permission to folder, it is applicable to all the documents in that folder unless it is broken or item level permission is enforced.

Sometimes this permission chain could be broken (called “broken permission” / “broken inheritance”) based on business requirements and it can happen at four levels: sites, lists/libraries, folders and individual items / documents

Unless there is a governance in place, which provides guidance on under which scenarios permission inheritance can be broken, it will go un-noticed as the site grows into thousands of lists, documents & folders and will result in significant performance issues.

While broken inheritance provides more granular security control & flexibility, it impacts the performance, scalability and maintainability of the system

Authentication Providers – Kerberos & NTLM

We have two options when it comes to Authentication Providers for Integrated Windows Authentication: NTLM & Kerberos. NTLM is default and does not require any special configuration and hence results in less Maintainability.  But it is slower than Kerberos and also does not support delegation of credentials which is required for the usage of the service applications such as Excel services, PerformancePoint services & Visio services.

In case of Kerberos, it requires additional infrastructure & environment configuration for ensuring proper functioning, complicating Maintainability.

HNSC Vs. Path based site collection

Host named site collection allows multiple site collections within a web application to have unique DNS name and it increases scalability as additional resources are not required because of application pools. But when there is a need to have highest level of isolation for security, then additional application pools / proxy groups are to be employed where path based site collection, only path based site collection is to be used.

Wrap-Up

Similar to architectural trade-offs made in any custom built / COTS based integrated solutions, scenarios exists in SharePoint based solution deployment where solution planning / decisions are to be made with the consideration to the impact of different Quality of service attributes.

As SharePoint 2013 provides flexibility at various levels starting from OOB farm deployments such as single tier, two tier, multi-tier to custom development based solutions deployment such as provider hosted , self-hosted & auto-hosted, informed decisions made based on the prioritized architectural QoS attributes will drive towards successful solution deployment and meeting expectations of both business & technology stakeholders.