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
others
Virtual directories allow information consumers to interact with the information contained in those systems without actually connecting to them. The virtual directory receives queries, retrieves the appropriate data from each back-end 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
Yet another application may hold more
The identities in each of these systems is only a "partial identity." To gain a fuller representation of those identities, you need to access 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 act as an 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 back-end 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 Identity Warehouses 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.
EmpowerID's Implementation of the Virtual Directory
The EmpowerID Virtual Directory is EmpowerID's implementation of an LDAP virtual directory server. It was built using a stateless Node.js architecture. Node.js is a platform built on Chrome's JavaScript runtime for building fast, scalable network applications, and uses an event-driven, non-blocking I/O model that makes it lightweight and efficient, perfect for data-intensive real-time applications that run across distributed devices.
As with other virtual directory servers, the EmpowerID LDAP Server allows you to create consolidated views of the user data that lives in disparate heterogeneous account stores. Like the more "advanced" versions of virtual directories mentioned above, the EmpowerID LDAP Server has the ability to maintain data synchronization with any connected user repositories. However, unlike many other virtual directory servers, the EmpowerID LDAP Server does not rely on live data pulls; thus, there is never an issue with slow responses due to an unstable system.
And because the EmpowerID LDAP Server is an extension of EmpowerID, it has the full power of the EmpowerID synchronization engine standing behind it. Attributes from any connected account store always remain up to date, with any authoritative changes to those attributes being processed and pushed to each relevant system based on the attribute flow rules you set for those systems—regardless of where those changes originated. This means that if a change occurs within an HR system, not only will that change be reflected in any new views served up by the EmpowerID LDAP Server, it will be propagated in real time to every other connected system where that attribute lives as well.
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. LDAP client actions initiate EmpowerID workflows that can create, delete, and update user accounts and/or groups within the source LDAP directory as well as 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 Person objects 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
Authenticating to the EmpowerID LDAP Server
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.
Users without an EmpowerID Person can view data as an anonymous user; however, any attempts to run operations against that data will be denied.
How the EmpowerID LDAP Server Identifies Users
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. Along with a valid password, they can enter:
the DN of their EmpowerID Person
such as cn=Terry Adams,cn=people,o=empoweridthe simple logon for their EmpowerID Person
such as tadamsthe DN for an external LDAP system that EmpowerID knows about
such as cn=Terry Adams,ou=London,ou=Offices,cn=tdnfdemo,cn=directories,o=empoweridthe SAMAccountName of an account in an external LDAP system that EmpowerID knows about
such as tadamsthe netbios of an account in an external LDAP system that EmpowerID knows about
such as tdnfdemo/tadamsor present the user principal name of an account in an external LDAP system that EmpowerID knows about
such as tadams@tdnfdemo.comor they can forgo credentials and submit an anonymous request
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:
In the case of a DN submission, the LDAP Server checks to see if the DN is the DN for a valid EmpowerID Person.
If it is, then EmpowerID authenticates the person against EmpowerID.
If it is not an EmpowerID DN, but a DN to an account in an external system that is linked to an EmpowerID Person, EmpowerID authenticates the user against that external system by making a binding request to the DC for that account store.
If the user name has backslash with first part being a netbios name matching the netbios name of an external system that EmpowerID knows about then EmpowerID authenticates the user against that external system by making a binding request to the DC for that account store.
If the username has the ampersand symbol in it, the LDAP Server determines it to be in UPN format, and checks to see if the suffix exists in the EmpowerID Identity Warehouse for a connected system.
If it does, EmpowerID authenticates the user against that external system by making a binding request to the DC for that account store.
If the username is not in any of the above formats, EmpowerID checks to see if the logon is the logon for an EmpowerID Person and authenticates the person against EmpowerID.
If the username does not belong to an EmpowerID Person, but to an account that is linked to an EmpowerID Person, EmpowerID authenticates the user against that external system by making a binding request to the DC for that account store.
If the LDAP Policy for the Password Manager Policy applied to the user calls for second factor authentication (or if second-factor authentication is set on the Person object itself), EmpowerID checks the password submitted by the user for the inclusion of the six-digit OATH token that has been registered to the Person in the EmpowerID Identity Warehouse.
If the token matches, EmpowerID strips the token from the password and either matches the password to that for an EmpowerID Person or, in the case of an external user, passes the password, along with the username to the external system.
From a high level, this process looks like the below image.
The client submits credentials in any one of the accepted formats.
The EmpowerID LDAP Server parses the credentials and checks for a corresponding Person object matching those credentials in the EmpowerID Identity Warehouse.
The Password Manager Policy is checked to see if Second Factor Authentication is required for that Person.
The credentials are verified against the appropriate account store.
Once these steps are successfully completed, the user is granted access to any delegated resources according to your access policies.
