Karten-ACLs

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.

Hinweis: Das Content Connector SDK unterstützt ACLs für einzelne Domains, aber nicht domainübergreifenden ACLs verwendet. Sie können keinen Nutzern und Gruppen Zugriff gewähren, außerhalb Ihrer Organisation. Alle ACLs, die sich auf Nutzer oder Gruppen außerhalb Ihres Organisation keine Auswirkungen.

ACL erstellen

Die Erstellung einer ACL erfolgt in zwei Schritten:

1. Erstellen: Principal mit statischen Methoden in der ACL .
2. 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.

Hinweis: Nutzer können Artikel in Suchergebnissen erst nach ihrer externen ID sehen. mit ihrem Google-Konto synchronisiert ist. Synchronisierung dieser externen Nutzer oder Gruppen IDs für eine Google-E-Mail-Adresse können mithilfe einer Identität durchgeführt werden Connector. Weitere Informationen zu Identitätsconnectors finden Sie unter Erstellen Sie einen Identitätsconnector.

Warnung: Nachdem Sie die Identität eines Elements einer anderen Identität neu zugeordnet haben, müssen Sie Elemente neu zu indexieren, damit die neue Identität in Kraft tritt. Weitere Informationen finden Sie unter oder Identitäten neu zuordnen.

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.

Hinweis: Wenn Sie die Übernahme mithilfe der Eigenschaft setInheritFrom() müssen Sie den Vererbungstyp mithilfe der Methode setInheritanceType() . Informationen zu Vererbungstypen finden Sie unter Legen Sie den Übernahmetyp fest.

Abbildung 1 zeigt, wie die Die Methode setInheritFrom() wird verwendet, um indirekt zugelassene und indirekt abgelehnte Hauptkonten zu übernehmen.

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 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 auf BOTH_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 auf CHILD_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 auf PARENT_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.

Abbildung 2. Die verwendete Methode setInheritFrom().

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 jedoch 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.

Abbildung 3. Löschen eines Elements und einer ACL-Vererbung.

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 Nachkommen 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.