when you find the need to go beyond documentation.. IDentity EnAbled Services

Identity Management, and Identity Federation has been the buzzword in this space for a while now. According to the definition of "Federated Identity" on wikipedia, it has two general meanings:

• The virtual reunion, or assembled identity of a person's user information (or principal), stored across multiple distinct identity management systems. Data is joined together by use of the common token, usually the user name.
• The process of a user's authentication across multiple IT systems or even organisations.

now, this is great when the Legal Entity has a unique "identity" on each of the disparate systems. But when the Legal Entity who has a identity on a system is provided access to a partner site or system, there is absolutely no "Federation" possible if the Legal Entity has no identity on the partner site or system. I was involved in a brainstorming session related to shibboleth with a few technical folks from a university. What came up was the need to allow students from one university to access resources from another university. The folks I was interacting with were "sold" on the idea of federation, but lacked complete understanding of how federation really worked. Here were my concerns:

• The user needed to have a unique identity on either systems.
• The user needs to explicitly "federate" his identity. (If he does have a unique identity on each system)
• If the users identity gets stolen, well, we have a much bigger issue.

(I thought) What the university really needed was implicit Federation. Whereby when a user who has authenticated himself at one university, when provided access to resources in another, should be granted access even thought the user does not have a unique identity at the other. Here's an example:

1. University1 and University2 belong to a "defined" Circle of Trust.
2. Student at University1 authenticates at University1.
3. Student tries to access resources at University2.
4. University2 Requests University1 to assert the validity of the user session.
5. University1 Asserts that the user is "A" authenticated user, but does not actually reveal the users "handle" or "identity" in any form
6. University2 grants the user access by just knowing that the user is a "authenticated" user at University1, without even knowing who the user actually is. (University2 provides just generic content to the user)
7. User tries to personalize his "content" or University2 needs to provide the User "specific" content based on role the student has at University1
   • University2 would need to prompt the user for "permissions" to derive his "role" from UnIversity1
   • User grants permissions by using a digital signature of some sort.
   • University2 uses that digital signature to request University1 for the Users roles
   • University1 verifies that the digital signature matches that of the Authenticated User and grants University2 the users roles and/or "identity/alias".
   • University2 provisions a local "identity/alias" and associates it with the "role" as asserted by University1
8. University2 can now allow the user to "personalize "content" or provide the user "content" as necessary.

I believe that with this aproach, even though a student has no "identity" on one system or university (University2 in the example I used) he/She still gets to experience the "magic" of "federation". On second thoughts, If I apply this to the examples widely used in "federation", where a airliner and a car rental company are in a circle of trust, well, I am sure that the car rental company would love to receive a new unidentified user from a "partner airline" and dynamically provision the user and sell him a product !!! it's all about making money in the bargain right ? or is it just making the user experience more enjoyable and easy ? I believe that we'd be kidding ourselves if we say that it's ONLY about "user experience" Now: The user providing his/her "digital signature" to the car rental company is another story altogether.. ;-) Comment Away Please... (Comments are active for only 30 days from the date of this posting) UPDATE : Please Read Pat Patterson's response by Clicking Here or by following the link in the 1st Comment/Trackback below.