Il provisioning delle identità (o provisioning degli account) è il processo di configurazione degli account e di creazione di connessioni tra i tre sistemi che contengono i dati degli utenti e, in alcuni casi, di configurazione delle connessioni tra gli utenti e i loro dispositivi.
In un ambiente Android Enterprise, tre sistemi diversi contengono le informazioni dell'account utente:
- La directory utenti dell'organizzazione è la fonte definitiva di informazioni sugli utenti.
- Tu (il fornitore della soluzione EMM) devi mantenere almeno una directory minima degli utenti dell'organizzazione.
- Google conserva alcune informazioni sugli account Google Play gestiti 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 e utilizza l'account
su tutti. L'account può fornire l'accesso solo a Google Play gestito o
ad altri servizi Google, a seconda di come configuri
l'azienda del cliente:
Gli Account Google gestiti sono account esistenti gestiti da Google. Questi account richiedono al cliente di utilizzare Google come provider di identità o di collegare la directory utenti della sua organizzazione a Google. Per le aziende che utilizzano gli account Google gestiti, Google è responsabile dell'autenticazione dell'utente durante il provisioning del dispositivo.
Gli account Google Play gestiti consentono alle aziende di creare automaticamente account utente limitati tramite il proprio provider di soluzioni di gestione della mobilità aziendale (EMM). Questi account forniscono l'accesso solo alla versione gestita di Google Play. L'EMM è interamente responsabile dell'autenticazione dell'utente quando necessario. Per gli account Google Play gestiti per l'azienda, questo è l'unico tipo di account disponibile.
Tabella 1: campi e metodi dell'API Users
| account Google Play gestiti | account Google gestiti | |
|---|---|---|
| Campo | ||
| id | ||
| kind | ||
| accountIdentifier | Un identificatore univoco che crei e mappi
all'ID (userId) restituito da Google Play. Non utilizzare informazioni che consentono l'identificazione personale (PII). | Non impostato. |
| accountType | deviceAccount, userAccount | userAccount |
| displayName | Il nome visualizzato negli elementi dell'interfaccia utente, ad esempio in Google Play. Non utilizzare informazioni che consentono l'identificazione personale. | Non impostato. |
| managementType | emmManaged | googleManaged, emmManaged |
| primaryEmail | Non impostato. | Questo campo è la chiave primaria in base alla quale 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 | ||
Nell'ambito dei nostri miglioramenti alla registrazione dei dispositivi, stiamo passando all'utilizzo degli Account Google gestiti per tutti i dispositivi Android Enterprise utilizzati da un dipendente con un'identità aziendale.
Per le nuove registrazioni, ora consigliamo di utilizzare gli Account Google gestiti anziché gli account Google Play gestiti. Sebbene continuiamo a supportare gli account Google Play gestiti per gli utenti esistenti, questi forniscono solo l'accesso al Google Play Store gestito. Gli Account Google gestiti consentono agli utenti di accedere alla suite completa di servizi Google e alle funzionalità cross-device.
Miglioramenti alla registrazione
Gli Account Google gestiti stabiliscono l'identità di un utente con Google. Ciò consente esperienze cross-device, come il trasferimento di attività, le notifiche e la condivisione nelle vicinanze. Queste funzionalità sono sempre più importanti nell'ambito aziendale, dove gli utenti utilizzano spesso più dispositivi.
Alle aziende che non utilizzano Google come provider di identità ora è vivamente consigliato di collegare il proprio provider di identità esistente a Google. Ciò consente la creazione di Account Google gestiti per i dipendenti durante la procedura di collegamento. Le aziende devono utilizzare lo stesso provider di identità per questa operazione che utilizzano con il proprio EMM.
Abbiamo implementato le seguenti modifiche:
L'autenticazione dell'utente finale durante la registrazione del dispositivo ora viene gestita da Google/Android. Il controller dei criteri dei dispositivi (DPC) dell'EMM richiede che Android autentichi l'utente nel punto appropriato, quindi Android restituisce l'identità dell'utente che ha eseguito l'accesso al DPC.
L'EMM deve trasmettere un token di registrazione ad Android quando richiede l'autenticazione dell'utente. Questo token viene restituito da una chiamata API all'API Android Enterprise e potrebbe essere codificato all'interno del payload di registrazione tramite QR, NFC o zero-touch.
Anche se ora Android gestisce l'autenticazione e fornisce l'identità utente all'EMM, è comunque responsabilità dell'EMM mappare l'identità utente al gruppo o alla struttura organizzativa corretti. Questo mapping è essenziale per applicare le norme appropriate al dispositivo. Pertanto, le aziende devono continuare a collegare la directory utenti della propria organizzazione al proprio EMM.
Gli amministratori IT possono attivare o disattivare la nuova funzionalità di autenticazione dell'utente finale fornita da Google. Per offrire agli utenti la migliore esperienza, incluse le funzionalità cross-device, consigliamo agli amministratori IT di collegare la directory utenti della propria organizzazione a Google. Senza questo link, gli utenti avranno account Google Play gestiti e non avranno accesso alle esperienze cross-device.
Un nuovo requisito per tutti gli EMM è fornire ulteriori informazioni durante la creazione di token di registrazione e accesso. In particolare, ora devi indicare se un dispositivo è senza utente (ad esempio un kiosk o un dispositivo dedicato) o meno.
Vantaggi
La nuova procedura offre i seguenti miglioramenti chiave:
Registrazione semplificata: riduce il numero di passaggi manuali e la complessità rispetto ai metodi standard.
Supporto degli Account Google:ora puoi utilizzare gli Account Google con tutti i metodi di provisioning. In questo modo non è più necessario utilizzare gli account Google Play gestiti.
Esperienza utente migliorata: con gli Account Google gestiti, ottieni un'esperienza Android più ricca che include potenti funzionalità cross-device come la condivisione e il copia e incolla.
Implementazione degli account utente
Per scoprire come procedere con questo nuovo flusso di registrazione, consulta Implementare gli account utente.
Ciclo di vita degli Account Google gestiti
Per le organizzazioni che utilizzano gli Account Google, gli account utente nella soluzione di un EMM
rispecchiano gli account utente esistenti associati a un altro servizio Google
(come 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 del dominio Google utilizzando strumenti come Google Cloud Directory Sync (GCDS) e l'API Directory dell'SDK Admin Google. 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 di poter essere sottoposto a provisioning su uno qualsiasi 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.
Sincronizzare gli account cliente
In un'implementazione di Account Google, l'organizzazione può utilizzare lo strumento GCDS per sincronizzare i dati nel proprio dominio G Suite con quelli nella propria 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 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 quelle di Active Directory, può 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 di Account Google, puoi utilizzare l'API Google Directory per sincronizzare Active Directory, password o entrambi:
Utilizzando l'API Directory per la sincronizzazione solo della directory. Se hai accesso in sola lettura al dominio Google gestito dell'organizzazione, puoi utilizzare l'API Google Directory per ottenere da Google informazioni sull'Account Google, come i nomi utente (ma non le password). Poiché non puoi scrivere dati negli Account Google degli utenti, l'organizzazione è interamente responsabile dei cicli di vita degli account.
Lo scenario 1 e gli scenari di autenticazione SSO basata su SAML descrivono questa situazione in modo più completo.
Per informazioni sull'utilizzo dell'API Directory in questo modo, consulta Recuperare tutti gli utenti dell'account nella documentazione dell'API Directory.
Utilizzando 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 Google Directory per ottenere nomi utente, password e altre informazioni dell'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 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 di Account Google
Nella sezione seguente sono descritti alcuni scenari tipici di provisioning dell'identità degli Account Google.
Scenario 1: il cliente è responsabile dei cicli di vita degli account
In questo scenario, il tuo cliente crea e gestisce gli Account Google per i suoi utenti.
Ricevi le informazioni sull'account utente dalla directory LDAP dell'organizzazione e le metti in relazione con i dati dell'Account Google che ricevi da Google utilizzando l'API Directory.
L'organizzazione è interamente 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 riceve 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 Google Directory per ottenere le informazioni di base sull'account degli utenti del tuo cliente. Le informazioni a tua disposizione sono quelle non modificabili
restituite 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 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 delle identità. Facoltativamente, l'organizzazione può utilizzare anche lo strumento GSPS per sincronizzare non solo i nomi utente, ma anche le password.
Scenario 2: EMM responsabile dei cicli di vita degli account
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 utente.
Ad esempio, quando le informazioni utente cambiano nella directory LDAP dell'organizzazione, sei responsabile dell'aggiornamento dell'Account Google dell'utente. GCDS non viene utilizzato in questo scenario.
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 Google Directory per conto del tuo cliente per leggere e
scrivere informazioni sull'account per gli utenti dell'organizzazione. Le informazioni
a tua disposizione sono quelle non modificabili
restituite 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 basata su SAML
In un'implementazione 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 quando gli utenti accedono ai propri dispositivi. Ad esempio, SAML potrebbe essere utilizzato nello scenario 2. Per informazioni dettagliate su come configurare questa opzione, vedi Configurare il Single Sign-On (SSO) per gli account G Suite.