Die Zugriffssteuerung in Google Cloud Search basiert auf dem Google-Konto des Nutzers. Beim Indexieren von Inhalten müssen alle ACLs für Elemente in gültige Google-Nutzer- oder Gruppen-IDs (E-Mail-Adressen) aufgelöst werden.
In vielen Fällen sind in einem Repository keine direkten Kenntnisse über Google-Konten vorhanden. Stattdessen können Nutzer durch lokale Konten dargestellt werden oder zur Identifizierung der einzelnen Konten die föderierte Anmeldung mit einem anderen Identitätsanbieter und einer anderen ID als der E-Mail-Adresse des Nutzers verwenden. Diese ID wird als externe ID bezeichnet.
Identitätsquellen, die in der Admin-Konsole erstellt werden, helfen dabei, die Lücke zwischen Identitätssystemen zu schließen:
- Ein benutzerdefiniertes Nutzerfeld zum Speichern externer IDs festlegen. In diesem Feld werden externe IDs in ein Google-Konto aufgelöst.
- Definieren Sie einen Namespace für Sicherheitsgruppen, der von einem Repository oder Identitätsanbieter verwaltet wird.
Verwenden Sie Identitätsquellen in folgenden Fällen:
- Das Repository enthält nicht die primäre E-Mail-Adresse des Nutzers in Google Workspace oder Google Cloud Directory.
- Das Repository definiert Gruppen für die Zugriffssteuerung, die nicht mit E-Mail-basierten Gruppen in Google Workspace übereinstimmen.
Identitätsquellen verbessern die Indexierungseffizienz, da die Indexierung von der Identitätszuweisung entkoppelt wird. Durch diese Entkopplung können Sie die Suche nach dem Nutzer aufschieben, wenn Sie ACLs erstellen und Elemente indexieren.
Beispiel für ein Deployment
Abbildung 1 zeigt eine Beispielbereitstellung, bei der ein Unternehmen sowohl lokale als auch Cloud-Repositories verwendet. Jedes Repository verwendet eine andere Art von externer ID, um auf Nutzer zu verweisen.
![Beispiel für ein Deployment](https://developers-dot-devsite-v2-prod.appspot.com/static/cloud-search/images/identity-arch.png?authuser=3&hl=de)
Repository 1 identifiziert den Nutzer anhand der E-Mail-Adresse, die mit SAML bestätigt wurde. Da Repository 1 die primäre E-Mail-Adresse des Nutzers in Google Workspace oder Cloud Directory kennt, ist keine Identitätsquelle erforderlich.
Repository 2 ist direkt in ein lokales Verzeichnis eingebunden und identifiziert den Nutzer anhand des Attributs sAMAccountName
. Da Repository 2 ein sAMAccountName
-Attribut als externe ID verwendet, ist eine Identitätsquelle erforderlich.
Identitätsquelle erstellen
Wenn Sie eine Identitätsquelle benötigen, finden Sie weitere Informationen unter Nutzeridentitäten in Cloud Search zuordnen.
Sie müssen eine Identitätsquelle erstellen, bevor Sie einen Inhaltsconnector erstellen, da Sie die ID der Identitätsquelle benötigen, um ACLs zu erstellen und Daten zu indexieren. Wie bereits erwähnt, wird beim Erstellen einer Identitätsquelle auch ein benutzerdefiniertes Nutzerattribut in Cloud Directory erstellt. Verwenden Sie dieses Attribut, um die externe ID für jeden Nutzer in Ihrem Repository aufzuzeichnen. Das Attribut wird nach der Konvention IDENTITY_SOURCE_ID_identity
benannt.
Die folgende Tabelle enthält zwei Identitätsquellen: eine für die SAM-Kontonamen (sAMAccountName) als externe IDs und eine für die Nutzer-IDs (uid) als externe IDs.
Identitätsquelle | Nutzereigenschaft | externe ID |
---|---|---|
id1 | id1_identity | sAMAccountName |
id2 | id2_identity | uid |
Erstellen Sie eine Identitätsquelle für jede mögliche externe ID, mit der auf einen Nutzer in Ihrem Unternehmen verwiesen wird.
Die folgende Tabelle zeigt, wie ein Nutzer mit einem Google-Konto und zwei externen IDs (id1_identity und id2_identity) und ihren Werten in Cloud Directory angezeigt wird:
Nutzer | E‑Mail | id1_identity | id2_identity |
---|---|---|---|
Anne | ann@example.com | beispiel\ann | 1001 |
Mit den drei verschiedenen IDs (Google-E-Mail, sAMAccountName und UID) können Sie auf denselben Nutzer verweisen, wenn Sie ACLs für die Indexierung erstellen.
Nutzer-ACLs schreiben
Verwenden Sie die Methoden getUserPrincpal() oder getGroupPrincipal(), um Hauptkonten mit einer bereitgestellten externen ID zu erstellen.
Das folgende Beispiel zeigt, wie Dateiberechtigungen abgerufen werden. Diese Berechtigungen umfassen den Namen jedes Nutzers, der Zugriff auf die Datei hat.
Das folgende Code-Snippet zeigt, wie mithilfe der in den Attributen gespeicherten externen ID (externalUserName
) Hauptkonten erstellt werden, die Inhaber sind.
Mit dem folgenden Code-Snippet sehen Sie schließlich, wie Hauptkonten erstellt werden, die die Datei lesen.
Sobald Sie eine Liste mit Lesern und Inhabern haben, können Sie die ACL erstellen:
Die zugrunde liegende REST API verwendet beim Erstellen von Hauptkonten das Muster identitysources/IDENTITY_SOURCE_ID/users/EXTERNAL_ID
für die ID. Wenn Sie in den vorherigen Tabellen eine ACL mit Anns id1_identity
(SAMAccountName) erstellen, wird die ID so aufgelöst:
identitysources/id1_identity/users/example/ann
Diese gesamte ID wird als Zwischen-ID des Nutzers bezeichnet, da sie eine Brücke zwischen der externen ID und den in Cloud Directory gespeicherten Google-IDs bildet.
Weitere Informationen zum Modellieren der für ein Repository verwendeten ACLs finden Sie unter ACLs.
Gruppen zuordnen
Identitätsquellen dienen auch als Namespace für Gruppen, die in ACLs verwendet werden. Mit dieser Namespace-Funktion können Sie Gruppen erstellen und zuordnen, die nur zu Sicherheitszwecken verwendet werden oder lokal in einem Repository sind.
Verwenden Sie die Cloud Identity Groups API, um eine Gruppe zu erstellen und die Mitgliedschaften zu verwalten. Wenn Sie die Gruppe mit einer Identitätsquelle verknüpfen möchten, verwenden Sie den Ressourcennamen der Identitätsquelle als Gruppen-Namespace.
Im folgenden Code-Snippet sehen Sie, wie eine Gruppe mithilfe der Cloud Identity Groups API erstellt wird:
Gruppen-ACLs erstellen
Verwenden Sie zum Erstellen einer Gruppen-ACL die Methode getGroupPrincipal(), um ein Gruppenhauptkonto mithilfe einer bereitgestellten externen ID zu erstellen. Erstellen Sie dann die ACL mithilfe der Klasse Acl.Builder:
Identitätsconnectors
Sie können zwar externe, nicht von Google stammende IDs zum Erstellen von ACLs und Indexelementen verwenden. Nutzer können Elemente in einer Suche jedoch erst sehen, wenn ihre externen IDs in eine Google-ID in Cloud Directory aufgelöst werden. Es gibt drei Möglichkeiten, um dafür zu sorgen, dass Cloud Directory sowohl die Google-ID als auch die externen IDs eines Nutzers kennt:
- Jedes einzelne Nutzerprofil über die Admin-Konsole manuell aktualisieren Dieser Vorgang wird nur zum Testen und Prototyping mit wenigen Nutzerprofilen empfohlen.
- Verwenden Sie die Directory API, um externe IDs Google-IDs zuzuordnen. Diese Vorgehensweise wird empfohlen, wenn Sie das Identity Connector SDK nicht verwenden können.
- Mit dem Identity Connector SDK können Sie einen Identitätsconnector erstellen. Dieses SDK vereinfacht die Verwendung der Directory API zum Zuordnen von IDs.
Identitätsconnectors sind Programme, mit denen externe IDs von Unternehmensidentitäten (Nutzern und Gruppen) internen Google-Identitäten zugeordnet werden, die von Google Cloud Search verwendet werden. Wenn Sie eine Identitätsquelle erstellen müssen, müssen Sie einen Identitätsconnector erstellen.
Google Cloud Directory Sync (GCDS) ist ein Beispiel für einen Identitätsconnector. Er ordnet Nutzer- und Gruppeninformationen aus dem Active Directory von Microsoft Cloud Directory zusammen mit den Nutzerattributen zu, die ihre Identität in anderen Systemen darstellen können.
Identitäten mit der REST API synchronisieren
Verwenden Sie die Methode update
, um Identitäten mithilfe der REST API zu synchronisieren.
Identitäten neu zuordnen
Nachdem Sie die Identität eines Elements einer anderen Identität neu zugeordnet haben, müssen Sie die Elemente neu indexieren, damit die neue Identität verwendet werden kann. Beispiel:
- Wenn Sie versuchen, eine Zuordnung eines Nutzers zu entfernen oder einem anderen Nutzer neu zuzuordnen, bleibt die ursprüngliche Zuordnung erhalten, bis Sie neu indexieren.
- Wenn Sie eine zugeordnete Gruppe löschen, die in einer Element-ACL vorhanden ist, und dann eine neue Gruppe mit derselben
groupKey
erstellen, bietet die neue Gruppe erst dann Zugriff auf das Element, wenn das Element neu indexiert wurde.