Karten-ACLs

Damit nur Nutzer, die Zugriff auf ein Element haben, es auch in den Suchergebnissen sehen können, müssen Sie Elemente zusammen mit ihren Zugriffssteuerungslisten (Access Control Lists, ACLs) aus dem Unternehmensrepository indexieren. Sie müssen die Repository-ACLs modellieren und beim Indexieren von Elementen einbeziehen. Das Content Connector SDK bietet Methoden zum Modellieren der ACLs der meisten Repositories.

ACL erstellen

So erstellen Sie in zwei Schritten eine ACL:

Erstellen Sie mit statischen Methoden in der Klasse ACL ein Principal.
Verwenden Sie die Klasse Acl.Builder, um die ACL mithilfe des Hauptkontos zu erstellen.

In diesem Dokument werden Konzepte zum Modellieren und Erstellen von ACLs behandelt, z. B. Vererbung und Einkapselung (containment).

Mit einer externen ID ein Hauptkonto erstellen

Für Google Cloud Search müssen Nutzer und Gruppen in E‑Mail-Adressen von Google aufgelöst werden. Wenn Repository-Elemente indexiert werden, dürfen diese E-Mail-Adressen nicht in Inhaltsconnectors enthalten sein. Mit dem Content Connector SDK können Sie jedoch anstelle einer E-Mail-Adresse eine externe ID (ID, die einem Nutzer oder einer Gruppe Zugriff auf Repository-Elemente gewährt) zum Indexieren eines Elements verwenden. Verwenden Sie die Methode getUserPrincipal oder getGroupPrincipal, um Hauptkonten mit externen IDs zu erstellen. Die Klasse ACL enthält mehrere andere statische Methoden zum Erstellen von Principal-Objekten.

Nachdem Sie die Identität eines Elements neu zugeordnet haben, müssen Sie die Elemente neu indexieren, damit die neue Identität wirksam wird. Weitere Informationen finden Sie unter Identitäten neu zuordnen.

ACL-Vererbung

Der Begriff ACL-Vererbung bezeichnet die Autorisierung für ein bestimmtes Element und einen bestimmten Nutzer, die auf den kombinierten ACLs des Elements und seiner Vererbungskette basiert. Die Regeln für eine Berechtigungsentscheidung hängen vom Repository und den Attributen des Elements ab.

Vererbung festlegen

Für jedes Element können direkt zugelassene Hauptkonten und direkt verweigerte Hauptkonten mit den Methoden setReaders und setDeniedReaders angegeben werden. Als „direkt zugelassenes Hauptkonto“ wird ein in einer ACL identifizierter Nutzer bezeichnet, der über direkten Zugriff auf ein Element verfügt. Als „direkt verweigertes Hauptkonto“ wird ein in einer ACL identifizierter Nutzer bezeichnet, dem kein Zugriff auf ein Element gewährt wird.

Ein Element kann auch indirekt zugelassene Hauptkonten und indirekt verweigerte Hauptkonten mit der Methode setInheritFrom erben. Ein indirekt zugelassenes Hauptkonto hat über die ACL-Vererbung indirekten Zugriff auf ein Element. Einem indirekt verweigerten Hauptkonto wird der Zugriff über die Vererbung verweigert.

Abbildung 1 zeigt, wie Sie die Methode setInheritFrom verwenden, um Hauptkonten zu erben.

Darstellung von Verbindungen zwischen Elementen — **Abbildung 1.** Die Methode `setInheritFrom`.

Abbildung 1 zeigt diese Zugriffssteuerungen:

Nutzer 1 ist ein direkt zugelassenes Hauptkonto für Element A.
Nutzer 2 ist ein direkt zugelassenes Hauptkonto für Element B.
Element B erbt die ACL von Element A.

Dadurch ergeben sich die folgenden Zugriffsregeln:

Nutzer 1 ist ein indirekt zugelassenes Hauptkonto für Element B, ohne dass er explizit angegeben werden muss. Der Zugriff wird von Element A vererbt.
Nutzer 2 ist kein indirekt zugelassenes Hauptkonto für Element A.

Vererbungstyp festlegen

Wenn Sie die Vererbung mit der Methode setInheritFrom festlegen, müssen Sie den Vererbungstyp mit der Methode setInheritanceType festlegen. Der Übernahmetyp bestimmt, wie eine untergeordnete ACL mit einer übergeordneten ACL kombiniert wird. Die Acl.InheritanceType implementiert drei Typen:

