Microsoft Sharepoint 2013 Authentication (part 1) - Legacy Approach—Classic Mode Authentication

Legacy Approach—Classic Mode Authentication

I promise I shall keep this section short and not dwell too much on this legacy implementation of authentication. However, it is important to have some background knowledge on Classic Mode Authentication so you understand why CBA is so much better and why SharePoint 2013 no longer supports CMA.

Prior to SharePoint 2010, Classic Mode Authentication was the only mechanism of authenticating users. SharePoint 2007 at least included support for custom membership credentials such that we could store user credentials in SQL databases or third-party systems. Even so, authentication was still the job of SharePoint.

Let us consider a common scenario, implemented for many SharePoint 2007 solutions. Users can authenticate with their Active Directory credentials: when in the office they access the company intranet using their workstation credentials and when at home they access the intranet via a forms-based login. In both cases, the username and password is the same, just the authentication mechanism differs. In the office, users authenticate using NTLM—standard Windows challenge response protocol synonymous with workstation login. When accessing the Internet from home, users enter their credentials into an SSL-hosted form, and SharePoint authenticates these users against Active Directory using a Microsoft Membership Provider component.

Everything seems peachy, but there are a couple of major drawbacks with this implementation:

1. SharePoint 2007 allows only one authentication mechanism per web application (a restriction because SharePoint builds on ASP.NET). Therefore, the implementation consists of a primary web application, using NTLM, and an extended web application, configured for forms authentication.
2. The identity of the user ties to the username of the user—if accessing the site from the office the user has the username DOMAIN\username, whereas accessing the intranet via forms gives a username of Membership-Provider:username.

Perhaps we can overcome the first issue, although it does mean accessing the intranet from a URL in the office different from that outside the office because each SharePoint application requires a unique domain name or port number. I have seen some clever DNS tricks to redirect users to a different domain based on location in the network. This aside, bookmarks become a problem with different URLs because the links you saved in the office differ from those used when accessing the same document or pages at home.

The second issue is more of a deal-breaker—consider how identity mapped to username and authentication method affects services like User Profile Import. User Profile Import maps users with a given username to records in a directory, such as Active Directory or an LDAP system. If we have multiple usernames then the profile import has no way of knowing that each username is that of the same person: we effectively have multiple identities and thus multiple profiles. The problem also surfaces when tracking version history and changes to a document, since this also assumes unique username.

Fortunately for us, SharePoint 2010 introduced Claims-Based-Authentication, and made the world a better place. SharePoint 2010 still supported CMA and we had a choice when provisioning a new web application of which mode of authentication to use. With the release of SharePoint 2013, Microsoft depreciated CMA, and CBA is now the only mechanism for authentication.

Claims-Based-Authentication Approach

Claims-Based-Authentication is a new flexible and abstract approach to user authentication. CBA supports a variety of credential systems, including Active Directory, Live ID, LDAP directories, and any credential store that adopts CBA and federated authentication standards (via SAML).

CBA is composed of a number of components. These components operate in unison to authenticate users per the following high-level process:

1. A non-authenticated user (anonymous user) attempts to access secured content in SharePoint.
2. SharePoint determines available identity providers—CBA supports Windows (NTLM), Membership Provider, and Trusted Claims Provider types. If the application allows for multiple providers, then SharePoint presents the user with a choice to select the desired provider, otherwise SharePoint uses the only selected provider.
3. For Windows and Membership authentication, SharePoint forwards the request to the Secure Token Service, which integrates with SharePoint 2013 on the same server. The request to STS uses the industry standard web service protocol WS-Trust. Requests destined to trusted providers route to the STS of each provider.
4. STS looks up the username in a credential store and verifies the given password with that in the store. In the case of Windows NTLM or Membership Provider, SharePoint uses the built-in STS; in the case of Trusted Claims Provider, the STS might exist elsewhere.
5. If successfully authenticated, the STS returns a SAML token, containing claims about the user’s identity. In the case of built-in STS, the claims returned are limited to details provided by the directory or membership provider.

SharePoint CBA uses the Windows Identity Foundation (WIF), a collection of APIs that provides for creation of claims-aware applications and federated identity.

With the theory part of CBA covered, I will now run through a series of steps for creating a new CBA web application and configuring it for multiple authentication types.