Implémenter des comptes utilisateur

Il existe deux types principaux d'identité utilisateur pour les enregistrements Android Enterprise : les comptes Google Play d'entreprise et les comptes Google gérés. Les comptes Google Play d'entreprise sont axés sur l'appareil, ce qui signifie qu'ils ne sont pas liés à l'identité Google d'un utilisateur spécifique. En revanche, les comptes Google gérés sont associés à l'identité Google professionnelle d'un utilisateur, ce qui améliore l'expérience utilisateur en le maintenant connecté sur ses appareils.

Les comptes Google Play d'entreprise étaient la norme. Toutefois, Google encourage désormais tous les nouveaux développements à utiliser le flux d'enregistrement amélioré, qui crée par défaut des comptes Google gérés.

Bien que des conseils pour l'ancienne implémentation soient fournis à la fin de ce document à titre d'information, tous les nouveaux développements doivent suivre le nouveau flux d'enregistrement décrit ici.

Présentation

Le flux d'enregistrement d'appareils amélioré simplifie la configuration des appareils en tirant parti de plusieurs nouveaux composants et en modifiant la façon dont les outils de contrôle des règles relatives aux appareils (DPC) personnalisés sont implémentés. Cette nouvelle approche nécessite que les solutions DPC personnalisées s'intègrent au SDK de l'API Android Management (AMAPI) et à Android Device Policy pour effectuer les fonctions de préparation des appareils et d'enregistrement des utilisateurs.

Le SDK AMAPI fournit les API nécessaires pour interagir avec Android Device Policy sur l'appareil lui-même. Côté serveur, les solutions de gestion de la mobilité en entreprise (EMM) utiliseront l'API Play EMM pour générer les jetons d'enregistrement requis pour lancer le processus d'enregistrement des appareils.

L'application Android Device Policy joue désormais un rôle central dans la gestion des opérations côté appareil. Le SDK AMAPI est utilisé pour gérer son installation et les mises à jour nécessaires sur l'appareil. Android Device Policy prend également en charge le flux d'authentification des utilisateurs, en gérant directement l'authentification des utilisateurs et en fournissant l'identité de l'utilisateur à l'EMM. Si Google ne parvient pas à authentifier l'utilisateur pour quelque raison que ce soit, un nouveau compte Google Play d'entreprise est créé et ajouté à l'appareil en remplacement.

Un élément clé de ce nouveau flux d'enregistrement consiste à gérer l'accès de l'appareil aux services Google. Par défaut, les appareils démarrent dans un état restreint, et l'EMM joue un rôle essentiel dans l'activation de l'accès une fois l'appareil conforme.

Intégration d'API

Avant de commencer, vérifiez que vous utilisez la dernière version du client API Play EMM et du SDK AMAPI.

Guide d'implémentation de l'enregistrement

Ce guide fournit les étapes nécessaires à l'implémentation de l'enregistrement. Il couvre la préparation de l'environnement, la gestion des différentes méthodes d'enregistrement et la gestion du cycle de vie des appareils.

Préparer l'environnement

Avant de lancer la configuration du compte, il est nécessaire de préparer l'environnement de l'appareil. Cette préparation implique de mettre à jour le Play Store vers sa dernière version et d'installer en mode silencieux Android Device Policy (com.google.android.apps.work.clouddpc) sur l'appareil. L'installation d'Android Device Policy est essentielle, car elle héberge des composants essentiels du processus de configuration du compte. Les EMM n'ont pas besoin d'effectuer une préparation manuelle de l'environnement. Au lieu de cela, ils doivent utiliser le EnvironmentClient, comme indiqué dans et respecter les exemples de code fournis.

Exemple de code

Avant de pouvoir utiliser l' AccountSetup pour ajouter le compte professionnel sur l'appareil, l'outil DPC doit d'abord vérifier que l' environnement de l'appareil est prêt.

  • Utilisez EnvironmentClientFactory pour instancier un EnvironmentClient et appelez prepareEnvironment ou prepareEnvironmentAsync

    val notificationReceiverServiceName = ComponentName(context,
NotificationReceiver::class.java)

