アイテムへのアクセス権を持つユーザーのみが検索結果内のそのアイテムを表示できるようにするには、エンタープライズ リポジトリからアクセス制御リスト（ACL）を使用してアイテムをインデックスに登録する必要があります。リポジトリ内のアイテムをインデックスに登録する際には、リポジトリの ACL をモデル化し、それらの ACL を含める必要があります。Content Connector SDK には、ほとんどのリポジトリの ACL をモデル化できる有用な ACL メソッドが豊富に用意されています。
ACL の作成
ACL の作成は、2 つのステップによるプロセスになります。
- ACL クラスの静的メソッドを使用して、
Principalを作成します。 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() メソッドを使用して、間接許可プリンシパルと間接拒否プリンシパルを継承する方法を示しています。
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 よりも優先されます。つまり、親アイテムの ACL で拒否閲覧者としてユーザーのアクセスが拒否されていても、ユーザーが子アイテムに対して閲覧者としてのアクセス権を持っている場合はアクセスできます。逆に、親アイテムの ACL でユーザーのアクセスが許可されていても、ユーザーが子の拒否閲覧者である場合はアクセスできません。PARENT_OVERRIDE- 継承タイプをPARENT_OVERRIDEに設定すると、親アイテムの ACL が子アイテムの ACL より優先されるように設定できます。つまり、子アイテムの 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 にアクセスできません。
setInheritFrom() メソッド。ACL の継承を包含階層から分離することで、さまざまな既存の構造をモデル化できます。
アイテムが正常に削除された場合の動作は、次のとおりです。
- 削除対象アイテムを包含していたアイテムは検索できなくなり、Google のデータソースからの削除がスケジュールされます。
setInheritFrom()メソッドを使用して削除済みアイテムを指定していたアイテムは検索できなくなります。
リソースに setInheritFrom() メソッドを使用して削除されたアイテムがあるが、setContainer() を使用してコンテナセットがない場合、またはリソースの包含階層に削除済みのアイテムがない場合、そのアイテムとそのデータは Google のデータソースに残ります。そのアイテムの削除は個別に行う必要があります。
図 3 は、アイテム階層における削除の仕組みの例を示しています。
図 3 には、次のようなアクセス制御が示されています。
- ユーザー 1 は、アイテム A の直接許可プリンシパルです。
- ユーザー 2 は、アイテム D の直接許可プリンシパルです。
- アイテム D とアイテム E の両方がアイテム A の ACL を継承します。
- アイテム D はアイテム A をそのコンテナとして指定します。
- アイテム A とアイテム E は、コンテナ アイテムを持たないため、ルートレベルのアイテムです。
削除は、container 参照に沿って処理されます。アイテム A が削除された場合の動作は、次のとおりです。
setInheritFrom()参照のすべての子孫は、すべてのユーザーのアクセス権を失います。- いずれのユーザーもアイテム A にアクセスできません。
- アイテム D は暗黙的に削除されます。いずれのユーザーもアイテム D にアクセスできません。
- 削除はコンテナ参照のみに沿って処理されるため、アイテム E は削除されません。
- アイテム E にアクセスできなくなり、ユーザーはアイテム E を検索できなくなります。