Top Challenges Consolidating to a Central Identity Management System
Organizations manage a wide variety of identities. These include employees, contractors, customers, partners, vendors and prospects. Most organizations have grown organically or through mergers. They find their identity management (IDM) infrastructure spread out across the enterprise.
Figure 1: Distributed User Identity
Distributed Identity is difficult to manage and audit. Applications cannot be shared across the enterprise since they depend on a specific IDM. Customer and Employee applications cannot be consolidated.
For these reasons, most enterprises wish to consolidate their user directories to a single Identity Management System.
Figure 2: Target Consolidated Identity Management
It is tempting to approach directory management as a “Big Bang” with the entire user and customer base consolidating at once. At AssureBridge, we have worked with many clients undergoing directory consolidations and have found they face difficult challenges including:
Each User Directory is Different
Since each directory was implemented separately, they all have different schemas and attributes. Customer directories in particular often have large amounts of customer profile information such as preferences, billing codes etc.
Regulations, like GDPR, often restrict personal information about employees and customers from being stored across borders.
This is usually the number one objection to the Big Bang approach. Each application must be reworked to point to the new central directory, new user schema and new attributes. Converting all the applications at once is often not possible.
Consolidating everything to Active Directory is a problem
Active Directory (AD) is great for employee identity storage but not ideal for customer and prospect. In addition to licensing issues, most AD administrators do not wish to endanger the corporation by “polluting” the directory with all the extra fields and attributes required to support customers.
Consolidating everything to something other than Active Directory is a problem
It’s tempting to move everyone to a commercial or open-source LDAP directory. These directories have great track records and usually don’t charge per-user licenses. However, for any Microsoft Windows™ shop, operating without an AD is a non-starter. Windows depends on AD for file shares, windows, basic user login and a host of other functions.
Due to these challenges, most directory migration/consolidation projects never get off the ground. Finding the budget to migrate all enterprise applications at once is next to impossible. Diverting business and IT resources away from mission critical projects to a directory “Big Bang” is not feasible.
At AssureBridge, we have found our clients who successfully migrate to a central directory use the following best practices:
Plan for a consolidated end state
Examine the attribute and schema requirements of all the existing directory (LDAP, Active Directory, Database) and determine a single consolidated schema that will support them all. LDAP is particularly good for this since it supports the concept of object type. Users can be classified into different types (e.g. customer, partner, executive, prospect, etc.) with each type having a unique supporting set of fields.
Move the applications over to the new consolidated structure one at a time. Often, business requirements drive the migrations. For example, an application may be replaced or upgraded, or an application that used to be employee-only now needs to service partners as well.
Don’t Choose Between LDAP and Active Directory
Choose both! They each have their place. AD is needed for any windows shop and is the system of record for employees. LDAP is great for storing large quantities of customers and prospects and doesn’t need to incur huge per-user license costs.
Leave sensitive employee data in its own region
Privacy laws protect sensitive data such as an employee’s home address or taxpayer ID. But most applications only need non-personal data such as a user ID and email to function. The consolidated directory does not need to hold sensitive personal data from around the world in order to function.
Don’t store users in multiple directories
It is very tempting to duplicate users into multiple directories. This allows them to use the associated applications. But, this causes redundant data and leads to serious audit and cleanup problems down the road. Instead, each user should reside in only one directory for its system of record. If the user needs to be in another directory as well, use one-way, read-only replication.
Replication to a Central Directory (User Mart)
To facilitate gradual migration, our clients have placed an LDAP directory in front of each of the existing, legacy directories. Initially, the user mart is a consolidated, read-only directory. It contains the contents of all the other directories, converted to the new standard user schema.
Updates are only made to the legacy directories but then are replicated in near-real time to the user mart. This replications “normalizes” the user information from each directory into the new standard format. The applications that need combined data are gradually migrated to point to the central user mart directory. Passwords are still kept in the back-end directories but accessed via pass-through authentication when logging in via the user mart.
Figure 3: User Mart Migration in Progress
Eventually, after all applications are pointing to the new user mart, the legacy directories and customer database are retired. The user mart becomes the read/write system of record for all non-employee users. Active Directory houses only employees and remains the single source of employee data. The user mart can still support employee login by holding a minimal set of employee info and using pass-through authentication.
By using a staged, migration strategy. Our clients have been able to achieve directory consolidation over time without getting stymied by the giant hurdle of big-bang consolidation.