Karten-ACLs

Damit nur Nutzer mit Zugriff auf ein Element dieses Element in den Suchergebnissen sehen, sollten Sie Elemente mit ihren Access Control Lists (ACLs) aus dem Unternehmens-Repository indexieren. Sie müssen die ACLs Ihres Repositorys modellieren und beim Indexieren von Elementen im Repository einbeziehen. Das Content Connector SDK bietet zahlreiche ACL-Methoden, die leistungsfähig genug sind, um die ACLs der meisten Repositories zu modellieren.

ACL erstellen

Die Erstellung einer ACL erfolgt in zwei Schritten:

1. Erstellen Sie mit statischen Methoden in der ACL eine Principal.
2. Verwenden Sie die Klasse Acl.Builder, um die ACL mit dem Hauptkonto zu erstellen.

Im weiteren Verlauf dieses Dokuments werden einige Konzepte behandelt, die Sie zum Modellieren und Erstellen von ACLs kennen sollten, z. B. Vererbung und Eindämmung.

Hauptkonto mit externer ID erstellen

Für Google Cloud Search müssen Nutzer und Gruppen in eine Google-E-Mail-Adresse aufgelöst werden. Beim Indexieren von Repository-Elementen dürfen Inhaltsconnectors diese E-Mail-Adressen möglicherweise nicht enthalten. 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 die Methode getGroupPrincpal(), um Hauptkonten mit externen IDs zu erstellen. In der Klasse ACL gibt es mehrere andere statische Methoden, die zum Erstellen von Principal-Objekten verwendet werden.

ACL-Übernahme

ACL-Vererbung bezieht sich auf die Autorisierung für ein bestimmtes Element und einen bestimmten Nutzer, basierend auf dem Ergebnis einer Kombination aus den ACLs des Elements und den ACLs seiner Vererbungskette. Die Regeln, die für eine Autorisierungsentscheidung verwendet werden, hängen vom Repository und von den Eigenschaften des Elements ab.

Übernahme festlegen

Jedes Element kann direkt zugelassene Hauptkonten und direkt abgelehnte Hauptkonten haben, die mit den Methoden setReaders() und setDeniedReaders() angegeben werden. Ein direkt zugelassenes Hauptkonto ist ein in einer ACL identifizierter Nutzer, der ihm direkten Zugriff auf ein bestimmtes Element gewährt. Ein direkt abgelehntes Hauptkonto ist ein Nutzer, der in einer ACL keinen Zugriff auf ein bestimmtes Element hat.

Mit der Methode setInheritFrom() kann ein Element auch indirekt zulässige Hauptkonten und indirekt abgelehnte Hauptkonten übernehmen. Ein indirekt zugelassenes Hauptkonto ist ein Nutzer, der durch ACL-Vererbung indirekten Zugriff auf ein bestimmtes Element hat. Ein indirekt abgelehntes Hauptkonto ist ein Nutzer, dem durch 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 abgelehnte Hauptkonten zu übernehmen.

Diese Zugriffssteuerungen sind in Abbildung 1 dargestellt:

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

Abhängig von den Zugriffssteuerungen ergeben sich die folgenden Zugriffsregeln:

• Nutzer 1 muss nicht explizit als Hauptkonto von Element B angegeben werden, um ein indirekt zugelassenes Hauptkonto von Element B zu sein. Der Zugriff wird übernommen, da Nutzer 1 als direkt zugelassenes Hauptkonto von Element A aufgeführt ist und Element B die ACL von Element A übernimmt.
• Nutzer 2 ist kein indirekt zugelassenes Hauptkonto für Element A.

Übernahmetyp festlegen

Wenn Sie die Übernahme mit der Methode setInheritFrom() festlegen, müssen Sie den Übernahmetyp auch mit der Methode setInheritanceType() festlegen. Der Vererbungstyp bestimmt, wie die ACL eines untergeordneten Elements mit der ACL der übergeordneten ACL kombiniert wird. Mit Acl.InheritanceType werden drei Vererbungstypen implementiert:

• BOTH_PERMIT: Legen Sie den Vererbungstyp auf BOTH_PERMIT fest, um einem Nutzer nur dann Zugriff auf das Element zu gewähren, 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 es zu Konflikten kommt. Wenn die ACL des übergeordneten Elements dem Nutzer also den Zugriff als verweigerten Leser verweigert, hat er weiterhin Zugriff, sofern er als Leser Zugriff auf das untergeordnete Element hat. Umgekehrt hat der Nutzer selbst dann keinen Zugriff, wenn die ACL des übergeordneten Elements Zugriff auf das untergeordnete Element gewährt.

