Diese Seite wurde von der Cloud Translation API übersetzt.

Karten-ACLs

Damit nur Nutzer, die Zugriff auf ein Element haben, es auch in den Suchergebnissen sehen können, sollten Sie Elemente zusammen mit ihren Zugriffssteuerungslisten (Access Control Lists, ACLs) aus dem Unternehmensrepository indexieren. Die ACLs aus dem Repository müssen also modelliert und beim Indexieren von Elementen im Repository eingeschlossen werden. Im Content Connector SDK sind viele ACL-Methoden enthalten, die leistungsfähig genug sind, um die ACLs der meisten Repositories zu modellieren.

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.

Im Rest dieses Dokuments werden einige Konzepte erläutert, die Sie zum Modellieren und Erstellen von ACLs benötigen, z. B. Vererbung und Einkapselung (containment).

Mit einer externen ID ein Hauptkonto erstellen

Für Google Cloud Search müssen Nutzer und Gruppen in eine E-Mail-Adresse 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 beliebige 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 getGroupPrincpal(), um Hauptkonten mit externen IDs zu erstellen. Es gibt mehrere andere statische Methoden in der Klasse ACL, mit denen Principal-Objekte erstellt werden.

ACL-Vererbung

Der Begriff ACL-Vererbung bezeichnet die Autorisierung für ein bestimmtes Element und einen bestimmten Nutzer, die auf dem Ergebnis einer Kombination der ACLs des Elements und der ACLs seiner Vererbungskette basiert. Die Regeln, die für eine Berechtigungsentscheidung verwendet werden, 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 bestimmtes Element gewährt wird.

Ein Element kann auch indirekt zugelassene Hauptkonten und indirekt verweigerte Hauptkonten über die Methode setInheritFrom() erben. Ein indirekt zugelassenes Hauptkonto ist ein Nutzer, der über eine ACL-Vererbung indirekten Zugriff auf ein bestimmtes Element hat. Ein indirekt verweigertes Hauptkonto ist ein Nutzer, dem über ACL-Vererbung der Zugriff auf ein bestimmtes Element verweigert wird.

In Abbildung 1 sehen Sie, wie die Methode setInheritFrom() verwendet wird, um indirekt zugelassene und indirekt verweigerte Hauptkonten zu erben.

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

In Abbildung 1 sind die folgenden Zugriffssteuerungen dargestellt:

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 muss nicht explizit als Hauptkonto für Element B angegeben werden, um dem indirekt zugelassenen Hauptkonto von Element B zugeordnet werden zu können. Der Zugriff wird vererbt, da Nutzer 1 unter dem direkt zugelassenen Hauptkonto für Element A gelistet ist und die ACL wird durch Element B von Element A geerbt.
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 Vererbungstyp bestimmt, wie die ACL eines untergeordneten Elements mit der ACL des übergeordneten Elements kombiniert wird. Die Acl.InheritanceType implementiert drei Vererbungstypen:

BOTH_PERMIT: Wird der Vererbungstyp auf BOTH_PERMIT festgelegt, wird einem Nutzer nur dann Zugriff auf das Element gewährt, wenn sowohl die ACL des untergeordneten Elements als auch die geerbte ACL des übergeordneten Elements diesem Nutzer den Zugriff auf das Element ermöglichen.
CHILD_OVERRIDE: Wird der Vererbungstyp auf CHILD_OVERRIDE festgelegt, wird erzwungen, dass die ACL des untergeordneten Elements Vorrang vor der ACL des geerbten übergeordneten Elements hat, wenn diese in Konflikt stehen. Wenn also dem Nutzer durch die ACL des übergeordneten Elements der Zugriff untersagt wird (verweigerter Leser), hat er weiterhin Zugriff, wenn er als Leser auf das untergeordnete Element zugreifen kann. Umgekehrt hat ein Nutzer selbst dann keinen Zugriff, wenn ihm durch die ACL des übergeordneten Elements Zugriff gewährt wird, für das untergeordnete Objekt jedoch nicht (verweigerter Leser).
PARENT_OVERRIDE: Wird der Vererbungstyp auf PARENT_OVERRIDE festgelegt, wird erzwungen, dass die ACL des übergeordneten Elements Vorrang vor der ACL des untergeordneten Elements hat, wenn diese in Konflikt stehen. Wenn dem Nutzer also über die ACL des untergeordneten Elements der Zugriff untersagt wird (verweigerter Leser), hat er weiterhin Zugriff, wenn er als Leser auf das übergeordnete Element zugreifen kann. Umgekehrt hat ein Nutzer selbst dann keinen Zugriff, wenn ihm durch die ACL des untergeordneten Elements Zugriff gewährt wird, für das übergeordnete Objekt jedoch nicht (verweigerter Leser).

