Posted by: Dmitry Sotnikov on: August 17, 2009
In the brave new world of enterprise applications going to the web do we need an identity directory spawning the internet, and if so, will email address system become the de-facto global identity system?
Global directories are obviously not new. There were efforts like X.500 and like, but then we kind of got scaled back to company-wide identities instead. So most of us just use a username (or DOMAIN\username) to log into our computer at work, and do not care that this is not globally unique at all. Sounds like the internet will make us care again.
Suppose you are designing a global enterprise SaaS application and you absolutely do not want to maintain user identities yourself (because this would obviously be a headache both to you and your customers).
Federation is the answer, right? So OK, you go out, pick the federation standard you like (for example, WS-*) and you should not care about user identities. Just redirect users to their actual identity providers – in enterprise world this will likely be Active Directory – and let users in once you hear back that the user is authenticated there. Ay, there’s the rub – you still need to know something about user to decide where to send the user to authenticate.
This problem is known as Realm Discovery – even in the federation world you still need to know where the user comes from. Here are a few options which I see:
Identity Selector on user computer
If all users on all computers had Windows CardSpace you could never prompt users for anything and just use those. However, the reality is that this technology has not taken off (yet?) so you cannot rely on it.
URL-based discovery
You could ask your customers to use custom URLs to access your site: e.g. CustomerA.MyWebService.com. In that case you know where the user comes from and can redirect to proper federation partner. If you can have all users go to this custom URL instead of generic MyWebService.com this might be a pretty good idea.
The problem is that you probably cannot. Your users will probably want to be able to log in from your generic site as well. Even worse, they might want to delegate tasks in their services to users from other companies – and in this case they will have to learn and supply the CustomerB URL as well when setting up this delegation – which becomes kind of messy.
Ask the user
If the user comes to your generic URL and wants to authenticate (or is authenticated and want to delegate rights to another user), what do you ask the user so you know where to redirect her for authentication?
Displaying a drop-down list with all your customers is probably not a good idea.
DOMAIN\username notation won’t work either – intranet domains are not globally unique.
I would argue that email address is probably the only usable solution here:
Where does this lead us? Not only we probably need a global directory, we actually already have one. Long live email addresses.
August 17, 2009 at 5:22 pm
OpenID is already trying to do this as well. It provides more power over email addresses because you can associate certain information sharing rules with various sites and you can build you identity profile at a provider of your choice.