Wednesday, April 19, 2006

Identity Management Backlash

I have been waiting to blog on a subject that is early on in trending and I seem to have stumbled across it this week in enough places that I thought it was worth mentioning. In 3 separate conversations with 3 different entities in 3 separate markets (Education, Finance, and Government) there is a growing sense of backlash of the complexity of identity management application deployment.

Having spent two years at a firm that provided IdM implementation services both onshore and offshore I can tell you that the costs of implementation, even with the offshore (inexpensive) route, are 2-3 times the cost of the software, and you’re not even talking about support costs which are limited because of the nature of the highly customizable solution offerings out there. Greater complexity = greater cost.

Period.

The complexity has numerous sources – inability to define what identity management means (Single sign on, password management, provisioning, or something else altogether) is a big culprit as is the double edge sword of the IdM applications themselves – they can’t be too highly customized out of the box given the complex application environments that must be integrated to make identity management useful. If you force organizations to conform to the way the IdM code was written, it might mean changing business process to conform to software. Politically and technically not a good choice. If the IdM application vendors leave the software highly customizable then they have given organizations choice, along with cost of customizing the heck out of the apps to integrate with existing ‘stuff’.

So what are the alternatives?

If you define Identity management as I do, in its simplest form it is to deploy mechanisms as simply and as securely that allow organizations to know and validate who their users are and enable the identified users to access the assets and applications they need to do their jobs, while denying access to applications and assets to unknown and unwanted users.

You can contextualize compliance, privacy, security (physical and technical) within this definition as well, and truly keep it simple. Using this definition, you now have a framework by which to define and implement the fewest parts to accomplish this goal.

My suggestion: If you want to keep it simple, deploy a solution in the network. Think of it this way…

There could be a security checkpoint at every gate in the airport. Each gate representing a specific airline. Sometimes the gates are shared because of a business relationship, but most are stand alone. Since each airline has different methods of check in and boarding, the process by which they identify users is theoretically all the same, but because of the different processes, which are dynamic, it clearly is not.

Map this example to a company with gates being applications and assets, and users being passengers, then the deployment of a consistent identity management approach is rather complex. Instead, if organizations centralized the access point as airports do, then they now know who the users are because they have been authenticated, and where they go is dependent on their credentials (boarding pass). The network is the central point.

If an unknown user cannot access or even see what is on the network then the assets and applications are safe from people inside and outside the network. How much you want to control the authentication and travel throughout your ‘concourse’ is up to you…

mmacauley at trustednetworktech.com is how to reach me