Planning for Externalizing Authentication in SharePoint 2010: Part 1 – Introduction

Since the beginning of 2011, I’ve had the good fortune of being involved with several projects involving the claims authentication capabilities introduced in SharePoint 2010. The scope of these efforts have ranged from small proof-of-concept demonstrations to large Internet and Intranet production deployments. Some involved custom built Security Token Services (STS) and others relied on vendor-provided products like ADFS 2.0 and Ping Federate. As a sort of unofficial evangelist for this sort of thing, I’m impressed with how architects and developers, both from our consultants here at PointBridge and with our customers, have embraced the concept. In pretty much every case, we had a slightly different problem to solve and the technology has enabled us to deal with it in a straightforward way. Folks out there are “getting it” and I’m looking forward to helping advance this technology even further as we begin the new year.
So I thought this would be a good opportunity to share what are in my mind the key planning considerations when opting to use this approach for authentication. Note that for the purposes of this writing, when I say “externalizing authentication” I’m really talking about what Microsoft refers to as using “SAML claims”. In other words, using some sort of external STS (like ADFS 2.0 or Ping Federate) that issues tokens to be consumed by SharePoint for authentication.

What Do I Need to Plan For?

This can quickly become a pretty large and technical subject to discuss, so I’ll break this blog series into the main planning areas that I see need to be addressed:

1. Authentication and Authorization: Identity Providers, STS, SAML tokens, claims, custom claims provider, web applications, zones
2. Session Management: Token cache, sliding sessions, cookies
3. Functionality: Custom controls and pages, Office integration, search
4. Operations: Support processes and documentation

Note that in this series I won’t be covering much regarding the specifics for configuring external authentication for SharePoint 2010. That’s already well covered in previous posts I’ve written and also the following Microsoft whitepaper: Implementing Claims-Based Authentication with SharePoint Server 2010. Additionally, the recently released 2nd edition of “A Guide to Claims-Based Identity and Access Control” is pretty much required reading for anyone looking to get involved with this technology. My focus is going to be on what we’ve seen out there in the “real world”.

Before starting, have clear design objectives

Externalizing authentication will force your team to solve some things that are taken for granted when using traditional Windows-integrated authentication. Additional investments in time for development, testing, documentation, and operational procedures will be required to to ensure short and long term success. Therefore, I believe a strong justification for this approach is required. Externalizing authentication could be a good choice if the organization:

1. Requires Single Sign On (SSO) or Web Sign On (OpenID, Facebook, Twitter, Google, etc…) with vendors or customers. Because SAML is “standards based” and provides a very high degree of interoperability, this is a common justification.
2. Is undergoing a lot of transition with its directory services (acquisitions and migrations) and doesn’t want to be limited or held back by these changes. Externalizing authentication to a single “identity tier” creates a façade that enables SharePoint projects to move forward without being held hostage to other organizational initiatives.
3. Does not have a centralized identity infrastructure and never will. It operates more as a federation of entities and interested parties and still wants to take advantage of SharePoint as a collaboration platform.
4. Wishes to expose SharePoint 2010 to mobile devices.
5. Requires one of more of it’s SharePoint sites to work like a banking banking site with automated sign-out during idle times and doesn’t have expertise to accomplish this at the gateway (firewalls / reverse proxies).
6. Is looking to consolidate its web tier assets under a single identity infrastructure and enable more interoperability between applications. Claims authentication is fully supported in ASP.NET and Windows Communication Foundation, including REST web services. For obvious security reasons, this makes sense to standardize under a single authentication and authorization scheme, especially one that is as flexible as the various SAML-related protocols out there (WS-Trust and WS-Federation).
7. Is making a commitment to “the cloud”. Because claims authentication fundamentally works with the web, it can be used to tie together on- and off-premise applications in a seamless manner. And this goes for SaaS solutions like Microsoft Office 365, which utilizes ADFS 2.0 to achieve SSO with your local instance of Active Directory.

These are just a few common examples….and in most cases more than one scenario would apply to a given project. I mention all this because I believe it’s important to always “keep an eye on the prize” when fighting through all the details and nuances that externalizing authentication requires.

So….does it work?

I get this question a lot. The short answer is: “Yes, but with some effort”. We here at PointBridge have several customers in production today using SAML claims – with some implementations going pretty deep into the search and collaboration features. But as I mentioned above, a successful result may require implementing a series of customizations to SharePoint; some of them minor and others more substantial. For example, the reality is that any production-quality deployment is going to need to implement a custom People Picker to resolve what the user enters to something real (a group or user account in AD, LDAP, or SQL). That’s not available out of the box and will require code. Fortunately, there are great examples out there on the ‘net to get you started.
SAML claims requires each user to have an attribute that uniquely identifies the account. Your team will have to take a hard look at the Identity Provider (Active Directory in many cases) to ensure this attribute exists and is 100% populated (and standardized). If the attribute involves a given name or surname, you will need to call out processes to handle name changes. An unhandled name change will result in a new user account in SharePoint and a whole lotta confusion for all parties involved.
Depending on your level of sensitivity to the end-user experience, you may find you’ll need to customize several SharePoint administrative pages such as the default “Access Denied” and “Request Access” pages, which by default expose the unfriendly claims identity of the end-user (example: 0e.t|externalprovider|joe.user@corpdomain.com). You may also find that you’ll need to update extra controls such as the “Sign Out” and “Sign on as a different user” components in the Welcome Menu control.
If your environment is going to support document management functionality, your team will need a solid understanding of the relationship between session cookies and the various versions of Microsoft Office.
Search (both FAST for SharePoint and standard search) will require that your web applications have a specific zone configuration so that content can be indexed. This configuratio
n may drive other “fixes” to ensure automatically generated links such as workflow task alerts point the the URL you want your end users to see.
Out of the box, tokens for authenticated sessions are stored in memory on each Web Front End. If you’re working in a multi- WFE farm topology and don’t have sticky sessions available…or your system has any sort of vulnerability to unplanned app pool recycles (which is probably everybody 🙂 ) , you should consider implementing a persistent token cache as opposed to relying on what Microsoft gives you.
And there are a couple of things you’ll have to give up. The Document Preview functionality in FAST for SharePoint is one of them.
Almost all of these things can be addressed….and I’ll cover that in future posts in this series. My point here is you should look at the advantages SAML claims brings to the table versus any risks and costs associated before jumping in. Obviously, this sort of evaluation is necessary for almost any newer technology and externalizing authentication is no different.