Claims-Based Computing and Federated Identity – Part 3

Check other parts:

Claims-Based Computing and Federated Identity – Part 1

Claims-Based Computing and Federated Identity – Part 2

Claims-Based Computing and Federated Identity – Part 4

In this part, i will be talking about the Claims Clients and how they connect to the claims issuer and then to the claims based application.

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.

Browser-Based Applications

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.
  • Issuer asks the browser to go back to the application by returning HTML page to the browser with <form> element with the form-encoded token inside. The form’s action attribute is set to submit the token to whatever URL was configured for the application. The user does not normally see this form because the issuer also emits a bit of JavaScript that auto-post it.


  • 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 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.


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 3

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

  2. Pingback: Claims-Based Computing and Federated Identity – Part 2 | 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