Considering identity consolidation

James has provided me more to work with

Identity consolidation says that I figure out how to get user stores out of my enterprise application and instead get these applications to bind at runtime to a directory service such as Active Directory.

Ah, so identity consolidation is centralized authorization.  Got it.

I am making the assumption here that when James says user store he means authorization store.  (Applications in this model still need some modicum of a user store if nothing else for auditing purposes.)  I am assuming the implication here is that after authentication comes a round of authorization that the directory service provides.  The application would consume this authorization data, at runtime, and act accordingly.  Theoretically, an enterprise policy (XACML) store could theoretically reproduce the authorization models of every application in the enterprise today and that policy tools would interact with this store.  Though I think this is a very viable model for customer applications (especially J2EE and .NET), I do not see it as an enterprise approach where complex applications like mainframe security and ERP roam free.

Identity management says that I should go create a strategy around provisioning of identity and leverage tools such as Sun’s IDM, Thor, etc where I still fundamentally allow enterprise applications to have their own user stores and takes me down the path of building lots of connectors… [snip]  I am of the belief that identity management (provisioning) propagates and encourages an otherwise bad architecture.

I look at user provisioning as dealing with the reality (and foreseeable future) of the enterprise landscape.  That landscape involves lots of user and authorization stores.  For reasons I discuss below, that is not going to change any time soon.  It is better to provide flexible, short time-to-value solutions, as identity management does, that address the reality of today than to wait for the ideal enterprise landscape to arrive at its glacial speed.

I disagree with James’ assertion that user provisioning requires the construction of connectors.  The connector wars of the provisioning world are over.  Connecting to systems like a complex bespoke application or RACF or SAP has become a science, not an art.  On the whole, provisioning doesn’t require connector construction; it requires configuration.  Each provisioning vendor worth their salt has a way of quickly connecting to “unknown” systems that don’t require core engineering efforts.

The one thing that I would also love insight into is how to get vendors who still insist on having their own user stores (e.g. Documentum, Alfresco, etc) to see the error of their ways and to take quick steps towards remedying them.

I think you’ll find the reason the vendors give on maintaining their own user and authorization stores is much the same reason why they have yet to adopt Service Provisioning Markup Language in a meaningful way.  There is nothing in it for them.  Nada.  The only vendors who might stand to gain (and thus adopt) centralized authorization are mega-vendors like IBM who have dozens upon dozens of applications.  For these vendors, producing a common auth store with the requisite halo of tooling becomes a path to customer lock-in.  “Ms. Customer, you can use AuthStore 5.0 to manage all of the authorizations for all of our products.  And here is AuthManage 6.0 to help you do just that.”  And if the customer ports their bespoke applications to the common auth store, the vendor gets big-time lock-in.  Want to get rid of XYZ Vendor?  You’ll have to reincorporate authorization stores into your applications. I have to imagine externalizing an auth store for a homegrown application would be painful, undoing that work even more so.

Stepping back to what I originally wrote about: no amount of centralized user and authorization management will make up for a lack of strong organizational and business process understanding coupled with appropriately defined controls.  That is the fuel for identity management and, frankly, identity consolidation as well.

Give me more to work with and I will

James recently picked up on my Identity leprosy or identity zombies post and writes:

Ian believes that identity needs brains but falls into the trap of thinking about identity solely from the perspective of provisioning and while avoiding runtime aspects. I wonder if he would blog on why enterprises should consider identity consolidation over identity management? 

 Before I respond I’d like to get some clarity.  James, give me a more to work with and I’ll happily write more.  Help me understand that which you are contrasting between “identity consolidation” and “identity management.”  Help me understand how provisioning doesn’t have runtime implications. 

Identity leprosy or identity zombies?

Jackson, in discussing the demise retrenchment of HP’s identity business, had this little gem:

We talk about Identity 2.0 in the context of Web services and the evolution of digital identity but our infrastructure, enterprise identity “stuff” is decrepit and falling apart. I have visions of identity leprosy with this bit and that bit simply falling off because it was never built with Web services in mind.

Bits falling of, eh? I’ve never heard of someone losing their core directory services because someone forgot to add XACML support. I’ve also never heard off someone loosing an ear because their provisioning system didn’t support SPML v2. Enterprise identity “stuff” is more like a zombie. It lurks in the dark corners of your enterprise. It staggers out at you at inopportune moments. Two other aspects of this ridiculous image that are valid:

  1. The identity zombie is incredibly hard to kill.
  2. The identity zombie needs BRAINS!

“They stab with their steely knives…” Once deployed, even in rudimentary forms, enterprise identity systems are amazing difficult to uproot, to kill. Homegrown systems are notoriously tough to maintain as well as replace. Even worse were those early attempts at vendor provided solutions. Before IBM/Tivoli bought Access360, it had Tivoli User Administrator. TUA… one of the banes of my existence. The thing wouldn’t die. The customers who got it running were actually in love the rotting smelly thing. They kept it on a steady diet of scripts (BRAINS!) that served as connector definitions and entitlements all rolled into one. It just ran and ran and ran. From what I heard, early BMC Control/SA customers are much the same.

Think this problem is limit to the “old timers” in the identity market. Nope. Good luck replacing that SiteMinder deployment. Enjoy uprooting your original iPlanet directory implementation.


We all know zombies feed on brains. Common knowledge. Let’s consider for a sec that the enterprise identity “stuff” that Jackson refers to is a friendly, but slightly misguided, zombie. The rising aspects of the identity market are the brains that is so badly craves: enterprise role management, entitlement management, fine grained access control, etc. Feed our enterprise identity zombie with a healthy does of policy that has business-readable language as to role of the person and their subsequent entitlements and you’ll have an enterprise-class, unkillable (in the good way), identity infrastructure.

Further, you do not have venture into the newer territories of identity land to feed your identity zombie. Enterprise identity implementations have sufficiently progressed to the point that your more mature services providers can feed your zombie all the brains it needs based on their own experience, methodologies, and techniques: no emerging technologies needed.

Do enterprise identity technologies need a bit of a refresh? Sure. But that doesn’t mean they need a complete rip and replace with user-centric or other newer identity “stuff.” Absolutely not. What it does mean is that we are seeing a rise in the value of identity brains, entitlement and access management in business and organizational terms.

Back from Pune

IMG_0142I’ve been back about a week from my trip to Pune.  Had a great time.  The people and food were wonderful.  I did get a chance to go on our company “picnic,” a three day jaunt to the beach near Dapoli.  Some funny adventures along the way, like a 14 hour bus ride home featuring the bus breaking down on three different occasions.  Good times.  All in all, I know I’ll be back soon and hopefully have more of an opportunity to explore.