Bei der Bewertung einer ACL-Vererbungskette kann das Ergebnis der Berechtigungsentscheidung durch die Reihenfolge der Bewertung verändert werden. In Cloud Search gilt bei der Bewertung von ACL-Vererbungsketten die Reihenfolge „Blatt-zu-Stamm“. Die ACL-Entscheidung für eine Kette beginnt mit der Bewertung eines untergeordneten Elements mit seinen übergeordneten Elementen und kann bis zum Stamm-übergeordneten Element fortgesetzt werden.

Wenn das untergeordnete Element beispielsweise den Vererbungstyp CHILD_OVERRIDE hat und der Nutzer Zugriff auf das untergeordnete Element hat, muss Drive das übergeordnete Element nicht auswerten. Wenn das Kind jedoch PARENT_OVERRIDE oder BOTH_PERMIT hat, wird die Vererbung in Drive weiter oben in der Kette 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. Mit der Beziehung zwischen „Container“ vs. „im Container enthaltenes Element“ wird die physische Hierarchie von Elementen festgelegt und dafür gesorgt, dass Elemente richtig gelöscht werden. Wenn ein Container gelöscht wird, werden nämlich auch die darin enthaltenen Elemente gelöscht.

Diese Beziehungen sind völlig unabhängig von ACL-Vererbungsregeln. Beispielsweise kann eine Datei in einem Dateisystem in einem Ordner enthalten sein, um gelöscht zu werden. Die ACL kann sie 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 der Containment-Hierarchie des Ordners.

In Abbildung 2 sind die folgenden Zugriffssteuerungen dargestellt:

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 hat Zugriff auf Element C, weil es die ACL von Element A erbt.
Der indirekte Zugriff entsteht nicht dadurch, dass Element C in Element B enthalten ist. Nutzer 2 kann daher nicht auf Element C zugreifen.

Dadurch, dass die ACL-Vererbung von der Containment-Hierarchie getrennt ist, können viele verschiedene Strukturen modelliert werden.

Wenn ein Element erfolgreich gelöscht wurde, hat dies die folgenden Konsequenzen:

Jedes Element, das ein gelöschtes Element enthielt, kann nicht mehr gesucht werden und ist zum Löschen aus der Google-Datenquelle vorgesehen.
Jedes Element, in dem das gelöschte Element mit der Methode setInheritFrom() angegeben wurde, kann nicht mehr gesucht werden.

Wenn für eine Ressource ein gelöschtes Element mit der Methode setInheritFrom() vorhanden ist, aber kein Container mit setContainer() festgelegt wurde oder die Containment-Hierarchie keine gelöschten Elemente enthält, bleiben das Element und seine Daten in der Datenquelle von Google. Sie sind dafür zuständig, das Element zu löschen.

Abbildung 3 zeigt, wie das Löschen in einer Elementhierarchie funktioniert.

Die folgenden Zugriffssteuerungen sind in Abbildung 3 dargestellt:

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 die ACL von Element A.
Element A wird von Element D als sein Container bestimmt.
Die Elemente A und E sind Elemente auf Stammebene, da sie kein Containerelement haben.

Löschungen haben Auswirkungen auf die Container-Verweise. Das Löschen von Element A hat folgende Auswirkungen:

Alle Nachkommen des Verweises setInheritFrom() verlieren den Zugriff für alle Nutzer.
Kein Nutzer kann mehr auf Element A zugreifen.
Punkt D wird implizit gelöscht. Kein Nutzer kann mehr auf Element D zugreifen.
Element E wird nicht gelöscht, da das Löschen nur in Container-Verweisen erfolgt.
Element E kann nicht mehr erreicht werden und kein Nutzer kann mehr nach Element E suchen.