Verschiedene Identitätssysteme synchronisieren

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 zu einem gültigen Google-Nutzer oder Gruppen-IDs (E-Mail-Adressen) enthält.

Häufig verfügt ein Repository nicht über direkte Kenntnisse von Google Konten. Stattdessen können Nutzer durch lokale Konten repräsentiert werden oder föderierte Anmeldung über einen Identitätsanbieter und eine ID, andere als die E-Mail-Adresse des Nutzers, um jedes Konto zu identifizieren. Diese ID wird als externe ID.

Identitätsquellen, die über die Admin-Konsole erstellt wurden, schließen diese Lücke zwischen Identitätssysteme von:

• Ein benutzerdefiniertes Nutzerfeld festlegen zum Speichern externer IDs. Mit diesem Feld werden externe IDs in einen Google Konto.
• Namespace für Sicherheitsgruppen definieren die von einem Repository verwaltet werden, Identitätsanbieter.

Verwenden Sie Identitätsquellen in folgenden Fällen:

• Das Repository verfügt nicht über die primäre E-Mail-Adresse von Nutzer in Google Workspace oder Google Cloud Directory.
• Das Repository definiert Gruppen für die Zugriffssteuerung, die nicht übereinstimmen. für E-Mail-basierte Gruppen in Google Workspace.

Identitätsquellen verbessern die Indexierungseffizienz, indem sie die Indexierung entkoppeln aus der Identitätszuweisung. Durch diese Entkopplung können Sie die Suche nach wenn Sie ACLs erstellen und Elemente indexieren.

Beispiel für ein Deployment

Abbildung 1 zeigt ein Deployment, bei dem sowohl lokal als auch in der Cloud bereitgestellt werden. werden von einem Unternehmen genutzt. Für jedes Repository wird ein anderer Typ verwendet der externen ID, um auf Nutzer zu verweisen.

Repository 1 identifiziert den Nutzer anhand der E-Mail-Adresse, die mit SAML: Weil Repository 1 verfügt über die primäre E-Mail-Adresse des Nutzers in Für Google Workspace oder Cloud Directory ist keine Identitätsquelle erforderlich.

Repository 2 ist direkt in ein lokales Verzeichnis den Nutzer anhand seines sAMAccountName-Attributs 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 weitere Informationen unter Nutzeridentitäten in Cloud Search zuordnen.

Sie müssen zuerst eine Identitätsquelle erstellen, bevor Sie einen Inhaltsconnector erstellen, weil Sie benötigen die Identitätsquellen-ID, um ACLs zu erstellen und Daten zu indexieren. Wie bereits erwähnt Wenn Sie eine Identitätsquelle erstellen, wird auch ein benutzerdefinierte Nutzereigenschaft in Cloud Directory. Mit diesem Attribut können Sie die externe ID für jede in Ihrem Repository gespeichert. Die Eigenschaft wird mithilfe der Konvention IDENTITY_SOURCE_ID_identity.

Die folgende Tabelle zeigt zwei Identitätsquellen, eine für SAM-Kontonamen. (sAMAccountName) als externe IDs und eine mit User-IDs (uid) als externe IDs.

Erstellen Sie eine Identitätsquelle für jede mögliche externe ID, die für Folgendes verwendet wird: an einen Nutzer in Ihrem Unternehmen.

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

Sie können mit den drei verschiedenen IDs auf denselben Nutzer verweisen, (Google-E-Mail-Adresse, sAMAccountName und UID), wenn Sie ACLs für die Indexierung erstellen.

Nutzer-ACLs schreiben

Verwenden Sie die Methode getUserPrincpal() oder die Methode getGroupPrincipal() Methode zum Erstellen von Hauptkonten mithilfe einer bereitgestellten externen ID.

Das folgende Beispiel zeigt, wie Dateiberechtigungen abgerufen werden. Diese Berechtigungen umfassen den Namen jedes Nutzers, der Zugriff auf die Datei hat.

/**
 * 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 Hauptkonten erstellt werden, die Inhaber sind mit der in den Attributen gespeicherten externen ID (externalUserName).

// 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 die Datei lesen.

// 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:

// 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 ein, wenn Sie Hauptkonten erstellen. In den vorherigen Tabellen Wenn Sie eine ACL mit Anns id1_identity (SAMAccountName) erstellen, würde die ID auf:

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 gespeicherten Google-IDs bildet. mit Cloud Directory.

Weitere Informationen zur Modellierung 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. Sie können Verwenden Sie diese Namespace-Funktion zum Erstellen und Zuordnen von Gruppen, die für die Sicherheit verwendet werden oder sind lokal in einem Repository enthalten.

Cloud Identity Groups API verwenden um eine Gruppe zu erstellen und die Mitgliedschaften zu verwalten. Um die Gruppe mit einem Identitätsquelle verwenden Sie den Ressourcennamen der Identitätsquelle als Gruppen-Namespace.

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

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 zum Erstellen einer Gruppen-ACL die Methode getGroupPrincipal() , um ein Gruppenhauptkonto mithilfe einer bereitgestellten externen ID zu erstellen. Erstellen Sie dann die ACL mithilfe der Methode Acl.Builder -Klasse so an:

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 von Google stammende IDs verwenden, um ACLs und Indexelemente zu erstellen, Nutzer können Elemente in einer Suche erst sehen, wenn ihre externe ID einem Google-Konto zugeordnet ist ID in Cloud Directory. Es gibt drei Möglichkeiten, Cloud Directory kennt sowohl die Google-ID als auch die externen IDs eines Nutzers:

• Jedes einzelne Nutzerprofil über die Admin-Konsole manuell aktualisieren Diese Vorgehensweise wird nur für Tests und Prototyping mit wenigen Nutzerprofilen empfohlen.
• Verwenden Sie die Directory API, um externe IDs Google-IDs zuzuordnen. Diese Vorgehensweise wird empfohlen, wenn Sie das Identity Connector SDK nicht verwenden können.
• Identitätsconnector erstellen mithilfe der Identity Connector SDK Dieses SDK vereinfacht die Verwendung der Directory API zum Zuordnen von IDs.

Identitäts-Connectors sind Programme, mit denen externe IDs von Unternehmens-IDs zugeordnet werden. Identitäten (Nutzer und Gruppen) zu internen Google-Identitäten, die von Google verwendet werden, Cloud Search Wenn Sie eine Identitätsquelle erstellen müssen, Identitätsconnectors 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 in Cloud Directory, mit den Nutzerattributen, die ihre Identität in anderen Systemen repräsentieren können.

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 einem anderen Nutzer neu zuzuordnen, Die ursprüngliche Zuordnung bleibt erhalten, bis Sie neu indexieren.
• Wenn Sie eine zugeordnete Gruppe löschen, die in einer Element-ACL vorhanden ist, und dann ein mit derselben groupKey haben, bietet die neue Gruppe keinen Zugriff auf die bis das Element neu indexiert wurde.