SharePoint Authentication: From Classic to Claim-Based (Part II)

Claim-Based Authentication

In a simplistic world, one may think that using a single authentication method (such as NTLM or Kerberos) is sufficed for all the need. For example, a Windows application that doesn’t need much information about its users and that will be accessed only by people inside an organization. It’s true that Kerberos or even NTLM would do well in such a situation. However, reality is rarely this simple. Suppose that you now want to know more about each user than just a simple username and password provided by Kerberos. You will need some way to acquire this information from either Active Directory Domain Service or another source. And what if the application must be accessed both inside the organization and via the Internet? What if you’d like to let users from a business partner to single-sign-on to your application? Obviously you are in need of a more powerful authentication mechanism!

The preferred solution here is to have one approach based on industrial standards that interoperate between multiple platforms and organizations. That solution should also be widely implemented in many products and simple to use. Does it sound too ambitious? Actually, there exists such a solution, and that’s claims-based identity!

Claims-based identity relies on the Secure Token Service (STS) to authenticate users rather than requiring the application to do the job itself. Developers are thereby released from the burden of user authentication. They don’t need to care how the user proved its identity to the STS – with a password, a digital signature, or something else. This also implies that the application can be deployed independent of contexts, a dramatic improvement over the usual situation today.

Figure 3 – Token and Claims

So what is a claim exactly? A claim is, indeed, nothing more than a statement about a user. For example, a claim can contain a user’s name, role, or age. A claim might also indicate a user’s right to do something, such as access a file, or restrict some right, such as setting a bandwidth limit. Multiple claims about a specific user are transferred over the network inside of a token, which also includes a signature from the STS that issues it.

Imagine that a user wants to access an application from his browser. The browser first asks the STS for a token containing claims about the user (step 1). The STS authenticates the user, for example, using Kerberos ticket (step 2) to ensure that the user is who he claims to be. The STS then looks up information about both the user and the application in a database (step 3). Once the STS has found what it needs, it generates the token and returns it to the browser (step 4). The browser then use this token to access the application, providing the information it needs from the claims inside the token. Of course, for all of this to work, the application must trust the STS.

Figure 4 – A user acquiring a token from an STS

Federation Providers

So you may wonder, what happens when the application you want to access doesn’t trust the STS from which you get your identity? Would you be in a hopeless situation? Well, it turns out that even though the application doesn’t trust your STS, it might trust another STS that in turn trusts your STS. This concept is called identity federation, and is very useful. With federation, you still get your identity from an STS as usual, but there’s another STS behind the scene which is offered by a federation provider (FP). The federation provider STS is then configured by an administrator to trust the identity provider STS. This is illustrated in the image below.

Figure 5 – Identity Provider and Federation Provider

The image is pretty self-explanatory. To the end user, the complex authentication process is completely invisible. The user may not even be aware of being authenticated as no explicitly login is required, that is, he’s enjoying the benefit of what’s known as single sign-on. The underlying procedures are actually more complicated, but the core idea is straightforward: the power of claim is extended by the fact that one STS can trust another STS.

Conclusion

This overview has taken us through some of the basic concepts in SharePoint authentication. The topic of SharePoint authentication, however, is much bigger than what can be described here. A good understanding of NTLM, Kerberos and Claim-Based Identity will proved to be critically important to any SharePoint administrator. But as requirements change and new threats emerge, there’s always something out there to keep learning!

References:

1. Claims-Based Identity For Windows – David Chappell

SharePoint Authentication: From Classic to Claim-Based (Part I)

SharePoint Server 2010 is packed with a slew of authentication methods designed to fit into various situations. Though powerful, it also introduces some complexities that can confuse administrators and architects with questions such as “What are the pros and cons of each methods?” and “When should I use claim?”. This article hopes to shed some light on the subject by providing an overview on some of SharePoint’s most popular authentication methods, including the “classic” NTLM and Kerberos and the fancy Claim-Based Authentication with supported for Single-Sign-On scenarios.

NTLM

NTLM is Microsoft’s proprietary authentication protocol used on Windows networks and stand-alone systems. NTLM credentials are made up from a domain name, a user name, and a one-way hash of the user’s password. An encrypted challenge/response protocol helps authenticate a user without sending the user’s password over the wire.

NTLM is the default authentication method in SharePoint, partly due to its simplicity, but it’s also rather limited compared to Kerberos (which is why Microsoft no longer recommends using NTLM in applications). However, NTLM is still widely used today in situations where Kerberos is not supported.

The following steps describe NTLM authentication process:

1. The client sends the user name to the server.
2. The server generates a challenge (a 16-byte random number) and sends it to the client.
3. The client responds by encrypting this challenge with the hash of the user’s password and returns the result to the server.
4. The server sends the following three items to the domain controller:

+ User name
+ Challenge sent to the client
+ Response received from the client

5. The domain controller looks up the user’s password hash from the Security Account Manager database and uses it to encrypt the challenge.
6. The domain controller compares the encrypted challenge it computed (in step 6) to the response computed by the client (in step 4). If they are identical, authentication is successful.

Kerberos

The Kerberos protocol works on the idea of “tickets” that allow devices to safely prove their identity to one another in a non-secure environment. In this protocol, the Key Distribution Center (KDC) plays a vital part as the ticket provider from which all clients obtain their tickets. Clients then present those tickets to the server against which they want to authenticate. Kerberos tickets represent the client’s network credentials.

Here are some of the advantages over NTLM that Kerberos offers:

• Mutual authentication: Kerberos enables the client to verify the server’s identity.
• Delegation support: clients can be impersonated to use their security context to access network resources.
• Performance. Kerberos authentication offers improved performance over NTLM authentication. It is also reported that Kerberos uses less network bandwidth than NTLM.
• Simplified trust management. Networks with multiple domains no longer require a complex set of explicit, point-to-point trust relationships.
• Interoperability. The Kerberos protocol relies on open standards, and is not limited to proprietary codes or authentication mechanisms. As a result, it has much better interoperability with other networks where Kerberos is used for authentication.

The following figure shows what happen when a client issues an authentication request: basically, it contacts the KDC for the ticket which can be use to authenticate at the server.

References:

1. NTLM on MSDN
2. Kerberos on MSDN