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. Das Content Connector SDK bietet eine Vielzahl von ACL-Methoden, die leistungsfähig genug sind, um die ACLs der meisten Repositories zu modellieren.

ACL erstellen

So erstellen Sie in zwei Schritten eine ACL:

1. Erstellen Sie mit statischen Methoden in der ACL einen Principal.
2. Verwenden Sie die Klasse Acl.Builder, um die ACL mit dem Hauptkonto 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 noch 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 Autorisierungsentscheidung verwendet werden, hängen vom Repository und von den Eigenschaften des Elements ab.

Vererbung festlegen

Jedes Element kann direkt zugelassene Hauptkonten und direkt abgelehnte Hauptkonten haben, die 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.

indirekt verweigerte Hauptkonten erben.setInheritFrom() 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.

Diese Zugriffssteuerungen sind in Abbildung 1 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.

Basierend auf den Zugriffssteuerungen gelten folgende 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. Für Acl.InheritanceType werden drei Vererbungstypen implementiert:

• 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 sich diese im Konflikt befinden. Wenn also dem Nutzer ü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 übergeordneten Stammelement fortgesetzt werden.

Wenn das untergeordnete Element beispielsweise den Vererbungstyp CHILD_OVERRIDE hat und der Nutzer Zugriff darauf hat, muss das übergeordnete Element in Google Drive nicht ausgewertet werden. Wenn das untergeordnete Element jedoch PARENT_OVERRIDE oder BOTH_PERMIT hat, wird die Überschreibung weiter oben in der Hierarchie geprüft.

Eingrenzung und Löschen 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“ und „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.

Basierend auf den Zugriffssteuerungen gelten folgende 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.

Durch die Trennung der ACL-Vererbung von der Containment-Hierarchie können viele verschiedene Strukturen modelliert werden.

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

• Elemente, die ein gelöschtes Element enthalten, können nicht mehr gesucht werden und sind 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 eine Ressource ein gelöschtes Element mit der Methode setInheritFrom() enthält, aber keinen 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 keine Containerelemente enthalten.

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.