Introduction to Claims-based Authentication in SharePoint 2010 in plain English

Introduction

There is a lot of hype about claims based authentication, and unfortunately a lot of confusing jargon.   My goal in this post is to explain what claims based authentication means in plain English. This includes what it enables, and what it doesn’t enable. I am going to try my hardest not to use any technical terminology beyond the bare minimum.

What is authentication?

Authentication is the process of determining if someone is who they claim to be. It answers the question “Who is this guy really?”

In the Microsoft world, authentication is usually performed by Active Directory.  I claim to be Tristan, and i prove this to Active Directory by providing my password. Other systems don’t trust me, they trust Active Directory. Active Directory gives systems a bit of data that says “yeah, I personally vouch for this guy. It really is Tristan.”

Now, if everyone used the same Active Directory installation in the same environment, then that’s all we would need. Claims based authentication is not needed in a simple environment like that.

But in the real world, things are different. We face three big challenges:

• Privacy regulations and other pieces of legislation are impacting what kind of information we are allowed to capture and store about users, so in some cases we can’t just demand that people give us all of their personal details.
• Businesses want to interoperate with other businesses, and government organisations want to provide more integrated services to citizens. However, different systems use different authentication systems (not everyone uses Active Directory, and even when they do, they have different instances.), and businesses want to integrate in a secure, legally compliant manner.

What does claims based authentication do?

Claims based authentication is designed to address the two challenges mentioned above.

Claims based authentication addresses privacy and other compliance concerns by requesting less specific, less personal information about people, and by trusting other parties or systems to do the “proof of identity” check.

Imagine you have a “sell alcohol to public” ecommerce website, and you are in a country where there are only two laws, called Fantasyland. One of these laws says “alcohol may not be sold to people under 18”, and the other law says “people have a right to privacy and web sites aren’t allowed to track individual people”. (If the law was this simple in real life we wouldn’t need lawyers!)

We’ve got two competing concerns here. Firstly we need to ensure that a user is of legal age, while at the same time we’re not allowed to know who that user is! (Again, I blame the lawyers of Fantasyland).

It turns out that in Fantasyland, the Government has set up a web service that users log on to, which authenticates them based on their citizenId and citizenPassword. It then is able to tell other systems that a user is above 18 or not, without revealing who that user is.

So we implement our “sell alcohol to public” website by building a claims-aware system. Instead of building the standard “username and password” login mechanisms, we simply ask the Government’s web service to tell us if the user browsing our site is over 18. The claim that our system uses is a “userIsOver18” claim, and the claim value is either yes or no. We simply don’t build any authentication system at all beyond a simple “if (userIsOver18) then..“ statement.

By doing this, we address privacy concerns – we don’t know or keep personally identifiable information – while at the same time ensuring that we don’t sell alcohol to someone under 18.

Claims based authentication addresses integration of different systems by allowing communications using open standards, and by providing a platform for developing more specialised ‘identity connectors’ between systems.

What won’t it do for me?

Claims based authentication won’t address the lifecycle management of identity information. You’ll need a broader solution to that, but your solution may integrate with claims based authentication systems. How do you deal with new staff? How do you handle staff who are on long service leave? How do you handle fake accounts? Microsoft would like you to use their Identity Lifecycle Management application for this kind of thing.

I’m going to be a little controversial here, and point out what I believe the biggest limitation of claims based authentication. I believe that what enterprise customers really need is claims based authorization.  Claims based authentication may let our system know that a user is a contractor from a partner company, but it alone won’t let me specify a rule that says “all of my company’s financial spreadsheets must not be seen by contractors”. Not only does claims based authentication not provide this capability, but neither do the role-based access controls provided by SharePoint. In fact SharePoint’s role-based access control model itself is too limited to address this. It still needs substantial improvements.

The way industry is addressing this is by producing “entitlement management” systems, for specifying access control rules. Microsoft’s current solution, in my opinion, is strongly deficient in this regard. Yes, you can specify per item permissions for each individual financial spreadsheet. But this imposes such a high maintenance overhead that it is unworkable in practice. In my opinion companies like Oracle are well ahead of Microsoft in this field, but by no means does anyone have a complete turn-key solution.

How is it implemented?

The claims-based authentication implementation has a number of components. In simplified terms here’s how the pieces of technology fit together.

• From a developer’s point of view, the platform that Microsoft is providing is called the Windows Identity Foundation. This used to be called the Geneva framework. It provides a programming library suitable for building claims-aware applications. This library is also used by SharePoint 2010.
• Active Directory Federation Services implements services to create, accept, and transform tokens that contain claims.
• Cardspace provides a user interface for users to select which “identity card” they wish to use for a particular system

Next article

In the next article I will go into more detail about the implementation of Claims-based authentication in SharePoint 2010. Let me know what you thought of this article, and if you'd like to see focus on any particular aspect.