Verschiedene Identitätssysteme synchronisieren

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

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 kennt ein Repository keine direkten Kenntnisse über Google-Konten. Stattdessen können Nutzer durch lokale Konten dargestellt werden oder die föderierte Anmeldung mit einem Identitätsanbieter und einer ID (mit Ausnahme der E-Mail-Adresse des Nutzers) verwenden, um jedes Konto zu identifizieren. Diese ID wird als externe ID bezeichnet.

Die in der Admin-Konsole erstellten Identitätsquellen helfen dabei, die Lücke zwischen Identitätssystemen zu schließen. Dafür gibt es folgende Möglichkeiten:

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 die Suche des Nutzers auf später verschieben, wenn ACLs erstellt und Elemente indexiert werden.

Beispiel für ein Deployment

Abbildung 1 zeigt eine Beispielbereitstellung, bei der ein Unternehmen sowohl lokale als auch Cloud-Repositories verwendet. Jedes Repository verwendet einen anderen externen ID-Typ, um auf Nutzer zu verweisen.

Beispiel für ein Deployment
Abbildung 1. Beispiel für eine Unternehmensbereitstellung mit verschiedenen Identitätstypen

Repository 1 identifiziert den Nutzer anhand der mit SAML bestätigten E-Mail-Adresse. 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 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, 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 und Indexdaten zu erstellen. Wie bereits erwähnt, wird beim Erstellen einer Identitätsquelle auch ein benutzerdefiniertes Nutzerattribut in Cloud Directory erstellt. Mit diesem Attribut können Sie die externe ID für jeden Nutzer in Ihrem Repository aufzeichnen. Der Name der Property wird gemäß der Konvention 

IDENTITY_SOURCE_ID_identity
vergeben.

In der folgenden Tabelle sind zwei Identitätsquellen aufgeführt: eine mit SAM-Kontonamen (sAMAccountName) und eine externe User-ID (uid).

Identitätsquelle Nutzereigenschaft Externe ID
ID1 id1_identity 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 werden:

Nutzer E‑Mail id1_identity ID2_Identität
Anne ann@example.com beispiel\ann 1001

Sie können beim Erstellen von ACLs für die Indexierung auf denselben Nutzer verweisen. Verwenden Sie dazu die drei verschiedenen IDs (Google-E-Mail-Adresse, sAMAccountName und UID).

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.

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

Schließlich zeigt das folgende Code-Snippet, wie Hauptkonten erstellt werden, die Leser der Datei sind.

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 Lesern und Inhabern 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();

Die zugrunde liegende REST API verwendet das Muster

identitysources/IDENTITY_SOURCE_ID/users/EXTERNAL_ID
für die ID, wenn Hauptkonten erstellt werden. Wenn Sie in den vorherigen Tabellen eine ACL mit id1_identity von SAMAccountName (AnnAccountName) erstellen, wird die ID wie folgt 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 für Sicherheitszwecke verwendet werden oder einem lokalen Repository zugeordnet sind.

Mit der Cloud Identity Groups API können Sie eine Gruppe erstellen und die Mitgliedschaften verwalten. Verwenden Sie den Ressourcennamen der Identitätsquelle als Gruppen-Namespace, um die Gruppe mit einer Identitätsquelle zu verknüpfen.

Das folgende Code-Snippet zeigt, wie Sie eine Gruppe mithilfe der Cloud Identity Groups API erstellen:

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-ACL erstellen

Verwenden Sie die Methode getGroupPrincipal(), um ein Gruppenhauptkonto mithilfe einer bereitgestellten externen ID zu erstellen. Erstellen Sie dann 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 Nicht-Google-IDs verwenden, um ACLs und Indexelemente zu 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 externe IDs für einen Nutzer kennt:

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 dem 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 Elemente neu indexieren, damit die neue Identität wirksam 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 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, erhält die neue Gruppe erst dann Zugriff auf das Element, wenn das Element neu indexiert wird.