Alice in Claims: protocols


This is the third post of a series about claims based identity management and the Windows Identity Foundation (WIF).

The first two were:

The previous post presented the claims model, namely concepts such as identity provider, identity consumer, claims and security tokens. In this one, we will describe some of the protocols available for the communication between providers and consumers, namely for requesting security tokens and exchanging them.

Passive protocols

The following figure shows a typical interaction between the Identity Provider (IdP) and the Identity Consumer (a web app), when the user agent is a browser without javascript code (passive client).


  1. The protocol begins by Alice’s browser making the initial HTTP request to the web app.
  2. Since this request does not contain any identity information, the response is a redirect to the IdP. Alice’s browser fulfills this redirect by sending a GET request to the IdP. The redirect target URL contains information contextualizing the request, namely the identity of the requesting web app.
  3. After this request, typically there is an interaction between the IdP and Alice’s browser with the purpose of authenticating the user. For example, the IdP may respond with an HTML form for username+password authentication, which is followed by a POST containing this information, sent by Alice’s browser. This interaction may also include a step where the IdP and Alice agree on the issued claims, which is useful when Alice wants some control over releasing parts of her identity.
  4. Finally, the IdP responds with a security token containing the issued claims. This response may be:
    1. A redirect to the web app, with the token encoded in the target URL, or
    2. An auto submitting HTML form, containing the token in an hidden field. The form’s target is the web app.

Both the WS-Federation and SAML protocols use the interactions described above. The SAML protocols have some variants not described above, namely the artifact binding.

These protocols are named passive, because the user agent (Alice’s browser) does not plays an active role in the protocols. It just has to play the HTTP protocol game. Namely, no browser javascript support is required.

Active protocols

In the active protocols, the user-agent plays an active role in the protocols.


  1. The protocol starts by the user agent directly requesting a token from the IdP. This request must contain all the information required for the IdP to authenticate the requesting user and determine the claims to issue.
  2. Next, the IdP responds with the issued token.
  3. Finally, the user agent sends the request to the Identity Consumer (typically a service), with the token attached.

The WS-Trust is an example of an active protocols based using the SOAP and WS-* specifications.

In the next post we will show some examples of security tokens, namely the SAML assertion format.


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