The IT Leader's Guide to Multicloud Readiness
This guide provides practical key insights and important factors to consider to make informed decisions in your multicloud journey.
Download the Guide
If you’ve used claims with SharePoint 2010, you know that it can be incredibly frustrating to work with. Setting it up is only half the battle. When you want to interface with it either via web services or your own client applications, it can quickly become a nightmare. In addition, you had to make sure that you always sent the user to the same server even though your farm is load balanced because of how the internal authentication model worked in previous versions of SharePoint. Search didn’t support non-NTLM claims, etc. All of this helped hinder the adoption of claims and the holy grail of end user security it helps enable: single sign-on.
Fortunately, SharePoint 2013 has addressed a lot of the issues that people had with authentication and claims specifically. This is a good thing since claims is the default authentication scheme of SharePoint 2013. For a quick hit on what’s new with claims, check out my previous blog post: SharePoint 2013 Claims: Your New Best Friend.
Here in this three-part series, we’re going to check out some of the coolest new features that SharePoint 2013 has out of the box and look at how you can leverage them going forward.
Distributed Cache Service
In SharePoint 2010 and previous versions of SharePoint, authentication happened at the server level within Internet Information Services (IIS). The authentication cookie was tied to the server (often as a session cookie) and if you jumped to a new server you had to log in again. In a load balanced environment, this required “sticky sessions” where the load balancer had to remember where it had sent you previously within the same session so that you didn’t have to log in again. All of your SharePoint requests had to go to that server (images, pages, etc.) instead of being actively load balanced.
With SharePoint 2013, Microsoft has included a customized version of Windows App Fabric (code named Velocity) that’s implemented in SharePoint as the Distributed Cache Service. Think of it as a second layer of cache that’s managed in SQL/process and is shared across servers in a farm. SharePoint takes advantage of this service in quite a few ways, specifically through user profiles and authentication.
For user profiles, it enables everything to be “in sync” and have minimal visible POSTs back to the server. Instead, the browser POSTs to the distributed cache and returns quickly because the distributed cache is resident in server memory. The data doesn’t have to be persisted to the database. Behind the scenes, a process is doing the persistence from the distributed cache to the database, but the browser doesn’t’ have to wait for it. This drastically improves responsiveness.
For authentication, it means that the authentication information exists above the IIS Cache level (see diagram). So you can move from server to server with ease without being redirected to the login page. This allows your load balancers to actively balance the load of all requests. So you could get the page you requested from server A, but all of the images may come from server B. The end result is a faster response and a healthier, more balanced SharePoint farm.
If you have the 3-server farm described above, each server has its own IIS Cache. This cache is not shared across servers, even if you back it with a SQL table. This makes sharing state nearly impossible across servers in an application farm. Microsoft recognized this and created the Windows App Fabric functionality as part of Windows Azure to make sure that cloud-based applications could interact properly regardless of the server the user hit.
They have since ported a specialized version of App Fabric to SharePoint 2013. That’s very important to recognize. App Fabric in SharePoint 2013 has been specifically customized by Microsoft. This means there’s no configuration necessary for it to work correctly and you can manage the service on each server directly from Central Administration. By default, it’s enabled on each server and there’s very little reason not to leave it enabled unless you have a single-server farm.
Another cool aspect of App Fabric is you can use it directly from your code! So aside from making login easier and allowing load balancing to be more robust, you’ve got another level of cache that’s farm-wide aside from the Hierarchical Object Store that you can use.
Stay tuned for part II where we look at Open Authentication (OAuth) and Client Tokens.
lets say i have multiple WebApps:
will the FedAuth Cookie be shared across WebApps?
No further Browser redirect after the User hits one WebApp?
Thanks for the question. Unfortunately, the way that cookies work means that the FedAuth cookie for App1.example.com is not valid for App2.example.com. So when you try to access the second site, you’re going to get redirected through the authentication cycle. There’s no way around that. If you’re using an Identity Provider in SharePoint (like ADFS) for both web apps, then the redirection will be painless because the user will bounce through the IDP’s authentication process (the IDP authentication cookie is still valid).
I suppose that, in SharePoint 2013, you could leverage the Distributed Cache to circumvent the cookie limitation through session cookies and some clever code on the SharePoint authentication page (essentially accepting the same FedAuth cookie), but I do not recommend it.