Die Zugriffssteuerung in Google Cloud Search basiert auf dem Google-Konto des Nutzers. Bei der Indexierung 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 die Google-Konten eines Repositorys nicht direkt bekannt. Stattdessen können Nutzer durch lokale Konten dargestellt werden oder die föderierte Anmeldung mit einem Identitätsanbieter und einer anderen ID als der E-Mail-Adresse des Nutzers verwenden, um jedes Konto zu identifizieren. 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, indem sie:
- Ein benutzerdefiniertes Nutzerfeld zum Speichern externer IDs definieren. Mit dem 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.
In folgenden Fällen sollten Identitätsquellen verwendet werden:
- 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 den E-Mail-basierten Gruppen in Google Workspace entsprechen.
Identitätsquellen verbessern die Indexierungseffizienz, indem sie die Indexierung von der Identitätszuweisung entkoppeln. Durch diese Entkopplung können Sie die Suche nach dem Nutzer zurückstellen, wenn Sie ACLs erstellen oder Elemente indexieren.
Beispiel für ein Deployment
Abbildung 1 zeigt eine beispielhafte Bereitstellung, bei der von einem Unternehmen sowohl lokale als auch Cloud-Repositories verwendet werden. Jedes Repository verwendet eine andere Art externer ID, um auf Nutzer zu verweisen.
In Repository 1 wird der Nutzer anhand der E-Mail-Adresse identifiziert, 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. In diesem Fall wird der Nutzer anhand des Attributs sAMAccountName
identifiziert. 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 im Hilfeartikel Nutzeridentitäten in Cloud Search zuordnen weitere Informationen.
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 eine benutzerdefinierte Nutzereigenschaft in Cloud Directory erstellt. Mit diesem Attribut können Sie die externe ID jedes Nutzers in Ihrem Repository aufzeichnen. Das Attribut wird nach der Konvention IDENTITY_SOURCE_ID_identity
benannt.
Die folgende Tabelle zeigt zwei Identitätsquellen, eine mit SAM-Kontonamen (sAMAccountName) als externe IDs und eine mit 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, die verwendet wird, um auf einen Nutzer in Ihrem Unternehmen zu verweisen.
Die folgende Tabelle zeigt, wie ein Nutzer mit einem Google-Konto und zwei externen IDs (id1_identity und id2_identity) sowie deren Werten in Cloud Directory angezeigt wird:
Nutzer | id1_identity | id2_identity | |
---|---|---|---|
Anne | ann@example.com | beispiel\ann | 1001 |
Beim Erstellen von ACLs für die Indexierung können Sie mit den drei verschiedenen IDs (Google-E-Mail-Adresse, sAMAccountName und UID) auf denselben Nutzer verweisen.
Nutzer-ACLs schreiben
Verwenden Sie die Methode getUserPrincpal() oder getGroupPrincipal(), um Hauptkonten mit einer angegebenen 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.
Schließlich zeigt das folgende Code-Snippet, wie Hauptkonten erstellt werden, die die Datei lesen.
Sobald Sie eine Liste der Leser und Inhaber 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
als ID. Wenn Sie in den vorherigen Tabellen eine ACL mit dem id1_identity
(SAMAccountName) von Ann erstellen, würde die ID so aufgelöst werden:
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 zur Modellierung der für ein Repository verwendeten ACLs finden Sie unter ACLs.
Zuordnungsgruppen
Identitätsquellen dienen auch als Namespace für Gruppen, die in ACLs verwendet werden. Sie können diese Namespace-Funktion verwenden, um Gruppen zu erstellen und zuzuordnen, die nur zu Sicherheitszwecken verwendet werden oder die sich lokal in einem Repository befinden.
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.
Das folgende Code-Snippet zeigt, wie Sie eine Gruppe mit der Cloud Identity Groups API erstellen:
Gruppen-ACL erstellen
Verwenden Sie zum Erstellen einer Gruppen-ACL die Methode getGroupPrincipal(), um ein Gruppenhauptkonto mit einer angegebenen externen ID zu erstellen. Erstellen Sie dann die ACL mithilfe der Klasse Acl.Builder:
Identitäts-Connectors
Sie können zwar externe IDs, die nicht von Google stammen, zum Erstellen von ACLs und Indexelementen verwenden, aber Nutzer können Elemente erst dann in einer Suche sehen, wenn ihre externen IDs in eine Google-ID in Cloud Directory aufgelöst werden. Es gibt drei Möglichkeiten, 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.
- Ordnen Sie mithilfe der Directory API externen IDs Google-IDs externe IDs zu. Dieser Vorgang wird für Nutzer empfohlen, die das Identity Connector SDK nicht verwenden können.
- Verwenden Sie das Identity Connector SDK zum Erstellen eines Identitätsconnectors. Dieses SDK vereinfacht die Verwendung der Directory API zum Zuordnen von IDs.
Identitätsconnectors sind Programme, mit denen externe IDs von Unternehmensidentitäten (Nutzer 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 Active Directory von Microsoft Cloud Directory zu, zusammen mit den Nutzerattributen, die ihre Identität in anderen Systemen darstellen.
Identitäten mit der REST API synchronisieren
Verwenden Sie die Methode update
, um Identitäten mit 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 übernommen wird. Beispiel:
- Wenn Sie versuchen, eine Zuordnung für einen Nutzer zu entfernen oder sie einem anderen Nutzer neu zuzuordnen, bleibt die ursprüngliche Zuordnung erhalten, bis Sie 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, gewährt die neue Gruppe erst dann Zugriff auf das Element, wenn es neu indexiert wird.