Verschiedene Identitätssysteme synchronisieren

Die Zugriffskontrolle in Google Cloud Search basiert auf dem Google-Konto eines Nutzers. Bei der Indexierung von Inhalten müssen alle Zugriffssteuerungslisten (Access Control Lists, 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 Informationen zu Google-Konten vorhanden. Stattdessen sind Nutzer entweder durch lokale Konten dargestellt. Oder für die Identifizierung eines Kontos wird bei der Anmeldung eine föderierte Identität verwendet. Diese hat einen anderen Identitätsanbieter und eine andere ID als die E-Mail-Adresse eines Nutzers. Diese ID wird als externe ID bezeichnet.

Identitätsquellen, die über die Admin-Konsole erstellt werden, helfen dabei, die Lücken zwischen Identitätssystemen zu schließen, weil sie Folgendes erlauben:

In folgenden beiden Fällen sollten Sie Identitätsquellen verwenden:

  • Das Repository enthält nicht die primäre E-Mail-Adresse des Nutzers für Google Workspace oder Google Cloud Directory.
  • Im Repository sind Gruppen für die Zugriffssteuerung festgelegt, die nicht den auf E-Mail-Adressen basierenden Gruppen in Google Workspace entsprechen.

Mit Identitätsquellen kann die Effizienz der Indexierung optimiert werden, indem die Indexierung von der Identitätszuordnung entkoppelt wird. Dies ermöglicht es Ihnen, einen Nutzer erst später zu suchen, wenn ACLs erstellt oder Elemente indexiert werden.

Beispiel für ein Deployment

Abbildung 1 zeigt ein Beispiel für eine Bereitstellung, bei der von einem Unternehmen sowohl lokale als auch Cloud-Repositories verwendet werden. Für jedes Repository wird dabei eine andere Art externe ID verwendet, um auf Nutzer zu verweisen.

Beispiel für ein Deployment
Abbildung 1. Beispiel eines Deployments für ein Unternehmen mit verschiedenen Identitätstypen.

In Repository 1 wird der Nutzer anhand der mit SAML bestätigten E-Mail-Adresse identifiziert. Da für Repository 1 die primäre E-Mail-Adresse des Nutzers für Google Workspace oder Cloud Directory bekannt ist, wird keine Identitätsquelle benötigt.

Repository 2 ist direkt in einem lokalen Verzeichnis integriert. In ihm wird der Nutzer über das Attribut sAMAccountName identifiziert. Da als externe ID das Attribut sAMAccountName verwendet wird, 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.

Eine Identitätsquelle muss vor einem Inhaltsconnector erstellt werden, 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. Damit kann die externe ID jedes Nutzers in Ihrem Repository gespeichert werden. Für das Attribut gilt folgende Benennungskonvention: IDENTITY_SOURCE_ID_identity.

In der folgenden Tabelle sehen Sie zwei Identitätsquellen, eine mit SAM-Kontonamen (sAMAccountName) 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.

In der folgenden Tabelle sehen Sie, wie ein Nutzer mit einem Google-Konto, dessen zwei externe IDs (id1_identity und id2_identity) und dazugehörigen Werte in Cloud Directory angezeigt werden:

Nutzer E-Mail id1_identity id2_identity
Anne ann@example.com Beispiel\Ann 1001

Wenn Sie für die Indexierung ACLs erstellen, können Sie über alle drei IDs (Google-E-Mail, SAMAccountName und UID) auf denselben Nutzer verweisen.

Nutzer-ACLs schreiben

Mithilfe der Methoden getUserPrincpal() und getGroupPrincipal() können Sie Hauptkonten (Principals) mit einer bereitgestellten externen ID erstellen.

Im folgenden Beispiel sehen Sie, wie Dateiberechtigungen abgerufen werden. Sie enthalten den Namen jedes Nutzers, der Zugriff auf die Datei hat.

FilePermissionSample.java
/**
 * Sample for mapping permissions from a source repository to Cloud Search
 * ACLs. In this example, POSIX file permissions are used a the source
 * permissions.
 *
 * @return Acl
 * @throws IOException if unable to read file permissions
 */
static Acl mapPosixFilePermissionToCloudSearchAcl(Path pathToFile) throws IOException {
  // Id of the identity source for external user/group IDs. Shown here,
  // but may be omitted in the SDK as it is automatically applied
  // based on the `api.identitySourceId` configuration parameter.
  String identitySourceId = "abcdef12345";

  // Retrieve the file system permissions for the item being indexed.
  PosixFileAttributeView attributeView = Files.getFileAttributeView(
      pathToFile,
      PosixFileAttributeView.class,
      LinkOption.NOFOLLOW_LINKS);

  if (attributeView == null) {
    // Can't read, return empty ACl
    return new Acl.Builder().build();
  }

  PosixFileAttributes attrs = attributeView.readAttributes();
  // ...
}

Im folgenden Code-Snippet sehen Sie, wie mithilfe der externen ID (externalUserName), die in den Attributen gespeichert ist, Hauptkonten erstellt werden, die Inhaber sind.

FilePermissionSample.java
// Owner, for search quality.
// Note that for principals the name is not the primary
// email address in Cloud Directory, but the local ID defined
// by the OS. Users and groups must be referred to by their
// external ID and mapped via an identity source.
List<Principal> owners = Collections.singletonList(
    Acl.getUserPrincipal(attrs.owner().getName(), identitySourceId)
);

Im folgenden Code-Snippet sehen Sie, wie Hauptkonten mit Leseberechtigung für Dateien erstellt werden.

FilePermissionSample.java
// List of users to grant access to
List<Principal> readers = new ArrayList<>();

// Add owner, group, others to readers list if permissions
// exist. For this example, other is mapped to everyone
// in the organization.
Set<PosixFilePermission> permissions = attrs.permissions();
if (permissions.contains(PosixFilePermission.OWNER_READ)) {
  readers.add(Acl.getUserPrincipal(attrs.owner().getName(), identitySourceId));
}
if (permissions.contains(PosixFilePermission.GROUP_READ)) {
  String externalGroupName = attrs.group().getName();
  Principal group = Acl.getGroupPrincipal(externalGroupName, identitySourceId);
  readers.add(group);
}
if (permissions.contains(PosixFilePermission.OTHERS_READ)) {
  Principal everyone = Acl.getCustomerPrincipal();
  readers.add(everyone);
}

Sobald Sie eine Liste mit Nutzern mit Leseberechtigung und Besitzern haben, können Sie die ACL erstellen:

FilePermissionSample.java
// Build the Cloud Search ACL. Note that inheritance of permissions
// from parents is omitted. See `setInheritFrom()` and `setInheritanceType()`
// methods on the builder if required by your implementation.
Acl acl = new Acl.Builder()
    .setReaders(readers)
    .setOwners(owners)
    .build();

In der zugrunde liegenden REST API wird für die ID das Musteridentitysources/IDENTITY_SOURCE_ID/users/EXTERNAL_ID verwendet, um Hauptkonten zu erstellen. Wie Sie in den vorherigen Tabellen gesehen haben, wird die ID folgendermaßen aufgelöst, wenn Sie mit dem SAMAccountName von Ann (id1_identity) eine ACL erstellen:

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 zu ACLs.

Gruppen zuordnen

Identitätsquellen dienen auch als Namespace für in ACLs verwendete Gruppen. Mit dieser Namespace-Funktion können Sie Gruppen erstellen und zuordnen, die nur zu Sicherheitszwecken verwendet werden oder nur in einem Repository vorhanden sind.

Verwenden Sie die Cloud Identity Groups API, um eine Gruppe zu erstellen und die Mitgliedschaften zu verwalten. Wenn Sie eine Gruppe mit einer Identitätsquelle verknüpfen möchten, verwenden Sie den Ressourcennamen der Identitätsquelle als Namespace für die Gruppe.

Im folgenden Code-Snippet sehen Sie, wie eine Gruppe mithilfe der Cloud Identity Groups API erstellt wird:

CreateGroupCommand.java
String namespace = "identitysources/" + idSource;
Group group = new Group()
    .setGroupKey(new EntityKey().setNamespace(namespace).setId(groupId))
    .setDescription("Demo group")
    .setDisplayName(groupName)
    .setLabels(Collections.singletonMap("system/groups/external", ""))
    .setParent(namespace);
try {
  CloudIdentity service = Utils.buildCloudIdentityService();
  Operation createOperation = service.groups().create(group).execute();

  if (createOperation.getDone()) {
    // Note: The response contains the data for a Group object, but as
    // individual fields. To convert to a Group instance, either populate
    // the fields individually or serialize & deserialize to/from JSON.
    //
    // Example:
    // String json = service.getJsonFactory().toString(response);
    // Group createdGroup =  service.getObjectParser()
    //     .parseAndClose(new StringReader(json), Group.class);
    System.out.printf("Group: %s\n",
        createOperation.getResponse().toString());
  } else {
    // Handle case where operation not yet complete, poll for
    // completion. API is currently synchronous and all operations return
    // as completed.
    // ...
  }
} catch (Exception e) {
  System.err.printf("Unable to create group: %s", e.getMessage());
  e.printStackTrace(System.err);
}

Gruppen-ACLs erstellen

Wenn Sie eine Gruppen-ACL erstellen möchten, verwenden Sie die Methode getGroupPrincipal(), um mithilfe der bereitgestellten externen ID ein Gruppenhauptkonto zu erstellen. Anschließend erstellen Sie die ACL mit der Klasse Acl.Builder:

FilePermissionSample.java
if (permissions.contains(PosixFilePermission.GROUP_READ)) {
  String externalGroupName = attrs.group().getName();
  Principal group = Acl.getGroupPrincipal(externalGroupName, identitySourceId);
  readers.add(group);
}

Identitätsconnectors

Sie können zwar externe, d. h. nicht von Google stammende IDs verwenden, um ACLs und Indexelemente zu erstellen; Nutzer können jedoch keine Elemente in einer Suche sehen, bis ihre externen IDs in eine Google-ID in Cloud Directory aufgelöst werden. Es gibt drei Möglichkeiten, dafür zu sorgen, dass sowohl die Google-ID als auch die externen IDs in Cloud Directory bekannt sind:

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. Für eine Identitätsquelle wird auch ein Identitätsconnector benötigt.

Google Cloud Directory Sync (GCDS) ist ein Beispiel für einen Identitätsconnector. Mit diesem Identitäts-Connector werden Nutzer- und Gruppeninformationen aus dem Active Directory von Microsoft Cloud Directory zusammen mit den Nutzerattributen zugeordnet, 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 Artikels einer anderen Identität neu zugeordnet haben, müssen Sie die Artikel neu indexieren, damit die neue Identität übernommen wird. Beispiel:

  • Wenn Sie versuchen, eine Zuordnung von einem Nutzer zu entfernen oder einem anderen Nutzer neu zuzuordnen, bleibt die ursprüngliche Zuordnung erhalten, bis Sie die Indexierung neu erstellen.
  • Wenn Sie eine zugeordnete Gruppe löschen, die in einer Artikel-ACL vorhanden ist, und dann eine neue Gruppe mit derselben groupKey erstellen, kann die neue Gruppe erst dann auf das Element zugreifen, wenn es neu indexiert wurde.