Unified/centralized Identity Management is the goal of many if not most organizations.  Let’s consolidate our numerous separate directories and applications under a common, centralized and federated directory to simplify user and rights management.  A large industry has emerged to assist with this task with sophisticated (read expensive) tools.  Yet, after initial, painful forays into consolidating identity most employees charged with the task find themselves frustrated and discouraged at how daunting the task is.  Why is such a basic goal as IDM so elusive?

There are a number of reasons.

  1. The applications are against you.  Most IDM tools rely on the premise that each and every application will be “adjusted” to use the central directory.  The applications usually have other ideas.  Some applications only support: users in their own proprietary database.  Some applications only support a specific type of directory such as Microsoft Active Directory or Oracle LDAP.  Many applications will allow users to authenticate,  against an external directory, like an LDAP, but they still insist on storing a record for each user in their database.
  2. Too many standards.  Its been said, the great thing about standards is that there are so many of them. This truism definitely applies to identity management.  Even when applications support an identity standard, they will usually support one of many.  Application standards for development include Jesse and JNDI for java, forms based and MVC based for .NET,  Kerberos, and CAS for local federation OpenID, OAuth, SAML and WS-Federation for Single Sign-On.  Trying to get a set of locally developed and commercial software packages to agree to use a single method is near impossible.
  3.  Authorization is an even bigger can of worms.  While many applications support some form of external authentication, virtually all applications have a proprietary scheme for granting authorization to app data and functions.  Getting even two applications to agree on a central set of roles and permissions is very rare.
  4. All politics is local.  The job of centralizing identity usually falls to someone in the infrastructure group.  They quickly find that each existing directory has an owner/champion that is very reluctant to give up control of their local domain since it is so critical to the business functions that rely on it. Similarly, each application has an owner.  Asking the application owner to modify the application to work with a new central identity system involves competing for scarce development resources that have probably been committed to providing new business function enhancements. Further, with the increasing use of cloud-based systems such as CRM, ERP, incident management, etc., companies find that they are dealing with external systems that are managed by third parties and cannot be modified to fit a particular identity management system.
  5. All or nothing.  Most identity management systems don’t start to pay off until they have all or most of the applications under their control.  Until then, the new IDM is just one more directory in the mix.  For reasons 1 – 4, this will be a very long time coming.

Before getting too discouraged with central IDM, it’s a good idea to take a step back and look at why you want identity management in first place.  This will help get a practical solution into perspective.

The most common reasons sited include:

  1. A single source of “truth”.  Companies want to have a single place to determine which employees, customers, clients, partners have access to corporate resources.  They want each user to be known by a single Id.  They do not want users logging into multiple systems with separate sets of user ids and passwords.  They also want additional information such as user phone, address, department, etc. to be centralized and consistent.
  2. Fulfill termination requirements.  Legal and contractual requirements demand the “immediate” removal of user from systems when the user relationship with the company ends.  If users are scattered amonng multiple systems using multiple sign-on ids, compliance becomes very difficult.
  3. Support single sign-on.  The ability to sign into multiple systems without entering user ids and passwords multiple times.
  4. Central authorization.  Although levels of access are often application-specific, some companies wish for broad assignment of roles (such as Supervisor) that grant  particular sets of authorities across multiple systems.

These are all laudable goals; however, the cost of implementation given the hurdles above is hard to justify. Yet, do we really need to overhaul the complete application base to achieve these benefits?  By focusing less on re-writing applications, and more on synchronization and federation, a centralized identity can be phased in over time while realizing most of the needed features in the short term.

At AssureBridge, we have seen considerable success with a practical, phased approach to identity management.

The major steps are as follows:

  1. Design a central identity store to capture all required employee data.  While leaving the existing directories in place, design the “ideal” user directory store as if you were starting from green field.  This includes concepts such as fixed ID numbers so users can change their names, emails, etc without major disruptions.  Required information for customers and partners as well as employees.  A flattened directory hierarchy so that the directory is relatively immune to organizational changes.  Then, looking at the existing directories, add in the legacy information such as existing systems ids to allow for cross reference.  At AssureBridge, we prefer to use proven, powerful, open-source LDAP directories that can scale up to millions of users at a very low cost and cluster them into highly available configurations to assure continuous availability.
  2. Use advanced synchronization services to populate the central directory.  Getting as close to the existing identity sources as possible to create real-time feeds into the new, central directory.  This would include any feeds that populate any of the existing directories, or if need be use the existing directories themselves.  Internal employees are often stored in a Microsoft Active Directory which ties into the company domain.  We have found that it is best to leave this directory in place permanently and perform continuous sync into the central directory which also contains all external users such as customers and partners.  By using pass-through authentication, employees logging in via the central directory can use their existing AD password. Using the legacy IDs as a cross-reference, the new directory now has a single record for every user, yet it is accessible to the legacy applications without each application  having to re-create every user.  At AssureBridge, we use our SyncFire TM identity synchronization service to provide guaranteed user sync and also convert user’s information from existing databases and directories into the new, standard format using rules-based transforms. At this point, the new directory becomes the single source of user information.
  3. Use the central directory to populate downstream, “specialty directories”. For applications that must use their own directory such as a SaaS application or an app with a proprietary database, use the same synchronization services to provide real-time sync from the central database to the applications’s directory. This way, changes only need to be made into the central directory and they automatically propagate to the downstream directories. 
  4. Over time, migrate the existing applications to the new central directory.  As stated above, every application is different.  Some applications can simply be pointed to the new directory and take advantage of the cross-reference data to continue operating as usual.  Other applications insist on their own, proprietary  directory; in this case, treat it like a downstream specialty directory using the central directory as the source.  For applications that support single sign-on, use we use AssureBridge SAMLConnect to integrate the applications via SSO, using the central directory as the Identity Provider.
  5. Implement central authorization only where desired.  Many applications have privileges that only make sense to the local application (e.g. receive daily finance report permission).  These privileges can stay with the application.  For more general roles such as corporate supervisor, the related permissions are defined the central directory.  They can then be retrieved by each application based on the application’s preferred method.  This may  include accessing the central directory directly, propagation by sync into the downstream directory/database or inclusion in the assertion claim of single sign-on. 

At AssureBridge, we have found this strategy of working with the applications instead of against them to be the most practical approach for delivering all the intended benefits of identity management.  There is a single source of truth, terminated employees are removed from all systems immediately,  users achieve single sign-on, and key central roles can be implemented.  We have been able to implement major systems in 2-3 months rather than the multi-year projects that are typically stated.  Adding new applications no longer pose a identity nightmare since their are multiple integration options into the IDM instead of just one.  

For more information on the AssureBridge Identity 360™ approach to practical identity management, please click here.