リソースに対するユーザーのアクセス権の認定要求を受け取ると、MLDAP ESM Module は LDAP リポジトリに保存されている規則をチェックして、その判断を下します。
Enterprise Server リソースは、クラスと呼ばれるカテゴリに分類されます。各クラスはリポジトリ内の LDAP コンテナーとして存在します。クラス コンテナー内にリソース規則が含まれています。規則の名前は規則が適用されるリソースの名前を表しており、名前にはワイルドカードを含めることができます。たとえば、"*" (またはデータセットに対する "**") という名前の規則は、そのクラスのすべてのリソースに適用されます。
アクセス対象のリソースの名前に一致する規則が、クラス内に複数含まれていることがあるため、どの規則を用いて特定の要求の結果を導き出すかを、MLDAP ESM Module はアルゴリズムを適用して決定します。通常、要求に一致するより限定的な規則に高い優先順位が付与されます。たとえば、ユーザーが ACCT という CICS トランザクションを発行し、"ACCT" という名前の規則と "A*" という名前の規則がある場合、"ACCT" 規則が "A*" 規則をオーバーライドします。
MLDAP ESM Module のバージョン 1 は、Enterprise Server 2.3 より前のすべての製品 (2.2 Update 2 の Hotfix リリースを除く) に含まれており、LDAP サーバーから複雑なアルゴリズムを使用してリソース規則データを取得し、これをさらに「照合順序」という別のアルゴリズムを使用して評価していました。照合順序アルゴリズムは、ACL のどの部分 (アクセス制御エントリまたは ACE) を要求を発行したユーザーに使用するのかの判断にも使用されていました。モジュールのバージョン 1 で使用されるプロセスの詳細については、「適合性規則照合」を参照してください。Enterprise Server 2.3 で導入された MLDAP ESM Module バージョン 2 は、新しい簡素化されたプロセスで、リソース アクセス要求を規則およびユーザーに対応する ACE と照合します。この新しい処理アルゴリズムでは、リソース規則があいまいな場合の挙動がわかりやすく予測しやすくなりました。また、場合によってはパフォーマンスも向上します。
Enterprise Server 2.3 では、新しいアルゴリズムがデフォルトです。(Enterprise Server バージョン 2 を含む MLDAP ESM Module 2.2 Update 2 Hotfix は、古いアルゴリズムがデフォルトであるため、Hotfix リリースで挙動が変わるのを回避できます。)動作やパフォーマンスの向上を期待して、あるいは新しい機能で利用するために、多くのお客様がこの新しいアルゴリズムを採用すると考えています。しかしお客様によっては、複雑であいまいなリソース アクセス制御規則が原因で、認定クエリを新しいアルゴリズムで処理したときに異なる結果が生成される可能性があります。Version 1 authentication 構成設定を指定すると、古いアルゴリズムを使用するように MLDAP ESM Module を構成できます。
次のような 2 つのデータセット アクセス制御規則と、対応する ACL があるとします。
| DEV.** | allow:alice:read |
| **.ALICE.* | allow:alice:update |
最初の規則は、最上位の修飾子がDEV であるすべてのデータセットへの read アクセスを Alice に許可しています。また、最後の修飾子が ALICE であるすべてのデータセットへの update アクセスを許可しています。Alice がデータセット DEV.PROJ1.ALICE.NOTES の更新を試みた場合、どのようになるでしょうか?
2 つの規則のうち、2 番目の規則 (**.ALICE.*) のほうが、一致するリテラル文字が多いため、データセット名との一致度が高いことになります。しかし、バージョン 1 のアルゴリズムでは、最初の規則が適用されます。これは該当する規則の検索時に、この規則が最初に見つかるためです。つまり、Alice にはデータセットに対する update アクセス権が付与されません。バージョン 2 のアルゴリズムでは、該当する可能性のある規則がすべて検出され、一致度の高いものから順に規則が処理されます。バージョン 2 のアルゴリズムが使用された場合、2 番目の規則が適用され、Alice に update アクセス権が付与されます。