% fortune -ae paul murphy

The joys of identity management

I think it's obvious that automated identity management is becoming increasingly important and could easily be at the top of nearly every big organization's CIO agenda for the next year or two. Unfortunately I don't know what identity management is, and my guess is most of them don't either.

One of the things contributing to this contradiction is that people seem to be forming their ideas about identity management by combining what they understand from fairly cursory reviews of their default vendor's offerings with unexamined assumptions based on their interpretation of the words used, mainly "identity" and "management".

As a result conversations about identity management with people whose default vendor is IBM tend to be based on different premises, and reflect different expectations, than nominally similar conversations with people whose information about identity management comes mainly from Sun.

Most fundamentally the IBM focus is ultimately on process management while Sun's is really about rights management -and neither one actually has much of anything to do with identity as normal people would normally understand it.

I think that's come about largely because the products aren't purpose designed - they're lashups: packaged offerings evolved on marketing commonalities between ad hoc "solutions" slapped together to meet specific customer needs.

For example, here's how one Sun document among many describes "The 4 A's of Identity Management:"

Authentication -Quickly verify user identities

Authorization -Control user access

Administration -Manage users and assets

Auditing -Automatically document what happened

Look at this list and you should see first that it's full of redundancies, and second that a lot of the "what to do" more or less explicitly includes the "how to do." Thus identity management will "authenticate and authorize" users using "role and rule-based authorization for centralized policy enforcement."

Look more closely, however, and what you'll see is an effort to ensure that potential customers reading this will check off as many "required functionality" boxes as possible without inviting those customers to think about what the labels might actually mean.

Which would be fair game, except that when you get to implementing the pieces a specific customer has actually bought into, you need to make this stuff concrete -and at that point the absence of a central, consistent, motivation for the entire package means that you can make it work, but you can't make it resilient against contra-skilled support or external change.

More tomorrow

Paul Murphy wrote and published The Unix Guide to Defenestration. Murphy is a 25-year veteran of the I.T. consulting industry, specializing in Unix and Unix-related management issues.