Claims-Based Authentication Unleashed
Claims-based authentication and claims-based identity are different way to represent an identity and perform authentication inside organizations, in other organizations, and in the cloud. It provides a powerful abstraction of identity that is presented in two parts: notion of claims, and the concept of an authority.
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 identifier 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, 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
Claims-Based Authentication helps a lot when it comes to privacy because one can consume 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
In Claims-Based Authentication, 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 and Claims-Based Authentication can be used to connect organizations and enterprises into the cloud, because they are standardized and can be used across platforms. This is possible 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 on 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.
Claims-Based Authentication provides a powerful abstraction. Even with integrated authentication (NTLM or Kerberos), there are still challenges. 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 due to the abstraction layer.
Application and identity are loosely coupled
Claims-Based Authentication provides separation between identity and applications consuming that identity. 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.
The whole idea behind the claims computing model and claims-Based Authentication is separating the identity and authentication from the application.
There are two parts in claims computing model:
- Claims consumed by the application.
- Application should trust a body or an issuer to produce claims. That issuer is also called Security Token Service or STS.
Usually the application that trusts the claims issuer is called Relying Party.
First, to access the application, user must communicate with a claims issuer that the application trust. The user shall authenticate using any type of authentication available on the STS issuer to get a security token. Security token in this context refer to a bunch of claims that the application needs like firstname and emailaddress for example.
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 trusts, 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.
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.
Claims Issuer Concept
Claims-Based Authentication is built on the concept of an issuer that construct claims. Active Directory Federation Services (a.k.a ADFS) is an example of claims issuer. It can authenticate users with Kerberos, forms authentications, or certificates. Or you can configure your ADFS to accept a security token from an issuer in another realm as a proof of authentication. This is called identity federation.
Let me explain what is happening here. You have a claim based application that needs to know the user firstname, lastname and perhaps the user’s emailaddress. The user will try to connect to the issuer (ADFS) to get those claims packed inside a security token. The issuer will authenticate the user, connect to many sources like Active Directory, AD LDS, or perhaps a relational database, to gather that information. Once authenticated, that issuer will create three claims, one for the user’s firstname, one for the lastname and one for the emailaddress. It will then package these claims inside a security token that is signed by the issuer’s private key, and will send the token back to the user.
It is also interesting to see how the ADFS connects to many sources to gather information. ADFS can be extended to add other stores of information. By doing this, ADFS hides the fragmentation of data it collects from different sources. Your claim based application will not break if you decide to move data around between sources that way.
Note: In identity terms, a realm is the set of applications, URLs, domains, or sites for which a token is valid. Typically a realm is defined using an Internet domain such as microsoft.com, or a path within that domain, such as microsoft.com/practices/guides. A realm is sometimes described as a security domain because it encompasses all applications within a specified security boundary.
In Claims-Based Authentication, each application may need different types of claims. A certain application may need only the firstname, while other may need the firstname and emailaddress.
Saying that, applications consuming claims should know many information about their claims issuer like:
- What claims does the issuer offer?
- What key should the application use to validate the signatures on the issued token? (that is the public key of the issuer)
- What URL must users access to request a token from the issuer?
All those questions can be answered by asking the issuer for federation metadata.
This is an XML formatted according to the WS-Federation standard that the issuer provides to the application. It contains:
- The issuer public key.
- List of claims the issuer offer.
- URL to get security tokens.
If the issuer public key used for signing is changed, the application should query the federation metadata again.
Issuer should know about the application
In Claims-Based Authentication,the issuer needs to know the following information about the application:
- What URI defines the application?
- Of the claims that the issuer offers, which ones does the application require and which are optional?
- Should the token be encrypted? And if yes what key should be used?
- What URLs does the application expose to receive the tokens?
Establishing trust between the application and the issuer (STS)
With Claims-Based Authentication, there should be a trust between the application and the issuer. The application creates this trust by querying the federation metadata, and the issuer trust the application by defining the application as a Relying Party.
The application adds the trust information on its web.config, and the ADFS (as an example of STS) will store that information on its database.
The figure below refers to the relying party as RP. Both the application and the STS have sort of federation metadata that should be exchanged. The most interesting part is that the STS should communicate its public key to the application so that the application can use that public key to validate signed tokens. If the application requires that tokens should be encrypted, then the application will need to exchange its encryption public key to the STS so that the STS can use that public key to do the token encryption.
In that case, if the token should be encrypted, the following cryptography operations will be performed on the STS:
- STS issues a security token. It uses its private key to sign that token.
- STS will encrypt that token with the application’s public encryption key.
- The application will use the STS public key to check the signature and make sure that it is signed by a trusted body.
- The application will use its private encryption key to decrypt the token and get the claims out of it.
Claims-Based Authentication Clients
If you think of the way claims clients should work, you will definitely know that the whole objective is to communicate the token from the client to the application in a secure way.
There are two types of claims clients:
- Browser clients (passive nature) :
- Based on WS-Federation Passive Requestor Profile.
- Uses browser redirects, HTTP GET/POST.
- Non browser smart client (active nature)
- Based on WS-Trust and WS-Federation Active Requestor Profile.
- Smart clients can be Windows-based applications or services such as WCF services.
- WS-Trust: describes how to get security token from issuer
- WS-Security: describes how to pass that security token to a claims-based web service.
- WS-Federation: a protocol that is built on other standard protocols like WS-Trust and WS-Security, and it helps requesting security tokens in browser-based applications, among other things.
- Windows Identity Foundation WIF: .NET classes used to build claims-aware apps.
In this section, I will cover the browser as a client consuming claims in such Claims-Based Authentication.
Step 1: Redirect to issuer
Browser access the application and get redirected to the issuer logon page (HTTP 302) with many query string arguments that act as an instruction to the issuer. Those query strings are:
- Wa: stands for action and indicates weather you are signing in (wsignin1.0) or signing out (wsignout1.0)
- Wtrealm: target realm and contains the URI that identifies the application.
- Wct: time stamp
- Wctx: context data such as return URL
Step 2: Issuer
- The issuer then will try to authenticate the user. This can be a form to type your credentials in, or empty page that is configured in IIS to require Integrated Authentication or smart card authentication.
- The issuer will use the information in the wtrealm query string to identify claims for that application.
- The issuer will generate security token (SAML token).
- The SAML token will be signed with the issuer private key.
- If the application wants its tokens encrypted, the issuer encrypts the token with the public key in the application’s certificate.
- A standard HTTP redirect cannot be used because the token may be 4 KB long, which is larger than most browser’s size limit for a URL. Instead a <form> that includes a POST method is used.
- The issuer may issue its own cookie so that users remain logged on at the issuer and can access many applications. Think about how this works—when a user visits a second application and that application redirects back to the same issuer, the issuer sees its cookie and knows the user has recently been authenticated, so it can immediately issue a token without having to authenticate again. This is how to use claims to achieve Internet-friendly single sign-on with a browser based application.
SAML response (a.k.a Security Token) received from the issuer contains:
- Creation date.
- Expiration Date.
- Token Audience (URL for the application).
- SAML restrictions and conditions.
Step 3: Redirect to application
- POST arrives at the application and WIF takes over.
- The Application has a WIF HTTP module named WSFederationAuthenticationModule (FAM) to intercept the POST
- FAM listens for AuthenticateRequest events and do the following:
- Verifies the token signature
- Extracts the claims in the token and uses the User.Identity property to present IClaimsPrincipal object to the application.
- Issues a cookies (Session tokens) called FedAuth[n] that contains the ClaimsPrincipal object with any other attributes in a compressed and encrypted form.
- On subsequent requests to the application, the SessionApplicationModule intercepts the cookies and uses them to reconstruct the ClaimsPrincipal.
Non Browser-Based (Smart Clients)
In this section, I will cover non browser clients consuming claims in such Claims-Based Authentication.
In smart clients, the client will try to get a token from the issuer before contacting the application, while in browser based clients, the browser will visit the application first and then get redirected to the issuer for token requests.
- The application’s web service is configured with wsFederationHttpBinding that specifies a policy requiring the client to add a SML token to the SOAP security header in order to invoke the service.
- Client sends RequestSecurityToken RST to the issuer.
- Then the issuer sends back the response (RSTR), which includes a signed security token that is encrypted with the public key of the web service. The token includes a proof key. This is a symmetric key randomly generated by the issuer and included as part of the RSTR so that the client also gets a copy.
- Mainly everything later is the same as the browser client.