When the MLDAP ESM Module receives a request to authorize a user's access to some resource, it checks the rules stored in the LDAP repository to make its decision.
Enterprise Server resources are grouped into categories called classes. Each class exists as an LDAP container in the repository. Within the class containers are resource rules. Rules are named for the resources they apply to, and their names can include wildcards, so a rule named "*" (or "**" for datasets) applies to all resources of that class.
Because a class can have multiple rules that match the name of the resource being accessed, the MLDAP ESM Module applies algorithms to determine which rule will determine the result of a particular request. Generally speaking, a more specific rule that matches the request should take precedence. So, for example, if a user attempts to submit the CICS transaction ACCT, and there is a rule named "ACCT" and another rule named "A*", the "ACCT" rule should override the "A*" rule.
Version 1 of the MLDAP ESM Module, included in all products prior to Enterprise Server 2.3 (except for some hotfix releases for 2.2 Update 2), used a complex algorithm to retrieve resource rule data from the LDAP server and evaluate it using another algorithm called "Match Rank". The Match Rank algorithm was also used to decide which part of an ACL (an Access Control Entry or ACE) applied to the user making the request. See Compatibility Rule Matching for more information on the process used in version 1 of the module. Enterprise Server 2.3 introduced MLDAP ESM Module version 2, with a new, simplified process for matching resource access requests to rules and matching ACEs to users. This new processing algorithm provides more predictable and understandable behavior when resource rules are ambiguous, and also offers better performance in some cases.
For Enterprise Server 2.3 the new algorithm is the default. (In Enterprise Server 2.2 Update 2 hotfixes that include MLDAP ESM Module version 2, the old algorithm is still the default, to avoid changing behavior in a hotfix release.) Most customers will want to use the new algorithm for its better behavior and performance, and possibly for new features that require it. In rare cases, however, customers with complex, ambiguous resource access control rules might notice different results for some authorization queries using the new algorithm. The MLDAP ESM Module can be configured to use the old algorithm by specifying the Version 1 authentication configuration setting.
Suppose you have the following two dataset access control rules, with corresponding ACLs.
| DEV.** | allow:alice:read |
| **.ALICE.* | allow:alice:update |
The first rule is meant to give Alice read access to all datasets under the DEV top-level qualifier, and update access to all datasets with ALICE as the final qualifier. What happens if Alice tries to update the dataset DEV.PROJ1.ALICE.NOTES?
Of the two rules, the second (**.ALICE.*) matches that dataset name better, because it matches more literal characters. Under the version 1 algorithm, however, the module will apply the first rule, because it will find it first while searching for applicable rules. That means Alice will not have update access to the dataset. With the version 2 algorithm, the module finds all the rules that might apply, then processes them in the order of closest to furthest match. So when the version 2 algorithm is used, the second rule will apply, and Alice will be granted update access.