Questa pagina è stata tradotta dall'API Cloud Translation.

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 sugli elementi devono risolversi in un utente Google valido o ID gruppo (indirizzi email).

In molti casi un repository non ha una conoscenza diretta di Google . Gli utenti possono essere rappresentati da account locali o accesso federato con un provider di identità e un ID, altro diverso dall'indirizzo email dell'utente, per identificare ciascun account. Questo ID è chiamato ID esterno.

Le origini identità, create utilizzando la Console di amministrazione, aiutano a colmare questo divario tra sistemi di identità per:

Definire un campo utente personalizzato per archiviare gli ID esterni. Il campo viene utilizzato per risolvere gli ID esterni in una richiesta .
Definisci uno spazio dei nomi per i gruppi di sicurezza gestiti da un repository provider di identità.

Utilizza le origini identità quando:

Il repository non conosce l'indirizzo email principale di l'utente in Google Workspace o Google Cloud Directory.
Il repository definisce i gruppi per il controllo dell'accesso che non corrispondono ai gruppi basati su email in Google Workspace.

Le origini identità migliorano l'efficienza dell'indicizzazione disaccoppiando l'indicizzazione dalla mappatura delle identità. che ti consente di rimandare la ricerca durante la creazione di ACL e l'indicizzazione degli elementi.

Deployment di esempio

La figura 1 mostra un esempio di distribuzione in cui sia on-premise che cloud vengono utilizzati da un'azienda. Ogni repository utilizza un tipo diverso dell'ID esterno per fare riferimento agli utenti.

Il repository 1 identifica l'utente tramite l'indirizzo email dichiarato utilizzando SAML. Poiché Il repository 1 conosce l'indirizzo email principale dell'utente in Google Workspace o Cloud Directory, non è necessaria un'origine identità.

Il repository 2 si integra direttamente con una directory on-premise identifica l'utente tramite il suo attributo sAMAccountName. Poiché il repository 2 utilizza un attributo sAMAccountName come ID esterno, un'origine identità è necessaria.

Crea un'origine identità

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

Devi creare un'origine identità prima di creare un connettore di contenuti perché ti servirà l'ID origine identità per creare ACL e indicizzare i dati. Come menzionato In precedenza, la creazione di un'origine identità comporta anche proprietà utente personalizzata in Cloud Directory. Utilizza questa proprietà per registrare l'ID esterno di ogni un utente nel tuo repository. La proprietà viene denominata utilizzando convenzione IDENTITY_SOURCE_ID_identity.

La tabella seguente mostra due origini identità, una per contenere i nomi degli account SAM (sAMAccountName) come ID esterni e uno per contenere gli ID utente (uid) come ID esterni.

Origine identità	proprietà utente	ID esterno
id1	id1_identity	sAMAccountName
id2	id2_identity	UID

Crea un'origine identità per ogni possibile ID esterno utilizzato fare riferimento a un utente della tua azienda.

La tabella seguente mostra in che modo un utente con un Account Google e due ID esterni (id1_identity e id2_identity) e i relativi valori vengono visualizzati in Cloud Directory:

utente	email	id1_identity	id2_identity
Anna	ann@example.com	esempio\ann	1001

Puoi fare riferimento allo stesso utente utilizzando i tre ID diversi, (Email Google, sAMAccountName e uid) durante la creazione di ACL per l'indicizzazione.

Scrivi ACL utente

Utilizza la getUserPrincpal() o il metodo getGroupPrincipal() per creare entità utilizzando un ID esterno fornito.

L'esempio seguente mostra come recuperare le autorizzazioni dei file. Questi includono il nome di ogni utente che ha accesso al file.

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

Il seguente snippet di codice mostra come creare entità proprietarie utilizzando l'ID esterno (externalUserName) memorizzato negli attributi.

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

Infine, il seguente snippet di codice mostra come creare entità sono lettori del file.

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 ottenuto un elenco di lettori e proprietari, puoi creare 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 sottostante utilizza il pattern identitysources/IDENTITY_SOURCE_ID/users/EXTERNAL_ID per l'ID durante la creazione delle entità. Facendo riferimento alle tabelle precedenti, se crei un ACL con id1_identity (SAMAccountName) di Ann, l'ID risolvi in:

identitysources/id1_identity/users/example/ann

L'intero ID è chiamato ID intermedio dell'utente perché fornisce un collegamento tra l'ID esterno e gli ID Google archiviati con Cloud Directory.

Per ulteriori informazioni sulla modellazione degli ACL utilizzati per un repository, consulta ACL.

Gruppi sulla mappa

Le origini identità fungono anche da spazio dei nomi per i gruppi utilizzati negli ACL. Puoi utilizza questa funzionalità dello spazio dei nomi per creare e mappare i gruppi utilizzati per la sicurezza o sono locali in un repository.

Utilizzare l'API Cloud Identity Groups per creare un gruppo e gestire le iscrizioni. Per associare il gruppo a un origine identità, usa il nome risorsa dell'origine identità come spazio dei nomi gruppo.

Il seguente snippet di codice mostra come creare un gruppo utilizzando il metodo API Cloud Identity Groups:

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

Crea un ACL di gruppo

Per creare un ACL di gruppo, utilizza la getGroupPrincipal() per creare un'entità gruppo utilizzando un ID esterno fornito. Quindi, crea ACL che utilizza Acl.Builder come segue:

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à

Puoi utilizzare ID esterni non Google per creare ACL ed elementi di indice, gli utenti non possono visualizzare gli elementi di una ricerca finché i loro ID esterni non generano una in Cloud Directory. Esistono tre modi per garantire che Cloud Directory conosce sia l'ID Google sia gli ID esterni di un utente:

Aggiornare manualmente ogni singolo profilo utente tramite la Console di amministrazione Questa procedura è consigliata solo per i test e la prototipazione con pochi profili utente.
Mappa gli ID esterni agli ID Google utilizzando l'API Directory. Questa procedura è consigliata a chi non può utilizzare l'SDK Identity Connector.
Crea un connettore di identità utilizzando SDK Identity Connector. Questo SDK semplifica l'utilizzo dell'API Directory per mappare gli ID.

I connettori di identità sono programmi utilizzati per mappare gli ID esterni dall'azienda (utenti e gruppi) alle identità Google interne utilizzate da Google in Cloud Search. Se devi creare un'origine identità, devi per la creazione di un connettore di identità.

Google Cloud Directory Sync (GCDS) è un esempio di connettore di identità. Questo connettore di identità mappa l'utente raggruppare le informazioni da Active Directory di Microsoft a Cloud Directory con gli attributi utente che potrebbero rappresentare la loro identità in altri sistemi.

Sincronizzazione delle identità con l'API REST

Utilizza il metodo update per sincronizzare le identità utilizzando l'API REST.

Rimappatura delle identità

Dopo aver rimappato l'identità di un elemento a un'altra identità, devi reindicizzare gli elementi per mantenere la nuova identità. Ad esempio,

Se provi a rimuovere una mappatura da un utente o a rimapparla a un altro utente, il mapping originale viene conservato fino alla reindicizzazione.
Se elimini un gruppo mappato presente in un ACL degli elementi e quindi crei un nuovo gruppo con lo stesso groupKey, il nuovo gruppo non fornisce accesso ai elemento finché non viene reindicizzato.