SharePoint Security: Claims-Aware Options

Authorizing access to content that's held in Microsoft SharePoint is covered in "SharePoint Security 101: What You Need to Know to Secure SharePoint," the first article in this multi-part series covering certain security aspects. To enforce access rights, SharePoint must be able to identify the user who is attempting to access content. Similarly, user identity is crucial in providing services such as the User Profile service: The user's identity controls what they can do with personal homepages and social features.

Authentication is part of the overall process of establishing a user's identity. Ultimately, requesting users presents some form of token to SharePoint to prove who they are. SharePoint then uses this token to associate the user to an internal object (called SPUser), which is subsequently used to authorize access to content.

In earlier versions of SharePoint, this token could be a standard Windows security token, representing an Active Directory (AD) user object or security group, or a token generated by an ASP.NET membership and role provider. Although it still supports classic Windows identities, SharePoint 2010 also supports a claims-based approach to identity, which results in several added capabilities. For example, SharePoint can participate in authentication infrastructures that are not based on Windows, benefiting from ease of identity delegation to back-end applications and a simpler and consistent environment for solution developers.

In this article, I look at SharePoint as a claims-aware application and discuss the options that you now have for authenticating users and providing claims about their identity. You can then use these claims in your back-end applications.

Claims-Based Identity

In the claims world, a user's identity consists of any number of attributes that describe things about the user: email address, full name, groups to which the user belongs, country of residence, and even more personal attributes such as passport or driving-license number. Issuing authorities, such as Active Directory Federation Services (ADFS), that you explicitly trust issue claims about these attributes and their values.

Claims-aware applications therefore have an explicit trust relationship with an issuer. These applications believe claims about users only if the application trusts the entity that issued the claim. And if the application trusts the entity, then the application need not care how that entity authenticates the user or from where the entity gathers the attributes and their values. Therefore, the application does not need any authentication logic within its code. This abstraction of authentication allows the application to work in almost any identity infrastructure, merely processing the claims that are presented to it to establish a user's identity. The trusted authorities that perform authentication are commonly referred to as identity providers or authentication providers.

The notion of explicit trust is important. Without it, claims-based identity systems would be impossible. Your application must decide the authorities from which claims will be trusted. Consider the age attribute. You might trust people to provide their own age if its use within your application is merely for informational purposes; for example, it doesn't really matter whether I enter my real age on my Facebook page. But if the purpose is to verify whether someone is legally allowed to buy alcohol, then you want the answer to come from a more authoritative power—some authority that can verify the answer, such as a birth-registration authority.

SharePoint 2010 is a claims-aware application, meaning that it doesn't really care how the user is authenticated. All it cares about is receiving a Security Assertion Markup Language (SAML) token that provides values for attributes that it can use to determine the user's identity. This distinction allows SharePoint to be deployed in environments that might require more Internet-friendly authentication techniques than a pure Windows system can provide. It also means that you can make changes to the available authentication methods without recoding, recompiling, or reconfiguring SharePoint or any integrated solutions.

One example that is often used for a high-level description of claims-based identity is that of boarding an aircraft:

1. As you approach the departure gate, you present your boarding card—in paper or electronic format—to the agents.

2. The agents confirm that the boarding pass is not a forgery by verifying (via a barcode or magnetic strip) that it was issued by the airline.

3. Because the agents trust the airline, they trust the details (i.e., the claims) such as seat number, name, and flight number that are on the boarding card.

4. The agents authorize you to board the airplane.

You have various ways to physically get your boarding card, such as via online check-in or at a ticket desk. Regardless of how you get the card, you must provide some credentials (e.g., a booking reference, your passport or driving license) to prove your identity before the card is issued to you.

In essence, the boarding card is a set of claims about you that have been issued and verified by an authority that the agents at the gate trust. The agents at the gate don't care how you got the boarding card or, by implication, how you proved your identity to the issuing authority. This is a key benefit of claims-based identity systems: They abstract the whole authentication area (including maintenance such as password management) from the application.

In software terms, the set of claims is called a security token. The issuer signs each token. A claims-based application considers users to be authenticated if they present a valid, signed security token from a trusted issuer. No matter which authentication protocol was used, the application gets a security token in a simple and consistent format (i.e., SAML) that it can use to subsequently determine authorization and permission levels for that user. Ultimately, the application can authorize access to its resources by using any of the claims that the user presents.

Claims-Based Authentication

SharePoint 2010 supports two methods of identifying users. The method that is used is scoped to the web application level.

The first method is known as classic-mode authentication. This method uses Windows identities to identify users and supports only one authentication provider: Windows (or AD). The second method is known as claims-based authentication. This method uses claims to identify users and supports three authentication providers—Windows, forms-based authentication, and trusted identity providers—which can all be used for the same web application. All these providers result in the generation of a SAML token and its subsequent presentation to SharePoint when accessing resources.

There are many reasons why you might need or want to use something other than Windows identities in the environments in which you run SharePoint:

SharePoint 2010 uses the Microsoft Windows Identity Foundation (WIF—formerly code-named the Geneva Framework) to implement claims-based identity. WIF is a set of Microsoft .NET Framework classes that enable the creation of claims-aware applications. Applications that are created with WIF can process WS-Federation authentication requests. WS-Federation is an authentication protocol that builds on two other standard protocols: WS-Trust and WS-Security. WS-Federation supports the token-based authentication architecture that enables a web application to require a security token for authenticated access to resources.

