Introduction

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

The first one presented a scenario with decentralized identity authority. This posts uses this scenario to introduce the claims based model.

The following figure serves two goals:

· It presents the main claims model concepts, and

· Concretizes this concepts in the presented scenario

Claims model concepts

• Identity is represented by a set of claims, where a claim is a declaration made by an entity. In this scenario, Alice, LeadDev, IssueMgr and IssueView are examples of claims that represent’s Alice’s identity.
• An Identity Provider (or Issuer) is an entity that issues identity claims, typically containing information for which it is authoritative. In this scenario, WeDev is the identity provider, and it issues name and role claims (e.g Alice and IssueMgr).
• An Identity Consumer (or Relying Party) is an entity that uses (consumes, relies on) identity claims. In the above example, the consumer is CloudTrack, which uses the consumed claims to make the authorization decisions..
• A Security Token is a set of claims securely packaged for transportation between participants. This packaging ensures properties such as
• Privacy: only the authorized receiver of the token is able to access the contained claims. This typically is obtained by encrypting the token to the authorized receiver.
• Claim integrity and issuer authentication: the token receiver is able to determine the original claims producer. Usually, this property is achieved by the issuer digitally signing the token.
• Subject authentication and proof of possession: the token receiver is able to determine who is the subject of the claims. The two more common proof of possession methods are
• Bearer – any entity who has the token can allege that it is the claims subject. This is similar to bearer checks or bus tickets.
• Holder of key – the claims subject is any entity who proves possession of a related key (e.g. by signing the message where the token is attached).

The “Proposal for a Common Identity Framework: A User-Centric Identity Metasystem” contains an interesting taxonomy of claims

• Claims are divided between primordial and substantive
  • Primordial (or primitive) claims are proofs presentable by only one subject
  • Substantive claims are claims produced by claims providers, typically after the subject presenting a primordial or other substantive claim.
• Substantive claims are further subdivided in
  • Static – properties of the subject (e.g. National Identifier Number; Date-of-Birth)
  • Derived – derived from other claims (e.g. Portuguese Citizen; Over-18)
  • Membership – role or group membership, relation with other subject (e.g. Administrator; Lead Developer; Purchase Officer)
  • Capability – authorization to something (e.g. Can-emit-purchase-order; Can-admin-CI-server)
  • Contextual – information about the context (e.g. Authentication method, location and time)

Claims transformers

A Claims Transformer is an entity or module that produces claims based on claims that it receives (consumes).

For instance, in above scenario, the WeDev identity provider can also be seen as a claims transformer since it produces the name and role claims (substantive claims) upon receiving and validating Alice’s credentials (primordial claims).

We also can see the CloudTrack’s web app as divided in to two modules:

• The first module is a claims transformer, transforming the input role claims (LeadDev) into application specific roles (IssueMgr) and authorization roles (IssueView).
• The second module is an identity consumer, using the input authorization claims (IssueView) to decide if the access is allowed or not.

Notice that the claims exchange between these two modules doesn’t have to use a token, since no unprotected communication channel is used.

In the next post, we will present some of the protocols that are used for requesting and communicating claims and tokens.