Sincronizza diversi sistemi di identità

Il controllo dell'accesso in Google Cloud Search si basa sull'Account Google dell'utente. Quando indicizzi i contenuti, tutti gli ACL degli elementi devono essere risolti in ID utente o gruppo Google validi (indirizzi email).

In molti casi, un repository non ha una conoscenza diretta degli Account Google. Invece, gli account locali rappresentano gli utenti oppure gli utenti utilizzano l'accesso federato con un provider di identità. Questa identificazione, diversa dall'indirizzo email, è chiamata ID esterno.

Create utilizzando la Console di amministrazione, le origini identità colmano il divario tra i sistemi di identità:

• Definendo un campo utente personalizzato per archiviare gli ID esterni. Questo campo risolve gli ID esterni in un Account Google.
• Definendo uno spazio dei nomi per i gruppi di sicurezza gestiti da un repository o da un provider di identità.

Utilizza le origini identità quando:

• Il repository non conosce l'indirizzo email principale dell'utente in Google Workspace o nella directory Google Cloud.
• Il repository definisce gruppi di controllo dell'accesso che non corrispondono ai gruppi basati su email in Google Workspace.

Le origini identità migliorano l'efficienza disaccoppiando l'indicizzazione dalla mappatura delle identità. In questo modo puoi rimandare la ricerca degli utenti durante la creazione di ACL e l'indicizzazione degli elementi.

Esempio di deployment

La Figura 1 mostra un'azienda che utilizza repository on-premise e cloud. Ognuno utilizza un tipo diverso di ID esterno.

Il repository 1 identifica gli utenti tramite indirizzo email utilizzando SAML. Poiché conosce l'indirizzo email principale in Google Workspace o nella directory cloud, non ha bisogno di un'origine identità.

Il repository 2 si integra con una directory on-premise e identifica gli utenti tramite sAMAccountName. Poiché utilizza questo attributo come ID esterno, richiede un'origine identità.

Creare un'origine identità

Se hai bisogno di un'origine identità, consulta Mappare le identità utente in Cloud Search.

Crea l'origine identità prima di creare un connettore di contenuti; ti serve il suo ID per creare ACL e indicizzare i dati. La creazione di un'origine identità crea anche una proprietà utente personalizzata nella directory cloud per archiviare gli ID esterni. Il nome della proprietà utilizza la convenzione IDENTITY_SOURCE_ID_identity.

Questa tabella mostra due origini identità: una per i nomi degli account SAM e una per gli ID utente (uid).

Crea un'origine identità per ogni tipo di ID esterno utilizzato nella tua azienda.

Questa tabella mostra come un utente con un Account Google e due ID esterni viene visualizzato nella directory cloud:

Puoi fare riferimento allo stesso utente utilizzando uno di questi ID quando crei gli ACL per l'indicizzazione.

Scrivere ACL utente

Utilizza getUserPrincipal() o getGroupPrincipal() per creare entità utilizzando ID esterni.

Questo esempio recupera le autorizzazioni dei file, inclusi gli utenti con accesso:

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

Questo snippet crea entità per i proprietari utilizzando l'attributo 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)
);

Questo snippet crea entità per i lettori:

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

Una volta che hai lettori e proprietari, crea l'ACL:

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

L'API REST utilizza il pattern identitysources/IDENTITY_SOURCE_ID/users/EXTERNAL_ID. id1_identity di Ann viene risolto in identitysources/id1_identity/users/example/ann. Questo è l'ID intermedio dell'utente.

Per saperne di più sulla modellazione degli ACL dei repository, consulta ACL.

Mappare i gruppi

Le origini identità fungono anche da spazio dei nomi per i gruppi ACL. Utilizzalo per creare e mappare i gruppi utilizzati solo per la sicurezza o locali a un repository.

Utilizza l'API Cloud Identity Groups per creare gruppi e gestire le iscrizioni. Associa il gruppo a un'origine identità utilizzando il nome dell'origine identità come spazio dei nomi.

Questo snippet crea un gruppo:

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

Creare un ACL di gruppo

Utilizza getGroupPrincipal() per creare un'entità gruppo con un ID esterno, quindi crea l'ACL:

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

Connettori di identità

Gli utenti non possono visualizzare gli elementi nei risultati di ricerca finché i loro ID esterni non vengono risolti in un ID Google nella directory cloud. Puoi assicurarti che ciò avvenga in tre modi:

• Aggiorna manualmente i profili utente nella Console di amministrazione (consigliato solo per i test).
• Mappa gli ID utilizzando l'API Directory.
• Crea un connettore di identità utilizzando l'SDK Identity Connector.

I connettori di identità mappano gli ID esterni delle identità aziendali con le identità Google interne. Se crei un'origine identità, devi creare anche un connettore di identità.

Google Cloud Directory Sync (GCDS) è un esempio di connettore di identità. Mappa le informazioni di utenti e gruppi da Active Directory alla directory cloud.

Sincronizzare le identità utilizzando l'API REST

Utilizza il update metodo per sincronizzare le identità.

Rimappare le identità

Dopo aver rimappato un'identità, devi reindicizzare gli elementi affinché la modifica venga applicata.

• Se rimuovi o modifichi una mappatura utente, la mappatura originale rimane fino alla reindicizzazione.
• Se elimini un gruppo mappato e ne crei uno nuovo con la stessa groupKey, non concederà l'accesso finché non reindicizzi.