Sincronizza diversi sistemi di identità

Il controllo dell'accesso in Google Cloud Search si basa sull'Account Google dell'utente. Durante l'indicizzazione dei 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 conoscenza diretta degli Account Google. Invece, gli account locali rappresentano gli utenti o 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à:

• Definizione di un campo utente personalizzato per memorizzare gli ID esterni. Questo campo risolve gli ID esterni in un Account Google.
• Definizione di 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 Google Cloud Directory.
• Il repository definisce gruppi di controllo dell'accesso che non corrispondono a gruppi basati su email in Google Workspace.

Le origini identità migliorano l'efficienza separando l'indicizzazione dalla mappatura delle identità. Ciò consente di posticipare la ricerca utente durante la creazione di ACL e l'indicizzazione degli elementi.

Implementazione di esempio

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

Figura 1. Esempio di deployment aziendale con diversi tipi di identità.

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

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

Crea un'origine identità

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

Crea l'origine identità prima di creare un connettore di contenuti. Hai bisogno del suo ID per creare ACL e indicizzare i dati. La creazione di un'origine identità crea anche una proprietà utente personalizzata in Cloud Directory 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).

Origine identità	Proprietà utente	ID esterno
id1	id1_identity	sAMAccountName
id2	id2_identity	uid

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

Questa tabella mostra come viene visualizzato in Cloud Directory un utente con un Account Google e due ID esterni:

Utente	Email	id1_identity	id2_identity
Anna	[e-mail]	example\ann	1001

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

Scrivere ACL utente

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

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

FilePermissionSample.java

Visualizza su GitHub

/**
 * 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 principal per i proprietari utilizzando l'attributo externalUserName:

FilePermissionSample.java

Visualizza su GitHub

// 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 i principal per i lettori:

FilePermissionSample.java

Visualizza su GitHub

// 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 aggiunti i lettori e i proprietari, crea l'ACL:

FilePermissionSample.java

Visualizza su GitHub

// 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. Il valore id1_identity di Anna viene risolto in identitysources/id1_identity/users/example/ann. Questo è l'ID intermedio dell'utente.

Per saperne di più sulla modellazione degli ACL del repository, consulta la sezione ACL.

Gruppi di mappe

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

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

Questo snippet crea un gruppo:

CreateGroupCommand.java

Visualizza su GitHub

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 elenco di controllo dell'accesso di gruppo

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

FilePermissionSample.java

Visualizza su GitHub

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 in Cloud Directory. 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 delle 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 a Cloud Directory.

Sincronizzare le identità utilizzando l'API REST

Utilizza il metodo update 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 un mapping utente, il mapping originale rimane fino alla reindicizzazione.
• Se elimini un gruppo mappato e ne crei uno nuovo con lo stesso groupKey, non verrà concesso l'accesso finché non viene eseguita la reindicizzazione.