If you would like to read the other parts in this article series please go to:
- Claims Based Identity: What does it Mean to You? (Part 2)
- Claims Based Identity: What does it Mean to You? (Part 3)
I hope you enjoyed the five-part series that I did earlier this year about the evolution of identity management, called Identity (Management) Crisis. I want to keep exploring the identity management dilemma by addressing some of the more specific implementation of identity technologies.
Over the last few years, you may have run into the terms “claims based identity” and “claims based authentication” and “claims based access control” but what exactly does that mean? Microsoft introduced the idea of a claims based identity model to developers back in the 3.0 version of the .NET Framework, as a way to address the problem of having applications authenticate users who don’t have Windows domain accounts.
As I mentioned in an article I wrote that was published on this site last May, First Look at Dynamic Access Control in Windows Server 2012, DAC relies on claims based authentication. In this two part article, we'll first look at the concept of claims based security mechanisms and in part two, we’ll examine how modern Microsoft technologies take a claims based approach.
Why do we need a new identity model?
Windows already has a well-established system for authenticating users via the user’s Windows domain account. Applications can use Windows integrated authentication to leverage the power of Kerberos. The user logs onto the domain and is authenticated by the domain controller, and is issued a credential called a master ticket. To authenticate to the application, that master ticket is presented and this gets you a ticket from the Kerberos server to the particular service you want to access. That ticket is presented to the service/application to prove your identity.
Think of this real life analogy: You have to present credentials such as a birth certificate or passport, social security card and possibly other documents to obtain a driver’s license or state ID card, which is like the master ticket. The driver’s license is a general form of identification, which you can present to get a more specific “ticket” to use a particular service – for example, to open a bank account. The bank relies on the driver’s license (master ticket) and doesn’t make you show them your birth certificate and social security card every time you want to cash a check. That’s more convenient for you and easier for the bank.
So if this method has been working fine for all these years, why do we need a new identity model in the first place? What happens if you have a user who doesn’t have those original credentials that get the ball rolling? Many years ago in the “real world,” I remember my grandfather telling me about having to deal with that problem. He was born at home so there were no hospital records, and he didn’t drive a car on public roads (just tractors and trucks and other farm implements on private property). He worked on his parents’ farm and back then, didn’t have to get a social security card. So when the time came, late in life, when he needed to prove his age and birth date, he had a problem. The state government ended up accepting sworn affidavits from people who had known him all his life and a handwritten entry in a family bible, and he was able to get his government ID that he needed to get into a hospital program – but not without a great deal of time and effort and frustration.
In the world of computers, you may have users outside your organization who need to access your services, but they don’t have accounts in your Windows domain so they’re missing that first set of credentials on which the Kerberos process depends. What do you do with them?
Today, and even more so in coming years, computing will be all about the cloud. And cloud computing is going to introduce even more complexity into the problem of authenticating users across different organizations and networks. Most of us have multiple digital identities for different applications and services, and the same identity information may be presented to them in entirely different ways. Application developers need a better way to ensure that users can be properly authenticated, and that’s the idea behind claims based authentication and identity.
How claims based identity works
The foundation of claims based identity is, as the name implies, claims. This term is used in this context as a name for what those of us familiar with Active Directory schema might think of as attributes. Once you realize that, it clears up a lot of the mystery surrounding claims based identity.
The dictionary definition of “claim” is “an assertion of the truth of something.” A claim, then, is a single piece of information about an individual user that the one making the claim asserts to be true. A specific claim, alone, might or might not be unique to that individual. One claim would be the user’s name, another claim would be his/her age, another would be his/her gender, another would be his/her role in the organization, and so forth. Claims are not just descriptors, however; the user’s right to access a particular server or file can also be represented as a claim.
All of the claims for a particular user are contained in a security token, which is the complete set of claims information in digital form that is associated with that user.
Security tokens often (but not always) use SAML (Security Association Markup Language), which is built on the XML standard.
Tokens are used to transfer the authentication/identity information between the identity provider and the service provider. The token is created and issued by a Security Token Service (STS), which is operated by an identity provider. Obviously anyone could claim anything, so it’s up to the identity provider to verify and then guarantee that these claims are indeed true. The identity provider’s STS serves as an intermediary between the user and the application or service that the user wants to access. Here’s the process:
- The user requests to access the application or service.
- The application or service sends a request to the STS for a token for that user.
- The STS authenticates the user (for example, via a password or smart card or biometric scan.
- The STS generates the token.
- The STS digitally signs the token and the digital signature becomes part of the token.
- The STS returns the token to the application or service that requested it.
- The application verifies that the digital signature is valid and that it came from an STS that the application trusts (each application will have a list of trusted STSs).
- The application processes the claims information to determine whether to allow the user to access the service or application, and what level of access the user will have.
Advantage of claims based identity
The big advantage of claims based identity is that the burden of authenticating users is moved from the application or service to an identity provider. Because this is the primary job of the identity provider and not just an afterthought, as security often is for application developers, it’s likely that the identity provider will do a better job of vetting and correctly identifying the users and their claims. And the application no longer has to maintain a database of user information or get different pieces of information about the user from different systems. The user benefits because this should also speed up the process of being granted access to the application or service.
For more about claims based identity from the application developer’s point of view, see the MSDN Magazine article titled Exploring Claims-Based Identity by Keith Brown.
This brings us to the obvious question: Who (what entity) is to be entrusted with the task of verifying identities in the first place, and issuing tokens? Within a company or other organization, the company itself can act as the identity provider.
If your organization and another organization have a trust relationship and want users from the two different companies to be able to access resources on both companies’ networks, you can set up a federated identity relationship where your services and applications trust the other company’s STS and vice versa. Claims based identity makes it easy to do this, even if the companies’ networks use different operating systems and authentication protocols. The STS authenticates the users with whatever protocols their companies use and then issue SAML tokens, so it doesn’t matter if one company is using Windows domain networking and the other isn’t.
For accessing resources outside the company, such as public social networking sites, you will generally use providers operated by those sites. Large companies such as Microsoft and Google that operate many different Internet services have moved to consolidate their identity services. This means that instead of having to log onto several different services separately (such as your Hotmail account and your SkyDrive account), you log onto all of them with a Windows Live ID account. Likewise, your Google account gets you into your Gmail, Google+ account, Google Voice and so forth.
The Holy Grail is “one identity to rule them all,” better known as single sign-on (SSO). The problem has been: What entity does everyone trust to serve the role of universal identity provider? Some might trust Google while others would trust Microsoft. Still others might trust neither, but would trust Facebook. Should governments – which, after all, issue “real world” identity credentials – be entrusted with this task?
With claims based identity, an application can explicitly trust multiple STSs – or it can be configured to trust an STS that is trusted by the STS that it trusts. This is like having someone you know vouch for the integrity of someone you don’t know. This is another instance of identity federation.
Claims based identity provides definite advantages to users, application developers and organizations – but how do you implement it? In Part 2, we’ll look at Microsoft’s technologies that use or enable claims based identity.
If you would like to read the other parts in this article series please go to: