DE-Federated Identity Access (DEAF)
By Rohan Pinto on Jan 17, 2008
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:
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 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.
- 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.
- University1 and University2 belong to a "defined" Circle of Trust.
- Student at University1 authenticates at University1.
- Student tries to access resources at University2.
- University2 Requests University1 to assert the validity of the user session.
- University1 Asserts that the user is "A" authenticated user, but does not actually reveal the users "handle" or "identity" in any form
- 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)
- 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
- University2 can now allow the user to "personalize "content" or provide the user "content" as necessary.