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.
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.
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.
Architectural Trade-Offs QoS Attributes
Security, Performance, Agility, Maintainability
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
Security, Performance, Maintainability
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
While broken inheritance provides more granular security control & flexibility, it impacts the performance, scalability and maintainability of the system
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.
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.
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.