Fragmented Identities Solutions

Fragmented Identities and Data Augmentation are both related to the same essential issue: the fact that pieces of the required data are stored in different repositories. This can happen under the following two circumstances:

There becomes a need to store some specific new attributes in the entries, but the directory's permissions do not allow write access or the directory schema cannot be modified. This case is called "Data Augmentation".

Various pieces of identity data are stored in different repositories. Before it is possible to retrieve or write an entry, data must be joined from all those different sources.

Data Augmentation

A common case involves deployment of a new application that needs to store additional user data in the directory. If the directory schema can be extended, and the new data can be stored in the directory, this is relatively straight-forward. However, many times this is not possible because of technical or political reasons - perhaps the directory is managed by a different department and cannot be written to - or the directory schema is static and cannot be changed without major repercussions to the rest of the infrastructure.

Parts of Identity Data in Different Stores

Many organizations have not one, but in fact many identity stores - LDAP directories, relational databases, and other repositories. Each of these contains fragments of identity data - or sometimes even a copy of the whole identity itself. This distribution of data is problematic for applications that need to access identity information.

Solution

Symlabs Virtual Directory Server solves both problems by supporting a unified view for fragmented identities - effectively collecting all the pieces from the different repositories and presenting them as a single entry to applications. This is done using the "Join" module that comes with Virtual Directory Server.

Virtual Directory Server's Join Functionality

The Join module uses one attribute as the "join key" in order to match entries across different directories or databases. This join key is the name of an attribute that is used as the common link between several entries from several sources. Values must be unique in every repository, and entries that have this attribute set to the same value will be considered as different parts of the identity.

Data Augmentation

In cases where additional data needs to be written to a directory that does not allow writes, it is possible to define a join-rule for this additional data and configure Virtual Directory Server to store the additional data elsewhere. This can be either on another (writeable) branch in the same directory, on a different directory server, or even in a relational database.

Bi-Directional Support (Reading and Writing)

Virtual Directory Server's Join Module fully supports reading and writing. The routing logic is highly configurable and has been designed for maximum flexibility. For instance, when different parts of the identity data stores in directories or databases contain the same attribute, but with different values it is possible to assign precedence, or to aggregate all different values as a multi-valued attribute. When writing, it is possible to store the same attribute in multiple locations.

Benefits

Performance

At Symlabs, we take special pride in developing the fastest virtual directory server on the market. Many of our customers use our software in mission-critical deployments that carry out thousands of requests per second. One example of our commitment to performance is demonstrated by the design of the Join Module, in the specific optimizations employed to maximize performance. Queries are carried out asynchronously whenever possible in order to reduce latency and increase the number of requests per second that can be handled by the virtual directory.