Top IDM Challenges when Exposing Internal Applications to Customers

Companies are increasingly providing direct systems access to their customers.  This streamlines service, improves satisfaction and fosters a sense of community. Systems such as inventory, billing, ticketing and custom business applications are made available via the web directly to customers, partners, suppliers and prospects.

Figure 1: Shared and Internal Only Applications

At AssureBridge, we have worked with many clients that are moving from an employee only access to customer access strategy and we have encountered the following Identity Management challenges:

Scale

Companies that have a few hundred to a few thousand employees may have tens of thousands to millions of customers, partners, suppliers and prospects.  Existing Identity Managements systems now need to scale by orders of magnitude.  The administrative challenges are worse.  New accounts, forgot passwords, directory maintenance, account expiration is now a huge job that the existing IT and help desk cannot keep up with.

Managing Access Rights

Now that customers have access to systems, the access rights need to be much more fine-grained.  For example, a customer accessing billing system can see and pay their own bill but not others.  Nor can they edit billing information.  All this information needs to be standardized stored.

Active Directory “Pollution”

Active directory may be fine for internal employees, but once the Identity Management population expands, large amounts of application-specific information needs to be stored,  for example, roles, inventory codes, app preferences, etc.  Typically,  Active Directory (AD) is a mission-critical IDM vital for the proper functioning of the internal infrastructure.  AD administrators are very reluctant to jeopardize this by “polluting” the AD with many thousands of outside customers each with dozens of new attributes.

Customer Synchronization

When the customers include large organizations, they do not wish to manually enter each employee into your system.  They expect you to synchronize with their existing directories either via feeds, single sign-on or both.  They also expect you to maintain compliance with timely deactivation when their employees if they are terminated.  Even your smaller customers expect to be able to manage their employees via spreadsheet upload.

Keeping Applications Separated

When employees sign-in, they typically have access to the entire application ecosystem. Customers that sign-in, must be strictly restricted from internal-use-only applications like payroll and benefits.


Some short term strategies for addressing these issues include:

Add customers to application databases

Let’s say the customers will need access to a custom application (for example a portal) plus the billing system.  The billing system is capable of storing users so just add all the external users to the billing system.  The user info ends up in the billing system’s back end database.  The other shared applications are pointed to the billing system’s database as well so they can access the user info.  There are two major issues with this.  A business application (portal) is now the system of record for the customers, so customers must be in the billing system whether they need to use it or not.  Further, the portal and the billing system are both used by internal employees, therefore, both the portal and the billing system must be able to look for users both in the back-end database and in the employee Active Directory.  Most application packages are not capable of dual-sourcing identity.

Expand the existing employee directory

Many start by adding the new customers to the existing Active Directory.  Possibly, they create a separate AD just for customers and federate the two.   This approach can work well if there are not that many customers, but it does not address the Active Directory “pollution” problem in that AD will need dozens if not hundreds of custom attributes added to support the applications.  Further, for large amounts of customers, prospects and partners,  the specialized AD staff now needs to take on many thousands of new users in the active directory for administration.  AD licensing costs can also get out of hand quickly.

Create a specialized directory just for customers

Many organizations create a new directory either using and LDAP tool or a relational database.  This usually is very cost effective but it still does not solve the issue that most applications cannot simultaneously use more than one directory.  Users are now split between the new directory and the existing AD.  It also does not solve the administration problem since LDAP tools are powerful but also dangerous, requiring skilled administrators to manage the huge number of new customers.

User Mart Strategy

The strategy that has worked best for our clients is a User Mart hybrid approach that keeps the Active Directory in place but augments it with an LDAP-based user mart which stores the Customer identity.  The User mart also front-ends the Active Directory, making it appear that all the Users (customers and employees) are in one location.

Figure 2: User Mart Hybrid IDM Strategy

The User Mart strategy places a directory in front of the existing active directory.   A commercial-grade LDAP, the mart can easily store up to millions of customers, vendors and prospects.  A number of high quality, commercial and open-source LDAP solutions are available that do not charge per-user licensing fees.  One-way sync is then implemented in real/near time from the Active Directory, assuring that the user mart also contains the employee accounts.  Pass-through authentication is used to allow the user mart to accept employee login requests even though the passwords are only stored and managed in AD.  Since both employee and non-employee identity is now stored in a single directory, applications that are shared between employees and customers can point at the single user-mart LDAP.  Virtually all applications that support user identity will support this configuration.

Since the mart is not part of Active Directory, numerous application specific permissions and attributes can be added here, both for employees and customers. For employees, the mart accepts these extra attributes, but treats the standard AD info (email, employeeId, dept number, etc) as read only. This supports fine-grained access into the shared applications without polluting the active directory.

It’s essential that the user mart be an enterprise-class directory since the shared applications will depend on it.  It needs robust high availability and backup and the synchronization must be rock solid.

One-way sync can also be used to capture customer user feeds so that the user mart is automatically populated with customer data without the need for manual entry and maintenance.   It is important to make sure these feeds not only add and update user data but can inactivate and delete it when the users leave the customers place of business.

Our clients have found it useful to front-end the mart with help desk and self-service utilities to allow for both help desk, self-service and delegated management.  The most common features needed are spreadsheet based upload of users, user self-service password change/reset, and simplified front end for entering/updating user permissions to the applications.  In particular, delegating client update and management to customer representatives greatly reduces the help desk load.

Our clients often pair this solution with standards-based single sign-on (SSO).  This allows both users and employees to seamlessly move between the various systems. The access control needs to be linked to the SSO to assure customers cannot connect with internal-only systems.

Front-ending the Active Directory with a commercial or open-source LDAP avoids the complexities and license fees of expanding AD while future-proofing the entire application eco system to support employees, customers, partners and prospects.