アイテムにアクセスできるユーザーにのみ、検索結果内でそのアイテムが見えるようにするには、エンタープライズ リポジトリからアクセス制御リスト（ACL）を使用してアイテムをインデックスに登録する必要があります。リポジトリの ACL をモデル化し、アイテムをインデックスに登録する際に含める必要があります。Content Connector SDK には、ほとんどのリポジトリの ACL をモデル化するためのメソッドが用意されています。
ACL の作成
ACL の作成は 2 段階のプロセスです。
- ACL クラスの静的メソッドを使用して
Principal`Principal` を作成します。 -
Acl.Builderクラスを使用し、そのプリンシパルを使って ACL を構築します。
このドキュメントでは、継承や包含など、ACL をモデル化して作成するためのコンセプトについて説明します。
外部 ID を使用したプリンシパルの作成
Google Cloud Search では、ユーザーとグループが Google
のメールアドレスに解決される必要があります。リポジトリ
アイテムをインデックスに登録する際に、コンテンツ
コネクタにこれらのメールアドレスがない場合があります。ただし、Content Connector SDK では、メールアドレスの代わりに外部
ID （リポジトリ アイテムに対するアクセス権をユーザーやグループに付与する ID）を使用して、アイテムをインデックスに登録できます。外部 ID を含むプリンシパルを作成するには、
getUserPrincipal
メソッドまたは
getGroupPrincipal
メソッドを使用します。
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 で許可されている場合にのみアクセス権を付与します 。CHILD_OVERRIDE- 競合が発生した場合、子 ACL が親 ACL より優先されます。親が拒否してもユーザーは子にアクセスできます。また、親が許可しても子へのアクセスを拒否できます。PARENT_OVERRIDE- 競合が発生した場合、親 ACL が子 ACL より 優先されます。
Cloud Search では、リーフからルートへと ACL の継承チェーンが評価されます。 評価は子とその親から始まり、ルートの親まで進むことができます。
たとえば、子が CHILD_OVERRIDE を使用していて、ユーザーがアクセスできる場合、Cloud Search
は親を評価する必要はありません。ただし、子が PARENT_OVERRIDE または BOTH_PERMIT を使用している場合、Cloud
Search はチェーンの評価を続行します。
包含とアイテムの削除
アイテムをインデックスに登録する際に、
setContainer
メソッドを使用して、
IndexingItemBuilder
クラスのコンテナとしてラベル付けできます。この関係により、物理階層が確立され、適切に削除されます。コンテナを削除すると、含まれているアイテムも削除されます。
包含関係は、ACL の継承ルールとは独立しています。たとえば、フォルダに削除するファイルを格納できますが、ファイルは別のフォルダから ACL を継承できます。フォルダを削除しても、その ACL を継承するアイテムは、そのアイテムが包含階層にも含まれていない限り削除されません。
図 2 は、次のアクセス制御を表しています。
- ユーザー 1 は、アイテム A の直接許可プリンシパルです。
- ユーザー 2 は、アイテム B の直接許可プリンシパルです。
- ユーザー 3 は、アイテム C の直接許可プリンシパルです。
- アイテム C はアイテム A の ACL を継承します。
- アイテム B はアイテム A をそのコンテナとして指定します。
- アイテム C はアイテム B をそのコンテナとして指定します。
これらの制御に基づいて、アクセスルールは次のようになります。
- 間接的なアクセス権は
setInheritFromメソッドから取得されます。ユーザー 1 はアイテム A から継承するため、アイテム 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 は削除されませんが、到達できなくなり、検索できなくなります。