Sincronizza diversi sistemi di identità

Il controllo dell'accesso in Google Cloud Search si basa sull'Account Google dell'utente. Quando indicizzi i contenuti, tutte le ACL sugli elementi devono risolvere in ID gruppo o utente Google validi (indirizzi email).

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

Creati utilizzando la Console di amministrazione, le origini identità aiutano a colmare questa lacuna tra i sistemi di identità:

• Definizione di un campo utente personalizzato per memorizzare gli ID esterni. Il campo viene utilizzato per risolvere gli ID esterni in un account Google.
• Definisci uno spazio dei nomi per i gruppi di sicurezza gestito 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 per il controllo dell'accesso che non corrispondono ai gruppi basati su email in Google Workspace.

Le origini identità migliorano l'efficienza dell'indicizzazione scollegandola dalla mappatura delle identità. Questo disaccoppiamento ti consente di rimandare la ricerca dell'utente quando crei ACL e indicizzi gli elementi.

Esempio di implementazione

La Figura 1 mostra un esempio di implementazione in cui un'azienda utilizza i repository sia on-premise sia cloud. Ogni repository utilizza un tipo diverso di ID esterno per fare riferimento agli utenti.

Il repository 1 identifica l'utente utilizzando l'indirizzo email rivendicato tramite 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 e identifica l'utente tramite l'attributo sAMAccountName. Poiché il repository 2 utilizza un attributo sAMAccountName come ID esterno, è necessaria un'origine identità.

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é ne avrai bisogno per creare ACL e indicizzare i dati. Come accennato in precedenza, la creazione di un'origine identità comporta anche la creazione di una proprietà utente personalizzata in Cloud Directory. Utilizza questa proprietà per registrare l'ID esterno di ogni utente nel tuo repository. La proprietà viene denominata utilizzando la convenzione IDENTITY_SOURCE_ID_identity.

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

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

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

Puoi fare riferimento allo stesso utente utilizzando tre ID diversi (email Google, sAMAccountName e uid) quando crei ACL per l'indicizzazione.

Scrivi ACL utente

Utilizza il metodo getUserPrincpal() o il metodo getGroupPrincipal() per creare i principali utilizzando un ID esterno fornito.

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

/**
 * 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à principali che sono proprietari utilizzando l'ID esterno (externalUserName) memorizzato negli attributi.

// 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à principali che sono lettori del file.

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

// 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 patternidentitysources/IDENTITY_SOURCE_ID/users/EXTERNAL_ID per l'ID durante la creazione dei principali. Facendo riferimento alle tabelle precedenti, se crei un'ACL con il id1_identity (SAMAccountName) di Ann, l'ID sarà:

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 definizione del modello degli ACL utilizzati per un repository, consulta ACL.

Gruppi di mappe

Le origini delle identità fungono anche da spazio dei nomi per i gruppi utilizzati negli ACL. Puoi utilizzare questa funzionalità dello spazio dei nomi per creare e mappare gruppi utilizzati solo per scopi di sicurezza o che sono locali per un repository.

Utilizza l'API Cloud Identity Groups per creare un gruppo e gestire le iscrizioni. Per associare il gruppo a un'origine identity, utilizza il nome della risorsa dell'origine identity come spazio dei nomi del gruppo.

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

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

Per creare un'ACL di gruppo, utilizza il metodo getGroupPrincipal() per creare un gruppo principale utilizzando un ID esterno fornito. Quindi, crea l'ACL utilizzando la classe Acl.Builder come segue:

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

Connettori di identità

Sebbene tu possa utilizzare ID esterni non Google per creare ACL e indicizzare gli elementi, gli utenti non possono vedere gli elementi in una ricerca finché i loro ID esterni non vengono risolti in un ID Google in Cloud Directory. Esistono tre modi per assicurarti che Cloud Directory conosca sia l'ID Google sia gli ID esterni di un utente:

• Aggiorna manualmente ogni singolo profilo utente tramite la Console di amministrazione. Questa procedura è consigliata solo per i test e la prototipazione utilizzando alcuni profili utente.
• Mappa gli ID esterni agli ID Google utilizzando l'API Directory. Questa procedura è consigliata per chi non può utilizzare l'SDK Identity Connector.
• Crea un connettore di identità utilizzando l'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 dalle identità aziendali (utenti e gruppi) alle identità Google interne utilizzate da Google Cloud Search. Se devi creare un'origine identità, devi creare un connettore di identità.

Google Cloud Directory Sync (GCDS) è un esempio di connettore di identità. Questo connettore di identità mappa le informazioni su utenti e gruppi da Microsoft Active Directory a Cloud Directory, nonché gli attributi utente che possono rappresentare la loro identità in altri sistemi.

Sincronizzare le identità utilizzando l'API REST

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

Rimappata delle identità

Dopo aver rimappato l'identità di un elemento a un'altra identità, devi indicizzare di nuovo gli elementi perché la nuova identità venga applicata. Ad esempio,

• Se provi a rimuovere una mappatura da un utente o a mapparla a un altro utente, la mappatura originale viene comunque conservata fino al nuovo indicizzazione.
• Se elimini un gruppo mappato presente in un ACL elemento e poi crei un nuovo gruppo con lo stesso groupKey, il nuovo gruppo non fornisce l'accesso all'elemento finché non viene sottoposto a nuova indicizzazione.