Importante:non accettiamo più nuove registrazioni per l'API Play EMM. Scopri di più.

Questa pagina è stata tradotta dall'API Cloud Translation.

Esegui il provisioning degli account utente

Il provisioning delle identità (o provisioning dell'account) è il processo di configurazione e la connessione tra i tre sistemi; in alcuni casi, a configurare le connessioni tra gli utenti e i loro dispositivi.

In un ambiente aziendale Android, ci sono fino a tre sistemi diversi dati dell'account:

La directory degli utenti dell’organizzazione è la fonte definitiva di informazioni sugli utenti.
In qualità di fornitore di soluzioni EMM, devi gestire almeno una directory minima di gli utenti dell'organizzazione.
Google conserva alcune informazioni sugli account della versione gestita di Google Play e Account Google per la gestione delle app tramite Google Play.

Una risorsa Users rappresenta un account associati a un'azienda. L'account può essere specifico di un dispositivo oppure essere associate a un individuo che dispone di più dispositivi (telefono cellulare, tablet, e così via) e utilizza l'account in tutti questi elementi. L'account può fornire l'accesso solo alla versione gestita di Google Play o ad altri servizi Google, a seconda di come configura l'azienda del tuo cliente:

Gli account Google Play gestiti offrono alle aziende un mezzo trasparente di creare automaticamente account utente o dispositivo tramite la propria un provider di soluzioni di gestione della mobilità (EMM). Questi account consentono di accedere a solo nella 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 Play	Account gestiti da Google
Campo
id
kind
accountIdentifier	Un identificatore univoco che crei e mappa all'ID (`userId`) restituito da Google Play. Non usare personalmente che consentono l'identificazione personale (PII).	Non impostato.
accountType	deviceAccount, userAccount	userAccount
displayName	Il nome visualizzato negli elementi dell'interfaccia utente, ad esempio all'interno su Google Play. Non utilizzare informazioni che consentono l'identificazione personale.	Non impostato.
managementType	emmManaged	Gestito da Google, emmManaged
primaryEmail	Non impostato.	Questo campo è la chiave primaria che gestisci la sincronizzazione dagli account del dominio gestiti da Google agli utenti 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 della versione gestita di Google Play:

Account utente: Offre 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 ad aggiungere autonomamente account Google Play gestiti.; 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 mobili.
Account dispositivo: Fornisce l'accesso alla versione gestita di Google Play da un singolo dispositivo. Se token di autenticazione per un account dispositivo, una nuova richiesta di autenticazione per quell'account del dispositivo disattiva il token precedente. Ogni dispositivo deve avere le proprie licenze separate per le app.; Per creare un account del dispositivo, chiama Users.insert e imposta il tipo di account su deviceType,

L'utente crea e gestisce una mappatura tra le identità utente o dispositivo e gli account della versione gestita di Google Play corrispondenti, che potrai gestire tramite nel loro ciclo di vita. L'organizzazione non ha bisogno di alcun controllo diretto su questi gli account della versione gestita di Google Play, in quanto esistono account esclusivamente per gestione dei dispositivi.

Requisiti per console e server EMM

Gli account della versione gestita di Google Play vengono creati on demand e in modo programmatico tramite il le API EMM di Google Play e le API del framework Android per i componenti del tuo Soluzione EMM (console EMM, server EMM e DPC). Questi componenti interagiscono 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 di account anonimi univoci (il campo accountIdentifier) da usare nella chiamata a Users.insert Ad esempio, potrebbe utilizzare un valore interno per l'utente ("sanjeev237389") o un numero di tag asset criptici ("asset#44448"). Evita di usare informazioni che consentono l'identificazione personale (PII) per l'identificatore dell'account.
Archivia la mappatura tra userId (restituita da insert chiamata) e i accountIdentifier selezionati.

di Gemini Advanced.

Per i requisiti del DPC, consulta Creazione di criteri relativi ai dispositivi un controller.

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 dell'utente al server o alla console EMM. Supponendo che l'utente non sia noto al tuo sistema:
1. Invia la richiesta per un nuovo account Google Play gestito chiamando il numero Users.insert con valori per nuovi accountIdentifier, displayName e accountType.
  - Il tuo sistema deve creare accountIdentifier. L'identificatore dell'account deve essere un valore univoco nel tuo sistema. Non utilizzare informazioni che consentono l'identificazione personale per identificatore dell'account.
  - L'icona displayName viene mostrata nel selettore dell'account di Google Play e devono avere un significato per l'utente (ma non informazioni che consentono l'identificazione personale) dell'utente). Ad esempio, il nome potrebbe includere il nome dell'organizzazione un nome generico correlato all'EMM.
  - Imposta accountType su userAccount o deviceAccount. R L'app userAccount può essere usata su più dispositivi, mentre un deviceAccount è specifica di un singolo dispositivo. Il valore 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. Archivia la mappatura tra accountIdentifier e userId in e il tuo datastore.
