ACL のマッピング

アイテムにアクセスできるユーザーだけが検索結果内のそのアイテムを閲覧できるようにするには、エンタープライズ リポジトリからアクセス制御リスト（ACL）を使用してアイテムをインデックス登録する必要があります。リポジトリ内のアイテムをインデックス登録する際は、リポジトリの ACL をモデル化し、それらの ACL を含める必要があります。Content Connector SDK には、ほとんどのリポジトリの ACL をモデル化できる強力な ACL メソッドが豊富に用意されています。

ACL の作成

ACL の作成は、2 つのステップによるプロセスになります。

  1. ACL クラスの静的メソッドを使用して Principal を作成します。
  2. Acl.Builder クラスで、プリンシパルを使用して ACL を構築します。

このドキュメントの残りの部分では、継承や包含など、ACL をモデル化して作成するために知っておくべきコンセプトについて説明します。

外部 ID を使用したプリンシパルの作成

Google Cloud Search では、ユーザーやグループが Google のメールアドレスに解決される必要があります。リポジトリ アイテムをインデックスに登録する際、コンテンツ コネクタにはこれらのメールアドレスがない場合があります。ただし、Content Connector SDK では、メールアドレスの代わりに任意の外部 ID（ユーザーまたはグループにリポジトリ アイテムへのアクセス権を付与する ID）を使用して、アイテムをインデックスに登録できます。外部 ID を含むプリンシパルを作成するには、getUserPrincipal() メソッドまたは getGroupPrincpal() メソッドを使用します。ACL クラスには、Principal オブジェクトのビルドに使用される静的メソッドが他にもいくつかあります。

ACL の継承

ACL の継承とは、アイテムの ACL とその継承チェーンの ACL の組み合わせの結果に基づいて、特定のアイテムと特定のユーザーを認可することです。承認の決定に使用されるルールは、リポジトリとアイテムのプロパティによって異なります。

継承を設定する

各アイテムには、setReaders() メソッドと setDeniedReaders() メソッドで指定される直接許可プリンシパルと直接拒否プリンシパルを設定できます。直接許可プリンシパルは、ACL で特定のアイテムに対する直接アクセス権を持つとして識別されたユーザーです。直接拒否プリンシパルは、ACL で特定のアイテムに対するアクセス権を持たないとして識別されたユーザーです。

アイテムは、setInheritFrom() メソッドを使用して、間接許可プリンシパルと間接拒否プリンシパルを継承することもできます。間接許可プリンシパルは、ACL の継承によって、特定のアイテムに対する間接的なアクセス権を持つユーザーです。間接拒否プリンシパルは、ACL の継承によって、特定のアイテムに対するアクセスを拒否されたユーザーです。

図 1 は、setInheritFrom() メソッドを使用して、間接許可プリンシパルと間接拒否プリンシパルを継承する方法を示しています。

アイテム間の関係の図
図 1: setInheritFrom() メソッド

図 1 には、次のようなアクセス制御が示されています。

  • ユーザー 1 は、アイテム A の直接許可プリンシパルです。
  • ユーザー 2 は、アイテム B の直接許可プリンシパルです。
  • アイテム B はアイテム A の ACL を継承します。

このアクセス制御に基づくと、アクセスルールは次のようになります。

  • ユーザー 1 は、アイテム B の間接許可プリンシパルになるために、アイテム B のプリンシパルとして明示的に指定されている必要はありません。ユーザー 1 はアイテム A の直接許可プリンシパルとして指定され、アイテム B はアイテム A から ACL を継承するため、アクセス権が継承されます。
  • ユーザー 2 は、アイテム A の間接許可プリンシパルではありません。

継承タイプを設定する

setInheritFrom() メソッドを使用して継承を設定する場合は、setInheritanceType() メソッドを使用して継承タイプを設定する必要があります。継承タイプによって、子の ACL と親の ACL の組み合わせが決まります。Acl.InheritanceType は、次の 3 つの継承タイプを実装します。

  • BOTH_PERMIT - 子アイテムの ACL と継承される親アイテムの ACL の両方でユーザーがアイテムへのアクセスを許可されている場合にのみ、アイテムに対するアクセス権をユーザーに付与するには、継承タイプを BOTH_PERMIT に設定します。

  • CHILD_OVERRIDE - 親アイテムの ACL が競合する場合に、子アイテムの ACL が継承された親アイテムの ACL よりも優先されるようにするには、継承タイプを CHILD_OVERRIDE に設定します。つまり、親アイテムの ACL で拒否閲覧者としてユーザーのアクセスが拒否されていても、ユーザーが子アイテムに対して閲覧者としてのアクセス権を持っている場合はアクセスできます。逆に、親アイテムの ACL でユーザーのアクセスが許可されていても、ユーザーが子の拒否閲覧者である場合はアクセスできません。

  • PARENT_OVERRIDE - 親アイテムの ACL と子アイテムの ACL が競合する場合に、親アイテムの ACL が強制的に優先されるようにするには、継承タイプを PARENT_OVERRIDE に設定します。つまり、子アイテムの ACL で拒否閲覧者としてユーザーのアクセスが拒否されていても、ユーザーが親アイテムに対して閲覧者としてのアクセス権を持っている場合はアクセスできます。逆に、子アイテムの ACL でユーザーのアクセスが許可されていても、ユーザーが親アイテムの拒否閲覧者である場合はアクセスできません。