// An EMM should implement android.app.admin.DeviceAdminReceiver and use that
// class to instantiate a ComponentName

val admin = ComponentName(this, com.example.dpc.DeviceAdminReceiver::class.java)

EnvironmentClientFactory.create(context)
    .prepareEnvironment(
        PrepareEnvironmentRequest.builder()
            .setRoles(
                listOf(
                    Role.builder().setRoleType(
                        Role.RoleType.DEVICE_POLICY_CONTROLLER
                    ).build()
                )
            )
    .setAdmin(admin)
            .build(),
          notificationReceiverServiceName,
        )

[Proceed with AccountSetup]

Cette opération peut prendre plusieurs secondes ou minutes, car les applications peuvent être installées ou mises à jour pour vérifier que l'environnement de travail est correct. Google recommande de démarrer ce processus le plus tôt possible en arrière-plan et d'afficher une interface utilisateur appropriée pendant que l'utilisateur attend. Une fois l'opération terminée, l'appareil est prêt à ce que l'outil DPC utilise l'API AccountSetup.

Flux d'enregistrement

Les EMM doivent cesser d'utiliser users.generateAuthenticationToken() et users.insert() pour tous les appareils. Au lieu de cela, les EMM doivent appeler l'API sur l'appareil pour effectuer l'authentification de l'utilisateur final. La nouvelle API renverra le userId et l'email à l'outil DPC. Si Google ne parvient pas à authentifier l'utilisateur, un compte Google Play d'entreprise sera créé et ajouté à l'appareil. Dans ce cas, Google renverra le userId de ce compte.

Google introduit désormais l'utilisation de jetons d'enregistrement, qui doivent être transmis à l'API d'authentification. Les EMM déterminent quand et comment créer le jeton, qui peut faire partie d'une charge utile d'enregistrement existante (par exemple, un code QR ou une configuration sans contact).

Exemption pour les jetons d'enregistrement existants

Certains clients utilisent des jetons d'enregistrement avec de longues dates d'expiration pour effectuer des enregistrements répétés. Pour s'assurer que ces workflows existants ne sont pas interrompus, tous les jetons créés AVANT l'activation de l'exigence "S'authentifier avec Google" sont exemptés des nouvelles invites de connexion. Ces anciens jetons continueront de fonctionner comme avant, ce qui permettra aux utilisateurs d'enregistrer des appareils sans passer par le processus d'authentification Google. Toutefois, tous les jetons créés APRÈS l'activation de l'exigence d'authentification Google suivront les nouvelles règles d'authentification. Cela signifie que les appareils utilisant ces jetons plus récents devront authentifier les utilisateurs en fonction des paramètres choisis par l'administrateur informatique.

Google recommande de créer le jeton à la demande et de remplacer l'API existante pour les comptes Google Play d'entreprise par la nouvelle API afin de minimiser le changement.

Intégration DPC typique avec les API précédentes
Figure 1. Intégration DPC typique avec les API précédentes
Exemple d'intégration d'un DPC avec les nouvelles API pour les appareils sans utilisateur
Figure 2. Exemple d'intégration DPC avec de nouvelles API pour les appareils sans utilisateur
Exemple d'intégration de DPC avec de nouvelles API pour les appareils utilisateur
Figure 3. Exemple d'intégration DPC avec de nouvelles API pour les appareils utilisateur

Le flux d'enregistrement DPC personnalisé amélioré comprend les étapes suivantes :

État initial important de l'appareil : lors de l'enregistrement d'un appareil avec un outil DPC personnalisé, le compte Google ajouté à l'appareil commence dans un état désactivé. Cela signifie que l'accès aux services Google, y compris Google Play, est initialement limité.

