Damit nur Nutzer mit Zugriff auf ein Element dieses Element innerhalb eines in Suchergebnissen, sollten Sie die Elemente mit ihren Access Control Lists (ACLs) indexieren. aus dem Unternehmens-Repository. Sie müssen die ACLs Ihres Repositorys diese ACLs bei der Indexierung von Elementen im Repository miteinbeziehen. Content-Connector SDK bietet eine große Auswahl an ACL-Methoden, die leistungsfähig genug sind, um die ACLs von für die meisten Repositories.
ACL erstellen
Die Erstellung einer ACL erfolgt in zwei Schritten:
- Erstellen:
Principal
mit statischen Methoden in der ACL . - Verwenden Sie den
Acl.Builder
. , um die ACL mithilfe des Hauptkontos zu erstellen.
Im weiteren Verlauf dieses Dokuments werden einige Konzepte behandelt, die Sie zum Modellieren kennen sollten. und ACLs wie Vererbung und Eindämmung zu erstellen.
Hauptkonto mit externer ID erstellen
Für Google Cloud Search müssen Nutzer und Gruppen in eine Google-E-Mail-Adresse aufgelöst werden
Adresse. Bei der Indexierung von Repository-Elementen enthalten Inhalts-Connectors diese möglicherweise nicht.
E-Mail-Adressen. Mit dem Content Connector SDK können Sie jedoch
external ID (ID, die einem Nutzer oder einer Gruppe Zugriff auf Repository-Elemente gewährt)
einer E-Mail-Adresse, um ein Element zu indexieren. Verwenden Sie die Methode
getUserPrincipal()
oder die Methode
getGroupPrincpal()
Methode zum Erstellen von Hauptkonten mit externen IDs. Es gibt noch einige andere
statische Methoden in der
ACL
Klasse, die zum Erstellen
Principal
-Objekte.
ACL-Übernahme
Die ACL-Vererbung bezieht sich auf die Autorisierung für ein bestimmtes Element und basierend auf einer Kombination aus den ACLs des Artikels und dem ACLs seiner Vererbungskette Die Regeln, die für eine Autorisierungsentscheidung verwendet werden hängen vom Repository und den Eigenschaften des Elements ab.
Übernahme festlegen
Jedes Element kann direkt zugelassene Hauptkonten und direkt abgelehnte Hauptkonten haben.
mit dem Parameter
setReaders()
und
setDeniedReaders()
-Methoden. Eine direkte zugelassene
Principal ist ein in einer ACL identifizierter Nutzer, der ihm direkten Zugriff auf eine
für ein bestimmtes Element. Ein direkt abgelehntes Hauptkonto ist ein Nutzer, der in einer ACL als nicht
auf ein bestimmtes Element zugreifen können.
Ein Element kann auch indirekt zulässige Hauptkonten und
indirekt abgelehnte Hauptkonten mithilfe der Methode
setInheritFrom()
. 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.
Abbildung 1 zeigt, wie die
Die Methode setInheritFrom()
wird verwendet, 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 für Element B angegeben werden, um ein indirekt zulässiges Hauptkonto von Element B; Der Zugriff wird übernommen da Nutzer 1 als direkt zugelassenes Hauptkonto für Element A und Element B aufgeführt ist erbt die ACL von Element A.
- Nutzer 2 ist kein indirekt zugelassenes Hauptkonto für Element A.
Übernahmetyp festlegen
Wenn Sie die Vererbung mithilfe der Eigenschaft
setInheritFrom()
müssen Sie den Vererbungstyp mithilfe der Methode
setInheritanceType()
. Der Vererbungstyp bestimmt, wie die
Die ACL wird mit der ACL ihres übergeordneten Elements kombiniert. Die Acl.InheritanceType
implementiert drei Vererbungstypen:
BOTH_PERMIT
: Legen Sie den Übernahmetyp aufBOTH_PERMIT
fest, um einem Nutzer Zugriff zu gewähren. auf das Element nur dann, wenn sowohl die ACL des untergeordneten Elements als auch die geerbte ACL des übergeordneten Elements um diesem Nutzer den Zugriff auf dieses Element zu gestatten.CHILD_OVERRIDE
: Legen Sie den Vererbungstyp aufCHILD_OVERRIDE
fest, um das untergeordnete Element zu erzwingen. hat die ACL des Elements Vorrang vor der ACL des geerbten übergeordneten Elements, wenn sie Konflikt. Wenn die ACL des übergeordneten Elements dem Nutzer als verweigerten Leser erhalten, hat der Nutzer weiterhin Zugriff, sofern er Zugriff auf das Kind hat. als Leser. Umgekehrt gilt: Selbst wenn die ACL des übergeordneten Elements Zugriff auf Der Nutzer hat keinen Zugriff, wenn ihm das Kind nicht zur Verfügung steht.PARENT_OVERRIDE
: Legen Sie den Übernahmetyp aufPARENT_OVERRIDE
fest, um die hat die ACL des übergeordneten Elements Vorrang vor der ACL des untergeordneten Elements, wenn Konflikt. Wenn also die ACL des untergeordneten Elements den Zugriff des Nutzers als abgelehnt -Leser, hat der Nutzer weiterhin Zugriff, wenn er als Zugriff auf das übergeordnete Element Leser. Umgekehrt gilt: Selbst wenn dem Nutzer durch die ACL des untergeordneten Elements Zugriff gewährt wird, Nutzer hat keinen Zugriff, wenn ihm der Zugriff auf das übergeordnete Element verweigert wird.
Bei der Bewertung einer ACL-Vererbungskette kann sich die Reihenfolge der Auswertung ändern. das Ergebnis der Autorisierungsentscheidung. Cloud Search bietet Blatt-zu-Stamm-Unterstützung Bewertungsreihenfolge für ACL-Vererbungsketten. Die ACL-Entscheidung für eine Kette beginnt mit der Auswertung eines untergeordneten Elements mit seinen übergeordneten Elementen bis zum übergeordneten Element.
Beispiel: Das untergeordnete Element hat den Übernahmetyp CHILD_OVERRIDE
und der Nutzer
Zugriff auf das untergeordnete Element hat, muss das übergeordnete Element in Drive nicht überprüft werden.
Hat das Kind jedoch PARENT_OVERRIDE oder BOTH_PERMIT, fährt Drive fort.
zur weiteren Auswertung der Vererbung.
Begrenzung und Löschen von Elementen
Beim Indexieren eines Elements können Sie es mithilfe der Methode
setContainer()
-Methode des
IndexingItemBuilder
. Durch die Beziehung „Container/containee“ wird die physische
und stellt sicher, dass die 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 in einem Ordner für den zum Löschen aus, sondern übernehmen die ACL aus einem anderen Ordner. Löschen eines werden beim Ordner keine Elemente gelöscht, die ihre ACL erben, es sei denn, diese Elemente sind 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
setInheritFrom()
. Nutzer 1 kann also auf Element C zugreifen, da Element C die ACL von Element A. - 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 bestehenden Strukturen nutzen können.
Wenn ein Element erfolgreich gelöscht wurde:
- Alle Elemente, die ein gelöschtes Element enthielten, können nicht mehr gesucht werden und werden für die Löschung aus der Google-Datenquelle geplant ist.
- Jedes Element, bei dem das gelöschte Element mithilfe des
Methode
setInheritFrom()
nicht mehr durchsuchbar ist.
Wenn eine Ressource ein gelöschtes Element enthält, verwenden Sie den
setInheritFrom()
Sie enthält aber kein Container-Set,
setContainer()
oder seine Begrenzungshierarchie keine gelöschten Elemente enthält, dieses Element und seine Daten
bleibt 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.
Löschungen werden über die Containerverweise weitergegeben. Wenn Element A gelöscht wird:
- Alle Nachfolgerelemente von
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 den Container erfolgt Referenzen.
- Element E ist nicht mehr erreichbar und kein Nutzer kann mehr nach Element E suchen.