ACL の継承チェーンを評価する際、評価の順序によって承認決定の結果が異なることがあります。Cloud Search では、ACL の継承チェーンについてリーフからルートまで評価できます。具体的には、チェーンの ACL の決定は、親を持つ子の評価から始まり、ルートの親に到達するまで進められます。

たとえば、子の継承タイプが CHILD_OVERRIDE で、ユーザーが子にアクセスできる場合、ドライブは親を評価する必要はありません。ただし、子に PARENT_OVERRIDE または BOTH_PERMIT が設定されている場合、ドライブはチェーンの上位で継承の評価を続けます。

包含とアイテムの削除

アイテムをインデックス登録する場合、IndexingItemBuilder クラスの setContainer() メソッドを使用して、アイテムにコンテナとしてラベルを付けることができます。コンテナと包含者の関係により、アイテムの物理階層が確立され、アイテムが適切に削除されます。コンテナが削除されると、包含されているアイテムも削除されます。

包含関係は ACL 継承ルールから完全に独立しています。 たとえば、ファイル システム内のファイルを削除目的でフォルダに格納し、別のフォルダから ACL を継承できます。フォルダを削除しても、その ACL を継承するアイテムは、削除したフォルダの包含階層にそのアイテム自体も含まれていない限り、削除されません。

図 2 には、次のようなアクセス制御が示されています。

  • ユーザー 1 は、アイテム A の直接許可プリンシパルです。
  • ユーザー 2 は、アイテム B の直接許可プリンシパルです。
  • ユーザー 3 は、アイテム C の直接許可プリンシパルです。
  • アイテム C はアイテム A の ACL を継承します。
  • アイテム B はアイテム A をそのコンテナとして指定します。
  • アイテム C はアイテム B をそのコンテナとして指定します。

このアクセス制御に基づくと、アクセスルールは次のようになります。

  • 間接的なアクセス権は、setInheritFrom() メソッドで取得されます。したがって、アイテム C はアイテム A の ACL を継承するので、ユーザー 1 はアイテム C にアクセスできます。
  • アイテム B に含まれているアイテム C からは、間接的なアクセス権は取得されません。 そのため、ユーザー 2 はアイテム C にアクセスできません。
アイテム間の関係の図
図 2.setInheritFrom() メソッドが使用されている。

ACL の継承が包含階層から分離されていることで、多くの異なる既存の構造をモデル化できます。

アイテムが正常に削除された場合の動作は、次のとおりです。

  • 削除対象アイテムを包含していたアイテムは検索できなくなり、Google のデータソースからの削除がスケジュールされます。
  • setInheritFrom() メソッドを使用して削除されたアイテムを指定したアイテムは検索できなくなります。

リソースに setInheritFrom() メソッドによって削除されたアイテムがあるものの、setContainer() を使用してコンテナセットが設定されていないか、その包含階層に削除されたアイテムが含まれていない場合、そのアイテムとそのデータは Google のデータソースに残ります。そのアイテムの削除は個別に行う必要があります。

図 3 は、アイテム階層における削除の仕組みの例を示しています。

アイテム間の関係の図
図 3. 項目の削除と ACL の継承

図 3 には、次のようなアクセス制御が示されています。

  • ユーザー 1 は、アイテム A の直接許可プリンシパルです。
  • ユーザー 2 は、アイテム D の直接許可プリンシパルです。
  • アイテム D とアイテム E の両方がアイテム A の ACL を継承します。
  • アイテム D はアイテム A をそのコンテナとして指定します。
  • アイテム A とアイテム E は、コンテナ アイテムを持たないため、ルートレベルのアイテムです。

削除は、container 参照に沿って処理されます。アイテム A が削除された場合の動作は、次のとおりです。

  • setInheritFrom() 参照のすべての子孫は、すべてのユーザーのアクセス権を失います。
  • いずれのユーザーもアイテム A にアクセスできません。
  • アイテム D は暗黙的に削除されます。いずれのユーザーもアイテム D にアクセスできません。
  • 削除はコンテナ参照のみに沿って処理されるため、アイテム E は削除されません。
  • アイテム E にアクセスできなくなり、どのユーザーもアイテム E を検索できなくなります。