Claims-Based Authentication and the Cloud

I give up! I can’t really explain how the cloud works unless I cover the topic of authentication in the cloud first. If I didn’t tackle this topic first, I could only explain boring unauthenticated applications. The issue is, for all practical purposes the authentication fit for the cloud is claims based. There is no worldwide active directory you can rely on. There is no single aspnetdb.mdf database. What’s more, there are many kinds of authentications already - Facebook, Twitter, Google, OpenID, Windows Live ID, etc.

Users are fed up with having to remember so many passwords, and yet security breaches are rampant.

The funny thing is, security breaches are almost always the user’s or the IT staff’s fault. It is rarely the technology’s fault. At the heart of security is SSL and the RSA algorithm. How secure is SSL, really? If you were to use 128-bit encryption, it would take you significantly longer than the age of the universe to crack such a key. For an interesting reading on just really how secure SSL is, you should read this article http://www.inet2000.com/public/encryption.htm.

The good news is, claims-based authentication (CBA) is built on the same secure foundation as SSL. There is plenty of RSA encryption and certificates for everyone to go around. Not only is it quite secure, it is also suitable for the Internet, and extremely, extremely flexible. Let’s examine in depth what CBA means to cloud-based applications, and specifically to SharePoint.

What Is Claims-Based Authentication?

The process of establishing your identity is referred to as authentication. Claims-based authentication is the process of establishing your identity by presenting unarguable, trustable, and non-tamperable claims about who you are. For instance, if you saw me outside union station, hungry, begging for five dollars. But you recognized me based on trustable assertions I made about myself - my eyes, hair, height, voice, perhaps I am talking about SharePoint - you’d trust that was me! What I have done there is I have established my identity by providing you claims about myself.

Now, with this identity, you would loan me $5 for a sandwich. But what if I asked for your car keys? You’d probably walk away! Unless of course, I was able to provide you further claims (trustable, untamperable), proving to you that I’m a secret agent and unless you gave me your car keys the world would end. If you were convinced, you’d probably hand me your car keys. This is referred to as the process of claims augmentation. I have augmented my identity by providing you with additional claims about who I am, thereby allowing me an elevated level of access.

Now imagine, I intend to drive your fancy car on an Autobahn in Germany, and the Polizei pulled me over. The Polizei would probably also insist on me establishing my identity. I guess I’d show him my passport. Based on that claim, my identity would be established. What just happened here? The policeman didn’t call the US embassy to verify if my passport was real or not. Plus the fact that a US passport is a valid identity claim in Germany - is a trust relationship that was previously established. So effectively, I was able to authenticate over the Internet (in another country) without an active directory (the US embassy being the domain controller).

In .NET, claims-based authentication is performed using Windows Identity Foundation. SharePoint 2010 uses Claims-based authentication out of the box. SharePoint 2007 can be made to use claims-based authentication. And those fancy tokens (the passport for instance), that are untamperable, and can be easily passed around the Internet - are called SAML tokens. And they can participate in all sorts of protocols. They can work with WS-Federation, or they can be passed using REST-based API using OAUTH. This is what makes them not just suitable, but absolutely essential for cloud-based applications.

Claims-based Authentication in SharePoint

SharePoint 2010 by default uses classic Windows authentication. This means, a web.config with the following:

This is pure ASP.NET-based authentication - it uses either Kerberos or NTLM. I wrote about this topic in a previous CODE Magazine article (http://www.code-magazine.com/Article.aspx?quickid=0909031). The IPrincipal on the server in this case will be a WindowsPrincipal. Put simply, if you’re on an intranet, with the domain controller always reachable, and you have no reason to use claims-based authentication - stick with this for now. There are too many backend systems that do not understand claims-based identities, so when you’re trying to connect to something such as SQL Server Reporting Services using claims-based authentication, you won’t be able to - because SQL Server does not understand claims-based identities.

There is a workaround to this issue though. And that is Claims to Windows Token Service or C2WTS for short. C2WTS can convert Windows-based claims back into WindowsPrincipal identities. This means, you could float an active directory identity across the Internet, bring it back into the AD, and convert it back from claims to a Windows identity. This is what the next version of SQL Server (Denali) reporting services will use. You can, of course, write your own C2WTS. For more information, please see http://msdn.microsoft.com/en-us/library/ee517278.aspx. You should remember, however, that only Windows-based claims can be converted to Active Directory identities. In other words, identities such as Live ID, Google, forms-based authentication, or even ADFS v2.0 cannot be converted to Active Directory-based identities.

Setting up claims-based authentication on SharePoint is quite trivial, and there are many tutorials on the Internet that walk you through it. Specifically, in my book, in Chapter 12, I walk you through how to use simple forms-based authentication inside claims-based authentication. The steps look almost too simple. The reality is that they mask a lot of complexity. Here is how claims-based authentication works in SharePoint.

1. The user requests a resource from SharePoint, but the first request is unauthenticated.
2. SharePoint sends an HTTP 401 (unauthorized) informing the user that the following kinds of identities are accepted. The list provided are the trusted identity providers - security token service (IP-STS) that is previously registered as trusted inside of SharePoint. SharePoint 2010 out of the box has two such identity providers registered - Active Directory, and Forms Based Authentication (membership provider). In order to add more, such as ADFSv2, you can use some simple PowerShell commands.
3. The user then authenticates themselves to the IP-STS and in return receives a security token.
4. The user then does a service token request by passing the security token from step #3 to another STS built into SharePoint, which then fills claims in the ClaimsPrincipal.Claims collection for the user.
5. The user receives the security token response from the SharePoint STS.
6. The user is able to access the resource from step #1 with this service token.

There are two notable things to see here.

1. The user, at the end of all this hullaballoo, is still represented as an SPUser object. In other words, Windows authentication or claims authentication - SharePoint doesn’t care.
2. The login process is really when claims are filled for the user, so the process of claims augmentation in SharePoint cannot be done without a logout/login process.

By: Sahil Malik

Sahil Malik is a Microsoft MVP, INETA speaker, a .NET author, consultant, and trainer, and a well-rounded overweight geek. He has a passion for SharePoint, data access, and application architecture.

Sahil loves interacting with fellow geeks in real time. His talks are full of humor and practical nuggets. His talks tend to get very highly charged, fast moving, and highly interactive.

You should check out his blog at http://blah.winsmarts.com

sahilmalik@gmail.com