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 Nutzer- oder Gruppen-IDs (E-Mail-Adressen) von Google 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 die föderierte Anmeldung mit einem Identitätsanbieter und einer ID (außer der E-Mail-Adresse des Nutzers) verwenden, um jedes Konto zu identifizieren. Diese ID wird als externe ID bezeichnet.
Identitätsquellen, die über die Admin-Konsole erstellt wurden, helfen dabei, die Lücke zwischen Identitätssystemen zu schließen, und zwar so:
- Definieren eines benutzerdefinierten Nutzerfelds zum Speichern externer IDs. Das Feld wird verwendet, um externe IDs in ein Google-Konto aufzulösen.
- Definieren Sie einen Namespace für Sicherheitsgruppen, die von einem Repository oder Identitätsanbieter verwaltet werden.
Verwenden Sie Identitätsquellen in folgenden Fällen:
- Das Repository kennt die primäre E-Mail-Adresse des Nutzers in Google Workspace oder Google Cloud Directory nicht.
- Das Repository definiert Gruppen für die Zugriffssteuerung, die nicht E-Mail-basierten Gruppen in Google Workspace entsprechen.
Identitätsquellen verbessern die Indexierungseffizienz, indem die Indexierung von der Identitätszuweisung entkoppelt wird. Durch diese Entkopplung können Sie das Suchen des Nutzers bei der Erstellung von ACLs und der Indexierung von Elementen aufschieben.
Beispiel für ein Deployment
Abbildung 1 zeigt eine Beispielbereitstellung, bei der sowohl ein lokales als auch ein Cloud-Repository von einem Unternehmen verwendet wird. Jedes Repository verwendet einen anderen externen ID-Typ, um auf Nutzer zu verweisen.

Repository 1 identifiziert den Nutzer anhand der mit SAML bestätigten E-Mail-Adresse. Da in Repository 1 die primäre E-Mail-Adresse des Nutzers in Google Workspace oder Cloud Directory bekannt ist, ist keine Identitätsquelle erforderlich.
Repository 2 ist direkt in ein lokales Verzeichnis eingebunden und identifiziert den Nutzer anhand seines sAMAccountName
-Attributs. 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, lesen Sie den Hilfeartikel 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 und Indexdaten zu erstellen. 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. Der Name der Property wird entsprechend der Konvention
IDENTITY_SOURCE_ID_identityvergeben.
In der folgenden Tabelle sind zwei Identitätsquellen aufgeführt: eine für SAM-Kontonamen (sAMAccountName) und eine für Nutzer-IDs (uid).
Identitätsquelle | Nutzereigenschaft | externe ID |
---|---|---|
ID1 | ID1_Identität | sAMAccountName |
ID2 | ID2_Identität | 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.
In der folgenden Tabelle sehen Sie, wie ein Nutzer mit einem Google-Konto und zwei externen IDs (id1_identity und id2_identity) sowie deren Werte in Cloud Directory angezeigt wird:
Nutzer | ID1_Identität | ID2_Identität | |
---|---|---|---|
Anne | ann@example.com | Beispiel\ann | 1001 |
Sie können beim Erstellen von ACLs für die Indexierung auf die drei unterschiedlichen 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 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.
Im folgenden Code-Snippet sehen Sie, wie mithilfe der externen ID (externalUserName
), die in den Attributen gespeichert ist, Hauptkonten erstellt werden.
Das folgende Code-Snippet zeigt schließlich, wie Hauptkonten erstellt werden, die Leser der Datei sind.
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_IDfür die ID. Wenn Sie die vorherigen Tabellen noch einmal aufrufen: Wenn Sie eine ACL mit Ann
id1_identity
(SAMAccountName) erstellen, wird die ID wie folgt aufgelöst:
identitysources/id1_identity/users/example/ann
Die 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 ACLs für ein Repository 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 oder lokal in einem Repository verwendet werden.
Mit der Cloud Identity Groups API können Sie eine Gruppe erstellen und die Mitgliedschaften 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 Sie eine Gruppe mithilfe der Cloud Identity Groups API erstellen:
Gruppen-ACL 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 mit der Klasse Acl.Builder so:
Identitätsconnectors
Sie können zwar ACLs und Indexelemente mit externen, nicht von Google stammenden IDs erstellen, aber Nutzer können Elemente in einer Suche erst sehen, wenn ihre externen IDs in eine Google-ID in Cloud Directory aufgelöst werden. Es gibt drei Möglichkeiten, um sicherzustellen, dass Cloud Directory sowohl die Google-ID als auch die externen IDs für einen Nutzer kennt:
- Sie können die einzelnen Nutzerprofile manuell über die Admin-Konsole aktualisieren. Dieser Vorgang wird nur zum Testen und Prototyping mit wenigen Nutzerprofilen empfohlen.
- Externe IDs mithilfe der Directory API Google-IDs zuordnen Dieser Vorgang wird für Nutzer empfohlen, die das Identity Connector SDK nicht verwenden können.
- Erstellen Sie einen Identitätsconnector mit dem Identity Connector SDK. 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. Dieser Identitätsconnector ordnet Nutzer- und Gruppeninformationen aus Active Directory von Microsoft Cloud Directory zusammen mit den Nutzerattributen zu, die ihre Identität in anderen Systemen darstellen.
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 übernommen wird. Beispiel:
- Wenn Sie versuchen, eine Zuordnung von einem 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, hat die neue Gruppe keinen Zugriff auf das Element, bis das Element neu indexiert wird.