アクセス評価

特定の操作のためのアクセスが認可されるかどうかは、ターゲット・オブジェクト上でその操作を行うための、サブジェクトのバインド DN によって決まります。アクセスが決定されると、処理はただちに停止されます。

アクセスの検査は、まず有効な entryOwnership と ACI 定義を検索し、次に項目の所有権を検査してから、オブジェクトの ACI の値を評価することで行われます。

フィルター・ベースの ACL では、最下位の収容項目から、祖先項目チェーンを上に向かって、DIT の最上位の収容項目まで累算します。有効なアクセスは、構成する祖先項目によって付与または否認されたアクセス権の共用体として計算されます。特定規則と結合規則の既存のセットは、フィルター・ベースの ACL の有効なアクセスを評価します。

フィルター・ベースの属性と非フィルター・ベースの属性は、単一の収容ディレクトリー項目内では相互に排他的です。両方のタイプの属性を同じ項目に入れることはできません。制約違反になります。この条件が検出されると、ディレクトリー項目の作成または更新に関連する操作は失敗します。

有効なアクセスを計算する場合、ターゲット・オブジェクト項目の祖先チェーンで検出される最初の ACL タイプにより、計算のモードが設定されます。フィルター・ベース・モードでは、有効なアクセスを計算するときに非フィルター・ベースの ACL は無視されます。同様に、非フィルター・ベース・モードでは、有効なアクセスを計算するときにフィルター・ベースの ACL は無視されます。

有効なアクセスを計算するときに、フィルター・ベースの ACL の累算を制限するには、値を false に設定した ibm-filterAclInherit 属性を、サブツリーの ibm-filterAclEntry の最上位と最下位のオカレンスの間にある項目に配置します。この方法により、ターゲット・オブジェクトの祖先チェーンでそれより上にある ibm-filterAclEntry 属性のサブセットが無視されます。

有効なアクセスを計算するときに、フィルター・ベースの ACL の累算を除外するには、値を false に設定した ibm-filterAclInherit 属性を、サブツリーの ibm-filterAclEntry の最下位のオカレンスの下にあるいずれかの項目に配置します。この方法により、ターゲット・オブジェクトの祖先チェーンでそれより上にあるすべての ibm-filterAclEntry 属性が無視されます。結果のアクセスは、デフォルトのフィルター ACL 値に解決されます。

デフォルトでは、ディレクトリー管理者、DirDataAdmin 役割に割り当てられているローカル管理グループのメンバー、およびマスター・サーバー (複製の場合はピア・サーバー) は、ディレクトリー内のすべてのオブジェクトに対するフル・アクセス権を取得します。ただし、システム属性に対する書き込み権限は除きます。その他の entryOwner は、system 属性への書き込みアクセスを除き、その所有権の下のオブジェクトへのアクセス権をすべて取得します。デフォルトでは、すべてのユーザーが normal、system、restricted の各属性に対する読み取りアクセス権を持っています。要求を出しているサブジェクトに entryOwnership が付与されている場合、アクセス権はデフォルト設定によって決定され、アクセス処理は停止されます。

注: 項目に明示的に ACL を設定し、システム属性には明示的に ACL を設定しない場合、リクエスターには自動的に読み取り、検索、比較許可が付与されます。アクセスを拒否するには、明示的に拒否する必要があります。デフォルトではアクセス権は拒否されていません。

要求を出しているサブジェクトが entryOwner でない場合は、オブジェクト項目の ACI の値が検査されます。ACI 内で定義されている、ターゲット・オブジェクトに対するアクセス権は、特定規則と結合規則によって計算されます。

特定規則

最も特定的な aclEntry 定義は、ユーザーへの許可の付与または否認を評価するときに使用される aclEntry 定義です。特定性のレベルは以下のとおりです。

アクセス ID は、グループまたは役割よりも特定的です。グループと役割は、同じレベルです。
同じ dnType レベル内では、個々の属性レベルの許可の方が、属性クラス・レベルの許可よりも特定的です。
同じ属性または属性クラス・レベル内では、deny の方が grant よりも特定的です。

結合規則

同じ特定性を持つ複数のサブジェクトに付与されている許可は、結合されます。同じ特定性のレベル内でアクセスを決定できない場合は、特定性のレベルがより低いアクセス定義が使用されます。定義済みの ACI がすべて適用されてもアクセスが決定されない場合は、アクセスが否認されます。

注: アクセス評価の際に、一致するアクセス ID レベルの aclEntry が見つかると、グループ・レベルの aclEntry は、アクセス計算に含まれません。ただし、例外として、一致するアクセス ID レベルの aclEntry が cn=this の下ですべて定義されている場合は、一致するグループ・レベルの aclEntry も、評価の際にすべて結合されます。

つまり、オブジェクト項目内において、バインド DN と同じアクセス ID サブジェクト DN が、定義済みの ACI 項目に含まれている場合、許可は、最初にその aclEntry に基づいて評価されます。同じサブジェクト DN の下で、一致する属性レベルの許可が定義されていると、それらの許可は、属性クラスの下で定義されている許可に取って代わります。同じ属性または属性クラス・レベル定義の下で、競合する許可がある場合は、deny (否認) された許可が grant (付与) された許可をオーバーライドします。

注: ヌル値許可を定義すると、特定性のより低い許可定義は含まれなくなります。

アクセスがまだ決定できず、見つかった aclEntry のうち一致するものがすべて cn=this の下で定義されている場合は、グループ・メンバーシップが評価されます。ユーザーが複数のグループに属している場合、ユーザーはそれらのグループから、組み合わされた許可を受け取ります。また、ユーザーは自動的に cn=Anybody グループに属します。ユーザーが認証済みのバインドを実行した場合は、cn=Authenticated グループに属することがあります。これらのグループに対して許可が定義されている場合、ユーザーは、指定された許可を受け取ります。

注: グループおよび役割メンバーシップは、バインド時に決定されます。これらは、別のバインドが発生するまで、またはアンバインド要求を受け取るまで継続します。ネストされたグループおよび役割 (すなわち、別のグループまたは役割のメンバーとして定義されたグループまたは役割) は、メンバーシップの決定やアクセス評価では解決されません。

例えば、attribute1 が sensitive 属性クラス内にあり、ユーザー cn=Person A, o=sample が group1 と group2 の両方に属しており、以下の aclEntry が定義されていると想定します。

aclEntry: access-id: cn=Person A, o=sample: at.attributel:grant:rsc:sensitive:deny:rsc
aclEntry: group: cn=group1,o=sample:critical:deny:rwsc
aclEntry: group: cn=group2, o=sample:critical:grant:r:normal:grant:rsc

このユーザーのアクセス権は以下のとおりです。

rsc から attribute1 へのアクセス権を取得します (1. より。属性レベル定義は、属性クラス・レベル定義に取って代わります)。
ターゲット・オブジェクト内の他の sensitive クラス属性へのアクセス権は取得しません (1. より)。
その他の権限は与えられません (2. および 3. は、アクセス評価に含まれません)。

別の例として、以下の aclEntry が定義されていると想定します。

aclEntry: access-id: cn=this: sensitive
aclEntry: group: cn=group1, o=sample:sensitive:grant:rsc:normal:grant:rsc

このユーザーのアクセス権は以下のとおりです。

sensitive クラス属性へのアクセス権は付与されません (1. より。access-id の下にヌル値が定義されているため、group1 の sensitive クラス属性へのアクセス権を含めることはできません)。
rsc から normal クラス属性へのアクセス権は持ちます (2. より)。