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

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

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

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

包含とアイテムの削除

アイテムにインデックスを付けるときは、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 を検索できなくなります。