ACLs zuordnen

Es ist zwar nicht zwingend erforderlich, aber sehr zu empfehlen, dass Elemente zusammen mit Ihren Zugriffssteuerungslisten (Access Control Lists, ACLs) aus dem Unternehmensrepository indexiert werden. So wird dafür gesorgt, dass Nutzer als Suchergebnis nur Elemente angezeigt bekommen, auf die sie auch Zugriff haben. 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.

ACLs erstellen

So erstellen Sie in zwei Schritten eine ACL:

  1. Erstellen Sie mit statischen Methoden in der ACL-Klasse ein Principal (Hauptkonto).
  2. Erstellen Sie mit der Klasse Acl.Builder mithilfe des Hauptkontos eine ACL.

Im Rest dieses Artikels 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. Richten Sie mit den Methoden getUserPrincipal() und getGroupPrincpal() Hauptkonten ein, in denen externe IDs enthalten sind. Es gibt noch mehrere statische Methoden in der Klasse ACL, mit denen sich Principal-Objekte erstellen lassen.

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. Diese Berechtigungsentscheidung wird mit unterschiedlichen Regeln abhängig vom Repository und den Attributen des Elements festgelegt.

Vererbung festlegen

Für jedes Element kann es direkt zugelassene Hauptkonten und direkt verweigerte Hauptkonten geben, die über die Methoden setReaders() und setDeniedReaders() angegeben werden. Als "direkt autorisiertes 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.

Darüber hinaus können Elemente über die Methode setInheritFrom() auch indirekt zugelassene und indirekt verweigerte Hauptkonten erben. Ein indirekt zugelassenes Hauptkonto ist 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 jedoch kein indirekt zugelassenes Hauptkonto für Element A.

Vererbungstyp festlegen

Wenn Sie die Vererbung mithilfe der Methode setInheritFrom() festlegen, müssen Sie den Vererbungstyp über die Methode setInheritanceType() bestimmen. Dieser bezieht sich auf die Regel, die bestimmt, wie eine untergeordnete ACL mit einer übergeordneten ACL kombiniert wird. Durch Acl.InheritanceType werden die folgenden 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 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, indem vom Blatt mit jeweiligem übergeordneten Element bis hin zum Stamm bewertet wird.

Containment und Löschung von Elementen

Wenn ein Element indexiert wird, können Sie ihm ein Containerlabel hinzufügen, indem Sie die Methode setContainer() der Klasse IndexingItemBuilder verwenden. Mit der Beziehung zwischen "Container" vs. "im Container enthaltenes Element" wird die physische Hierarchie von Elementen festgelegt, insbesondere dafür, Elemente richtig löschen zu können. 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.
Darstellung von Verbindungen zwischen Elementen
Abbildung 2: Die Methode setInheritFrom()

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, in dessen Container das gelöschte Element angegeben wurde, 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 eine Ressource ein gelöschtes Element enthält, für das die Methode setInheritFrom() verwendet wird, für das jedoch kein Container mithilfe der Methode setContainer() festgelegt wurde, oder dessen 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.

Darstellung von Verbindungen zwischen Elementen
Abbildung 3: Löschen eines Elements und einer ACL-Vererbung

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 B.
  • 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.