Verschiedene Identitätssysteme synchronisieren

Die Zugriffssteuerung in Google Cloud Search basiert auf dem Google-Konto eines 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 in einem Repository keine Informationen zu Google-Konten vorhanden. Stattdessen werden Nutzer durch lokale Konten dargestellt oder sie verwenden die föderierte Anmeldung mit einem Identitätsanbieter. Diese Kennzeichnung, die nicht die E-Mail-Adresse ist, 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 Fällen sollten Sie Identitätsquellen verwenden:

  • Das Repository kennt die primäre E-Mail-Adresse des Nutzers in Google Workspace oder Google Cloud Directory nicht.
  • 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 optimiert werden, indem die Indexierung von der Identitätszuordnung entkoppelt wird. So können Sie die Nutzersuche auf einen späteren Zeitpunkt verschieben, wenn ACLs erstellt und Elemente indexiert werden.

Beispiel für ein Deployment

In Abbildung 1 sehen Sie ein Unternehmen, das sowohl lokale als auch Cloud-Repositories verwendet. Für jedes wird eine andere Art externe ID verwendet.

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

In Repository 1 werden Nutzer anhand ihrer E-Mail-Adresse mit SAML identifiziert. Da die primäre E-Mail-Adresse in Google Workspace oder Cloud Directory bekannt ist, ist keine Identitätsquelle erforderlich.

Repository 2 ist in ein lokales Verzeichnis integriert und identifiziert Nutzer anhand von sAMAccountName. Da dieses Attribut als externe ID 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.

Erstellen Sie die Identitätsquelle, bevor Sie einen Inhaltsconnector erstellen. Sie benötigen die ID der Identitätsquelle, um ACLs zu erstellen und Daten zu indexieren. Beim Erstellen einer Identitätsquelle wird auch eine benutzerdefinierte Nutzereigenschaft in Cloud Directory erstellt, in der externe IDs gespeichert werden. Für den Attributnamen gilt die Konvention IDENTITY_SOURCE_ID_identity.

In dieser Tabelle sehen Sie zwei Identitätsquellen: eine für SAM-Kontonamen und eine für Nutzer-IDs (UID).

Identitätsquelle Nutzereigenschaft Externe ID
id1 id1_identity sAMAccountName
id2 id2_identity uid

Erstellen Sie eine Identitätsquelle für jede Art von externer ID, die in Ihrem Unternehmen verwendet wird.

In dieser Tabelle sehen Sie, wie ein Nutzer mit einem Google-Konto und zwei externen IDs in Cloud Directory angezeigt wird:

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

Wenn Sie für die Indexierung ACLs erstellen, können Sie über alle diese IDs auf denselben Nutzer verweisen.

Nutzer-ACLs schreiben

Verwenden Sie getUserPrincipal() oder getGroupPrincipal() , um Hauptkonten mit externen IDs zu erstellen.

In diesem Beispiel werden Dateiberechtigungen abgerufen, einschließlich der Nutzer mit Zugriff:

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();
  // ...
}

Mit diesem Snippet werden Hauptkonten für Eigentümer mit dem Attribut externalUserName erstellt:

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)
);

Mit diesem Snippet werden Hauptkonten für Nutzer mit Leseberechtigung erstellt:

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 Nutzer mit Leseberechtigung und Eigentümer haben, erstellen Sie die ACL:

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 REST API wird für die ID das Muster identitysources/IDENTITY_SOURCE_ID/users/EXTERNAL_ID verwendet. Die id1_identity von Anne wird in identitysources/id1_identity/users/example/ann aufgelöst. Dies ist die Zwischen-ID des Nutzers.

Weitere Informationen zum Modellieren von Repository-ACLs finden Sie unter ACLs.

Gruppen zuordnen

Identitätsquellen dienen auch als Namespace für ACL-Gruppen. So 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 Gruppen zu erstellen und Mitgliedschaften zu verwalten. Verknüpfen Sie die Gruppe mit einer Identitätsquelle, indem Sie den Namen der Identitätsquelle als Namespace verwenden.

Mit diesem Snippet wird eine Gruppe erstellt:

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

Verwenden Sie getGroupPrincipal() , um ein Gruppenhauptkonto mit einer externen ID zu erstellen, und richten Sie dann die ACL ein:

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

Identitätsconnectors

Nutzer können erst Elemente in Suchergebnissen sehen, wenn ihre externen IDs in eine Google-ID in Cloud Directory aufgelöst werden. Dazu haben Sie drei Möglichkeiten:

Identitätsconnectors ordnen externe IDs von Unternehmensidentitäten internen Google-Identitäten zu. Wenn Sie eine Identitätsquelle erstellen, müssen Sie auch einen Identitätsconnector erstellen.

Google Cloud Directory Sync (GCDS) ist ein Beispiel für einen Identitätsconnector. Damit werden Nutzer- und Gruppeninformationen aus Active Directory in Cloud Directory zugeordnet.

Identitäten mit der REST API synchronisieren

Verwenden Sie die update Methode um Identitäten zu synchronisieren.

Identitäten neu zuordnen

Nachdem Sie eine Identität neu zugeordnet haben, müssen Sie Elemente neu indexieren, damit die Änderung wirksam wird.

  • Wenn Sie eine Nutzerzuordnung entfernen oder ändern, bleibt die ursprüngliche Zuordnung bis zur Neuindexierung bestehen.
  • Wenn Sie eine zugeordnete Gruppe löschen und eine neue mit demselben groupKey erstellen, wird erst nach der Neuindexierung Zugriff gewährt.