Karten-ACLs

Damit nur Nutzer mit Zugriff auf ein Element dieses Element in einem Suchergebnis sehen können, sollten Sie Elemente mit den entsprechenden ACLs (Access Control Lists) aus dem Repository des Unternehmens indexieren. Sie müssen die ACLs Ihres Repositorys modellieren und diese ACLs bei der Indexierung von Elementen im Repository einschließen. Das Content Connector SDK bietet umfangreiche ACL-Methoden, mit denen die ACLs der meisten Repositories modelliert werden können.

ACL erstellen

Das Erstellen einer ACL besteht in zwei Schritten:

  1. Erstelle eine Principal mit statischen Methoden in der ACL-Klasse.
  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 benötigen, z. B. Übernahme und Eindämmung.

Hauptkonto mit einer externen ID erstellen

Bei Google Cloud Search müssen Nutzer und Gruppen in die Google-E-Mail-Adresse aufgelöst werden. Bei der Indexierung von Repository-Elementen haben Inhaltsconnectors möglicherweise nicht diese E-Mail-Adressen. Mit dem Content Connector SDK können Sie jedoch anstelle einer E-Mail-Adresse eine externe ID (ID, die einem Nutzer oder einer Gruppe Zugriff auf Repository-Elemente gewährt) verwenden, um ein Element zu indexieren. 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, mit denen Principal-Objekte erstellt werden.

ACL-Übernahme

Mit ACL-Übernahme wird die Autorisierung für ein bestimmtes Element und einen bestimmten Nutzer basierend auf einer Kombination der ACLs des Elements und der ACLs der Übernahmekette angegeben. Die für eine Autorisierungsentscheidung verwendeten Regeln hängen vom Repository und den Attributen des Elements ab.

Übernahme festlegen

Jedes Element kann direkt zulässige Hauptkonten und direkt abgelehnte Hauptkonten haben, die mit den Methoden setReaders() und setDeniedReaders() angegeben werden. Ein direkt zugelassenes Hauptkonto ist ein Nutzer, der in einer ACL identifiziert wird und ihm direkten Zugriff auf ein bestimmtes Element gewährt. Ein direkt verweigertes Hauptkonto hat einen Nutzer, der in einer ACL identifiziert wurde, aber keinen Zugriff auf ein bestimmtes Element hat.

Ein Element kann auch die indirekt zulässigen Hauptkonten und indirekt gesperrte Hauptkonten mit der Methode setInheritFrom() erben. Ein indirektes zugelassenes Hauptkonto ist ein Nutzer, der durch ACL-Übernahme einen indirekten Zugriff auf ein bestimmtes Element hat. Ein indirekt blockiertes Hauptkonto ist ein Nutzer, der über eine ACL-Übernahme keinen Zugriff auf ein bestimmtes Element hat.

Abbildung 1 zeigt, wie die Methode setInheritFrom() für indirekt zugelassene und indirekt abgelehnte Hauptkonten verwendet wird.

Grafik: Verbindungen zwischen Elementen
Abbildung 1. Die Methode setInheritFrom().

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 übernimmt die ACL von Element A.

Je nach Zugriffssteuerung gelten folgende Zugriffsregeln:

  • Nutzer 1 muss nicht ausdrücklich als Hauptkonto von Element B angegeben werden, um ein indirektes zulässiges Hauptkonto von Element B zu sein. Der Zugriff wird übernommen, weil 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 indirektes Hauptkonto für Element A.

Übernahmetyp festlegen

Wenn Sie die Übernahme mit der Methode setInheritFrom() festlegen, müssen Sie den Übernahmetyp mit der Methode setInheritanceType() festlegen. Der Übernahmetyp bestimmt, wie ein untergeordnetes ACL mit dem ACL des übergeordneten Elements kombiniert wird. Mit Acl.InheritanceType werden drei Übernahmetypen implementiert:

  • BOTH_PERMIT – Übernahmetyp auf BOTH_PERMIT festlegen, um einem Nutzer nur dann Zugriff auf das Element zu gewähren, wenn sowohl das ACL-Objekt als auch das übergeordnete Element des Elements Zugriff erhalten.

  • CHILD_OVERRIDE – Setzen Sie den Übernahmetyp auf CHILD_OVERRIDE, um zu erzwingen, dass das ACL des untergeordneten Elements Vorrang vor dem ACL des übergeordneten Elements hat, wenn es zu Konflikten kommt. Wenn das Übergeordnete Element über den ACL des Nutzers den Zugriff als abgelehnter Leser ablehnt, hat der Nutzer weiterhin Zugriff auf das untergeordnete Element. Umgekehrt hat der Nutzer, auch wenn die ACL des übergeordneten Elements Zugriff gewährt, keinen Zugriff, wenn es sich um einen abgelehnten Leser des untergeordneten Elements handelt.

  • PARENT_OVERRIDE: Setzen Sie den Übernahmetyp auf PARENT_OVERRIDE, um zu erzwingen, dass das ACL des übergeordneten Elements Vorrang erhält, indem es bei einem Konflikt auftritt. Wenn das ACL-Objekt den Nutzer als verweigerten Leser ablehnt, hat er weiterhin Zugriff auf das übergeordnete Element. Umgekehrt hat der Nutzer, auch wenn die ACL des untergeordneten Elements Zugriff gewährt, keinen Zugriff, wenn er ein Lesegerät des übergeordneten Elements ist.