4. Chiama il numero Users.generateAuthenticationToken con userId e enterpriseId. Google Play restituisce un di autenticazione che può essere utilizzato una sola volta e che deve essere utilizzato all'interno di un per alcuni minuti.
5. Inoltra in sicurezza il token di autenticazione al DPC (controller criteri dispositivi).
Il DPC esegue il provisioning del profilo di lavoro e aggiunge l'account al profilo o dal dispositivo mobile.
L'utente può accedere alla versione gestita di Google Play nel profilo di lavoro o nel dispositivo.

di Gemini Advanced.

Account amministratore

Quando un amministratore crea un'azienda con la versione gestita di Google Play Account, l'Account Google usato non può essere un account G Suite. L'account utilizzato diventa proprietario dell'azienda, che può aggiungere altri proprietari e nella versione gestita di Google Play Console.

Sia Enterprises.get che Enterprises.completeSignup restituiscono un elenco di indirizzi email di amministratori associati a un'azienda (solo aziende con account Google Play gestiti).

Gestire i cicli di vita degli account

In un'implementazione di Account Google Play gestiti, sei responsabile di dati e cicli di vita degli account del dispositivo, ovvero la creazione, l'aggiornamento e l'eliminazione questi account.

Puoi creare gli account durante il provisioning del dispositivo, un processo che prevede l'app DPC (controller criteri dispositivi) e la tua console EMM. Per istruzioni, vedi 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 per l'azienda con account della versione gestita di Google Play. In questo caso, il dispositivo gli account utente associati all'azienda vengono eliminati, descritto in Annullare l'iscrizione, ripetere l'iscrizione elimina.

Scadenza dell'account

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

Il token di autenticazione ottenuto per aggiungere l'account al dispositivo è scaduta.
L'account o l'azienda è stato eliminato.
Per gli account dispositivo, l'account è stato aggiunto a un nuovo dispositivo ed è pertanto disattivata sul vecchio dispositivo.
I controlli automatici degli abusi vengono attivati.

Nella maggior parte dei casi (a meno che il provider EMM trasferisca intenzionalmente un account dispositivo a un nuovo dispositivo), la best practice consiste nell'utilizzare l'API Play EMM per richiedere un nuovo token dal server EMM, prendi nota dello stato dell'account, dell'azienda e di eventuali hanno restituito errori, quindi intraprendere le azioni appropriate sul dispositivo. Ad esempio: aggiornare il token oppure, se l'errore non è recuperabile, reimpostare o annullare la registrazione dispositivo.

La versione 9.0.00 di Google Play Services ti consente di DPC che l'account è scaduto utilizzando l'azione di trasmissione:

Quando l'account della versione gestita di Google Play viene invalidato su un dispositivo, il DPC (controller criteri dispositivi) riceve una trasmissione con la seguente azione:
```
com.google.android.gms.auth.ACCOUNT_REAUTH_REQUIRED
```
L'intent di trasmissione contiene un extra di Parcelable con il nome account, che è Account dell'account invalidato.
Il DPC controlla Account#name con il server EMM per identificare l'account non più valido.
Il DPC richiede nuove credenziali o un nuovo account seguendo le stesse flusso utilizzato per eseguire il provisioning del dispositivo all'inizio.

Account Google

Per le organizzazioni che utilizzano Account Google, gli account utente in un EMM soluzione mirroring degli 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 la fonte per la creazione di informazioni sull'account.

In qualità di EMM, puoi fornire meccanismi nella tua console per facilitare la creazione e la sincronizzazione continua degli account utente tenuti nel sistema con i loro Origini degli account del dominio Google con strumenti come Google Cloud Directory Sync (GCDS) e l'API Google 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 soluzione (console EMM, server EMM, magari in un datastore) prima di poterne eseguire il provisioning dei dispositivi dell'utente nel contesto di un profilo di lavoro.

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

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

Sincronizzare gli account dei clienti

In un deployment di Account Google, l'organizzazione può utilizzare lo strumento GCDS per sincronizzare i dati del proprio dominio G Suite con i dati presenti nel proprio LDAP . In alternativa, puoi utilizzare GCDS per eseguire questa operazione nel se l'organizzazione ti concede l'accesso.

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

Se l'organizzazione utilizza Microsoft Active Directory e vuole mantenere le Le password di G Suite siano sincronizzate con le password di Active Directory, il cliente (o anche tu) può utilizzare G Suite Password Sync (GSPS) con GCDS.

Per le istruzioni di GCDS per gli amministratori, vedi 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 le directory attive, le password o entrambe:

Utilizzo dell'API Directory per la sincronizzazione solo della directory. Se disponi di un accesso di sola lettura per accedere al dominio Google gestito dell'organizzazione, puoi utilizzare API Directory per ottenere i dati dell'Account Google, ad esempio i nomi utente (ma non password) di Google. Poiché non puoi scrivere nessun dato per il database Account Google, l'organizzazione è pienamente responsabile della vita dell'account. ciclico.

