Implémenter des comptes utilisateur

Il existe deux principaux types d'identité utilisateur pour les inscriptions Android Enterprise : les comptes Google Play gérés et les comptes Google gérés. Les comptes Google Play gérés sont axés sur les appareils, 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éveloppeurs à utiliser le flux d'inscription 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 pour le contexte, tout nouveau développement doit suivre le nouveau processus d'inscription détaillé ici.

Présentation

Le processus d'enregistrement des appareils amélioré simplifie la configuration des appareils en s'appuyant sur 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 exige 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 la stratégie relative aux appareils Android 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 permet de gérer l'installation et les mises à jour nécessaires sur l'appareil. Android Device Policy prend également en charge le flux d'authentification de l'utilisateur, en gérant directement l'authentification de l'utilisateur et en fournissant son identité à l'EMM. Si Google ne parvient pas à authentifier l'utilisateur pour une raison quelconque, un nouveau compte Google Play géré est créé et ajouté à l'appareil en remplacement.

Une partie essentielle de ce nouveau processus 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 crucial pour permettre l'accès une fois que l'appareil est conforme.

Intégration d'API

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

Guide d'implémentation de l'inscription

Ce guide décrit les étapes nécessaires pour implémenter 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 configurer le compte, il est nécessaire de préparer l'environnement de l'appareil. Cette préparation implique la mise à jour du Play Store vers sa dernière version et l'installation silencieuse d'Android Device Policy (com.google.android.apps.work.clouddpc) sur l'appareil. L'installation d'Android Device Policy est essentielle, car elle contient des éléments critiques du processus de configuration du compte. Les EMM n'ont pas besoin de préparer manuellement l'environnement. Ils doivent plutôt utiliser EnvironmentClient, comme indiqué dans la documentation, et respecter les exemples de code fournis.

Exemple de code

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

  • Utilisez EnvironmentClientFactory pour instancier un EnvironmentClient et appeler 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 des 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 l'interface utilisateur appropriée pendant que l'utilisateur attend. Une fois l'opération terminée, l'appareil est prêt à ce que le DPC utilise l'API AccountSetup.

Parcours d'inscription

Les EMM doivent cesser d'utiliser users.generateAuthenticationToken() et users.insert() pour tous les appareils. Les EMM doivent plutôt appeler l'API sur l'appareil pour authentifier l'utilisateur final. La nouvelle API renverra userId et email au DPC. Si Google ne parvient pas à authentifier l'utilisateur, un compte Managed Google Play est 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 QR code ou une configuration Zero-touch).

Toutefois, Google recommande de créer le jeton à la demande et de remplacer l'API existante pour les comptes Google Play gérés 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 de DPC avec les 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 de DPC avec les nouvelles API pour les appareils utilisateur

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

État initial important de l'appareil : lorsque vous enregistrez un appareil avec un DPC personnalisé, le compte Google ajouté à l'appareil est initialement désactivé. Cela signifie que l'accès aux services Google, y compris Google Play, est initialement restreint.

Cet état "désactivé" par défaut et l'obligation 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 : le 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 : le DPC personnalisé appelle l'API startAccountSetup dans le SDK AMAPI, en transmettant le jeton d'enregistrement. Remarque : Le DPC doit être propriétaire de l'appareil ou du profil avant d'appeler cette API.
  4. Lancer l'activité d'authentification Google : si nécessaire, le DPC personnalisé appelle l'API launchAuthenticationActivity dans le SDK AMAPI, en transmettant AccountSetupAttempt. Cette action lance une activité d'authentification Google et renvoie l'utilisateur au DPC personnalisé une fois l'authentification réussie. L'utilisateur peut également ignorer cette étape. 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 le DPC personnalisé du résultat de l'enregistrement.

  6. Activer les services Google : une fois que le DPC personnalisé a entièrement provisionné l'appareil et confirmé qu'il respecte 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 indique que l'appareil est 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 qui nécessitent l'authentification du compte.

Gérer l'état de l'appareil et l'accès au service

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. Plusieurs raisons sont possibles :

  • L'EMM n'a jamais appelé Devices.setState("enabled") après l'enregistrement initial de l'appareil.
  • L'appareil ne respecte plus les 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 "disabled". Cela peut être dû à des problèmes de sécurité, à des actions administratives ou à d'autres raisons.

Cette intention inclut un code d'état, tel que "ThirdPartyDeviceManagementRequired".

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

Lorsqu'il reçoit cette diffusion, le DPC doit :

  1. Réévaluer la conformité : vérifiez si l'appareil respecte actuellement toutes les règles définies par l'EMM.
  2. Action requise :
    • Si l'appareil est conforme : le DPC doit en informer le serveur EMM. Le serveur EMM doit ensuite appeler Devices.setState() avec accountState défini sur "enabled" pour l'ID utilisateur et l'ID de l'appareil spécifiques afin de tenter de restaurer 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 le 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 prise de contrôle d'une entreprise

Le type de compte de l'organisation peut changer (par exemple, de ManagedGoogleDomainType.TYPE_TEAM à ManagedGoogleDomainType.TYPE_DOMAIN). Bien que ce processus ne rompe généralement pas l'association 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 piratage 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 backend de Google dans la nouvelle structure client. Les appels proactifs pour tous les appareils après une prise de contrôle ne sont généralement pas nécessaires, mais ils constituent un outil clé pour résoudre les problèmes d'accès.

Configuration du compte : exemple de code

  1. Pour tenter de configurer un 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 l'interface AccountSetupListener et fournissez une implémentation pour gérer les mises à jour d'état reçues.

  3. Étendez NotificationReceiverService et fournissez l'instance AccountSetupListener 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 "queries" est nécessaire dans le AndroidManifest.xml pour spécifier qu'elle interagira avec ADP.

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

Conseils pour les tests

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

Tester les 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 la règle Android Device Policy n'est pas installée, un résultat vide est attendu.

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

  3. Attente du résultat PrepareEnvironment : le DPC personnalisé attend la fin de l'opération 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 associée à un EMM de test, avec enterprises.generateSignupUrl.
  2. Activez 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 : le DPC personnalisé appelle l'API startAccountSetup dans le SDK AMAPI, en transmettant le jeton d'enregistrement.
  5. Activité de lancement requise : le SDK AMAPI informe le DPC personnalisé qu'une activité doit être lancée pour authentifier l'utilisateur.
  6. Authentifiez l'utilisateur : le 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 le DPC personnalisé du résultat de l'enregistrement.

Tester l'ignorance de l'authentification Google

Nous allons utiliser 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 s'effectue 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 de DPC personnalisé amélioré utilise les étapes suivantes lorsque l'authentification Google est désactivée :

  1. Créez 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 : le DPC personnalisé appelle l'API startAccountSetup dans le SDK AMAPI, en transmettant le jeton d'enregistrement.
  4. Finaliser l'enregistrement : le SDK AMAPI informe le DPC personnalisé du résultat de l'enregistrement.