This is an architecture topic primarily, no code or screenshots. Definition of identity to start with; set of information about some entity, such as a user. Authentication is the act of establishing identity. Authorisation is distinct and potentially disjoint from authentication.

Working with identity is too hard; Kerberos for network, username/password for the web, federation and SAML between organisations. Claims-based identity is intended as a single approach to cover all these scenarios. Simpler for developers.

Token: artifact transporting identity information; consists of one or more claims. Claims: are statements about an entity (examples: age, gender, group, etc.) An identity provider is an authority that makes claims about an entity (generates tokens?)

Example identity providers; at work the employer, internet is most often yourself (does not mean the claims are true!).

Identity provider implements security token service (STS). Software that issues tokens which are requested via WS-trust, WS-federation, SAML. Authentication can be outsourced depending on who you trust!

Illustration; identity provider has a store and an STS. User calls the STS (browser, or rich client, for example) and asks for a token. STS decides if the user is valid based on provided evidence, and will get information from the store, package it in a security token and send it back to the user.

Illustration; user has a token, relying party has a resource that the user wants to access. User invokes the application at the RP sending a token along. RP checks that the token has not been tampered with, whether it is successful, etc, etc. If all is well, the call is passed through to access the resource.

Today's world... application typically only gets simple 'identity' information. Example: user's name. Doesn't say 'who you are', just that you have been there before and you have returned. To get more, the app needs to query a remote or loca database, or directory service.

Claims can be used to: identify a user, convey group or role membership, personalisation information, grant or deny the right to do something, constrain the right to do something (purchasing limit).

Supporting multiple identities, using an identity selector. User, IP (many) and RP; user first lands on the RP page. Gets a list of trusted IPs to choose from. User picks an IP and gets a token. Sends the token on to RP.

Windows Identity Foundation sits in front of the RP and performs the validation and pass-through. All interactions are open standards, so no Windows tools mandatory to do any of this. ADFS 2.0 is an IP. Windows Cardspace 2.0 is a piece of client software that performs the identity selection feature.

Using this architecture isolates the RP from changes based on the type of authentication or context involved. Identity across organisations is a little trickier. User in one Windows forest needs to access app in another forest, or perhaps a non-windows user.

Option one: duplicate accounts; very bad, extra administration needed! Better: identity federation, no duplicated accounts, allows single-sign-on, also means that cancellation of account automatically de-authorises the dependent companies.

Out of battery, so saving now...