Cet état "désactivé" par défaut et l'exigence ultérieure pour l'EMM de marquer l'appareil comme conforme (par exemple, en appelant Devices.SetState) s'appliquent spécifiquement dans les conditions suivantes :

  1. L'organisation a validé la propriété de son domaine auprès de Google.
  2. L'administrateur informatique a explicitement activé la gestion des appareils mobiles Android tiers pour l'unité organisationnelle (UO) spécifique de l'utilisateur dans la console d'administration Google.
  1. Créer un jeton d'enregistrement : l'EMM crée un jeton d'enregistrement à l'aide de l'API Play EMM.
  2. Préparer l'environnement : l'outil DPC personnalisé utilise le flux de préparation de l'environnement pour vérifier que l'appareil est prêt à être enregistré.
  3. Lancer l'enregistrement : l'outil DPC personnalisé appelle l'startAccountSetup API dans le SDK AMAPI, en transmettant le jeton d'enregistrement. Remarque : L'outil DPC doit être le propriétaire de l'appareil ou du profil avant d'appeler cette API.
  4. Lancer l'activité d'authentification Google : si nécessaire, l'outil DPC personnalisé appelle l'API launchAuthenticationActivity dans le SDK AMAPI, en transmettant AccountSetupAttempt. Cela lance une activité d'authentification Google, qui renvoie l'utilisateur à l'outil DPC personnalisé une fois l'authentification réussie. L'utilisateur peut également ignorer ce processus. Dans ce cas, un compte Google Play d'entreprise sera ajouté à l'appareil. Cette option peut être configurée à l'aide de googleAuthenticationOptions.
  5. Finaliser l'enregistrement : le SDK AMAPI informe l'outil DPC personnalisé du résultat de l'enregistrement.
  6. Activer les services Google : une fois que l'outil DPC personnalisé a entièrement provisionné l' appareil et confirmé qu'il est conforme à toutes les règles de l'entreprise, le serveur EMM doit appeler Devices.setState() avec le paramètre accountState défini sur "enabled".
  • Pourquoi est-ce essentiel ? Cet appel d'API marque l'appareil comme conforme.
  • Conséquence de l'absence d'appel : sans cet appel Devices.setState(setStateRequest), le compte reste à l'état "désactivé". L'utilisateur ne pourra pas accéder à Google Play (pour installer ou mettre à jour des applications) ni à d'autres services Google nécessitant l'authentification du compte.

Gérer l'état des appareils et l'accès aux services

Après l'enregistrement initial, l'EMM est responsable du maintien de l'accès de l'appareil aux services Google en fonction de son état de conformité.

Gérer les interruptions de service : BAD_DEVICE_MANAGEMENT

Si l'accès d'un appareil aux services Google est bloqué, les services Google Play (GMSCore) diffuseront un intent avec l'action : com.google.android.gms.auth.BAD_DEVICE_MANAGEMENT. Cela peut se produire pour plusieurs raisons :

  • L'EMM n'a jamais appelé Devices.setState("enabled") après l'enregistrement initial de l'appareil.
  • L'appareil n'est plus conforme aux règles EMM, et l'EMM ne l'a pas encore réactivé.
  • L'EMM a explicitement défini l'état de l'appareil sur "désactivé" en appelant Devices.setState() avec accountState défini sur "désactivé". Cela peut être dû à des problèmes de sécurité, à des actions administratives ou à d'autres raisons.

Cet intent inclut un code d'état, tel que "ThirdPartyDeviceManagementRequired".

Les outils DPC personnalisés DOIVENT implémenter un BroadcastReceiver pour écouter cet intent BAD_DEVICE_MANAGEMENT.

Lors de la réception de cette diffusion, l'outil DPC doit effectuer les opérations suivantes :

  1. Réévaluer la conformité : vérifiez si l'appareil respecte toutes les règles définies par l'EMM.
  2. Agir :
    • Si l'appareil est conforme : l'outil DPC doit notifier le serveur EMM. Le serveur EMM doit ensuite appeler Devices.setState() avec accountState défini sur "enabled" pour l'ID utilisateur et l'ID d'appareil spécifiques afin de tenter de rétablir l'accès au service.
    • Si l'appareil n'est pas conforme : une fois les problèmes résolus et l'appareil conforme, l'EMM doit appeler Devices.setState().

