Layered Identity Management
They sit way out front (12-18 months). They are where everyone will get to when they look at Federation and what the Liberty Alliance Project is doing.
So a strategy I will be refining with my peers is one of layers of identity management where there are several solutions, tightly coupled and specific to their piece of the identity problem. There is no holy grail, amigos. Not yet anyway. I'm going to work on a picture that illustrates what I'm talking about, when I talk about this layering concept in a future blog entry.
In a nutshell, the solution that I envision starts at the transport/network level with a solution from TNT. This gives an organization their unalterable, pervasive identity or 'iDNA' (this is my term first used in July 2005, and now copyrighted).
The next level up is the directory level and you can pick your own flavor here. The next layer is the SSO layer where the users, now identified as absoltely as possible, begin to access key resources (applications or content).
The next layer is provisioning (Sun, Novell, IBM) whereby users now identified, have logged in, and now are granted access to applications and content they have been provisioned for.
The next layer, or step I guess is more accurate, is to reference the policy engine (Epok) to see what applications or content outside the organization the user has access to and is federated for.
You now have positively identified the user at a very fine level of granularity, you have authorized user access, automatically provisioned the identified user for access on your systems, AND have federated that identity to other systems outside of your domains. In short, you have arrived at the best place you can get to today - A known user, with automatically provisioned and auditable access to content and applications useful and necessary to that persons functioning (not necessarily role) as a member of these connected systems.
Pretty cool, huh?
Let me tell you cool it *really* is - email@example.com