Le provisionnement d'identité (ou provisionnement de compte) consiste à configurer des comptes et à établir des connexions entre les trois systèmes qui contiennent les données utilisateur, et dans certains cas, à établir des connexions entre les utilisateurs et leurs appareils.
Dans un environnement Android Enterprise, trois systèmes différents contiennent des informations sur les comptes utilisateur :
- L'annuaire des utilisateurs de l'organisation est la source d'informations de référence sur les utilisateurs.
- Vous (le fournisseur de solution EMM) devez tenir à jour au moins un répertoire minimal des utilisateurs de l'organisation.
- Google conserve certaines informations sur les comptes Google Play gérés et les comptes Google pour permettre la gestion des applications via Google Play.
Une ressource Users représente un compte associé à une entreprise. Le compte peut être spécifique à un appareil ou associé à une personne qui possède plusieurs appareils et utilise le compte sur chacun d'eux. Le compte peut donner accès à Google Play d'entreprise uniquement ou à d'autres services Google, selon la façon dont vous configurez l'entreprise de votre client :
Les comptes Google gérés sont des comptes existants gérés par Google. Ces comptes exigent que le client utilise Google comme fournisseur d'identité ou qu'il associe le répertoire utilisateur de son organisation à Google. Pour les entreprises qui utilisent des comptes Google gérés, Google est responsable de l'authentification de l'utilisateur lors du provisionnement de l'appareil.
Les comptes d'entreprise Google Play Accounts permettent aux entreprises de créer automatiquement des comptes utilisateur limités par le biais de leur fournisseur de solution Enterprise Mobility Management (EMM). Ces comptes ne permettent d'accéder qu'à Google Play d'entreprise. L'EMM est entièrement responsable de l'authentification de l'utilisateur lorsque cela est nécessaire. Pour les comptes d'entreprise Google Play Accounts, il s'agit du seul type de compte disponible.
Tableau 1 : Champs et méthodes de l'API Users
| Comptes Google Play d'entreprise | Comptes Google gérés | |
|---|---|---|
| Champ | ||
| id | ||
| kind | ||
| accountIdentifier | Identifiant unique que vous créez et mappez à l'ID (userId) renvoyé par Google Play. N'utilisez pas d'informations permettant d'identifier personnellement l'utilisateur. | Non défini. |
| accountType | deviceAccount, userAccount | userAccount |
| displayName | Nom que vous affichez dans les éléments de l'UI, par exemple dans Google Play. N'utilisez pas d'informations permettant d'identifier personnellement l'utilisateur. | Non défini. |
| managementType | emmManaged | googleManaged, emmManaged |
| primaryEmail | Non défini. | Ce champ est la clé primaire à l'aide de laquelle vous gérez la synchronisation des comptes de domaine gérés par Google avec les comptes utilisateur de votre système. |
| Méthodes | ||
| supprimer | ||
| generateAuthenticationToken | ||
| generateToken | ||
| get | ||
| getAvailableProductSet | ||
| insert | ||
| list | ||
| revokeToken | ||
| setAvailableProductSet | ||
| update | ||
Dans le cadre de l'amélioration de l'enregistrement des appareils, nous allons passer à l'utilisation de comptes Google gérés pour tous les appareils Android Enterprise utilisés par un employé disposant d'une identité professionnelle.
Pour les nouvelles inscriptions, nous vous recommandons désormais d'utiliser des comptes Google gérés plutôt que des comptes Google Play gérés. Bien que nous continuions à prendre en charge les comptes Google Play d'entreprise pour les utilisateurs existants, ils ne donnent accès qu'au Google Play d'entreprise. Les comptes Google gérés donnent aux utilisateurs accès à l'ensemble des services Google et des fonctionnalités multi-appareils.
Améliorations de l'enregistrement
Les comptes Google gérés permettent d'établir l'identité d'un utilisateur auprès de Google. Cela permet des expériences multi-appareils, comme le transfert de tâches, les notifications et le partage à proximité. Ces fonctionnalités sont de plus en plus importantes dans le domaine de l'entreprise, où les utilisateurs utilisent souvent plusieurs appareils.
Il est désormais fortement recommandé aux entreprises qui n'utilisent pas Google comme fournisseur d'identité d'associer leur fournisseur d'identité existant à Google. Cela permet de créer des comptes Google gérés pour les employés lors du processus d'association. Les entreprises doivent utiliser le même fournisseur d'identité pour cette opération que pour leur EMM.
Nous avons apporté les modifications suivantes :
L'authentification de l'utilisateur final lors de l'enregistrement de l'appareil est désormais gérée par Google/Android. Le contrôleur de règles relatives aux appareils (DPC) de l'EMM exige qu'Android authentifie l'utilisateur au moment opportun, puis Android renvoie l'identité de l'utilisateur connecté au DPC.
L'EMM doit transmettre un jeton d'enregistrement à Android lorsqu'il demande l'authentification de l'utilisateur. Ce jeton est renvoyé par un appel d'API à l'API Android Enterprise et peut être encodé dans la charge utile d'enregistrement par code QR, NFC ou sans contact.
Bien qu'Android gère désormais l'authentification et fournisse l'identité de l'utilisateur à l'EMM, il incombe toujours à l'EMM de mapper l'identité de l'utilisateur au groupe ou à la structure organisationnelle appropriés. Ce mappage est essentiel pour appliquer les règles appropriées à l'appareil. Par conséquent, les entreprises doivent continuer à associer l'annuaire des utilisateurs de leur organisation à leur solution EMM.
Les administrateurs informatiques peuvent activer ou désactiver la nouvelle fonctionnalité d'authentification des utilisateurs finaux fournie par Google. Pour offrir aux utilisateurs la meilleure expérience possible, y compris les fonctionnalités multi-appareils, nous recommandons aux administrateurs informatiques d'associer le répertoire d'utilisateurs de leur organisation à Google. Sans ce lien, les utilisateurs disposeront de comptes Google Play gérés et n'auront pas accès aux expériences inter-appareils.
Tous les EMM doivent désormais fournir des informations supplémentaires lorsqu'ils créent des jetons d'enregistrement et de connexion. Plus précisément, vous devez désormais indiquer si un appareil est sans utilisateur (comme un kiosque ou un appareil dédié) ou non.
Avantages
Le nouveau processus offre les principales améliorations suivantes :
Inscription simplifiée : elle réduit le nombre d'étapes manuelles et la complexité par rapport aux méthodes standards.
Prise en charge des comptes Google : vous pouvez désormais utiliser les comptes Google avec toutes les méthodes de provisionnement. Il n'est donc plus nécessaire d'utiliser des comptes Google Play gérés.
Expérience utilisateur améliorée : les comptes Google gérés vous offrent une expérience Android plus riche, qui inclut de puissantes fonctionnalités inter-appareils comme le partage et le copier-coller.
Implémentation des comptes utilisateur
Pour savoir comment procéder avec ce nouveau flux d'inscription, consultez Implémenter des comptes utilisateur.
Cycle de vie des comptes Google gérés
Pour les organisations qui utilisent des comptes Google, les comptes utilisateur dans la solution d'EMM reflètent les comptes utilisateur existants associés à un autre service Google (tel que Google Workspace). Ces comptes sont googleManaged (tableau 1), car les services de backend de Google sont à l'origine de la création et des informations sur le compte.
En tant qu'EMM, vous pouvez fournir des mécanismes dans votre console pour faciliter la création et la synchronisation continue des comptes utilisateur détenus dans votre système avec leurs sources de comptes de domaine Google à l'aide d'outils tels que Google Cloud Directory Sync (GCDS) et l'API Directory Google Admin SDK. Pour obtenir une vue d'ensemble des différentes approches, consultez la documentation. Le modèle d'identité de domaine géré par Google exige que le compte utilisateur existe dans le contexte de votre solution (console EMM, serveur EMM, peut-être dans un data store) avant de pouvoir être provisionné sur l'un des appareils de l'utilisateur dans le contexte d'un profil professionnel.
Lors du provisionnement des identités, le domaine géré par Google de l'organisation est renseigné avec des comptes utilisateur. Dans certains cas, les identités en ligne existantes des utilisateurs (par exemple, leurs comptes Microsoft Exchange) sont synchronisées avec leurs comptes Google.
Synchroniser les comptes client
Dans un déploiement de comptes Google, l'organisation peut utiliser l'outil GCDS pour synchroniser les données de son domaine G Suite avec celles de son annuaire LDAP. Vous pouvez également utiliser GCDS pour effectuer cette opération au nom de l'organisation, si elle vous y autorise.
L'outil GCDS appelle l'API Google Directory et synchronise les noms d'utilisateur, mais pas les mots de passe.
Si l'organisation utilise Microsoft Active Directory et souhaite synchroniser les mots de passe G Suite des utilisateurs avec leurs mots de passe Active Directory, elle (ou vous) peut utiliser l'outil G Suite Password Sync (GSPS) avec GCDS.
Pour obtenir des instructions sur GCDS destinées aux administrateurs, consultez Préparer votre domaine G Suite pour la synchronisation.
API Google Directory
Dans un déploiement de comptes Google, vous pouvez utiliser l'API Google Directory pour synchroniser les annuaires actifs, les mots de passe ou les deux :
Utiliser l'API Directory pour la synchronisation du répertoire uniquement Si vous disposez d'un accès en lecture seule au domaine Google géré de l'organisation, vous pouvez utiliser l'API Google Directory pour obtenir des informations sur les comptes Google, comme les noms d'utilisateur (mais pas les mots de passe) de Google. Étant donné que vous ne pouvez écrire aucune donnée dans les comptes Google des utilisateurs, l'organisation est entièrement responsable des cycles de vie des comptes.
Les scénarios 1 et les scénarios d'authentification unique basée sur SAML décrivent cette situation plus en détail.
Pour savoir comment utiliser l'API Directory de cette manière, consultez Récupérer tous les utilisateurs d'un compte dans la documentation de l'API Directory.
Utilisez l'API Directory pour la synchronisation du répertoire et du mot de passe (facultatif). Si vous disposez d'un accès en lecture et en écriture au domaine Google géré de l'organisation, vous pouvez utiliser l'API Google Directory pour obtenir des noms d'utilisateur, des mots de passe et d'autres informations sur les comptes Google. Vous pouvez mettre à jour ces informations et les synchroniser avec votre propre base de données. Vous pouvez être responsable du cycle de vie des comptes en totalité ou en partie, selon la solution que vous proposez à votre client.
Le Scénario 2 décrit cette situation plus en détail.
Pour en savoir plus sur l'utilisation de l'API Directory pour gérer les informations des comptes utilisateur, consultez le guide du développeur API Directory : comptes utilisateur.
Scénarios de comptes Google
Quelques scénarios typiques de provisionnement d'identité de comptes Google sont décrits dans la section suivante.
Scénario 1 : le client est responsable du cycle de vie des comptes
Dans ce scénario, votre client crée et gère des comptes Google pour ses utilisateurs.
Vous obtenez les informations sur les comptes utilisateur à partir de l'annuaire LDAP de l'organisation et vous les mettez en corrélation avec les données de compte Google que vous obtenez de Google à l'aide de l'API Google Directory.
L'organisation est entièrement responsable du cycle de vie des comptes. Par exemple, lorsqu'un nouveau compte Google est créé, l'organisation ajoute l'utilisateur à son annuaire LDAP. La prochaine fois que vous synchroniserez votre base de données avec l'annuaire LDAP, votre base de données recevra des informations sur ce nouvel utilisateur.
Dans ce cas, on a :
- Vous disposez d'un accès en lecture seule aux comptes Google.
- Votre base de données acquiert les noms de compte Google, mais pas les noms d'utilisateur ni les mots de passe LDAP.
- Vous utilisez l'API Google Directory pour obtenir des informations de base sur les comptes des utilisateurs de votre client. (Les informations dont vous disposez sont les informations non modifiables renvoyées par une requête
Users.get.) Vous utilisez ces informations pour vérifier que les comptes Google des utilisateurs existent afin qu'ils puissent s'authentifier sur leurs appareils. - Votre client utilise l'outil GCDS pour effectuer une synchronisation unidirectionnelle afin de renseigner les comptes Google des utilisateurs. (L'organisation utilise probablement aussi GCDS pour sa propre synchronisation continue une fois le provisionnement des identités terminé.) L'organisation peut également utiliser l'outil GSPS pour synchroniser non seulement les noms d'utilisateur, mais aussi les mots de passe.
Scénario 2 : EMM responsable des cycles de vie des comptes
Dans ce scénario, vous gérez la création de comptes Google pour le compte de votre client et vous êtes responsable du cycle de vie des comptes des utilisateurs.
Par exemple, lorsque les informations utilisateur changent dans le répertoire LDAP de l'organisation, vous êtes responsable de la mise à jour du compte Google de l'utilisateur. GCDS n'est pas utilisé dans ce scénario.
Dans ce cas, on a :
- Vous disposez d'un accès en lecture et en écriture aux comptes Google.
- Votre base de données acquiert les noms de compte Google et les noms d'utilisateur LDAP (ainsi que les hachages de mot de passe, le cas échéant).
- Vous utilisez l'API Google Directory au nom de votre client pour lire et écrire les informations de compte des utilisateurs de l'organisation. (Les informations dont vous disposez sont les informations non modifiables renvoyées par une requête
Users.get.) Vous utilisez ces informations pour vérifier que les comptes Google des utilisateurs existent afin qu'ils puissent s'authentifier sur leurs appareils. - L'outil GCDS n'est pas utilisé.
Scénarios d'authentification unique basée sur SAML
Dans un déploiement de comptes Google, vous ou votre client pouvez utiliser SAML (Security Assertion Markup Language) avec un fournisseur d'identité (IdP) pour authentifier le compte Google associé à chaque utilisateur. Vous utilisez les noms de compte Google pour vérifier que les comptes Google des utilisateurs existent, ce qui est nécessaire pour l'authentification des utilisateurs lorsqu'ils se connectent à leurs appareils. Par exemple, SAML pourrait être utilisé dans le scénario 2. Pour savoir comment configurer cette fonctionnalité, consultez Configurer l'authentification unique (SSO) pour les comptes G Suite.