リソース規則、検索順序、および優先順位

MLDAP ESM Module ではリソース規則名においてワイルドカードがサポートされているため、複数の規則を単一のリソース アクセス問合せに適用できます。このモジュールは、規則を取得するために LDAP サーバーとやり取りする必要があり、このサーバーが、モジュールから送信された検索文字列と一致する規則を検索する必要があります。このことにより、単純に、要求に適用可能なすべての規則をこのモジュールで検索しようとすると、一般的には非常に負荷が高くなります。

十分なパフォーマンスを提供するために、MLDAP ESM Module では、アクセス問合せ (AUTH または XAUTH 呼び出し) に応答する際に、次のような原則を使用して可能な限り LDAP による検索の回数を少なくすることが試みられます。

1. アクセス権は、モジュールによって見つかり処理される、最初の決定規則によって決定されます。決定規則とは、アクセス問合せに応答できる規則です。その詳細を、次に示します。
   • 適切なリソース クラスに適用されます。
   • 文字どおりに、またはワイルドカードによるパターン照合でリソース名と一致する名前が付いています。
   • 指定されたユーザー (ユーザー グループ メンバーシップを含む) に適用される 1 つ以上のエントリが含まれた、要求されたアクセスのレベル (AUTH の場合) またはタイプ (XAUTH の場合) を許可するか拒否するアクセス制御リストがあります。拒否は暗黙的に行われる場合があることに注意してください (「アクセス許可」を参照)。
2. このモジュールでは、まず、検索しているリソースと同じリテラル名が付いた規則が検索されます。たとえば、"TRAN" という名前が付いたトランザクションへのアクセスを要求された場合は、まず、"TRAN" という名前が付いた規則が検索されます。
3. そのような規則が見つからないか、要求を行ったユーザーのための決定規則ではない場合 (つまり、現在のユーザーに適用される ACE が含まれていない)、ワイルドカードが使用された規則と照合するために、次のように最長プレフィックス検索が実行されます。
   1. まず、"*" というリテラル文字を後に続けてリソース名が検索されます。つまり、探している名前に文字どおり一致するプレフィックスで始まる、ワイルドカード規則が検索されます。
   2. 次に、プレフィックスの最後の文字を "*" 文字に置き換えて (つまり、"NAME*" は "NAM*" になる)、もう 1 回検索が実行されます。この工程は、検索文字が "*" に達するか、決定規則が見つかるまで続けられます。
   3. これらの検索のいずれかで複数の規則が返された場合、それらは照合順序の順位で処理されます。たとえば、モジュールで "NAME" へのアクセスを認証しようとしており、"N*" が検索される場合は、"N*" および "N*E" という名前の規則が見つかる可能性があります。後者は、より順位が高い (より一致度が高い) ため、前者より前に処理されます。

結論としては、すぐに結果が出ない可能性があるこの処理方法では、短いプレフィックスの後にワイルドカードを続けた場合のほうが、ワイルドカードの後に長い (または実際に存在する) サフィックスを続けた場合よりも先に結果が出ます。たとえば、"NAME" を検索するときは、"N*" という名前の規則が、"*AME" という名前の規則より前に見つかり、使用されます。