Virtual directory servers allow you to gather the information that is contained in heterogeneous sources and present it to users as a consolidated view that appears to be coming from one central repository. Virtual directories provide an abstraction layer between disparate data stores, such as payroll systems, HR systems, Active Directory, and others, that allows information consumers to interact with the information contained in those systems without actually connecting to ;them. The virtual directory receives the queries, retrieves the appropriate data from each backend system and sends it to the user in the form of a virtualized view. For example, many organizations may have more than one repository for holding user information. An HR system may hold one set of attributes, Active Directory may hold another, and yet another application may hold even more. The identities in each of these systems is only a "partial identity." To gain a fuller representation of those identities requires accessing each system separately. Virtual directories make it possible to pool the attributes from each of those systems for a more complete user profile. In this way, virtual directories can act as a type of Identity Warehouse, containing information from multiple authoritative sources that can be aggregated in response to queries made against its tree structure, similar to how views can be used to consolidate database tables. Information consumers can avoid querying multiple systems, combing through attributes until they have enough to create a composite. The virtual directory server can be instructed to do the combing for them based on the rules applied to it.
The following image depicts what this relationship looks like. In the image, information consumers—which could be people or applications—do ;not "talk" directly to each identity store; instead they talk to the virtual directory. The virtual directory responds to the queries by retrieving data from the backend systems and presenting it to the information consumers in the form of a consolidated view.
Usually this transaction occurs transparently with users being unaware of the layer that exists between them and their data. However, because many virtual directories depend on live data pulls, problems can and do occur, such as when a connected system moves offline or if one or more of the connected systems simply responds slowly. Because the view being presented is a composite of culled attributes, problems in one system can cause undesirable consequences across the board. To counter issues like these and speed up response times, many virtual directories store the data they pull in caches or—in more advanced scenarios—employ "sync stores." Sync stores are abbreviated versions of metadirectories that give virtual directories the ability to pull data into a more centralized repository where it can be maintained and synchronized with the authoritative backend systems as necessary. This scenario is represented by the below image.
The EmpowerID LDAP Server is not just a read-only application, however. CRUD operations can be initiated against any of the objects represented by the EmpowerID LDAP Server from any LDAP client. These operations are not simply LDAP calls that are forwarded to the back-end source directory to modify the users or groups contained therein. Instead, the LDAP client actions initiate EmpowerID workflows that can create, delete, and update user accounts and/or groups within the source LDAP directory or even across all connected systems. For example, one of the EmpowerID LDAP workflows is the LDAPCreateAccount workflow. This workflow allows users to create a new user account (or submit a request that a new user account be created, depending on their delegations) in the EmpowerID LDAP Server. EmpowerID processes the request in the same manner as it does for non-LDAP requests and either allows the account to be provisioned or routes the request to any users with the ability to approve the request. If the user initiating the workflows has the authority to complete the workflow or if an approver grants the request, EmpowerID can provision the account across all connected systems—in the HR system, in Active Directory, as well as provision a new EmpowerID Person linked to that account, granting to that person any resources to which the new account allows her to have, such as an Exchange Mailbox or a home folder. Similarly, if an account is deprovisioned via the LDAP client, EmpowerID can deprovision the account in each connected system, remove any resource entitlements the person received and terminate the EmpowerID Person associated with the account.
Additionally, because the EmpowerID LDAP Server is an extension of EmpowerID, identities for external users, such as customers or partners, can be created and granted access to internal resources without the need for creating new silos or adding additional user accounts to your existing directories. Instead, you can create an EmpowerID Person, which itself is an LDAP object, for each of these users and then grant those Persons abilities within your directories as needed. Once users have an EmpowerID Person, you can apply any of your EmpowerID policies against them, from requiring they use second-factor authentication to access (RBAC-trimmed) resources to allowing them to use SSO to federate their EmpowerID identities with other trusted entities
As with any type of access to resources in EmpowerID, the EmpowerID Virtual Directory requires users to be identified by and authenticated against the EmpowerID Identity Warehouse before they can do anything within EmpowerID. This means that users of the EmpowerID LDAP Server must have an EmpowerID Person object linked to at least one of the user accounts in the account stores that comprise the virtual directory. However, users do not need to use the credentials of their EmpowerID Person or even have knowledge of those credentials to gain access to the virtual directory. This is because the EmpowerID LDAP Server supports a number of binding methods by which users can be authenticated using their username and password maintained in another system, including anonymous binding, simple binding, and simple binding with TLS/SSL. Additionally, the EmpowerID LDAP server supports second factor authentication for enhanced security.
As the EmpowerID LDAP Server provides for a number of authenticating methods, users can identify themselves equally to the LDAP Server in one of the following ways:
When the EmpowerID LDAP Server receives a bind request, it determines the type of credentials the client is attempting to bind and processes the request in one of the following ways:
From a high level, this process looks like the below image.
In step 1, the client submits credentials in any one of the accepted formats. In step 2, the EmpowerID LDAP Server parses the credentials and checks for a corresponding Person object matching those credentials in the EmpowerID Identity Warehouse. In step 3, the Password Manager Policy is checked to see if Second Factor Authentication is required for that Person, and in step 4, the credentials are verified against the appropriate account store. Once these steps have successfully been completed, the user is granted access to any delegated resources according to your access policies.