With claims-based identity, SharePoint isn't hard-coded to a specific set of identity providers such as AD and ASP.NET authentication providers, which were the only available providers in SharePoint 2007. Instead, you can use any identity provider that has been designed and implemented in accordance with WS-* security standards. This means that you can use identity providers such as Windows LiveID, OpenID providers (e.g., Google, Yahoo) and ADFS.

But SharePoint actually goes a step farther. As well as accepting WS-Federation authentication requests, SharePoint now also accepts Windows and forms-based authentication requests and converts them into a claim. Such a claim can then be used inside SharePoint to communicate with service applications and to delegate to other back-end applications that support claims. Furthermore, SharePoint also provides the Claims to Windows Token Service (c2WTS), which can convert a claim back into a Kerberos ticket for integration with non–claims based applications.

SharePoint's Security Token Service

To dispatch unauthenticated requests for SharePoint resources to an identity provider, and to convert the returned security tokens into claims (i.e., SAML tokens), SharePoint has its own Security Token Service (STS).

The STS is a Web service that comes into play for any web application that has been enabled for claims-based authentication.

 
Figure 1: STS in action

Figure 1 shows the high-level steps occur when a user attempts to access a SharePoint resource:

1. An unauthenticated HTTP request is made to the URL of the SharePoint resource.

2. SharePoint responds, indicating that the request is unauthorized, and provides the calling application with a URL to go to, to perform authentication. This depends on the authentication providers that are enabled in SharePoint; for example, it might be a redirect to a Windows LiveID logon page. If more than one authentication provider is available, then the URL will be to a sign-in page that allows the user to select the type of identity provider that they want to perform the authentication.

3. The identity provider authenticates the user against the relevant resource, be it AD for Windows, a membership and role provider for forms-based authentication, or a SAML-based system such as ADFS or Windows LiveID.

4. The identity provider returns a security token that is specific to its authentication method.

5. This identity provider–specific security token is presented to the SharePoint STS. The STS verifies that it trusts the issuer of the security token and turns the token into a SAML token, which is suitable for use within SharePoint. (If the identity provider issued a SAML token, then the STS regenerates that token.) Note that the actual attributes in the SAML token depend on the identity provider. At this stage, the SAML token can also be augmented with your own claims provider before being passed back to the calling user. This augmentation is useful in ensuring that claims for other applications, such as a back-end customer relationship management (CRM) application, are already included in the user's list of claims.

6. The SAML token is returned to the user.

7. The HTTP request, with the SAML token attached, is made to the original URL. SharePoint then uses the SAML token to determine whether the user is authorized to access the requested resource.

The SharePoint STS is a Web service called SecurityTokenServiceApplication and is installed on your front-end servers, in the Microsoft IIS website called SharePoint Web Services.

Configuring Claims-Based Authentication

You configure claims-based authentication when you create a web application. Note that SharePoint does not allow you to change the authentication mode (claims-based or classic) through Central Administration after the application's creation. You can use Windows PowerShell to convert from classic mode to claims-based, but not vice-versa; see the TechNet article " Migrate from classic-mode to claims-based authentication (SharePoint Server 2010)" for details. Configuring claims-based authentication is slightly more complex than configuring classic mode because you must also think about the identity providers that you're going to use. Configure these core settings of the new web application process, which relate to claims-based authentication:

1. From the Manage Web Applications page in Central Administration, select the New task on the Ribbon.

2. From the resulting page, select the Claims Based Authentication radio button at the top of the page.

3. In Claims Authentication Types, select the identity providers that you want to support (e.g., Windows, FBA, or Trusted IP).

4. If you specify more than one identity provider, the Sign In Page URL section offers the option of overriding the default sign-in page.

Figures 2, 3, and 4 show claims authentication in action. Figure 2 shows what happens when a user attempts to sign in to a SharePoint site that is set up for claims authentication with both Windows and forms-based authentication (LDAP) authentication providers configured. The home page on the SharePoint site has a Web Part that displays the resulting claims of the requesting user. (This Web Part was written by Steve Peschka, as described in the MSDN article " Claims Walkthrough: Writing Claims Providers for SharePoint 2010.")

Figure 2: Sign-in page with choice of Windows or Forms Authentication 

The differences between the claims that Figure 3 and Figure 4 show can be accounted for by the different IPs that were used to authenticate the user. Even though the same data source (i.e., the same user object in AD) is used for authentication in both scenarios, Windows authentication returns a different set of attributes than LDAP authentication does.

Figure 3: Home page after authenticating by using the LDAP forms-based authentication provider 

Figure 4: Home page after authenticating by using the Windows provider

Flexibility and Opportunities

Claims-based authentication provides more flexible deployment options than classic mode, opening up more opportunity for integration with environments that aren't Windows based. Remember that Windows is a valid claims-authentication provider, so you can use the same Windows identities that you use now for logon purposes and still benefit from the new possibilities that claims-based authentication enables. To help you to decide whether to implement classic or claims-based authentication, I suggest that you read the TechNet article " Plan for claims-based authentication or classic-mode authentication (SharePoint 2010) ."

RELATED:  SharePoint Security 101: What You Need to Know to Secure SharePoint"

Security Assertion Markup Language

Security Assertion Markup Language (SAML) is an XML-based standard for exchanging authentication and authorization data between security domains; that is, between an identity provider (i.e., a producer of assertions) and a service provider (i.e., a consumer of assertions). SAML is a product of the OASIS Security Services Technical Committee.