• PARENT_OVERRIDE: Wenn Sie den Vererbungstyp auf PARENT_OVERRIDE setzen, wird erzwungen, dass die ACL des übergeordneten Elements Vorrang vor der ACL des untergeordneten Elements hat, wenn sie in Konflikt stehen. Wenn dem Nutzer in der ACL des untergeordneten Elements also der Zugriff als verweigerter Leser verweigert wird, hat er weiterhin Zugriff, wenn er als Leser Zugriff auf das übergeordnete Element hat. Umgekehrt gilt: Selbst wenn dem Nutzer über die ACL des untergeordneten Elements Zugriff gewährt wird, hat der Nutzer keinen Zugriff, wenn ihm das übergeordnete Element verweigert wird.

Bei der Bewertung einer ACL-Vererbungskette kann die Reihenfolge der Bewertung das Ergebnis der Autorisierungsentscheidung ändern. Bei Cloud Search gilt für die Bewertung von ACL-Vererbungsketten die Blatt-zu-Stamm-Reihenfolge. Insbesondere beginnt die ACL-Entscheidung für eine Kette mit der Auswertung eines untergeordneten Elements mit seinen übergeordneten Elementen und kann bis zur übergeordneten Stammebene fortgeführt werden.

Wenn das untergeordnete Element beispielsweise den Übernahmetyp CHILD_OVERRIDE hat und der Nutzer Zugriff auf das untergeordnete Element hat, muss Drive das übergeordnete Element nicht bewerten. Wenn das untergeordnete Element jedoch PARENT_OVERRIDE oder BOTH_PERMIT hat, wertet Drive die Übernahme weiter oben in der Kette aus.

Begrenzung und Löschen von Elementen

Beim Indexieren eines Elements können Sie es mit der Methode setContainer() der Klasse IndexingItemBuilder als Container kennzeichnen. Die Beziehung „Container“ und „Enthalten“ legt die physische Hierarchie der Elemente fest und sorgt dafür, dass Elemente ordnungsgemäß gelöscht werden. Wenn ein Container gelöscht wird, werden auch die darin enthaltenen Elemente gelöscht.

Begrenzungsbeziehungen sind völlig unabhängig von ACL-Vererbungsregeln. Eine Datei in einem Dateisystem kann beispielsweise zum Löschen in einem Ordner enthalten sein, aber die ACL von einem anderen Ordner übernehmen. Durch das Löschen eines Ordners werden keine Elemente gelöscht, die seine ACL übernehmen, es sei denn, diese Elemente befinden sich auch in der Begrenzungshierarchie des Ordners.

In Abbildung 2 sind die folgenden Zugriffssteuerungen dargestellt:

• Nutzer 1 ist ein direkt zugelassenes Hauptkonto von Element A.
• Nutzer 2 ist ein direkt zugelassenes Hauptkonto von Element B.
• Nutzer 3 ist ein direkt zugelassenes Hauptkonto von 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.

Abhängig von den Zugriffssteuerungen ergeben sich die folgenden Zugriffsregeln:

• Der indirekte Zugriff erfolgt über die Methode setInheritFrom(). Nutzer 1 kann also auf Element C zugreifen, da Element C die ACL von Element A erbt.
• Der indirekte Zugriff erfolgt nicht dadurch, dass Element C in Element B enthalten ist. Daher kann Nutzer 2 nicht auf Element C zugreifen.

Durch die Trennung der ACL-Vererbung von der Begrenzungshierarchie können Sie viele verschiedene vorhandene Strukturen modellieren.

Wenn ein Element erfolgreich gelöscht wurde:

• Jedes Element, das ein gelöschtes Element enthielt, kann nicht mehr gesucht werden und wird zum Löschen aus der Datenquelle von Google geplant.
• Jedes Element, für das das gelöschte Element mit der Methode setInheritFrom() angegeben wurde, kann nicht mehr gesucht werden.

Wenn in einer Ressource ein gelöschtes Element mit der Methode setInheritFrom(), aber kein Container mit setContainer() festgelegt ist oder die Begrenzungshierarchie keine gelöschten Elemente enthält, bleiben das Element und seine Daten in der Datenquelle von Google. Sie sind dafür verantwortlich, das Element zu löschen.

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

Diese Zugriffssteuerungen sind in Abbildung 3 dargestellt:

• Nutzer 1 ist ein direkt zugelassenes Hauptkonto von Element A.
• Nutzer 2 ist ein direkt zugelassenes Hauptkonto von 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 werden über die Containerverweise weitergegeben. Wenn Element A gelöscht wird:

• Alle Nachkommen der Referenz setInheritFrom() verlieren den Zugriff für alle Nutzer.
• Kein Nutzer kann auf Element A zugreifen.
• Element D wird implizit gelöscht. Kein Nutzer kann auf Element D zugreifen.
• Element E wird nicht gelöscht, da das Löschen nur über Containerverweise erfolgt.
• Element E ist nicht mehr erreichbar und kein Nutzer kann mehr nach Element E suchen.