Scenario 1 e scenari di autenticazione SSO basata su SAML a descrivere la situazione in modo più esaustivo.

Per informazioni sull'utilizzo dell'API Directory in questo modo, consulta Recupera tutto di utenti in la documentazione dell'API Directory.
Utilizzo dell'API Directory per la sincronizzazione della directory e della password facoltativa. Se disporre dell'accesso in lettura/scrittura al dominio Google gestito dell'organizzazione, puoi utilizzare l'API Google Directory per ottenere nomi utente, password e altri Dati dell'Account Google. Puoi aggiornare queste informazioni e sincronizzarle con il tuo database e potresti avere la responsabilità completa o parziale cicli di vita dell'account, a seconda della soluzione che offri al cliente.

Scenario 2 descrive la situazione in modo più esaustivo.

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

Scenari per gli Account Google

Sono descritti alcuni scenari tipici di provisioning delle identità per gli Account Google di seguito.

Scenario 1: cliente responsabile dei cicli di vita dell'account

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

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

Le informazioni sugli account utente sono recuperate dalla directory LDAP dell'organizzazione e è una correlazione con i dati dell'Account Google che ricevi da Google tramite la API Directory.

L’organizzazione è pienamente responsabile dei cicli di vita degli account. Ad esempio, quando un nuovo Account Google, l'organizzazione aggiunge l'utente al proprio LDAP . La prossima volta che sincronizzi il tuo database con la directory LDAP, riceve informazioni su questo nuovo utente.

In questo caso:

Disponi dell'accesso di sola lettura agli Account Google.
Il database acquisisce i nomi degli Account Google, ma non i nomi utente LDAP o password.
Puoi utilizzare l'API Google Directory per ottenere i dati di base dell'account per gli utenti del cliente. (le informazioni a tua disposizione sono quelle non scrivibili) restituito da un Users.get richiesta). Puoi utilizzare queste informazioni per verificare l'esistenza degli Account Google degli utenti per consentire agli utenti di eseguire l'autenticazione sui loro dispositivi.
Il tuo cliente utilizza lo strumento GCDS per eseguire una sincronizzazione unidirezionale e compilare i campi delle Account Google. (probabilmente l'organizzazione utilizza GCDS anche per il una volta completato il provisioning delle identità). Facoltativamente, il parametro un'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

Utilizzo dell'API Directory con
accesso in lettura/scrittura

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

Ad esempio, quando le informazioni utente cambiano nella directory LDAP dell'organizzazione, sei responsabile di aggiornare l'Account Google dell'utente. GCDS non è utilizzato in questo scenario.

In questo caso:

Disponi dell'accesso in lettura/scrittura agli Account Google.
Il database acquisisce i nomi degli Account Google e i nomi utente LDAP (e facoltativamente, 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 le informazioni non scrivibili restituito da un Users.get richiesta). Puoi utilizzare queste informazioni per verificare l'esistenza degli Account Google degli utenti per consentire agli utenti di eseguire l'autenticazione sui loro dispositivi.
Lo strumento GCDS non è utilizzato.

di Gemini Advanced.

Scenari di autenticazione SSO basati su SAML

In un deployment di Account Google, tu o il tuo cliente potreste usare la sicurezza SAML (Assertion Markup Language) con un provider di identità per l'autenticazione all'Account Google associato a ciascun utente. Utilizzi i nomi degli Account Google come verifica dell'esistenza degli Account Google degli utenti, che è necessaria per quando gli utenti accedono ai propri dispositivi. Ad esempio, SAML potrebbe essere utilizzata nello scenario 2. Per maggiori dettagli sulla procedura di configurazione, vedi Configurare un singolo utente Accesso agli account G Suite (SSO).

Attivare gli account sui dispositivi

Per distribuire app sul dispositivo di un utente tramite la versione gestita di Google Play, l'utente deve eseguire l'accesso sul dispositivo durante il provisioning del dispositivo:

Nel provisioning degli account Google Play gestiti, il tuo DPC (controller criteri dispositivi) indica all'utente di accedere utilizzando le credenziali accettate dal tuo provider EMM. della console, in genere le credenziali email aziendali.
Durante l'implementazione di Google Account, il DPC (controller criteri dispositivi) aiuta l'utente a inserire il proprio Credenziali di accesso all'Account Google. Di solito queste credenziali corrispondono a quelle con cui gli utenti accedono al proprio dominio aziendale quando sono sincronizzati con GCDS o GKE oppure quando un'organizzazione usa un IdP per l'autenticazione. In questo modo viene attivato l'Account Google dell'utente, viene generato un ID dispositivo univoco e vincola l'identità dell'Account Google dell'utente e l'ID dispositivo del dispositivo.