Claims-Based Security in SharePoint 2010

The introduction of claims-based security support in SharePoint 2010 opens up several new doors with respect to managing the user accounts required to establish user identity. User identity is crucial in SharePoint Foundation and SharePoint Server 2010 because it provides the underlying infrastructure for essential services such as security, access control, auditing, and personalization and user profiles.

In SharePoint Portal Server 2003, user identity could only be established using a Windows identity, which forced companies to maintain an Active Directory (AD) account for each individual user. While this constraint was fine for intranet environments where all the users are employees of the same company, it was a painful fit for extranet environments and publicly-facing web sites.

SharePoint 2007 broke the dependency on AD for establishing user identity by integrating ASP.NET support for forms-based authentication (FBA). Today, many companies with SharePoint 2007 environments use FBA and an ASP.NET authentication provider to establish the identity of external users such as partners, vendors and customers. This approach typically involves creating user accounts and managing their credentials in a SQL Server database and removes the requirement to create a new AD account for each user.

Although the new FBA support in SharePoint 2007 was a step in the right direction, it did create a few new problems of its own. First, companies using FBA were forced to either build or purchase a user account management application in order to create new user accounts and to reset user passwords. That’s because the SharePoint platform never has and never will supply a UI or any of the code required to manage FBA user accounts.

A second problem is that companies usually create a separate implementation of FBA support behind each SharePoint farm and each ASP.NET application. This leads to scenarios in larger environments in which there are several redundant FBA databases that all track the exact same set of users. This causes extra work and potential confusion for users as well as the IT department.

SharePoint 2010 provides solutions to these problems with the introduction of claims-based security. The central concept is that a SharePoint 2010 farm isn’t hard-coded to a specific set of identity providers such as AD and ASP.NET authentication providers. Instead, you can configure trusts in a SharePoint 2010 farm and use any identity provider that you’d like. That is, as long as the identity provider has been designed and implemented in accordance with emerging Internet security standards that are collectively known as the WS-* Security Standards. The actual names of these standards include WS-Security, WS-Security Policy, WS-Trust and WS-Federation.

The good news is that there are already quite a few existing identity providers you can use to establish user identity in SharePoint 2010. For example, your company can outsource its identity management requirements to an identity service publicly available on the Internet such as Microsoft’s LiveID or Google’s OpenID.

This gives you the ability to track who your users are for the purposes of security, auditing, and personalization. This approach also lets you avoid the hassles of setting up a user database, storing credentials, and all of the associated password management headaches.

Let’s say you need to create and configure a SharePoint 2010 web application for your company’s public-facing web site. You are required to make this web site accessible using anonymous access, but you also need to make it possible for customers to log into the site to establish user identity. You can configure a trust within this SharePoint 2010 farm to the LiveID service and the OpenID service, then configure the web application to trust both of these identity providers.

When customers attempt to log into your web site, they will be redirected to the site for either LiveID or OpenID and prompted to enter their credentials. After they authenticate against the external identity provider, they will then be redirected back to your web site with an established identity. The best part about this approach is that it can be entirely accomplished through configuration, without having to write a single line of custom code.

Let’s say you work in an enterprise environment which suffers from the problem of redundant FBA databases containing the same set of users. You can leverage Active Directory Federation Services 2.0 (ADFS 2.0) to stand up your own custom identity provider that can be used across many different SharePoint farms and ASP.NET applications. This can provide a strategic approach in enterprise environments to create a centralized repository of user accounts for employees, partners, vendors and customers. In some scenarios this can be done without writing any custom code. In other scenarios, you can quickly adapt the FBA user management code you wrote for SharePoint 2007 with ADFS 2.0 in order to create and manage the user accounts in a far more reusable way.