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 flux d'inscription détaillé ici.

Présentation

Le flux 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 nécessite des solutions DPC personnalisées pour s'intégrer au SDK de l'API Android Management (AMAPI) et à Android Device Policy afin d'effectuer des 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 Enterprise Mobility Management (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, gérant directement l'authentification de l'utilisateur et 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.

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'inscription. 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 en arrière-plan le plus tôt possible 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.

Processus 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 code QR 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 d'un 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 DPC avec les nouvelles API pour les appareils utilisateur

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

  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 procédure. 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 l'appareil d'un utilisateur avec le compte Google géré est conforme aux règles de l'entreprise, l'EMM doit appeler Devices.setState(). Cette action permet au compte d'accéder aux services Google sur l'appareil. Sans cet appel, le Play Store et d'autres services Google ne fonctionneront pas.

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.

            }
            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.

Test 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. Attendez le résultat de PrepareEnvironment : le 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 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'authentification Google ignorée

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.