Identity and Access Management (IAM)

My previous blogs discussed Identity 2.0 and  OpenID, both of which describe a user-centric perspective of identity that focus on breaking down the enterprise control over personal private information. 

I also collaborated on the joint paper "CA and Microsoft Support for User-Centric Identity and the Identity Metasystem", that describes how SiteMinder can participate within the Identity Metasystem by allowing Relying Parties to accept Information Cards from Identity Providers. 

Both of those blog postings have been from an educational view, but this one will be my own opinion.  To give some context for the discussion to follow, you should be familiar with the Identity Metasystem.   

Here is a quick recap of the main actors the Identity Metasystem defines:

Identity Provider (IdP) - produces identity in various formats.  I like to think of it as an identity prism.  It can produce my identity information in many flavors, based on the context of how I would like to use it, and on the policies defined.  Bottom line, it burps out identity in multiple token formats, based on policy.

Relying Party (RP) - consumes identity information provided by an Identity Provider.

Subject - me, the user who wants to access some service, and has to give then some identity information.

Identity Selector - a chunk of software that provides a mechanism for me (the subject) to manage and use their identity personas.

The Identity Metasystem describes a fundamentally new way to think about identity, how it is produced and consumed, and the rules that govern how this should happen.  Information Cards (CardSpace) is a particular implementation of the Identity Metasystem, the user-centric perspective.  Because Information Cards was the first implementation, and because it has a visual component (the selector), it made logical sense to use this new concept as an educational mechanism to educate people on the Identity Metasystem concepts.

People reacted positively to this approach, as we know a picture is worth a thousand words.  The problem is that I think we have painted ourselves into a corner.  The Identity Metasystem is more than Information Cards; they are just the tip of the iceberg.

Because the scenario that we have been using to date pushes the user-centric concept, people mistakenly interpreted the entire capability of this new Metasystem as only supporting user-centric behavior.  I fell into this trap at the beginning also.  I think we need to discuss the new ecosystem from a different perspective.

Most existing Identity Metasystem examples described a user accessing a web site and providing a computer equivalent rendition of a user license.  The visual metaphor made it easy to understand how things were happening.  This made sense since the most logical way to describe the new user-centric paradigm was to relate it to real world items and behaviors.  The infocard and its usage of claims became the central point of discussion and of education.

But if you take the time to really look at the Identity Metasystem and how it is constructed, you will realize that it is much grander that that -- much of it is under the water line, and it's big.  To really educate people on what problems the Identity Metasystem can help solve, we need a better way to describe it in a way that others can understand.  Basically, it needs to be a simple concept to explain and understand.

In the identity arena, we normally view identity from three different perspectives:

Web Site Access Management solutions (User-centric federation)

1. Web Service/SOA management solutions (Service federation)
2. Enterprise Federation

These deal with the federation of identity from someone who has it (Producer), and someone who wants it (Consumer).  The issue to date has been the format that each of these federations convey their identity (SAML, WS-*, username/password, smart card, assertions, claims, etc).  Sometimes a user is involved (User-Centric Federation), sometimes it is just an identity sharing arrangement between corporations (Enterprise Federation) and sometimes it is a service call (Service Federation)

So when we attempt to use or create solutions that require identity across the spectrum of these three federation models (User, Enterprise, and Service) we are often forced to use incompatible formats (e.g. SAML1.0 vs. SAML20 vs. WS-Federation).  If we want to access a web site and then access a web service, the underlying plumbing has often gone through many hoops to make this happen, often exposing new security risks or identity information that was not relevant to the situation.  Engineers must select a "dialect" that they want to communicate in when obtaining or using identity within their solutions.  The difficulty in developing and defining these relationships (Producer-Consumer) has made our lives difficult, and it is often unable to scale as business requirements evolve.  The Identity Metasystem can help.

The example of an infocard (User-Centric Federation), where a user provides a web site (Consumer) with their information from an Identity Provider (Producer) is pretty much the same interaction pattern across the federation models.  The only major difference is in how the identity information is conveyed from the producer to the consumer, and how it is processed.  Of course this is a wildly over-simplification of the situation, since it involves complex issues such as: how the policies of the producers/consumers are defined, exposed, and discovered, privacy, compliance, etc.  But at the end of the day, the Identity Metasystem offers an Identity Dial Tone

The "Identity Dial Tone" (IdT) is the ability to produce and consume identity in various formats, based on contextual information and adhering to defined policy.  The Identity Dial Tone produces identity claims that can be used in the various types of federation scenarios; it is able to transform identity from one form to another, based on the requirements of the task.

Think about it.  The Identity Metasystem shows how to move tokens from A to B, and how to provide the right format that each participant knows about.  It describes a mechanism that can take a request in one format and produce a response in another format.  If we convert an apple to an orange, in a language and technology independent fashion, then we can start to deliver the Identity Dial Tone.  We could accept a un/pw, generate a SAML assertion, take that and generate a WS-Security Token, take that and generate a totally custom token, etc, etc.  The strength lies in being able to isolate identity information from the format required for collaboration between heterogeneous environments, and token formats.  By separating the identity from the representation, and clearly defining the requirements that an identity producer or identity consumer should follow, the Identity Metasystem lays the foundation for truly portable identity, or the "Identity Dial Tone".

The incompatibilities between concepts like SAML, WS-*, SSO, User-Centric, and Web Services can be harmonized with the Identity Metasystem, by providing an Identity Dial Tone.  Until we start to educate everyone on the real strength of the system, we are going to be left with the misinterpretation that this relates only to user-centric identity, and the transfer of claims from point A to point B.  So, user-centric is the tip of the Identity Metasystem iceberg, the plumbing can provide for the Identity Dial Tone that helps harmonize enterprise, user, and services federation.  In future posts, I will discuss how the Identity Metasystem can be used to bridge the differences between competing federation formats and protocols.