Pillar 2: Identity and Access

To better illustrate this pillar I will use the registration at TechEd as an analogy.


When you go to the registration desk at TechEd you are asked a picture ID (this can be your driver license, your passport etc.). The picture ID, contains a irrefutable proof of the first/last name you claim having; once verified, your “real life” identity is exchanged for a TechEd badge. Within the halls of the convention center, passports and driver licenses are meaningless, only your TechEd identity i.e. your badge counts. In fact, it is not the badge per se that counts, but more precisely the color of your badge: purple badges for speakers, yellow badges for attendees, red badges for press… the color of your badge indicates the level of privilege you have. If you are a speaker you are free to go everywhere, if you are an attendee you can go to sessions but not the speaker lounge and if you are press in addition to the sessions you have access to the press center. Each member of the security staff holds a piece of paper in their hands indicating what colors are allowed where (sessions: purple, yellow, red; speaker lounge: purple; etc.)

Several things of interest happened here:

(1) You exchanged your identity (driver license, passport) with an identity that is much more relevant in the context of TechEd: your TechEd badge.

(2) Your new identity has some privileges (or permission) associated with it

(3) The security staff checks grant access to sessions, lounges etc. based on the color of your badge (policies), independently from how you got your badge.

Going back to the pillar:

(a) the driver license to TechEd badge is a claim transformation

(b) the color of your badge represent the claims you are making; (a purple badge is a claim that you are a speaker);

(c) the security guard is the “claim aware” application knowing what claim is required to grant access

(d) the piece of paper indicating what color is allowed where are the policies

(e) the registration desk is the issuing authority trusted by the security guard.

Hence, to implement federated identity in your connected systems (which at the goal here)

When exposing a service,

(a) you need to verify access against claims, independently from how claims are obtained

(b) you need to trust a specific claim issuing authority, accepting that if the claim is issued by that authority it is a valid claim

(c) And you don’t need to know the actual identity (user account) of the caller

The trusted issuing authority (or Secure Token Server in our jargon) needs to

(a) transform claim (picture ID, into TechEd badge)

(b) be able to request additional claims (picture ID + proof of payment) if necessary

Even though the concept of federated identity is more complex that this, the fundamental principles are the one described above.

Infocard which will be shipping at the same time as Indigo is the technology in the Windows platform that codifies all these concepts and principles in software.

In other words, Infocard is to the Indentity and Access pillar what Indigo is to messaging.