The following discussion applies only when
Compatibility Rule Matching
is enabled. In version 2 of the
MLDAP ESM Module
, the default behavior is to use the new rule matching algorithm, which retrieves all applicable rules from the LDAP repository
and checks them in the order of strongest to weakest match.
MLDAP ESM Module supports
wildcards in resource rule names, it is possible that several rules may apply to a single resource access query. The module has to
communicate with the LDAP server to retrieve rules, and the server has to search for rules that match the search string sent
by the module. That makes it prohibitively expensive, generally speaking, for the module to simply search for all the rules
that might apply to a request.
To provide adequate performance, the
MLDAP ESM Module tries to answer an access query (AUTH or XAUTH call) with as few LDAP searches as possible, using these principles:
- Access is determined by the first defining rule that the module finds and processes. A defining rule is a rule that can answer
the access query. It:
- Applies to the right class of resource.
- Has a name that matches the resource name, either literally or as a wildcard pattern match.
- Has an
Access Control List that includes at least one entry that applies to the specified user (including user group membership), and that allows or
denies the level (for AUTH) or type (for XAUTH) of access requested. Note that denial may be implicit; see
- The module first searches for a rule with the same literal name as the resource it's looking for. If it gets a request for
access to a transaction named "TRAN", for example, it will first look for a rule named "TRAN".
- If no such rule is found, or it is not a defining rule for the user making the request (that is, it doesn't have an ACE that
applies to the current user), the module performs a longest prefix search for matching wildcarded rules:
- First, it will search for the resource name followed by a literal "*" character - that is, for a wildcard rule that begins
with a prefix that matches the sought name literally.
- Then it replaces the last character of the prefix with a "*" character (so "NAME*" becomes "NAM*") and performs another search.
This process will continue until it gets to "*" or it finds a defining rule.
- If any of these searches returns multiple rules, they will be processed in
match rank order. For example, if the module is trying to authorize access to "NAME" and searches for "N*", it might find rules named
"N*" and "N*E". The latter would be processed before the former, because it has higher rank (is a closer match).
One consequence of this approach that may not be immediately obvious is that a short prefix followed by a wildcard will take
effect before a wildcard followed by a long (or indeed any) suffix. For example, when searching for "NAME", a rule named "N*"
would be found and used before one named "*AME".