Virtual directory

Virtual directories can have some or all of the following capabilities:[3]

• Aggregate identity data across sources to create a single point of access.
• Create high-availability for authoritative data stores.
• Act as identity firewall by preventing denial-of-service attacks on the primary data stores through an additional virtual layer.
• Support a common searchable namespace for centralized authentication.
• Present a unified virtual view of user information stored across multiple systems.
• Delegate authentication to backend sources through source-specific security means.
• Virtualize data sources to support migration from legacy data stores without modifying the applications that rely on them.
• Enrich identities with attributes pulled from multiple data stores, based on a link between user entries.

Some advanced identity virtualization platforms can also:

• Enable application-specific, customized views of identity data without violating internal or external regulations governing identity data. Reveal contextual relationships between objects through hierarchical directory structures.
• Develop advanced correlation across diverse sources using correlation rules.
• Build a global user identity by correlating unique user accounts across various data stores, and enrich identities with attributes pulled from multiple data stores, based on a link between user entries.
• Enable constant data refresh for real-time updates through a persistent cache.

Virtual directories:

• Enable faster deployment because users do not need to add and sync additional application-specific data sources
• Leverage existing identity infrastructure and security investments to deploy new services
• Deliver high availability of data sources
• Provide application-specific views of identity data which can help avoid the need to develop a master enterprise schema
• Allow a single view of identity data without violating internal or external regulations governing identity data
• Act as identity firewalls by preventing denial-of-service attacks on the primary data-stores and providing further security on access to sensitive data
• Can reflect changes made to authoritative sources in real-time
• Leverages existing update processes of authoritative sources, so no separate (sometimes manual) process to update a central directory is needed
• Present a unified virtual view of user information from multiple systems so that it appears to reside in a single system
• Can secure all backend storage locations with a single security policy

An original disadvantage is public perception of "push & pull technologies" which is the general classification of "virtual directories" depending on the nature of their deployment. Virtual directories were initially designed and later deployed with "push technologies" in mind, which also contravened with privacy laws of the United States. This is no longer the case. There are, however, other disadvantages in the current technologies.

• The classical virtual directory based on proxy cannot modify underlying data structures or create new views based on the relationships of data from across multiple systems. So if an application requires a different structure, such as a flattened list of identities, or a deeper hierarchy for delegated administration, a virtual directory is limited.
• Many virtual directories cannot correlate same-users across multiple diverse sources in the case of duplicate users
• Virtual directories without advanced caching technologies cannot scale to heterogeneous, high-volume environments.

• Unify metadata: Extract schemas from the local data source, map them to a common format, and link the same identities from different data silos based on a unique identifier.
• Namespace joining: Create a single large directory by bringing multiple directories together at the namespace level. For instance, if one directory has the namespace "ou=internal,dc=domain,dc=com" and a second directory has the namespace "ou=external,dc=domain,dc=com," then creating a virtual directory with both namespaces is an example of namespace joining.
• Identity joining: Enrich identities with attributes pulled from multiple data stores, based on a link between user entries. For instance if the user joeuser exists in a directory as "cn=joeuser,ou=users" and in a database with a username of "joeuser" then the "joeuser" identity can be constructed from both the directory and the database.
• Data remapping: The translation of data inside of the virtual directory. For instance, mapping “uid” to “samaccountname,” so a client application that only supports a standard LDAP-compliant data source is able to search an Active Directory namespace, as well.
• Query routing: Route requests based on certain criteria, such as “write operations going to a master, while read operations are forwarded to replicas.”
• Identity routing: Virtual directories may support the routing of requests based on certain criteria (such as write operations going to a master while read operations being forwarded to replicas).
• Authoritative source: A "virtualized" data repository, such as a directory or database, that the virtual directory can trust for user data.
• Server groups: Group one or more servers containing the same data and functionality. A typical implementation is the multi-master, multi-replica environment in which replicas process "read" requests and are in one server group, while masters process "write" requests and are in another, so that servers are grouped by their response to external stimuli, even though all share the same data.

The following are sample use cases of virtual directories:

• Integrating multiple directory namespaces to create a central enterprise directory.
• Supporting infrastructure integrations after mergers and acquisitions.
• Centralizing identity storage across the infrastructure, making identity information available to applications through various protocols (including LDAP, JDBC, and web services).
• Creating a single access point for web access management (WAM) tools.
• Enabling web single sign-on (SSO) across varied sources or domains.
• Supporting role-based, fine-grained authorization policies
• Enabling authentication across different security domains using each domain’s specific credential checking method.
• Improving secure access to information both inside and outside of the firewall.