Esegui il provisioning degli account utente

Il provisioning dell'identità (o provisioning dell'account) è il processo di configurazione degli account e di creazione di connessioni tra i tre sistemi e, in alcuni casi, di configurazione delle connessioni tra gli utenti e i loro dispositivi.

In un ambiente Android Enterprise, fino a tre sistemi diversi contengono informazioni sull'account:

  • La directory utenti dell'organizzazione è la fonte definitiva di informazioni sugli utenti.
  • Tu (il fornitore della soluzione EMM) devi gestire almeno una directory minima degli utenti dell'organizzazione.
  • Google conserva alcune informazioni sugli account della versione gestita di Google Play e sugli Account Google per fornire la gestione delle app tramite Google Play.

Una risorsa Users rappresenta un account associato a un'azienda. L'account può essere specifico per un dispositivo o può essere associato a una persona che ha più dispositivi (cellulare, tablet e così via) e utilizza l'account su tutti. L'account può fornire l'accesso solo alla versione gestita di Google Play o ad altri servizi Google, a seconda di come configuri l'azienda del cliente:

  • Gli account della versione gestita di Google Play forniscono alle aziende un mezzo trasparente per creare automaticamente account utente o dispositivo tramite il loro fornitore di soluzioni per la gestione della mobilità aziendale (EMM). Questi account forniscono l'accesso solo alla versione gestita di Google Play.

  • Gli Account Google sono account esistenti gestiti da Google e richiedono la sincronizzazione con le origini degli Account Google.

Tabella 1: campi e metodi dell'API Users

 Account della versione gestita di Google PlayAccount gestiti da Google
Campo
id
kind
accountIdentifierUn identificatore univoco che crei e mappi all'ID (userId) restituito da Google Play. Non utilizzare informazioni che consentono l'identificazione personale (PII).Non impostato.
accountTypedeviceAccount, userAccountuserAccount
displayNameIl nome che visualizzi negli elementi dell'interfaccia utente, ad esempio in Google Play. Non utilizzare informazioni che consentono l'identificazione personale.Non impostato.
managementTypeemmManagedgoogleManaged, emmManaged
primaryEmailNon impostato.Questo campo è la chiave primaria con cui gestisci la sincronizzazione dagli account di dominio gestiti da Google agli account utente nel tuo sistema.
Metodi
delete
generateAuthenticationToken
generateToken
get
getAvailableProductSet
insert
list
revokeToken
setAvailableProductSet
update

Account della versione gestita di Google Play

Esistono due tipi di account della versione gestita di Google Play:

Account utente
Fornisce a un singolo utente l'accesso alla versione gestita di Google Play da tutti i suoi dispositivi. Devi eseguire il provisioning degli account utente per i tuoi utenti: non hanno le credenziali per aggiungere autonomamente gli account della versione gestita di Google Play.
Per creare un account utente, chiama Users.insert. Imposta il tipo di account su userType e imposta un accountIdentifier, che fa riferimento in modo univoco all'utente all'interno dell'azienda.
Best practice: non utilizzare lo stesso account su più di 10 dispositivi.
Account dispositivo
Fornisce l'accesso alla versione gestita di Google Play da un singolo dispositivo. Se è stato emesso un token di autenticazione per un account dispositivo, una nuova richiesta di un token di autenticazione per quell'account dispositivo disattiva il token precedente. Ogni dispositivo deve disporre delle proprie licenze separate per le app.
Per creare un account dispositivo, chiama Users.insert e imposta il tipo di account su deviceType.

Crei e gestisci una mappatura tra le identità utente o dispositivo e gli account della versione gestita di Google Play corrispondenti e gestisci gli account durante il loro ciclo di vita. L'organizzazione non ha bisogno di alcun controllo diretto su questi account della versione gestita di Google Play, poiché gli account esistono esclusivamente per la gestione delle applicazioni.

Requisiti per console e server EMM

Gli account della versione gestita di Google Play vengono creati on demand, a livello di programmazione, utilizzando le API EMM di Google Play e le API del framework Android nei componenti della tua soluzione EMM (console EMM, server EMM e DPC). Questi componenti interagiscono in fase di runtime per creare un account utente ed eseguire il provisioning del profilo di lavoro sul dispositivo di destinazione .