Ce mécanisme permet de détecter et de résoudre les situations dans lesquelles un appareil perd l'accès aux services Google.

Points à prendre en compte concernant la reprise d'entreprise

Des modifications du type de compte de l'organisation (par exemple, de ManagedGoogleDomainType.TYPE_TEAM à ManagedGoogleDomainType.TYPE_DOMAIN) peuvent se produire. Bien que ce processus ne rompe généralement pas la liaison EMM, il peut parfois perturber l'accès aux services Google sur les appareils.

Les EMM doivent savoir que si les utilisateurs signalent des problèmes d'accès aux services après un événement de reprise connu, même si l'appareil semble conforme aux règles EMM, un appel à Devices.setState() peut être nécessaire pour resynchroniser l'état de l'appareil avec les backends de Google sous la nouvelle structure client. Les appels proactifs pour tous les appareils après la reprise ne sont généralement pas nécessaires, mais il s'agit d'un outil clé pour résoudre les problèmes d'accès.

Configuration du compte – exemple de code

  1. Pour lancer une tentative de configuration de compte, l'application appelante peut utiliser AccountSetupClient et appeler la méthode startAccountSetup() ou startAccountSetupFuture(). Pour obtenir un exemple d'implémentation, consultez l'exemple de code suivant :

    // Create AccountSetupClient
val client = AccountSetupClientFactory.create(
    this,
    activityResultRegistry
)
lifecycle.addObserver(client.lifecycleObserver)

// Create adminComponent
val notificationReceiver = ComponentName(this, AccountSetupNotificationReceiver::class.java)
// Helper method to get enrollment token created with Play EMM API
val enrollmentToken = getEnrollmentToken()
val request =
    StartAccountSetupRequest.builder()
        .setEnrollmentToken(enteredText)
        .setNotificationReceiverServiceComponentName(notificationReceiver)
        .setAdminComponentName(
            ComponentName(this, com.example.dpc.DeviceAdminReceiver::class.java))
        .build()
try {
    val accountSetupAttempt = client.startAccountSetup(request)
    // handle attempt
} catch (e: Exception) {
    // handle exception
}

  2. Implémentez AccountSetupListener interface et fournissez une implémentation pour gérer les mises à jour d'état reçues.

  3. Étendez NotificationReceiverService et fournissez l' AccountSetupListener instance créée à l'étape 2 en remplaçant getAccountSetupListener().

    // Handles account setup changes
class AccountSetupNotificationReceiver :
      NotificationReceiverService(),
      AccountSetupListener {

    override fun getAccountSetupListener(): AccountSetupListener = this

    override fun onAccountSetupChanged(accountSetupAttempt:
  AccountSetupAttempt) {

        when (accountSetupAttempt.state.kind) {
            StateCase.ADDED_ACCOUNT -> {
                val enterpriseAccount = state.addedAccount()
                val userId = enterpriseAccount.userId
                val deviceId = enterpriseAccount.deviceId
                // Handle account added state.

                // IMPORTANT: The device/account is now added but *DISABLED*
                // for Google services. Your EMM backend MUST be notified to
                // perform policy compliance checks and then call Devices.setState()
                // to activate Google Play and other services.

            }
            StateCase.AUTHENTICATION_ACTIVITY_LAUNCH_REQUIRED -> {
                val request = LaunchAuthenticationActivityRequest.builder()
            .setAccountSetupAttempt(accountSetupAttempt)
            .build();
                // Send the attempt to the foreground activity to call:
                accountSetupClient.launchAuthenticationActivity(request)
            }
            StateCase.ACCOUNT_SETUP_ERROR -> {
                // Handle error state.
                val failureReason = state.accountSetupError().failureReason
            }
            else -> {
                // Handle unknown account setup attempt state.
            }
        }
    }
}

  4. Ajoutez la classe étendue NotificationReceiverService à votre AndroidManifest.xml et vérifiez qu'elle est exportée.

      <application>
    <service
        android:name = ".accountsetup.AccountSetupNotificationReceiver"
        android:exported = "true" />
  </application>

    Si votre application cible le SDK 30 ou une version ultérieure, un élément de requêtes est nécessaire dans AndroidManifest.xml pour spécifier qu'il interagira avec ADP.

      <queries>
    <package android:name="com.google.android.apps.work.clouddpc" />
  </queries>

