“We had no idea that this would turn into a global and public infrastructure." – Vinton Cerf

As the Internet has grown to accommodate billions of identities, so has the need to systematically manage those identities. Without an organized way to store identity data, modern identity and access management operations would be virtually impossible, and chaos would ensue as individuals wrestle for access to required digital resources.

The directory services that have served us in the past, however, are not necessarily the ones that will serve us going forward. Currently, directory services in the form of LDAP Servers or RMDBS-based meta directories are the primary repositories in use. (I could also talk about Virtual Directories / LDAP Proxies, but those are special use cases.) But the organization of identity data has gone through a number of changes over the last fifteen years, especially with regards to the scale and the types of identities, and we need to reexamine how to best manage them within the directory framework.

In essence, we need to realize that when it comes to identity and access management (IAM), directory services in the enterprise is not necessarily the best approach for non-workforce use cases—and plan accordingly.

Directories and Related Services 

Before we look at where we’re headed, let’s take a moment to review how we got here.

In the early days of identity management, using an enterprise directory such as Microsoft’s Active Directory was the standard. This system would be used not only for storing identities, but also for the purposes of authentication and authorization for various connected systems. The goal was to connect as many systems as possible to this directory, with separate branches for non-corporate identities such as vendors, customers, suppliers and partners. Essentially, it was used to create a single silo of identity information, or an identity store, if you will. 

This worked fairly well as long as the use case for the directory was well specified, and there was little need for administrators to do anything other than executing backup and directory tuning activities. 

But in the past few years, the management of the identity store has grown much more complicated. The number of non-corporate identities stored in the directory, especially customer identities, is exploding as new apps are built, corporate acquisitions bring in additional directories, and users engage with brands across a growing number of channels. This results in a directory instance that is bloated and deep, decreasing the directory’s performance. 

Meta directories are excellent for acting as the backend for user provisioning and campaign compliance applications, but they don’t really work for high-volume use cases such as what we see in customer identity and access management (CIAM) authentication and authorization. Legacy directories aren’t engineered for peak usage and struggle with the attribute flexibility required in an environment of complex customer profiles. In addition, they don’t offer key security features like tamper-evident logs, admin alerts and admin data access limitations that are needed to protect consumer data.

Further expanding the issue, there is also an increasing need to administer these identities with regard to privacy and governance controls. Regardless of the type of identity being tracked, multiple laws mandate how these entries are managed. Remember above when I said administrators needed to do little more than ensure the directory was tuned and backed up back? That can’t really be the case when there is a constant need to address directory issues such as performance monitoring, editing attribute encryption settings, right to be forgotten, and connecting to an increasing array of on-premises and cloud-based systems. 

How to Evolve our Directory Infrastructure

Based on this evolution, it is time to consider a new architecture for the storage and maintenance of an organization’s identity data. In the early days of identity management, directory services were all about locating people and systems within a single network. But today, we need to grow this infrastructure to possibly look something like this:

We need to start reversing the trend of keeping all of our identities—customer, partner, employee, etc.—in one repository. Identities just don’t scale the way that they used to, and it doesn’t make sense to keep everything in one container. 

To be clear, I’m not talking about segregating any one individual’s identity data; unified profiles are critical to a smooth user experience. Unifying the data layer is essential in maintaining a single source of truth about your customers’ identities, attributes and preferences that is accessible to all applications. But your customer identity data set is very different from employee, partner and other identity data sets. Complex customer profile data includes unstructured data, and CIAM has security and scalability requirements that often go beyond those of IAM. 

By my way of thinking, deconstructing the current single silo into two separate CIAM and workforce IAM repositories brings about the following advantages:

1. Responsiveness. When we use separate identity stores, connecting applications have fewer entries to search, resulting in increased responsiveness. This also offers the option of dedicating resources to address application load on individual use cases (e.g., workforce and CIAM) rather than the combined solution. I think we can safely assume that the CIAM use case will require a different configuration and number of resources than what we find for enterprise applications. 
   
   
2. Security-based segregation. Enterprise directories are the front-line gateway to the network. When we separate the service, there is no chance to mix enterprise and non-enterprise identities. Every customer entry in the enterprise directory is another potential breach vector. The same applies for the non-enterprise directory service, where every enterprise user with access is potential data breach.
   
   
3. Better organization of data. The services only need to be as broad or deep as required for their use cases. No one likes a directory that is too broad or too deep. They are a hassle to navigate and administer, and keeping the identity stores segregated helps us achieve a more streamlined Directory Information Tree (DIT).

When we consider what needs to be done with the various types of identities being handled in today’s IT shops, it becomes more important than ever to consider how those identities are managed in modern infrastructure. We need to evolve our thinking about how this data is stored for various use cases. Creating organized repositories of data for access under the correct circumstances is critical for meeting use case, compliance and operational needs. Considering how we segment and store this data, especially as it relates to CIAM, is more critical than ever before.

To learn more about the unique requirements of CIAM, read our Ultimate Guide to Customer IAM.