Bei der Bewertung einer ACL-Übernahmekette kann die Reihenfolge der Auswertung das Ergebnis der Autorisierungsentscheidung ändern. Cloud Search bietet eine von Blatt zu Root evaluierte Bewertung für ACL-Übernahmeketten. Insbesondere beginnt die ACL-Entscheidung für eine Kette mit der Auswertung eines untergeordneten Elements mit seinen übergeordneten Elementen. Es kann bis zum übergeordneten Stammverzeichnis fortgeführt werden.

Wenn beispielsweise der untergeordnete Typ CHILD_OVERRIDE für das untergeordnete Element hat und der Nutzer Zugriff darauf hat, muss Drive in diesem Fall nicht ausgewertet werden. Wenn das Kind jedoch PARENT_OVERRIDE oder BOTH_PERMIT hat, wertet Drive die Übernahme weiter in der Kette aus.

Begrenzung und Elementlöschung

Beim Indexieren eines Elements können Sie es mit der Methode setContainer() der Klasse IndexingItemBuilder als Container kennzeichnen. Die Container-/Enthält-Beziehung definiert die physische Hierarchie von Elementen und stellt sicher, dass Elemente korrekt gelöscht werden. Wenn ein Container gelöscht wird, werden die darin enthaltenen Elemente ebenfalls gelöscht.

Einschlussbeziehungen sind vollständig unabhängig von ACL-Übernahmeregeln. Beispielsweise kann eine Datei in einem Dateisystem in einem Ordner enthalten sein, um sie zu löschen, aber die ACL aus einem anderen Ordner übernehmen. Wenn ein Ordner gelöscht wird, werden die Elemente, die seine ACL übernehmen, nicht gelöscht, es sei denn, diese Elemente befinden sich auch in der Einschlusshierarchie des Ordners.

Diese Zugriffssteuerungen sind in Abbildung 2 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 übernimmt die ACL von Element A.
  • Artikel B benennen Artikel A als dessen Container.
  • Artikel C benennen Artikel B als dessen Container.

Je nach Zugriffssteuerung gelten folgende Zugriffsregeln:

  • Der indirekte Zugriff erfolgt über die Methode setInheritFrom(). Nutzer 1 kann also auf Element C zugreifen, weil Element C die ACL von Element A übernimmt.
  • Der indirekte Zugriff stammt nicht von Element C, der in Element B enthalten ist. Nutzer 2 kann daher nicht auf Element C zugreifen.
Grafik: Verbindungen zwischen Elementen
Abbildung 2: Die verwendete setInheritFrom()-Methode.

Durch die Trennung der ACL-Übernahme von der Einschlusshierarchie können Sie viele verschiedene vorhandene Strukturen modellieren.

Wenn ein Element erfolgreich gelöscht wurde:

  • Elemente, die ein gelöschtes Element enthielten, können nicht suchbar werden und zum Löschen vorgemerkt werden.
  • Elemente, die mit der Methode setInheritFrom() das gelöschte Element angegeben haben, können nicht mehr durchsucht werden.

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

Abbildung 3 zeigt ein Beispiel für die Löschung einer Elementhierarchie.

Grafik: Verbindungen zwischen Elementen
Abbildung 3. Element und ACL-Übernahme löschen.

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 übernehmen beide die ACL von Element A.
  • Element D gibt Element A als Container an.
  • Elemente A und E sind Elemente auf Stammebene, da sie kein Containerelement haben.

Löscht den Wasserfall durch die Containerreferenzen. Wenn Element A gelöscht wird, gilt Folgendes:

  • Alle Nachfolger der Referenz in setInheritFrom() verlieren den Zugriff für alle Nutzer.
  • Kein Nutzer kann auf Element A zugreifen.
  • Element D wird implizit gelöscht. Nutzer können nicht auf Element D zugreifen.
  • Element E wird nicht gelöscht, da es nur durch Containerreferenzen zu Problemen kommt.
  • Artikel E ist nicht mehr erreichbar und Nutzer können nicht nach Artikel E suchen.