The Freak Parade

Identity is a big topic now-a-days. Not the identity you go backpacking across Europe to discover, but the kind of identity that a computer system uses to determine whether to allow itself to be queried or manipulated by one incoming connection as opposed to another. (Sounds kind of dirty, doesn’t it?)

As the World Wide Web continues its imperialistic drive to connect every electronic device on the planet to every other in Borg-like fashion (if you’ll permit me to lapse into slobbering geekatude) the momentum behind technology focused on Digital Identity is finally starting to catch up.

What’s wrong with digital identity the way that it is? Well, while you can access any of a billion different computer systems from your cell phone in the middle of a swamp in the Australian outback, you’ll still have to scrunch up your eyes and punch in half a dozen username-password combinations on your tiny keyboard as you move from system to system - a strange contrast. On the one hand almost godlike connectivity, bordering on omnipotence, and on the other a sad comedy of "forgot-my-password" links and identity theft. Power and Stupidity - fused together to form something as irritating as it is dangerous (see figure 1 to the right).

Affectionately known as  password hell, this kind of arrangement has implications far more sinister than simply being tremendously annoying. The cost to IT organizations and help-desks trying to support this unsupportable user-experience nightmare is huge, system integration is made much more difficult and expensive than it would otherwise need to be, and the privacy and security implications of your sensitive user information and login credentials being stored in n number of individual databases across the Internet protected by varying and unpredictable degrees of security are frightening. Then there’s just the good old fashioned loss of productivity that results from the high friction computing experience caused by the need for overly complex identity management.

So the 30,000 foot view of the root of the problem is this: most independent software applications maintain ownership of a proprietary user directory to authenticate and authorize access to themselves. (Applications that live entirely inside the corporate firewall will often rely on a shared infrastructure level directory service to synchronize or share user identity between internal applications, but this is not always the case for every application, and as Software as a Service and Cloud Computing begin to conquer the universe, the number of applications that have the luxury of living entirely within the firewall will get smaller and the number of applications living in the wild will get larger and larger. This is unavoidable.)

The 30,000 foot view of the solution is this: most independent software applications will need to give up the snuggly comfort of proprietary, internal user directories and delegate responsibility for authenticating and identifying their users to specialized, centralized systems designed for exactly that and nothing else.

Such externalized authentication systems are often referred to as Identity Providers and are implemented via a kind of server called a Secure Token Server (STS). The concept of a software application accepting authentication decisions made by a separate (though trusted) system is called Identity Federation.

Software developers, by and large, are control freaks, so this solution may be difficult for many of us to accept. We may clutch our Users table to our chests and scream "Don’t take my baby!" in a Southern accent, but in the end it won’t do us any good. As momentum behind identity federation increases both businesses and end users alike will quickly lose what is left of their rapidly deteriorating patience with any software application that insists on authenticating them personally.

Fortunately the technology part of the problem is essentially solved. In Part 2, Part 3 and Part 4 I’ll explore some of this technology, particularly the kind of stuff likely to be useful to those working with .NET. I’ll also take a closer look at the long-overdue replacement for Role Based Access Control: Claims Based Access Control, a style of determining what permissions a user has in a system that goes hand in hand with modern implementations of identity federation and the standards and protocols that enable it (such as SAML). Claims Based authorization is more powerful and more flexible than role based authorization, and so provides significant advantages even outside the context of identity federation.

Identity is no longer something that can be a foregone conclusion in the design of a new application. The old, loyal Users table with her gout-filled username and password columns is showing her age. The old girl is having trouble coping in a hyper-connected world. Time to tell the doc, "Pull the plug! For gods sake man, put her out of her misery! That just ain’t no kind of livin’!" And then it’s time to try something new.