Il provisioning delle identità (o provisioning degli account) è il processo di configurazione degli account e di creazione di connessioni tra i tre sistemi e, in alcuni casi, tra gli utenti e i loro dispositivi.
In un ambiente Android Enterprise, fino a tre diversi sistemi contengono informazioni sull'account:
- La directory degli utenti dell'organizzazione è la fonte definitiva di informazioni sugli utenti.
- Tu (il fornitore di soluzioni EMM) devi gestire almeno una directory minima degli utenti dell'organizzazione.
- Google gestisce 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 essere associato a una persona che ha più dispositivi (smartphone, tablet e così via) e utilizza l'account su tutti. L'account può fornire accesso solo alla versione gestita di Google Play o ad altri servizi Google, a seconda di come hai configurato l'azienda del cliente:
Gli account Google Play gestiti offrono alle aziende un mezzo trasparente per creare automaticamente account utente o dispositivo tramite il proprio fornitore di soluzioni di 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 Account Google.
Tabella 1: campi e metodi dell'API Users
Account della versione gestita di Google Play | Account gestiti da Google | |
---|---|---|
Campo | ||
id | ||
kind | ||
accountIdentifier | Un identificatore univoco che crei e mappi all'ID (userId ) restituito da Google Play. Non usare informazioni che consentono l'identificazione personale (PII). | Non impostato. |
accountType | account dispositivo, account utente | userAccount |
displayName | Il nome visualizzato negli elementi dell'interfaccia utente, ad esempio all'interno di Google Play. Non utilizzare informazioni che consentono l'identificazione personale. | Non impostato. |
managementType | emmManaged | googleManaged, emmManaged |
primaryEmail | Non 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 | ||
elimina | ||
generateAuthenticationToken | ||
generateToken | ||
get | ||
getAvailableProductSet | ||
insert | ||
list | ||
revokeToken | ||
setAvailableProductSet | ||
update |
Account della versione gestita di Google Play
Esistono due tipi di Account Google Play gestiti:
- 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, che non dispongono delle credenziali per aggiungere autonomamente account Google Play gestiti.
- Per creare un account utente, chiama
Users.insert
. Imposta il tipo di account suuserType
e imposta unaccountIdentifier
, 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 token di autenticazione per quell'account dispositivo disattiva il token precedente. Ogni dispositivo deve disporre della propria licenza separata per le app.
- Per creare un account dispositivo, chiama
Users.insert
e imposta il tipo di account sudeviceType
.
Creazione e gestione di una mappatura tra le identità utente o dispositivo e gli account Google Play gestiti corrispondenti, nonché gestione degli account durante il loro ciclo di vita. L'organizzazione non ha bisogno di alcun controllo diretto su questi account Google Play gestiti, poiché esistono esclusivamente per la gestione delle applicazioni.
Requisiti per console e server EMM
Gli account Google Play gestiti vengono creati su richiesta, in modo programmatico, utilizzando le API EMM di Google Play e le API del framework Android nei componenti della soluzione EMM (console EMM, server EMM e DPC). Questi componenti interagiscono in fase di esecuzione per creare un account utente e eseguire il provisioning del profilo di lavoro sul dispositivo di destinazione.
La console o il server EMM deve:
Fornisci un meccanismo per creare identificatori univoci anonimi degli account (campo
accountIdentifier
) da utilizzare nella chiamata aUsers.insert
. Ad esempio, potresti 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.Memorizza la mappatura tra
userId
(restituito dalla chiamatainsert
) eaccountIdentifier
selezionato.
Per i requisiti del DPC, consulta Creare un controller dei criteri dei dispositivi.
Creare un account utente della versione gestita di Google Play
- Un utente accede al tuo DPC utilizzando (in genere) le credenziali aziendali.
- Il DPC richiede i dettagli sull'utente al server o alla console EMM.
Supponendo che l'utente non sia noto al sistema:
- Invia una richiesta per un nuovo Account Google Play gestito chiamando
Users.insert
con i valori per i nuoviaccountIdentifier
,displayName
eaccountType
.- Il sistema deve creare il file
accountIdentifier
. L'identificatore account deve essere un valore univoco nel sistema. Non utilizzare PII per l'identificatore dell'account. - Il codice
displayName
viene visualizzato nel selettore di account del Google Play Store e dovrebbe 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 al provider EMM. - Imposta
accountType
suuserAccount
odeviceAccount
. UnuserAccount
può essere utilizzato su più dispositivi, mentre undeviceAccount
è specifico per un singolo dispositivo. Il valoreaccountType
specificato può esseredeviceType
ouserType
. - Imposta
managementType
suemmManaged
.
- Il sistema deve creare il file
- Google Play elabora la richiesta, crea l'account e
restituisce un
userId
. - Memorizza la mappatura tra
accountIdentifier
euserId
nel tuo datastore. - Chiama
Users.generateAuthenticationToken
con iluserId
e ilenterpriseId
. Google Play restituisce un token di autenticazione che può essere utilizzato una sola volta e che deve essere utilizzato entro pochi minuti. - Inoltra in sicurezza il token di autenticazione al tuo DPC.
- Invia una richiesta per un nuovo Account Google Play gestito chiamando
- Il PDC esegue il provisioning del profilo di lavoro e aggiunge l'account al profilo di lavoro o al dispositivo.
- 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 Google Play gestiti, l'Account Google che utilizza non può essere un account G Suite. L'account utilizzato diventa un proprietario per l'azienda e il proprietario può aggiungere altri proprietari e amministratori in Google Play Console gestito.
Sia Enterprises.get
sia
Enterprises.completeSignup
restituisce un elenco di indirizzi email di amministratore associati a un'azienda
(solo aziende con account Google Play gestiti).
Gestire i cicli di vita degli account
In un deployment degli account Google Play gestiti, sei responsabile dei cicli di vita degli account utente e dispositivo, il che significa che li crei, li aggiorni ed elimini.
Creerai gli account durante il provisioning del dispositivo, un processo che coinvolge l'app DPC e la console EMM. Per le istruzioni, consulta il metodo degli account Google Play gestiti.
Per modificare le informazioni di un account, chiama Users.update.
Per eliminare un account, chiama Users.delete.
Gli amministratori non possono eliminare singoli account, ma possono eliminare un'azienda con account Google Play gestiti. In questo modo, gli account dell'azienda e del dispositivo associati verranno eliminati, come descritto in Annullamento della registrazione, nuova registrazione ed eliminazione.
Scadenza dell'account
A volte gli account o i relativi token scadono, il che può accadere per diversi motivi:
- Il token di autenticazione ottenuto per aggiungere l'account al dispositivo è scaduto.
- L'account o l'azienda è stato eliminato.
- Per gli account del dispositivo, l'account è stato aggiunto a un nuovo dispositivo ed è quindi disattivato sul vecchio dispositivo.
- Vengono attivati controlli automatici per rilevare gli abusi.
- Se un dispositivo è offline per più di 270 giorni, le relative informazioni potrebbero essere eliminate a causa di una procedura di pulizia collettiva.
Nella maggior parte dei casi (a meno che l'EMM non stia spostando intenzionalmente un account dispositivo su un nuovo dispositivo), la best practice è utilizzare l'API Play EMM per richiedere un nuovo token dal server EMM, prendere nota dello stato dell'account e dell'azienda e di eventuali errori restituiti, quindi intraprendere l'azione appropriata 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:
- Chiama
users.generateAuthenticationToken
per richiedere un nuovo token di autenticazione per l'account. - Se la chiamata va a buon fine, rimuovi l'account esistente e aggiungi il nuovo account utilizzando la libreria di assistenza DPC.
- 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 comunica al PDC che l'account è scaduto utilizzando l'azione di trasmissione:
Quando l'Account Google Play gestito 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
denominatoaccount
, che è l'oggetto
dell'account invalidato.Account
Il DPC esegue dei controlli
Account#name
con il server EMM per identificare l'account invalidato.Il DPC richiede nuove credenziali o un nuovo account, seguendo lo stesso flusso utilizzato per il provisioning del dispositivo inizialmente.
Account Google
Per le organizzazioni che utilizzano Account Google, gli account utente in una soluzione EMM rispecchiano gli account utente esistenti associati a un altro servizio Google (ad esempio G Suite). Questi account sono googleManaged
(Tabella 1) perché
i servizi di backend di Google sono l'origine della creazione e delle informazioni
sullo stesso account.
In qualità di fornitore di soluzioni EMM, puoi fornire nella tua console meccanismi per facilitare la creazione e la sincronizzazione continua degli account utente nel tuo sistema con le relative origini dell'account del dominio Google utilizzando strumenti come Google Cloud Directory Sync (GCDS) e l'API Directory dell'SDK Admin di Google. per una panoramica dei vari approcci. Il modello di identità di dominio gestito da Google richiede che l'account utente esista nel contesto della tua soluzione (console EMM, server EMM, eventualmente in un data store) prima che sia possibile eseguire il provisioning su uno dei dispositivi dell'utente nel contesto di un profilo di lavoro.
Durante il provisioning delle 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 suo dispositivo, 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 degli Account Google, l'organizzazione può utilizzare lo strumento GCDS per sincronizzare i dati del proprio dominio G Suite con quelli della directory LDAP. In alternativa, puoi utilizzare GCDS per eseguire questa operazione per conto dell'organizzazione, se l'organizzazione ti concede l'accesso.
Lo strumento GCDS chiama l'API Google Directory e sincronizza i nomi utente, ma non le password.
Se l'organizzazione utilizza Microsoft Active Directory e vuole mantenere sincronizzate le password di G Suite degli utenti con le password di Active Directory, l'organizzazione o tu puoi utilizzare lo strumento G Suite Password Sync (GSPS) con GCDS.
Per le istruzioni di GCDS per gli amministratori, consulta Preparare il dominio G Suite per la sincronizzazione.
API Google Directory
In un deployment degli Account Google, puoi utilizzare l'API Google Directory 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 recuperare da Google informazioni sull'Account Google, ad esempio i nomi utente (ma non le password). Poiché non puoi scrivere dati negli Account Google degli utenti, l'organizzazione è pienamente responsabile dei cicli di vita degli account.
Lo scenario 1 e gli scenari di autenticazione SSO basati su SAML descrivono questa situazione in modo più completo.
Per informazioni sull'utilizzo dell'API Directory in questo modo, consulta Recupero di tutti gli utenti dell'account nella documentazione dell'API Directory.
Utilizzare l'API Directory per la sincronizzazione della directory e, facoltativamente, delle password. Se hai accesso in lettura/scrittura al dominio Google gestito dell'organizzazione, puoi utilizzare l'API Google Directory per recuperare nomi utente, password e altri dati dell'Account Google. Puoi aggiornare queste informazioni e sincronizzarle con il tuo database e potresti avere la responsabilità totale o parziale del ciclo di vita dell'account, a seconda della soluzione che offri al tuo cliente.
Lo scenario 2 descrive questa situazione in modo più completo.
Per saperne di più sull'utilizzo dell'API Directory per gestire le informazioni degli account utente, consulta la guida per gli sviluppatori API Directory: account utente.
Scenari degli Account Google
Di seguito sono descritti alcuni scenari tipici di provisioning dell'identità degli Account Google.
Scenario 1: il cliente è responsabile dei cicli di vita dell'account
In questo scenario, il cliente crea e gestisce gli Account Google per i suoi utenti.
Ottieni i dati dell'account utente dalla directory LDAP dell'organizzazione e li correlati ai dati dell'Account Google che ricevi da Google tramite l'API Directory di Google.
L'organizzazione è pienamente 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 volta successiva che sincronizzi il database con la directory LDAP, il database riceverà le informazioni su questo nuovo utente.
In questo caso:
- Hai accesso di sola lettura agli Account Google.
- Il database acquisisce i nomi degli Account Google, ma non i nomi utente o le password LDAP.
- Utilizzi l'API Google Directory per ottenere informazioni di base sull'account degli utenti del tuo cliente. Le informazioni a tua disposizione sono quelle non scrivibili
riportate da una richiesta
Users.get
. Utilizzi queste informazioni per verificare l'esistenza degli Account Google degli utenti, in modo che possano autenticarsi sui propri dispositivi. - Il cliente utilizza lo strumento GCDS per eseguire una sincronizzazione unidirezionale al fine di compilare gli Account Google degli utenti. Probabilmente l'organizzazione utilizza anche GCDS per la propria sincronizzazione continua dopo il completamento del provisioning delle 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 dell'account
In questo scenario, gestisci la procedura di creazione degli Account Google per conto del tuo cliente e sei responsabile del ciclo di vita degli account degli utenti.
Ad esempio, quando le informazioni utente cambiano nella directory LDAP dell'organizzazione, è tua responsabilità aggiornare l'Account Google dell'utente. GCDS non viene utilizzato in questo scenario.
In questo caso:
- Hai accesso in lettura/scrittura agli Account Google.
- Il database acquisisce i nomi degli Account Google e i nomi utente LDAP (e, facoltativamente, gli hash delle password).
- Utilizzi l'API Google Directory per conto del tuo cliente per leggere e scrivere i dati dell'account per gli utenti dell'organizzazione. (le informazioni disponibili sono quelle non scrivibili riportate da una richiesta
Users.get
). Utilizzi queste informazioni per verificare l'esistenza degli Account Google degli utenti, in modo che possano autenticarsi sui propri dispositivi. - Lo strumento GCDS non viene utilizzato.
Scenari di autenticazione SSO basati su SAML
In un deployment degli Account Google, tu o il tuo cliente potreste utilizzare il protocollo Security Assertion Markup Language (SAML) con un provider di identità (IdP) per autenticare l'Account Google associato a ciascun utente. Utilizzi i nomi degli Account Google come verifica dell'esistenza degli Account Google degli utenti, che è necessaria per l'autenticazione degli utenti quando accedono ai loro dispositivi. Ad esempio, SAML potrebbe essere utilizzato nello scenario 2. Per informazioni dettagliate su come eseguire la configurazione, vedi Configurare il Single Sign-On (SSO) per gli account G Suite.
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:
- Nel provisioning dei dispositivi per gli account Google Play gestiti, il PDC guida l'utente ad accedere utilizzando le credenziali accettate dalla console EMM, tipicamente le credenziali email aziendali.
- In un deployment degli Account Google, il PDC guida l'utente nell'inserimento delle sue credenziali di accesso all'Account Google. In genere, queste credenziali corrispondono a quelle con cui gli utenti accedono al dominio aziendale quando sono sincronizzati con GCDS o GSPS o quando un'organizzazione utilizza un provider di identità per l'autenticazione. In questo modo viene attivato l'Account Google dell'utente, viene generato un ID dispositivo univoco e viene associata l'identità dell'Account Google dell'utente all'ID dispositivo del suo dispositivo.