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 d'entreprise 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 uniquement à Google Play d'entreprise 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 qui sont 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 de la préparation de l'appareil.
Les comptes Google Play d'entreprise permettent aux entreprises de créer automatiquement des comptes utilisateur en accès limité par le biais de leur fournisseur de solution EMM (gestion de la mobilité en entreprise). 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 avec laquelle vous gérez la synchronisation des comptes de domaine gérés par Google vers 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 utiliser des 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 d'entreprise 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 permettent aux utilisateurs d'accéder à la suite complète des services Google et des fonctionnalités inter-appareils.
Améliorations apportées à 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 inter-appareils, telles que 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.
Nous recommandons vivement 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 cela que pour leur EMM.
Nous avons apporté les modifications suivantes :
L'authentification de l'utilisateur final lors de l'enregistrement d'un 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 approprié, 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 QR code, 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. Cette cartographie est essentielle pour appliquer les règles appropriées à l'appareil. Les entreprises doivent donc continuer à associer le répertoire d'utilisateurs de leur organisation à leur 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 inter-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 d'entreprise 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'inscription 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. Cela supprime la nécessité de comptes Google Play d'entreprise.
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'enregistrement, 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 de la solution 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 compte de domaine Google à l'aide d'outils tels que Google Cloud Directory Sync (GCDS) et l'API Directory du SDK Admin. Pour obtenir une vue d'ensemble des différentes approches, consultez la page. 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 Google géré 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 Google Workspace 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 Google Workspace des utilisateurs avec leurs mots de passe Active Directory, consultez Se préparer à utiliser Password Sync.
Pour obtenir des instructions sur GCDS destinées aux administrateurs, consultez À propos de Google Cloud Directory Sync.
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 d'annuaire 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 du cycle de vie des comptes.
Le scénario 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.
Utiliser l'API Directory pour la synchronisation de l'annuaire 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 entièrement ou partiellement responsable des cycles de vie des comptes, 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 l'annuaire 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 l'authentification unique, consultez À propos de l'authentification unique.