Claims-Based Computing and Federated Identity – Part 1

 Check other parts:

Claims-Based Computing and Federated Identity – Part 2

Claims-Based Computing and Federated Identity – Part 3

Claims-Based Computing and Federated Identity – Part 4

What was happening before?

Claims are used everywhere and since a long time.

In a single computer, when you type your credentials, the operating system passes claims about you to the running applications on that computer.

As systems become interconnected, a need came to identify a party across different computers and different operating systems, so services were created that would authenticate users and provide claims about them to target applications. Examples are NTLM, Kerberos and PKI.

In NTLM, Kerberos or PKI, identity depends on the use of unique identifier or name. This identifier or name can be used as a directory key to look-up other attributes for that identity. For example, in PKI, the public key is an identifier, and in NTLM, it is the account name.

While those identity authentication models are working and evolving, there are new needs that those identity models do not cover in a proper way, since they are not designed initially with those needs into considerations. Those needs are about cloud computing and identity federation, and more about connecting from devices.

How Claims are different?

Claim based computing is something that still uses those identity models that we talked about, but yet, add another few things and capabilities. Claims-based identity is about controlling the digital experience and allocating resources based on claims made by one party about another. If I was asked to describe claims model, i would say it is separating authentication from applications, so that applications do not care where those identities are stored, and how those identities get authenticated.

Claims model makes the identity and the application loosely coupled. You can change the whole infrastructure that authenticate people ( use smart cards instead of username and passwords), and your claims based application will not be affected. Claims based applications do not care or know if the person connecting is from the corporate inside network or from another partner federated organization. This is because claims based applications consume standardized claims instead of identities.

Claims do not require identifiers

Claims do not need a unique identifiers like other identity systems. We do not need to say that a person is associated with that unique identifier, and then look in a database to see if that unique identifier is married for example. We just say the person is married.

In other identity systems, like Kerberos, the applications will get a service ticket containing the user identity (username or SID), and a list of all group membership, and it can query a database or AD to get many other attributes about that person.

Maybe the application does not need to know about the user’s group membership. All it needs to know is fact that the user is authenticated. In this case, the application gets a lot of information that it does not need.

In claims model, the application will only get an information that the user is authenticated without revealing the username or SID unless the application really needs that information.

Claims protect privacy

This helps a lot when it comes to privacy because one can make claims without revealing the unique identity of that person. For example, the application can get a claim that the person trying to access it, is married and is a good customer, without the application knowing the real identity of that person. This is because claims remove the need of that unique identifier (username or public key). The application will get a claim that the connected person is married and that’s it. The application does not need to know who that person is, and may not or should not be able to get more information about that person in order to access the application.

Trust in claims is explicit

Applications should clearly and explicitly trust the claim issuer, not like Kerberos, where trust is implicit. This is a very important concept.

Claims provides elasticity

Claims can be used to connect organizations and enterprises into the cloud because they are standardized and can be used across platforms because claims can be transform from one world to another using “claims transformers”. That’s because claims offer a single programming interface and end user paradigm.

What is a claim?

If you use NTLM or Kerberos, you think of identity as user accounts and groups. While in APS.NET membership and role provider, you think about user, passwords and roles.

All those authentication mechanism define identity into two different parts:

  • A single notation of claim
  • Issuer or authority

So let us define the term Claim:

  • Claims are a statement that one subject makes about itself or another subject.
  • The statement can be about a name, identity, key, group, privilege or capability.
  • Claims are issued by a provider, and they are given one or more values and then packaged in a security tokens that are issued by an issuer, commonly known as Security Token Service “STS”

 While Integrated Authentication is the way to go in most cases, sometimes you need more than what integrated authentication offers. An example could be an internet facing web application and you want partners to log in using credentials that you do not store. Or maybe you have merged with an organization and you still do not have or do not want to have a AD trust between the two organizations, but still need cross organization authentication pipeline.

Authentication abstraction

Even with integrated authentication (NTLM or Kerberos), there are still challenges, and Kerberos tickets only give you a username and list of group membership. What if the application needs to send email to the user? What if the application needs the email address of the user’s manager? Things get more complicated because now you need to figure out how to get that manager’s email address.

Claims-based identity will factor out the authentication logic from individual applications. Instead of the application determine who the user is, it receives a claims that identify the user along with any other attributes that the application needs.

Also, claims based application won’t break if you decided to use smart card authentication to authentication users instead of username and passwords.

Application and identity are loosely coupled

Claim based applications expect to receive claims about the user, but they do not care about which identity store those claims come from. The user could have a logon account in Facebook, and yet can logon to your application using that identity. Your claim based application will not know or care about this.

Claims concept

The whole idea behind the claims computing model is separating the identity and authentication from the application.

There are two parts in claims computing model:

  1. Claims consumed by the application.
  2. Application should trust a body or an issuer to produce claims. That issuer is also called as Security Token Service STS.

Usually the application that trusts the claims issuer is called Relying Party.

First of all, in order to access the application, the user must communicate with a claims issuer that theapplication trust. The user shall authenticate using any type of authentication available on the STS issuer in order to get a security token. Security token in this context refer to a bunch of claims that the application needs like firstname and email address for exapmle.

The user then will send that security token to the application. The application will open the security token, verifies that the token was issued from an STS issuer it trust, by validating the signature created by the STS issuer. The application now knows for sure that the user had successfully authenticated by an STS issuer that the application trust, and will extract the claims from the security token (example: firstname, email address).

The application does not need to know how the user get authenticated and if he is part of the corporate domain or not. You can change the authentication on the STS issuer to require smart card authentication instead of username and passwords, without changing anything on the application side. Identity and Applications are loosely coupled.


Blog Reference: A guide to claims-based identity and access control – second edition / Microsoft Corporation

3 comments on “Claims-Based Computing and Federated Identity – Part 1

  1. Pingback: Claims-Based Computing and Federated Identity – Part 2 | Ammar Hasayen - Blog

  2. Pingback: Claims-Based Computing and Federated Identity – Part 3 | Ammar Hasayen - Blog

  3. Pingback: Claims-Based Computing and Federated Identity – Part 4 | Ammar Hasayen - Blog

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s