• Virtual Directory Server
• LDAP Proxy
• Federated Identity Suite
• Free LDAP Browser

Staged Processing Model

Challenge
  Many systems designed to overcome problems related to identity management are built around general concepts so that they can be implemented quickly to solve a specific problem. Unfortunately, this often means that these solutions cannot be adapted to work in a way that is specific to your particular environment. Furthermore, if the identity management solution that you require is broader than the scope of the product that you are using, or the way in which it resolves it, it becomes difficult to manage when a particular type of processing functionality should be implemented before requests and responses are sent on to their respective destinations. 

Solution
  Symlabs has designed its identity management products around a staged processing model. This model allows you to modularize particular functionalities and to order them in the way that you need them to work.

The staged processing model allows you to define various processing stages that can be attached to a client facing interface of the proxy engine, also known as a Listener. Within each processing stage you are able to add a number of plugins that perform various functionalities, or you can attach custom written scripts.

Each processing stage includes various protocol hooks that can intercept particular operations and can trigger a functionality depending on the type of operation being performed. So, for example, a hook can be created for a BIND request, and any BIND request submitted to the listener to which the stage is attached, will be intercepted. Furthermore, you are able to specify particular conditions that can control whether a particular functionality is implemented or not. So you can specify filters that will trigger actions. For instance, you may create a filter to only trigger a particular functionality for requests that have been authenticated using a specified BIND DN.

Most importantly, when attaching processing stages to a Listener, you can determine the order in which they should be implemented. You are also able to reuse processing stages at different points within the processing chain or pipeline. This means that you can create a Logging stage, which can log operations as they are intercepted by the Listener, and which can also log operations after they have moved through the entire processing chain, so that you are able to see how the operations are transformed by the different pieces of processing functionality that you have built into your solution.

The staged processing model, not only provides you with reusable pieces of functionality, but also provides you with the ability to apply business logic to most of the processing that will take place within the proxy. In this way, you can completely customize the behavior of the plugin to entirely match your own requirements.