La console o il server EMM deve:

  • Fornire un meccanismo per creare identificatori di account anonimi univoci (il campo accountIdentifier) da utilizzare nella chiamata a Users.insert. Ad esempio, puoi utilizzare un valore interno per l'utente ("sanjeev237389") o un numero di tag asset criptico ("asset#44448"). Evita di utilizzare informazioni che consentono l'identificazione personale (PII) per l'identificatore dell'account.

  • Memorizzare la mappatura tra userId (restituito dalla chiamata insert) e accountIdentifier selezionato.

Per i requisiti del DPC, vedi Creare un controller dei criteri dei dispositivi.

Creare un account utente della versione gestita di Google Play

  1. Un utente accede al DPC utilizzando (in genere) le credenziali aziendali.
  2. Il DPC richiede i dettagli dell'utente al server o alla console EMM. Supponendo che l'utente non sia noto al tuo sistema:
    1. Invia una richiesta per un nuovo account della versione gestita di Google Play chiamando Users.insert con i valori per nuovi accountIdentifier, displayName e accountType.
      • Il sistema deve creare accountIdentifier. L'identificatore dell'account deve essere un valore univoco nel tuo sistema. Non utilizzare PII per l'identificatore dell'account.
      • displayName viene visualizzato nel selettore dell'account di Google Play Store e deve avere un significato per l'utente (ma non PII sull'utente). Ad esempio, il nome potrebbe includere il nome dell'organizzazione o un nome generico correlato all'EMM.
      • Imposta accountType su userAccount o deviceAccount. Un userAccount può essere utilizzato su più dispositivi, mentre un deviceAccount è specifico per un singolo dispositivo. accountType specificato può essere deviceType o userType.
      • Imposta managementType su emmManaged.
    2. Google Play elabora la richiesta, crea l'account e restituisce un userId.
    3. Memorizza la mappatura tra accountIdentifier e userId nel tuo datastore.
    4. Chiama Users.generateAuthenticationToken con userId e enterpriseId. Google Play restituisce un token di autenticazione che può essere utilizzato una sola volta e che deve essere utilizzato entro pochi minuti.
    5. Inoltra in modo sicuro il token di autenticazione al tuo DPC.
  3. Il DPC esegue il provisioning del profilo di lavoro e aggiunge l'account al profilo di lavoro o al dispositivo.
  4. L'utente può accedere alla versione gestita di Google Play all'interno del profilo di lavoro o del dispositivo.

Account amministratore

Quando un amministratore crea un'azienda con account della versione gestita di Google Play Accounts, l'Account Google che utilizza non può essere un account Google Workspace. L'account che utilizza diventa un proprietario dell'azienda e il proprietario può aggiungere altri proprietari e amministratori nella console della versione gestita di Google Play.

Sia Enterprises.get sia Enterprises.completeSignup restituiscono un elenco di indirizzi email di amministrazione associati a un'azienda (solo aziende con account della versione gestita di Google Play).

Gestire i cicli di vita degli account

In un deployment di account della versione gestita di Google Play, sei responsabile dei cicli di vita degli account utente e dispositivo, il che significa che crei, aggiorni ed elimini questi account.

Crei gli account durante il provisioning del dispositivo, un processo che coinvolge l'app DPC e la console EMM. Per le istruzioni, vedi il metodo degli account della versione gestita di Google Play.

Per modificare le informazioni di un account, chiama Users.update.

Per eliminare un account, chiama Users.delete.

Gli amministratori non possono eliminare i singoli account, ma possono eliminare un'azienda con account della versione gestita di Google Play. In questo caso, i dispositivi e gli account utente associati all'azienda vengono eliminati, come descritto in Annullare la registrazione, registrare di nuovo, eliminare.

Scadenza dell'account

A volte gli account o i relativi token scadono, il che può accadere per una serie di motivi:

  • Il token di autenticazione ottenuto per aggiungere l'account al dispositivo è scaduto.
  • L'account o l'azienda è stato eliminato.
  • Per gli account dispositivo, l'account è stato aggiunto a un nuovo dispositivo e pertanto è disattivato sul vecchio dispositivo.
  • Vengono attivati i controlli automatici per rilevare comportamenti illeciti.
  • Se un dispositivo è offline per più di 270 giorni, le relative informazioni potrebbero essere eliminate a causa di una procedura di pulizia batch.

Nella maggior parte dei casi (a meno che l'EMM non stia spostando intenzionalmente un account dispositivo su un nuovo dispositivo), la best practice consiste nell'utilizzare l'API EMM di Play per richiedere un nuovo token dal server EMM, annotare lo stato dell'account e dell'azienda e gli eventuali errori restituiti, quindi intraprendere le azioni appropriate sul dispositivo. Ad esempio, rinnova il token o, se l'errore non è recuperabile, reimposta o annulla la registrazione del dispositivo.

Per rinnovare correttamente il token, devi:

  1. Chiamausers.generateAuthenticationToken per richiedere un nuovo token di autenticazione per l'account.
  2. Se la chiamata va a buon fine, rimuovi l'account esistente e aggiungi il nuovo account utilizzando la libreria di supporto DPC.
  3. Se la chiamata non va a buon fine, rimuovi l'account dal dispositivo e crea un nuovo utente utilizzando users.insert, genera un token di autenticazione e aggiungi l'account al dispositivo.

Google Play Services versione 9.0.00 notifica al DPC che l'account è scaduto utilizzando l'azione di trasmissione:

  1. Quando l'account della versione gestita di Google Play viene invalidato su un dispositivo, il DPC riceve una trasmissione con la seguente azione: 

    com.google.android.gms.auth.ACCOUNT_REAUTH_REQUIRED

    L'intent di trasmissione contiene un extra Parcelable con il nome account, che è l'oggetto Account dell'account invalidato.

  2. Il DPC controlla Account#name con il server EMM per identificare l'account invalidato.

  3. Il DPC richiede nuove credenziali o un nuovo account, seguendo lo stesso flusso utilizzato per eseguire il provisioning del dispositivo inizialmente.

Account Google

Per le organizzazioni che utilizzano Account Google, gli account utente nella soluzione di un EMM rispecchiano gli account utente esistenti associati a un altro servizio Google (ad esempio Google Workspace). Questi account sono googleManaged (Tabella 1) perché i servizi di backend di Google sono l'origine della creazione e delle informazioni sull'account.

In qualità di EMM, puoi fornire meccanismi nella tua console per facilitare la creazione e la sincronizzazione continua degli account utente presenti nel tuo sistema con le relative origini degli account di dominio Google utilizzando strumenti come Google Cloud Directory Sync (GCDS) e l'API Admin SDK Directory. per una panoramica dei vari approcci. Il modello di identità del dominio gestito da Google richiede che l'account utente esista nel contesto della tua soluzione (console EMM, server EMM, forse in un datastore) prima che possa essere eseguito il provisioning su uno dei dispositivi dell'utente nel contesto di un profilo di lavoro.

Durante il provisioning dell'identità, il dominio gestito da Google dell'organizzazione viene compilato con gli account utente. In alcuni casi, le identità online esistenti degli utenti (ad esempio, i loro account Microsoft Exchange) vengono sincronizzate con i loro Account Google.

Dopo la sincronizzazione iniziale, ma prima che le app vengano distribuite sul dispositivo di un utente, l'utente deve attivare il proprio Account Google, come descritto in Attivare gli account sui dispositivi. Questa attivazione consente al dispositivo di accedere alla versione gestita di Google Play.

Sincronizzare gli account cliente

In un deployment di Account Google, l'organizzazione può utilizzare lo strumento GCDS per sincronizzare i dati nel proprio dominio Google Workspace con i dati nella directory LDAP. In alternativa, puoi utilizzare GCDS per farlo per conto dell'organizzazione, se l'organizzazione ti concede l'accesso.

Lo strumento GCDS chiama l'API Directory di Google e sincronizza i nomi utente, ma non le password.

Se l'organizzazione utilizza Microsoft Active Directory e vuole mantenere sincronizzate le password di Google Workspace degli utenti con le password di Active Directory, vedi Prepararsi a utilizzare Sincronizzazione password.

Per le istruzioni di GCDS per gli amministratori, vedi Autorizzare l'Account Google.

API Directory di Google

In un deployment di Account Google, puoi utilizzare l'API Directory di Google per sincronizzare le directory attive, le password o entrambe:

  • Utilizzare l'API Directory per la sincronizzazione solo della directory. Se disponi dell'accesso di sola lettura al dominio Google gestito dell'organizzazione, puoi utilizzare l'API Directory di Google per ottenere informazioni sull'Account Google, come i nomi utente (ma non le password) da Google. Poiché non puoi scrivere dati negli Account Google degli utenti, l'organizzazione è completamente responsabile dei cicli di vita degli account.

    Lo scenario 1 e gli scenari di autenticazione SSO basata su SAML descrivono più completamente questa situazione.

    Per informazioni sull'utilizzo dell'API Directory in questo modo, consulta Recuperare tutti gli utenti dell'account in nella documentazione dell'API Directory.

  • Utilizzare l'API Directory per la sincronizzazione della directory e, facoltativamente, delle password. Se disponi dell'accesso in lettura/scrittura al dominio Google gestito dell'organizzazione, puoi utilizzare l'API Directory di Google per ottenere nomi utente, password e altre informazioni sull'Account Google. Puoi aggiornare queste informazioni e sincronizzarle con il tuo database e potresti avere la responsabilità totale o parziale dei cicli di vita degli account, a seconda della soluzione che offri al tuo cliente.

    Lo scenario 2 descrive più completamente questa situazione.

    Per ulteriori informazioni sull'utilizzo dell'API Directory per gestire le informazioni dell'account utente, consulta la guida per gli sviluppatori dell'API Directory: Account utente.

Scenari di Account Google

Di seguito sono descritti alcuni scenari tipici di provisioning dell'identità di Account Google.

Scenario 1: il cliente è responsabile dei cicli di vita degli account

Utilizzo dell'API Directory (con accesso di sola lettura) e di GCDS

In questo scenario, il cliente crea e gestisce gli Account Google per i suoi utenti.

Ottieni le informazioni dell'account utente dalla directory LDAP dell'organizzazione e le correli con i dati dell'Account Google che ottieni da Google tramite l'API Directory di Google.

L'organizzazione è completamente responsabile dei cicli di vita degli account. Ad esempio, quando viene creato un nuovo Account Google, l'organizzazione aggiunge l'utente alla propria directory LDAP. La prossima volta che sincronizzi il database con la directory LDAP, il database riceverà informazioni su questo nuovo utente.

In questo caso:

  • Disponi dell'accesso di sola lettura agli Account Google.
  • Il tuo database acquisisce i nomi degli Account Google, ma non i nomi utente o le password LDAP.
  • Utilizzi l'API Directory di Google per ottenere le informazioni di base dell'account per gli utenti del tuo cliente. (Le informazioni a tua disposizione sono le informazioni non scrivibili restituite da una Users.get richiesta). Utilizzi queste informazioni per verificare che gli Account Google degli utenti esistano in modo che gli utenti possano autenticarsi sui propri dispositivi.
  • Il tuo cliente utilizza lo strumento GCDS per eseguire una sincronizzazione unidirezionale per popolare gli Account Google degli utenti. (L'organizzazione probabilmente utilizza GCDS anche per la propria sincronizzazione continua dopo il completamento del provisioning dell'identità.) Facoltativamente, l' organizzazione può anche utilizzare lo strumento GSPS per sincronizzare non solo i nomi utente, ma anche le password.

Scenario 2: l'EMM è responsabile dei cicli di vita degli account

Utilizzo dell'API Directory con accesso in lettura/scrittura

In questo scenario, gestisci la procedura di creazione degli Account Google per conto del tuo cliente e sei responsabile dei cicli di vita degli account degli utenti.

Ad esempio, quando le informazioni dell'utente cambiano nella directory LDAP dell'organizzazione, sei responsabile dell'aggiornamento dell'Account Google dell'utente. In questo scenario non viene utilizzato GCDS.

In questo caso:

  • Disponi dell'accesso in lettura/scrittura agli Account Google.
  • Il tuo database acquisisce i nomi degli Account Google e i nomi utente LDAP (e, facoltativamente, gli hash delle password).
  • Utilizzi l'API Directory di Google per conto del tuo cliente per leggere e scrivere le informazioni dell'account per gli utenti dell'organizzazione. (Le informazioni a tua disposizione sono le informazioni non scrivibili restituite da una Users.get richiesta). Utilizzi queste informazioni per verificare che gli Account Google degli utenti esistano in modo che gli utenti possano autenticarsi sui propri dispositivi.
  • Lo strumento GCDS non viene utilizzato.

Scenari di autenticazione SSO basata su SAML

In un deployment di Account Google, tu o il tuo cliente potreste utilizzare SAML (Security Assertion Markup Language) con un provider di identità (IdP) per autenticare l'Account Google associato a ogni utente. Utilizzi i nomi degli Account Google come verifica dell'esistenza degli Account Google degli utenti, necessaria per l'autenticazione degli utenti quando accedono ai propri dispositivi. Ad esempio, SAML potrebbe essere utilizzato nello scenario 2. Per i dettagli su come configurare questa opzione, vedi Informazioni sull'SSO.

Attivare gli account sui dispositivi

Affinché le app vengano distribuite sul dispositivo di un utente tramite la versione gestita di Google Play, l'utente deve accedere al dispositivo durante il provisioning del dispositivo: