EmpowerID Virtual Directory Server Overview

Virtual directory servers enable the collection of information from various heterogeneous sources and present it as a consolidated view, appearing as if it originates from a single central repository. Virtual directories create an abstraction layer between different data stores, such as:

• Payroll systems

• HR systems

• Active Directory

• Others

These virtual directories allow users to interact with the information contained in these systems without directly connecting to them. The virtual directory processes queries, retrieves relevant data from each back-end system, and delivers it to the user as a virtualized view. For instance, many organizations may have multiple repositories for storing user information:

• An HR system may hold one set of attributes

• Active Directory may hold another

• Another application may hold more

In each of these systems, the user's profile is only partially complete, or a "partial identity." o get a comprehensive representation of user identities, it would typically require accessing each system individually.

However, virtual directories facilitate the aggregation of attributes from these systems, resulting in a more complete user profile. In this manner, virtual directories function as an Identity Warehouse, containing information from multiple authoritative sources that can be combined in response to queries made against its tree structure, similar to how views consolidate database tables. Users can avoid querying multiple systems and sifting through attributes to create a composite. Instead, the virtual directory server can perform this task based on the applied rules.

The following diagram illustrates this relationship. In the image, information consumers – which could be people or applications – do not communicate directly with each identity store; instead, they interact with the virtual directory. The virtual directory responds to queries by retrieving data from the back-end systems and presenting it to the information consumers in the form of a consolidated view.

Open

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.

Open

EmpowerID's Implementation of the Virtual Directory

EmpowerID's Virtual Directory: An Implementation of the LDAP Virtual Directory Server

EmpowerID's Virtual Directory is an innovative adaptation of an LDAP virtual directory server. Developed using a stateless Node.js architecture, this platform leverages Chrome's JavaScript runtime to build fast, scalable network applications. With its event-driven, non-blocking I/O model, it is efficient and lightweight, making it ideal for handling data-intensive real-time applications that operate over distributed devices.

Like most virtual directory servers, the EmpowerID LDAP Server creates unified views of user data residing across various heterogeneous account stores. It also aligns with more advanced virtual directory models by supporting data synchronization with any linked user repositories. A distinguishing factor of EmpowerID's LDAP Server is its independence from live data pulls, which eliminates any delays in responses due to system instability.

Furthermore, the EmpowerID LDAP Server is an extension of the EmpowerID platform, meaning it has the full backing of the EmpowerID synchronization engine. Consequently, attributes from any linked account store are consistently updated, with any authoritative changes processed and distributed to each relevant system according to the attribute flow rules set for those 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 reflected in new views generated by the EmpowerID LDAP Server but is also propagated in real time to every other connected system housing that attribute.

The EmpowerID LDAP Server is not merely a read-only application. It enables CRUD (Create, Read, Update, Delete) operations against any objects it represents from any LDAP client. These operations are not just LDAP calls forwarded to the back-end source directory for modifications to users or groups. Instead, LDAP client actions trigger EmpowerID workflows that can create, delete, and update user accounts and/or groups within the source LDAP directory and across all connected systems.

A typical workflow, for example, is the LDAPCreateAccount workflow. It permits users to establish a new user account (or submit a request for a new account, depending on their delegations) in the EmpowerID LDAP Server. EmpowerID handles this request similarly to non-LDAP requests by either allowing the account to be provisioned or routing the request to any users capable 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, including the HR system and Active Directory, and even create a new EmpowerID Person linked to that account. The new account also inherits any resource entitlements, such as an Exchange Mailbox or a home folder.

Likewise, if an account is de-provisioned via the LDAP client, EmpowerID can revoke the account in each connected system, remove any associated resource entitlements, 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.

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=empowerid

• the simple logon for their EmpowerID Person
  such as tadams

• the DN for an external LDAP system that EmpowerID knows about
  such as cn=Terry Adams,ou=London,ou=Offices,cn=tdnfdemo,cn=directories,o=empowerid

• the SAMAccountName of an account in an external LDAP system that EmpowerID knows about
  such as tadams

• the netbios of an account in an external LDAP system that EmpowerID knows about
  such as tdnfdemo/tadams

• or present the user principal name of an account in an external LDAP system that EmpowerID knows about
  such as tadams@tdnfdemo.com

• or 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:

1. 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.

2. 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.

3. 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.

4. 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.

5. 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.

1. The client submits credentials in any one of the accepted formats.

2. The EmpowerID LDAP Server parses the credentials and checks for a corresponding Person object matching those credentials in the EmpowerID Identity Warehouse.

3. The Password Manager Policy is checked to see if Second Factor Authentication is required for that Person.

4. 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.