ACL のマッピング

アイテムにアクセスできるユーザーだけが、 アクセス制御リスト（ACL）を使用してアイテムをインデックス登録する必要があります。 ダウンロードします。リポジトリの ACL をモデル化し、 リポジトリ内のアイテムをインデックスに登録する際に、これらの ACL を含めます。コンテンツ コネクタ SDK には豊富な ACL メソッドのセットが用意されており、インフラストラクチャの ACL をモデル化するのに十分な 使用できます。

ACL の作成

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

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

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

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

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

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

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

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

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

包含とアイテムの削除

アイテムをインデックス登録する場合、 setContainer() メソッド（ IndexingItemBuilder クラスです。コンテナと包含者の関係は、物理的な アイテムが適切に削除されるようにするためです。 コンテナが削除されると、包含されているアイテムも削除されます。

包含関係は 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 にアクセスできません。
で確認できます。 <ph type="x-smartling-placeholder">
</ph> アイテム間の関係の図
図 2.setInheritFrom() メソッドが使用されている。

ACL の継承と包含階層とが分離されているため、 多岐にわたります。

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

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

リソースに削除されたアイテムがある場合、 setInheritFrom() メソッドですが、Terraform を使用したコンテナ セットは 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 を検索できなくなります。