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 & Single-Sign-On with ADFS: Slideshow for SharePoint Saturday Vietnam 3rd

This is the slide that I used at the SharePoint Saturday Vietnam 3rd event. Hope that someone might find it helpful!

The content is about authentication in SharePoint. It comprises of four parts:

• Plan Authentication Methods: overview of authetication methods in SharePoint, also examine two classic authentication methods: NTLM & Kerberos
• Claim-Based Authentication: explains the new authentication mode in SharePoint 2010: Claim-Based. What is it? How does it function? What benefit does it brings? Those are some of the questions that this part wants to answer.
• Microsoft Claim: focuses on Microsoft claim technology and take a brief look at the underlying programming foundation: Windows Identity Foundation (WIF)
• Single-Sign-On using ADFS: how to use ADFS to allow Single-Sign-On to SharePoint applications

Download Link