Download Quest One Quick Connect Virtual Directory Server

7.1. STAGE MODEL
create a automatic, or a manual stage. Once you have created your Stage, it will appear in the navigator. Select
it in order to configure it, and then start attaching plugins (for automatic stages) or hooks (for manual stages).
QC VDS provides a set of pre-written scripts that can be used as plugins within any stage. To easily facilitate
the use of these plugins, DSGUI provides the option of setting up either Automatic or Manual stages. These
different stage types are fairly artificial in that all stage definitions appear identical to QC VDS and the actual
configuration will not make any differentiation between them. Automatic stages simply provide an easy method
to implement any of the built-in plugins, while Manual stages are more complex to configure, but will allow you
to define your own scripts and processing to be performed on PDUs. We will discuss the differences between
these stage types and how to configure them later.
7.1.2
Condition Model
In order to add more control to the different attached functionalities within a stage, QC VDS offers a condition
model that can be used to control the execution of each function. This provides fine-grained control over whether
a particular function applies to the data passing through the stage, and helps to avoid unnecessary processing.
The condition model consists of a set of conditions that are evaluated each time a PDU reaches the function
holder within a stage. In manual stages, the function holder is described as a ’Hook’, while in automatic stages
the function holder is described as a Plugin. All function holders will include a condition line which will be used to
evaluate whether or not the functionality provided should be invoked. So, for example, if a configuration requires
a mapping functionality for entries stored in a certain branch, the condition model can be used to specify that
the mapping functionality should only be invoked if the PDU is accessing that particular branch.
The are three different conditions that can be defined for both automatic and manual stages and another optional
one that can be used only in manual stages:
Suffix / Base DN / Prefix For LDAP operations this string specifies the DN suffix that must match the DN of
the PDU for the functionality to be triggered. If the string is empty the suffix match is not made at all.
If the string begins with an exclamation mark, the functionality is triggered if the DN of the PDU does
NOT match the suffix. For LDAP operations that do not have a natural DN (unbind, queries responses,
extended...) the evaluation of any suffix will always return false. For HTTP operations a prefix match on
the URL is performed unless the first character of the string is an asterisk in which case, a suffix match
is performed instead.
Bind DN Specifies the credential DN that must been in use in the client connection for the attached plugin or
script to be executed. An empty value means that the credential is not checked, and an exclamation mark
at the beginning of the string indicates that the credential DN must NOT match the specified one. Also, a
special value "anon" indicates that only non-authenticated connections will trigger the functionality (with
"!anon" meaning ANY authenticated connection). For HTTP requests the "Host:" header of the PDU is
matched.
IP / Mask Specifies the range of client IPs that must match. An exact IP match can be obtained by specifying
a 255.255.255.255 mask. The match can be omitted by leaving both fields empty or by specifying a
mask of 0.0.0.0. Adding an exclamation mark will invert the checking as it does for the other conditions
Condition Can only be used in conditions of HOOKs in manual stages. This field holds an expression that
uses a syntax similar to that used to filter LDAP search requests, and is able to check values of PDU
hash keys, checks on existence, using exact value or wild card matches. Only attributes present within
the PDU can be checked.
User Reference Manual
90