Karten-ACLs

Damit nur Nutzer mit Zugriff auf ein Element es in den Suchergebnissen sehen können, indexieren Sie Elemente mit ihren Zugriffssteuerungslisten (Access Control Lists, ACLs) aus dem Unternehmensrepository. Sie müssen die Repository-ACLs modellieren und beim Indexieren von Elementen einbeziehen. Das Content Connector SDK bietet Methoden zum Modellieren der ACLs der meisten Repositories.

ACL erstellen

Das Erstellen einer ACL umfasst zwei Schritte:

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

In diesem Dokument werden Konzepte zum Modellieren und Erstellen von ACLs erläutert, z. B. Vererbung und Containment.

Mit einer externen ID ein Hauptkonto erstellen

Für Google Cloud Search müssen Nutzer und Gruppen in Google-E-Mail-Adressen aufgelöst werden. Beim Indexieren von Repository-Elementen haben Content Connectors möglicherweise keinen Zugriff auf diese E-Mail-Adressen. Mit dem Content Connector SDK können Sie jedoch anstelle einer E-Mail-Adresse eine externe ID (eine ID, die einem Nutzer oder einer Gruppe Zugriff auf Repository-Elemente gewährt) zum Indexieren eines Elements verwenden. Mit den getUserPrincipal Methoden oder den getGroupPrincipal Methoden können Sie Hauptkonten (Principals) mit einer bereitgestellten externen ID erstellen. Die ACL Klasse enthält mehrere andere statische Methoden zum Erstellen von Principal Objekten.

Nachdem Sie die Identität eines Elements neu zugeordnet haben, müssen Sie die Elemente neu indexieren, damit die neue Identität wirksam wird. Weitere Informationen finden Sie unter Identitäten neu zuordnen.

ACL-Vererbung

Der Begriff ACL-Vererbung bezeichnet die Autorisierung für ein bestimmtes Element und einen bestimmten Nutzer, die auf den kombinierten ACLs des Elements und seiner Vererbungskette basiert. Die Regeln für eine Autorisierungsentscheidung hängen vom Repository und den Elementattributen ab.

Vererbung festlegen

Jedes Element kann direkt zugelassene Hauptkonten und direkt verweigerte Hauptkonten, die mit den setReaders und setDeniedReaders Methoden angegeben werden. Als „direkt zugelassenes Hauptkonto“ wird ein in einer ACL identifizierter Nutzer bezeichnet, der direkten Zugriff auf ein Element hat. Als „direkt verweigertes Hauptkonto“ wird ein in einer ACL identifizierter Nutzer bezeichnet, dem kein Zugriff auf ein Element gewährt wird.

Ein Element kann auch indirekt zugelassene Hauptkonten und indirekt verweigerte Hauptkonten über die setInheritFrom Methode erben. Ein indirekt zugelassenes Hauptkonto hat über die ACL-Vererbung indirekten Zugriff auf ein Element. Einem indirekt verweigerten Hauptkonto wird der Zugriff über die Vererbung verweigert.

In Abbildung 1 sehen Sie, wie die setInheritFrom Methode verwendet wird, um Hauptkonten zu erben.

Darstellung von Verbindungen zwischen Elementen
Abbildung 1. Die setInheritFrom Methode.

Abbildung 1 stellt diese Zugriffssteuerungen dar:

  • 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 diesen Steuerungen gelten die folgenden Zugriffsregeln:

  • Nutzer 1 ist ein indirekt zugelassenes Hauptkonto für Element B, ohne dass er explizit angegeben werden muss. Der Zugriff wird von Element A geerbt.
  • Nutzer 2 ist kein indirekt zugelassenes Hauptkonto für Element A.

Vererbungstyp festlegen

