Karten-ACLs

Damit nur Nutzer mit Zugriff auf ein Element dieses Element in einem Suchergebnis sehen können, sollten Sie Elemente mit ihren Access Control Lists (ACLs) aus dem Unternehmens-Repository indexieren. Sie müssen die ACLs Ihres Repositorys modellieren und diese ACLs bei der Indexierung von Elementen im Repository einbeziehen. Das Content Connector SDK bietet eine Vielzahl von ACL-Methoden, die leistungsstark genug sind, um die ACLs der meisten Repositories zu modellieren.

ACL erstellen

Das Erstellen 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 beschrieben, die Sie zum Modellieren und Erstellen von ACLs kennen sollten, z. B. Übernahme und Eindämmung.

Hauptkonto mit einer externen ID erstellen

Für Google Cloud Search müssen Nutzer und Gruppen in eine Google-E-Mail-Adresse aufgelöst werden. Bei der Indexierung von Repository-Elementen haben Inhaltsconnectors diese E-Mail-Adressen möglicherweise nicht. 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. In der Klasse ACL gibt es mehrere weitere statische Methoden zum Erstellen von Principal-Objekten.

ACL-Vererbung

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

Übernahme festlegen

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

Ein Element kann mit der Methode setInheritFrom() 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 verweigertes 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.

Zeichnung von Verbindungen zwischen Elementen
Abbildung 1. Die Methode setInheritFrom().

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.

Je nach Zugriffssteuerung lauten die Zugriffsregeln wie folgt:

  • 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, weil Nutzer 1 als direkt zugelassenes Hauptkonto für Element A aufgeführt ist und Element B seine ACL von Element A erbt.
  • Nutzer 2 ist kein indirekt zugelassenes Hauptkonto für Element A.

Vererbungstyp festlegen

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

  • BOTH_PERMIT: Legen Sie den Vererbungstyp auf BOTH_PERMIT fest, damit einem Nutzer nur dann Zugriff auf das Element gewährt wird, wenn sowohl die ACL des untergeordneten Elements als auch die ACL des übergeordneten Elements diesem Nutzer Zugriff auf das Element gewähren.

  • CHILD_OVERRIDE: Wird der Vererbungstyp auf CHILD_OVERRIDE festgelegt, wird erzwungen, dass die ACL des untergeordneten Elements Vorrang vor der ACL des übernommenen übergeordneten Elements hat, wenn ein Konflikt besteht. Wenn also die ACL des übergeordneten Elements dem Nutzer als verweigerter Leser den Zugriff verweigert, hat der Nutzer weiterhin Zugriff, wenn er als Leser auf das untergeordnete Element zugreifen kann. Umgekehrt hat der Nutzer auch dann keinen Zugriff, wenn die ACL des übergeordneten Elements dem Nutzer Zugriff gewährt, wenn er ein abgelehnter Leser des untergeordneten Elements ist.

  • 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 ein Konflikt besteht. Wenn also die ACL des untergeordneten Elements dem Nutzer als verweigerter Leser den Zugriff verweigert, hat der Nutzer weiterhin Zugriff, wenn er als Leser auf das übergeordnete Element zugreifen kann. Umgekehrt hat der Nutzer auch dann keinen Zugriff, wenn die ACL des untergeordneten Elements dem Nutzer Zugriff gewährt, wenn er dem übergeordneten Element verweigert wird.

Bei der Bewertung einer ACL-Vererbungskette kann die Reihenfolge der Bewertung das Ergebnis der Autorisierungsentscheidung ändern. Cloud Search bietet bei der Auswertung von ACL-Vererbungsketten die Reihenfolge "Blatt-zu-Stamm". Insbesondere beginnt die ACL-Entscheidung für eine Kette mit der Bewertung eines untergeordneten Elements mit seinen übergeordneten Elementen und kann bis zum übergeordneten Stammelement fortgesetzt werden.

Wenn die untergeordnete Datei beispielsweise den Vererbungstyp 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, wird die Übernahme in Drive weiter oben in der Kette ausgewertet.

Begrenzungen und das Löschen von Elementen

Beim Indexieren eines Elements können Sie es mithilfe der Methode setContainer() der Klasse IndexingItemBuilder als Container kennzeichnen. Durch die Beziehung zwischen Container und Container wird die physische Hierarchie der Elemente festgelegt und sichergestellt, dass die Elemente ordnungsgemäß gelöscht werden. Wenn ein Container gelöscht wird, werden auch die darin enthaltenen Elemente gelöscht.

Eingrenzungsbeziehungen sind völlig unabhängig von ACL-Vererbungsregeln. Beispielsweise kann eine Datei in einem Dateisystem in einem Ordner enthalten sein, um sie zu löschen, aber die ACL von einem anderen Ordner übernehmen. Durch das Löschen eines Ordners werden Elemente, die die ACL erben, nicht gelöscht, es sei denn, diese Elemente befinden sich auch in der Begrenzungshierarchie des Ordners.

In Abbildung 2 sind diese 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 bezeichnet.

Je nach Zugriffssteuerung lauten die Zugriffsregeln wie folgt:

  • Der indirekte Zugriff erfolgt über die Methode setInheritFrom(). Nutzer 1 kann also auf Element C zugreifen, weil Element C die ACL von Element A erbt.
  • Der indirekte Zugriff ergibt sich nicht dadurch, dass Element C in Element B enthalten ist. Nutzer 2 kann daher nicht auf Element C zugreifen.
Zeichnung von Verbindungen zwischen Elementen
Abbildung 2. Die verwendete Methode setInheritFrom().

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

Wenn ein Element erfolgreich gelöscht wurde, gilt Folgendes:

  • Jedes Element, das ein gelöschtes Element enthält, kann nicht mehr gesucht werden und wird zum Löschen aus der Datenquelle von Google geplant.
  • Alle Elemente, in denen 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 kein Container mit setContainer() festgelegt ist oder ihre Begrenzungshierarchie keine gelöschten Elemente enthält, bleiben dieses Element und seine Daten in der Datenquelle von Google. Sie sind dafür verantwortlich, das Element zu löschen.

Abbildung 3 zeigt ein Beispiel dafür, wie das Löschen für eine Elementhierarchie funktioniert.

Zeichnung von Verbindungen zwischen Elementen
Abbildung 3. Elemente und ACL-Vererbung löschen.

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

Löschvorgänge werden über die Containerverweise kaskadiert. Wenn Element A gelöscht wird, gilt Folgendes:

  • Alle Nachfolger 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 Nutzer können nicht mehr nach Element E suchen.