BOTH_PERMIT: Zugriff nur gewähren, wenn sowohl die ACLs für untergeordnete als auch für übergeordnete Elemente dies zulassen.
CHILD_OVERRIDE: Bei einem Konflikt hat die ACL des untergeordneten Elements Vorrang vor der ACL des übergeordneten Elements. Ein Nutzer kann auf das untergeordnete Element zugreifen, auch wenn der Elternteil dies ablehnt, oder der Zugriff auf das untergeordnete Element kann ihm verweigert werden, auch wenn der Elternteil dies zulässt.
PARENT_OVERRIDE: Bei Konflikten hat die übergeordnete ACL Vorrang vor der untergeordneten ACL.

In Cloud Search werden ACL-Vererbungsketten von Blatt zu Stamm ausgewertet. Die Auswertung beginnt mit dem Kind und seinen Eltern und kann bis zum übergeordneten Stamm fortgesetzt werden.

Wenn das Kind beispielsweise CHILD_OVERRIDE verwendet und der Nutzer Zugriff hat, muss Cloud Search das übergeordnete Element nicht auswerten. Wenn das untergeordnete Element jedoch PARENT_OVERRIDE oder BOTH_PERMIT verwendet, wird die Kette in Cloud Search weiter ausgewertet.

Containment und Löschung von Elementen

Wenn Sie ein Element indexieren, können Sie es mit der Methode setContainer der Klasse IndexingItemBuilder als Container kennzeichnen. Durch diese Beziehung wird die physische Hierarchie festgelegt und ein ordnungsgemäßes Löschen sichergestellt. Wenn Sie einen Container löschen, werden auch die darin enthaltenen Elemente gelöscht.

Diese Beziehungen sind unabhängig von ACL-Vererbungsregeln. Beispielsweise kann ein Ordner eine Datei zum Löschen enthalten, die Datei kann ihre ACL jedoch von einem anderen Ordner erben. Durch das Löschen eines Ordners werden Elemente, die seine ACL erben, nicht gelöscht, es sei denn, diese Elemente befinden sich auch in seiner Containment-Hierarchie.

Abbildung 2 zeigt diese Zugriffssteuerungen:

Nutzer 1 ist ein direkt zugelassenes Hauptkonto für Element A.
Nutzer 2 ist ein direkt zugelassenes Hauptkonto für Element B.
Nutzer 3 ist ein direkt zugelassenes Hauptkonto für Element C.
Element C erbt die ACL von Element A.
Element A wird von Element B als sein Container bestimmt.
Element B wird von Element C als sein Container bestimmt.

Dadurch ergeben sich die folgenden Zugriffsregeln:

Der indirekte Zugriff erfolgt über die Methode setInheritFrom. Nutzer 1 kann auf Element C zugreifen, weil es von Element A erbt.
Der indirekte Zugriff entsteht nicht durch die Einbettung. Nutzer 2 kann nicht auf Element C zugreifen.

Durch die Trennung der ACL-Vererbung von der Containment-Hierarchie können Sie viele Strukturen modellieren.

Wenn Sie ein Element löschen, geschieht Folgendes:

Jedes Element, das das gelöschte Element enthält, kann nicht mehr gesucht werden und ist zum Löschen vorgesehen.
Jedes Element, in dem das gelöschte Element in setInheritFrom angegeben ist, kann nicht mehr gesucht werden.

Wenn für eine Ressource setInheritFrom für ein gelöschtes Element verwendet wird, aber kein Container festgelegt ist oder die Hierarchie keine gelöschten Elemente enthält, bleibt das Element in der Datenquelle. Sie sind dafür verantwortlich, es zu löschen.

Abbildung 3 zeigt ein Beispiel für das Löschen in einer Elementhierarchie.

Abbildung 3 zeigt diese Zugriffssteuerungen:

Nutzer 1 ist ein direkt zugelassenes Hauptkonto für Element A.
Nutzer 2 ist ein direkt zugelassenes Hauptkonto für Element D.
Element D und Element E erben beide von Element A.
Element A wird von Element D als sein Container bestimmt.
Die Elemente A und E sind Elemente auf Stammebene.

Löschungen haben Auswirkungen auf die Container-Verweise. Wenn Sie Element A löschen, geschieht Folgendes:

Alle Nachkommen des Verweises setInheritFrom verlieren den Zugriff.
Nutzer können nicht mehr auf Element A zugreifen.
Punkt D wird implizit gelöscht und ist nicht mehr zugänglich.
Element E wird nicht gelöscht, kann aber nicht mehr erreicht werden und ist nicht mehr suchbar.