Wenn Sie die Vererbung mit der setInheritFrom Methode festlegen, müssen Sie auch den Vererbungstyp mit der setInheritanceType Methode festlegen. Der Vererbungstyp bestimmt, wie eine untergeordnete ACL mit einer übergeordneten ACL kombiniert wird. Die Acl.InheritanceType implementiert drei Typen:

  • BOTH_PERMIT : Zugriff wird nur gewährt, wenn sowohl die untergeordnete als auch die übergeordnete ACL dies zulassen.
  • CHILD_OVERRIDE : Bei einem Konflikt hat die untergeordnete ACL Vorrang vor der übergeordneten ACL. Ein Nutzer kann auf das untergeordnete Element zugreifen, auch wenn die übergeordnete ACL den Zugriff verweigert, oder der Zugriff auf das untergeordnete Element kann verweigert werden, auch wenn die übergeordnete ACL den Zugriff zulässt.
  • PARENT_OVERRIDE : Bei einem Konflikt hat die übergeordnete ACL Vorrang vor der untergeordneten ACL.

In Cloud Search werden ACL-Vererbungsketten von Blatt zu Stamm bewertet. Die Bewertung beginnt mit dem untergeordneten Element und seinen übergeordneten Elementen und kann bis zum Stammelement fortgesetzt werden.

Wenn das untergeordnete Element beispielsweise CHILD_OVERRIDE verwendet und der Nutzer Zugriff hat, muss Cloud Search das übergeordnete Element nicht bewerten. Wenn das untergeordnete Element jedoch PARENT_OVERRIDE oder BOTH_PERMIT verwendet, setzt Cloud Search die Bewertung in der Kette fort.

Containment und Löschung von Elementen

Beim Indexieren eines Elements können Sie es mit der setContainer Methode der IndexingItemBuilder Klasse als Container kennzeichnen. Diese Beziehung legt die physische Hierarchie fest und sorgt für die ordnungsgemäße Löschung. Wenn Sie einen Container löschen, werden auch die darin enthaltenen Elemente gelöscht.

Containment-Beziehungen sind unabhängig von ACL-Vererbungsregeln. Ein Ordner kann beispielsweise eine Datei zum Löschen enthalten, aber die Datei kann ihre ACL 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.

Abbildung 2 stellt diese Zugriffssteuerungen dar:

  • 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 diesen Steuerungen gelten die folgenden Zugriffsregeln:

  • Der indirekte Zugriff erfolgt über die setInheritFrom Methode. Nutzer 1 kann auf Element C zugreifen, da es von Element A erbt.
  • Der indirekte Zugriff erfolgt nicht über das Containment. Nutzer 2 kann nicht auf Element C zugreifen.
Darstellung von Verbindungen zwischen Elementen
Abbildung 2. Die setInheritFrom Methode in Verwendung.

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

Wenn Sie ein Element löschen:

  • Alle Elemente, die das gelöschte Element enthalten, können nicht mehr gesucht werden und werden zum Löschen geplant.
  • Alle Elemente, die das gelöschte Element in setInheritFrom angeben, können nicht mehr gesucht werden.

Wenn eine Ressource setInheritFrom für ein gelöschtes Element verwendet, aber kein Container festgelegt ist oder die Hierarchie keine gelöschten Elemente enthält, bleibt das Element in der Datenquelle. Sie sind für das Löschen verantwortlich.

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

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

Abbildung 3 stellt diese Zugriffssteuerungen dar:

  • Nutzer 1 ist ein direkt zugelassenes Hauptkonto für Element A.
  • Nutzer 2 ist ein direkt zugelassenes Hauptkonto für Element D.
  • Die Elemente D und E erben beide von Element A.
  • Element A wird von Element D als sein Container bestimmt.
  • Die Elemente A und E sind Elemente auf Stammebene.

Löschungen haben Auswirkungen auf die Container-Verweise. Wenn Sie Element A löschen:

  • Alle Nachkommen des Verweises setInheritFrom verlieren den Zugriff.
  • Nutzer können nicht mehr auf Element A zugreifen.
  • Element D wird implizit gelöscht und ist nicht mehr zugänglich.
  • Element E wird nicht gelöscht, kann aber nicht mehr erreicht werden und kann nicht mehr gesucht werden.