As the number of directories started to grow some 30 years ago, one approach was to build solutions that tied these directories together, and presented a view of the information from multiple sources. The way this is explained in Wikipedia is as follows (April 2022):

• A metadirectory system provides for the flow of data between one or more directory services and databases, in order to maintain synchronization of that data, and is an important part of identity management systems. The data being synchronized typically are collections of entries that contain user profiles and possibly authentication or policy information. Most metadirectory deployments synchronize data into at least one LDAP-based directory server, to ensure that LDAP-based applications such as single sign-on and portal servers have access to recent data, even if the data is mastered in a non-LDAP data source. 

• Metadirectory products support filtering and transformation of data in transit. 
• Most identity management suites from commercial vendors include a metadirectory product, or a user provisioning product. 

In 2000 however, Microsoft launched Windows 2000, with a new architecture that was very reliant on a new directory named “Active Directory” (AD). The name is to some extent misleading, because it is a fairly passive directory. There are some features that have become popular, that have some active components, with the Group Policy “push” and software deployments being the most common. 

The big change AD created in 2000, was that all application vendors had to adapt their solutions to AD. AD was almost LDAP, and introduced its own schemas, that few were brave enough to change. AD became the mountain, that everyone went to. 

One of the challenges with AD is it reliance on some internal network protocols (I.e. Kerberos) and security models. As applications dared to break away from the local network, Microsoft’s first response was ADFS, and most organizations used it as its first step in integrating applications outside. 

In 2009 the SVP of Engineering (Todd McKinnon) and a solution engineer (Frederic Kerrest) at Salesforce saw the growing need for a true identity source in the cloud as a SaaS.  During their first ten years, most of their business was about going to the “mountains” that started appearing in the cloud, such as Salesforce, ServiceNow, Box, Microsoft and Google. 

When I joined Okta as the first solution engineer in the Nordics, I saw the value of having a “gofer” that ran around and talked to the mountains. Over the years, Okta became a mountain by itself, and required the applications to take over the work of integrations. Their nice feature, the discovery of applications’ identities as a first step in integration, was not followed up in terms of using the applications as a source (except a number of HR systems, Google, Microsoft AD (not Azure AD) and LDAP. Okta has a lot of value in what they still deliver, but I decided to step outside of Okta and continue to help organizations to build bridges with what I call a true metadirectory, very much in line with Wikipedia’s definition. 

A true metadirectory is, in my view, a process that does not host the truth by itself, but collects the truth from the sources that hold the truth. I believe that data should managed and owned where the knowledge sits. This means that a metadirectory needs to understand how to prioritize each attribute and group membership per user type. Because of the true metadirectory being sourced from other systems, you can run multiple instances of it, using the same sources.