Conseils de test

Cette section fournit un ensemble de consignes et de bonnes pratiques pour tester votre implémentation.

Tester PrepareEnvironment

  1. Obtenir l'état actuel de l'appareil : l'EMM exécute

    adb shell dumpsys package com.google.android.apps.work.clouddpc | grep versionName

    pour obtenir la version d'Android Device Policy présente sur l'appareil. Si Android Device Policy n'est pas installé, une sortie vide est attendue.

  2. Intégrer PrepareEnvironment : l'outil DPC personnalisé appelle l'API prepareEnvironment dans le SDK AMAPI, en transmettant la requête appropriée.

  3. Attendre le résultat de PrepareEnvironment : l'outil DPC personnalisé attend la fin de prepareEnvironment.

  4. Confirmer la réussite de PrepareEnvironment : une fois l'opération terminée, l'EMM s'exécute à nouveau

    adb shell dumpsys package com.google.android.apps.work.clouddpc | grep versionName

    Cette fois, la version d'Android Device Policy doit être supérieure à celle de l'étape 1.

Tester l'authentification du compte Google

  1. Créer une entreprise de test : l'EMM crée une entreprise Google de domaine de test liée à un EMM de test, avec enterprises.generateSignupUrl.
  2. Activer l'authentification Google : l'EMM active l'authentification Google pour l'entreprise de test en suivant ces instructions dans la console d'administration Google.
  3. Créer un jeton d'enregistrement : l'EMM crée un jeton d'enregistrement à l'aide de l'API Play EMM avec le type userDevice.
  4. Lancer l'enregistrement : l'outil DPC personnalisé appelle l'startAccountSetup API dans le SDK AMAPI, en transmettant le jeton d'enregistrement.
  5. Activité requise : le SDK AMAPI informe l'outil DPC personnalisé qu'une activité doit être lancée pour authentifier l'utilisateur.
  6. Authentifier l'utilisateur : l'outil DPC personnalisé appelle launchAuthenticationActivity pour démarrer l'activité. L'utilisateur s'authentifie avec un compte Google géré (qui fait partie de l'entreprise créée à l'étape 1).
  7. Finaliser l'enregistrement : le SDK AMAPI informe l'outil DPC personnalisé du résultat de l'enregistrement.

Tester l'omission de l'authentification Google

Nous utiliserons la configuration décrite précédemment.

Cette fois, à l'étape 7, l'utilisateur appuie sur Ignorer au lieu de s'authentifier avec son compte Google. L'enregistrement se termine correctement, avec un compte de service sur l'appareil (c'est-à-dire que AuthenticationType est anonyme).

Tester les appareils sans utilisateur

Le flux d'enregistrement DPC personnalisé amélioré comprend les étapes suivantes lorsque l'authentification Google est désactivée :

  1. Créer une entreprise de test : il peut s'agir de la même entreprise que celle créée précédemment.
  2. Créer un jeton d'enregistrement : l'EMM crée un jeton d'enregistrement à l'aide de l'API Play EMM avec le type userlessDevice.
  3. Lancer l'enregistrement : l'outil DPC personnalisé appelle l'startAccountSetup API dans le SDK AMAPI, en transmettant le jeton d'enregistrement.
  4. Finaliser l'enregistrement : le SDK AMAPI informe l'outil DPC personnalisé du résultat de l'enregistrement.