Abstract

The benefits of Identity Management (IdM) are well known. Several vendor products rule the roost when it comes to IdM. However in reality, the costs of the vendor products, subsequent enhancements, customization and maintenance does not justify the Return On Investment (ROI) for Small & medium Businesses (SMBs). This blog series takes a contrarian view of the current state of Identity Management especially for SMBs and defines a strategy to leverage your company’s existing IT investment in SOA to achieve Identity Management.

Selling points for traditional Identity Management products

Traditionally Identity Management products IdM products are sold to Information Security division. Security management and security administrators are the primary users of IdM. These primary customers (Information Security division) are not developers by background. Hence the following arguments are used to sell IdM products:

  1. Companies that don’t use IdM product use a collection of vast array of scripts for achieving similar results with varying degree of success. A company’s IdM strategy cannot rely on hotch potch collection of scripts because
    1. Scripts are tactical
    2. What if scripts fails,
    3. What if scheduled script doesn’t run – who is notified etc.
    4. Scripts need programming and constant maintenance cost and man power
  2. Management needs Reports on user provisioning, password resets etc. and report generation is not trivial
  3. IdM vendor products come with
    1. Canned schema (ldap or db)
    2. Canned reports
    3. Canned provisioning workflows
  4. Products have great UI capabilities – A lot of provisioning, reconciliation and reporting can be done with the click of a button.

Capitalizing on the audience background, the scripting nightmare stories enhance the FUD factor. The “click of a button” provisioning and reporting demos convince the buyers beyond any doubt. However one needs to look beyond the sales demo to get to the whole truth.

 The whole truth about IdM products

Sure. all those selling points have some truth in them. But can they justify the cost of Identity Management products or the ROI on them – especially for SMBs?

Lets delve into the internals of any Identity Management product in a generic way. I am not stereotyping, however a majority of IdM product architecture goes like this.

  1. All IdM products need substantial customization to meet real world needs and this is where the “click of a button” paradigm falls apart. Canned schema, canned provisioning workflows and canned reports can only go so far. Once you reach this threshold, your luck runs out. (which certainly will, during the requirements analysis and design stage itself by the way)
  2. Reports, provisioning workflow and other facilities are accomplished as vendor supported extensions on top of basic datastore schema
  3. All additional data fields to meet custom business logic have to be crammed into limited extensible space in the tables or by extending the ldap schema. When you extend vendor datastore schema, vendor support is dropped as a general rule.
  4. User provisioning, deprovisioning, system access administration each require workflow that integrates with various IT systems in the company to create ids, grant access – logic ranging from simple to complex to sometimes weird, but all have logical explanations in the history of evolution of the company. However each IdM product comes with its own workflow syntax and semantics that is completely different from all other workflow systems in your company and requires integration with all other systems to come up with this logic. Since this kind of integration is expensive for the vendor, they take the route of copying the data from existing systems. This makes the vendor PS implementation easier but in the process, they are setting up operations nightmare down the road for data synchronization and data integrity. This approach is very shortsighted.
  5. Add to this the fact that most IdM customizations are written in a propeitory language that is arcane and known only to a few hundred folks (or thousand at best) in the entire world. These folks are expensive, often work for the vendor or their partners (Disclaimer: I am one of them. And yet, truth should be told). You have to go back to the vendor for enhancements. Even your trained folks quit – what do you do? (Note: Even when Java is supported, it is very propreitory API. BTW, this is the best case scenario today.)
  6. Needless to say that a lot of these IdM products are built upon their legacy propreitory foundations, acquired products patched up together and not standards compliant.
  7. Products cost are justified and sold by their UI capabilities, which is nice facade to the underlying mechanism described above.
  8. You now have in your hands, a solution that is isolated from other systems, with only tactical integration at best, that has to be maintained by the security department not to mention the redundant IT infrastructure needed to run the IdM system, including but not limited to clustering, load balancing and troubleshooting!

Now you as a company end up with a solution that

  1. Resistant to customizations or collapses under customizations
  2. Need tweaks to your working processes to work within the realms of the product,
  3. Risk of paying too much to get any useful functionality relevant to your company
  4. No support for extensions and your hands tied without any other alternative.

This doesnt mean that Identity management product has no value. It does of course. However keep in mind that:

All you really wanted from the Identity Management product/solution is the core identity management capability for a reasonable price.

Yet the price is inflated to incorporate all the bells and whistles that you really don’t need

Sounds like you got a raw deal! So, is there a better approach? Sure there is. I will discuss this in my future blogs in this series.