Virtual directory servers allow you to gather the information that is contained in enable the collection of information from various heterogeneous sources and present it to users as a consolidated view that appears to be coming from one , appearing as if it originates from a single central repository. Virtual directories provide create an abstraction layer between disparate different data stores, such as:
payroll Payroll systems
HR systems
Active Directory
othersOthers
Virtual These virtual directories allow information consumers users to interact with the information contained in those these systems without actually directly connecting to them. The virtual directory receives processes queries, retrieves the appropriate relevant data from each back-end system, and sends delivers it to the user in the form of as a virtualized view. For exampleinstance, many organizations may have more than one repository for holding multiple repositories for storing user information.:
An HR system may hold one set of attributes
Active Directory may hold another
Yet another Another application may hold more
The identities in In each of these systems, the user's profile is only partially complete, or a "partial identity." To gain o get a fuller comprehensive representation of those user identities, you need to access it would typically require accessing each system separately. Virtual directories make it possible to pool the attributes from each of those systems for individually.
However, virtual directories facilitate the aggregation of attributes from these systems, resulting in a more complete user profile. In this waymanner, virtual directories act function as an Identity Warehouse, containing information from multiple authoritative sources that can be aggregated combined in response to queries made against its tree structure, similar to how views can be used to consolidate database tables. Information consumers Users can avoid querying multiple systems , combing and sifting through attributes until they have enough to create a composite. The Instead, the virtual directory server can be instructed to do the combing for them perform this task based on the applied rules applied to it.
The following image depicts what diagram illustrates this relationship looks like. In the image, information consumers – which could which could be people or applications – do not "talk" directly to do not communicate directly with each identity store; instead, they talk to interact with 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.
...
EmpowerID's Implementation of the Virtual Directory
The EmpowerID's Virtual Directory is : An Implementation of the LDAP Virtual Directory Server
EmpowerID's implementation Virtual Directory is an innovative adaptation of an LDAP virtual directory server. It was built Developed using a stateless Node.js architecture. Node.js is a platform built on , this platform leverages Chrome's JavaScript runtime for building to build fast, scalable network applications, and uses an . With its event-driven, non-blocking I/O model that makes , it is efficient and lightweight and efficient, perfect making it ideal for handling data-intensive real-time applications that run across operate over distributed devices.
As with other Like most virtual directory servers, the EmpowerID LDAP Server allows you to create consolidated creates unified views of the user data that lives in disparate residing across various heterogeneous account stores. Like the more "advanced" versions of virtual directories mentioned above, the EmpowerID LDAP Server has the ability to maintain It also aligns with more advanced virtual directory models by supporting data synchronization with any connected linked user repositories. However, unlike many other virtual directory servers, the EmpowerID LDAP Server does not rely on A distinguishing factor of EmpowerID's LDAP Server is its independence from live data pulls; thus, there is never an issue with slow , which eliminates any delays in responses due to an unstable system instability.
And because Furthermore, the EmpowerID LDAP Server is an extension of the EmpowerID platform, meaning it has the full power backing of the EmpowerID synchronization engine standing behind it. Attributes . Consequently, attributes from any connected linked account store always remain up to dateare consistently updated, with any authoritative changes to those attributes being processed and pushed distributed to each relevant system based on according to the attribute flow rules you set for those systems—regardless of where those changes originated. This means that if a change occurs within systems. This applies regardless of the origin of these changes. For instance, if a modification occurs in an HR system, the change is not only will that change be reflected in any new views served up generated by the EmpowerID LDAP Server , it will be but is also propagated in real time to every other connected system where housing that attribute lives as well.
The EmpowerID LDAP Server is not just merely a read-only application, however. It enables CRUD operations can be initiated (Create, Read, Update, Delete) operations against any of the objects represented by the EmpowerID LDAP Server objects it represents from any LDAP client. These operations are not simply just LDAP calls that are forwarded to the back-end source directory for modifications to modify the users or groups contained therein. LDAP Instead, LDAP client actions initiate trigger EmpowerID workflows that can create, delete, and update user accounts and/or groups within the source LDAP directory as well as and across all connected systems.
For A typical workflow, for example, one of the EmpowerID LDAP workflows is the LDAPCreateAccount workflow. This workflow allows It permits users to create establish a new user account (or submit a request that for 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 handles this request similarly to non-LDAP requests and by either allows allowing the account to be provisioned or routes routing 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 requestcapable of approving it.
Once authorized by either a user with the requisite authority or an approver, EmpowerID can provision the account across all connected systems: in , including the HR system , in and Active Directory, as well as provision and even create a new EmpowerID Person linked to that account, granting to that person any resources to which the new account allows her to have. The new account also inherits any resource entitlements, such as an Exchange Mailbox or a home folder.
SimilarlyLikewise, if an account is deprovisioned de-provisioned via the LDAP client, EmpowerID can deprovision revoke the account in each connected system, remove any associated resource entitlements the person received , and terminate the EmpowerID Person associated with the account.
...
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.
...
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.
...