Claims-Based Computing and Federated Identity – Part 2

Check other parts:

Claims-Based Computing and Federated Identity – Part 1

Claims-Based Computing and Federated Identity – Part 3

Claims-Based Computing and Federated Identity – Part 4

In this part, i will be talking about Claims issuer also known as Scrutiny Token Service STS. 

Claims Issuer Concept

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 claims based application that needs to know the user firstname, userlastname and perhaps the user’s email address. 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 AD, AD LDS, or perhaps a relational database to gather those information and will create three claims, one for the user’s firstname, one for the lastname and one for the email address, and it will package those 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.



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, or a path within that domain, such as A realm is sometimes described as a security domain because it encompasses all applications within a specified security boundary.

Issuer Offering

A claim is piece of information like firstname, lastname, email address, and so. Each application may need different types of claims. A certain application may need only the firstname, while other may need the firstname and email address.

Saying that, the applications consuming claims should know many information about their claims issuer like:

  1. What claims does the issuer offer?
  2. What key should the application use to validate the signatures on the issued token? (that is the public key of the issuer)
  3. What URL must users access in order 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

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 in order to receive the tokens?

Establishing trust between the application and the issuer (STS) 

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 it as a Relying Party.

The application adds the trust information on its web.config, and the ADFS (as an example of STS) will store the info on its database.

The figure below refer 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.


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 2

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