アイテムにアクセスできるユーザーにのみ検索結果でアイテムが表示されるようにするには、エンタープライズ リポジトリからアクセス制御リスト（ACL）を使用してアイテムをインデックスに登録します。リポジトリの ACL をモデル化し、アイテムをインデックスに登録する際にそれらの ACL を組み込む必要があります。Content Connector SDK には、ほとんどのリポジトリの ACL をモデル化するメソッドが用意されています。
ACL の作成
ACL の作成は、2 つのステップによるプロセスになります。
- ACL クラスの静的メソッドを使用して、
Principalを作成します。 Acl.Builderクラスを使用して、プリンシパルで ACL をビルドします。
このドキュメントでは、継承や包含など、ACL をモデル化して作成するためのコンセプトについて説明します。
外部 ID を使用したプリンシパルの作成
Google Cloud Search では、ユーザーやグループが Google のメールアドレスに解決される必要があります。リポジトリ アイテムをインデックスに登録する際、コンテンツ コネクタにはこれらのメールアドレスがない場合があります。ただし、Content Connector SDK では、メールアドレスの代わりに外部 ID（リポジトリ アイテムに対するアクセス権をユーザーやグループに付与する ID）を使用して、アイテムをインデックスに登録できます。getUserPrincipal メソッドまたは getGroupPrincipal メソッドを使用して、外部 ID を含むプリンシパルを作成します。ACL クラスには、Principal オブジェクトをビルドするための静的メソッドが他にもいくつか含まれています。
アイテムの ID を再マッピングした後、新しい ID を有効にするには、アイテムのインデックスを再作成する必要があります。詳細については、ID の再マッピングをご覧ください。
ACL の継承
ACL の継承とは、アイテムとその継承チェーンの ACL を組み合わせた結果に基づいて、特定のアイテムとユーザーに対する承認が行われることを指します。承認のルールは、リポジトリとアイテムのプロパティによって異なります。
継承を設定する
各アイテムには、setReaders メソッドと setDeniedReaders メソッドを使用して指定された、直接許可プリンシパルと直接拒否プリンシパルを設定できます。直接許可プリンシパルは、アイテムに対する直接アクセス権を持つとして ACL で識別されたユーザーです。直接拒否プリンシパルは、ACL でアイテムに対するアクセス権を持たないとして識別されたユーザーです。
アイテムは、setInheritFrom メソッドを使用して、間接許可プリンシパルと間接拒否プリンシパルを継承することもできます。間接許可プリンシパルは、ACL の継承によってアイテムに対する間接的なアクセス権を持ちます。間接拒否プリンシパルは、継承によってアクセスを拒否されます。
図 1 は、setInheritFrom メソッドを使用してプリンシパルを継承する方法を示しています。
setInheritFrom メソッド。図 1 は、これらのアクセス制御を示しています。
- ユーザー 1 は、アイテム A の直接許可プリンシパルです。
- ユーザー 2 は、アイテム B の直接許可プリンシパルです。
- アイテム B はアイテム A の ACL を継承します。
これらの制御に基づくと、アクセスルールは次のようになります。
- ユーザー 1 は、明示的に指定されていなくても、アイテム B の間接許可プリンシパルです。アクセス権はアイテム A から継承されます。
- ユーザー 2 は、アイテム A の間接許可プリンシパルではありません。
継承タイプを設定する
setInheritFrom メソッドを使用して継承を設定する場合は、setInheritanceType メソッドを使用して継承タイプを設定する必要があります。継承タイプによって、子 ACL が親 ACL とどのように結合されるかが決定されます。Acl.InheritanceType は次の 3 つのタイプを実装します。
BOTH_PERMIT- 子 ACL と親 ACL の両方で許可されている場合にのみアクセス権を付与します。CHILD_OVERRIDE- 競合が発生した場合、子 ACL が親 ACL よりも優先されます。親が拒否しても子にアクセスできる場合もあれば、親が許可しても子にアクセスできない場合もあります。PARENT_OVERRIDE- 競合が発生した場合、親 ACL が子 ACL よりも優先されます。
Cloud Search は、リーフからルートへと ACL の継承チェーンを評価します。評価は子とその親から始まり、ルート親まで進むことができます。
たとえば、子アイテムが CHILD_OVERRIDE を使用しており、ユーザーがアクセス権を持っている場合、Cloud Search は親アイテムを評価する必要はありません。ただし、子に PARENT_OVERRIDE または BOTH_PERMIT が使用されている場合、Cloud Search はチェーンの上位の評価を続行します。
包含とアイテムの削除
アイテムのインデックス登録時に、IndexingItemBuilder クラスの setContainer メソッドを使用して、アイテムをコンテナとしてラベル付けできます。この関係によって、物理的な階層が確立され、適切な削除が保証されます。コンテナを削除すると、そのコンテナに含まれるアイテムも削除されます。
包含関係は、ACL の継承ルールとは独立しています。たとえば、フォルダに削除目的のファイルが含まれていても、そのファイルは別のフォルダから ACL を継承できます。フォルダを削除しても、その ACL を継承するアイテムは、そのアイテムも包含階層に含まれていない限り削除されません。
図 2 は、これらのアクセス制御を表しています。
- ユーザー 1 は、アイテム A の直接許可プリンシパルです。
- ユーザー 2 は、アイテム B の直接許可プリンシパルです。
- ユーザー 3 は、アイテム C の直接許可プリンシパルです。
- アイテム C はアイテム A の ACL を継承します。
- アイテム B はアイテム A をそのコンテナとして指定します。
- アイテム C はアイテム B をそのコンテナとして指定します。
これらの制御に基づくと、アクセスルールは次のようになります。
setInheritFromメソッドによって、間接的なアクセス権が継承されます。アイテム C はアイテム A から継承されるため、ユーザー 1 はアイテム C にアクセスできます。- 間接的なアクセス権はコンテインメントから付与されません。ユーザー 2 はアイテム C にアクセスできません。
setInheritFrom メソッド。ACL の継承が包含から分離されていることにより、さまざまな構造をモデル化できます。
アイテムを削除すると、次のようになります。
- 削除対象アイテムを包含していたアイテムは検索できなくなり、削除がスケジュールされます。
- 削除されたアイテムを
setInheritFromで指定しているアイテムは検索できなくなります。
リソースが削除されたアイテムに setInheritFrom を使用しているが、コンテナが設定されていないか、階層に削除されたアイテムが含まれていない場合、アイテムはデータソースに残ります。削除はお客様の責任で行ってください。
図 3 は、アイテム階層における削除の例を示しています。
図 3 には、次のようなアクセス制御が示されています。
- ユーザー 1 は、アイテム A の直接許可プリンシパルです。
- ユーザー 2 は、アイテム D の直接許可プリンシパルです。
- アイテム D とアイテム E はどちらもアイテム A から継承します。
- アイテム D はアイテム A をそのコンテナとして指定します。
- アイテム A とアイテム E はルートレベルのアイテムです。
削除は、コンテナ参照に沿ってカスケード処理されます。アイテム A を削除すると、次のようになります。
setInheritFrom参照のすべての子孫でアクセスが失われます。- ユーザーはアイテム A にアクセスできなくなります。
- アイテム D は暗黙的に削除され、アクセスできなくなります。
- アイテム E は削除されませんが、到達できなくなり、検索できなくなります。