sdk d’application Intune pour Android - Fonctionnalités de participation d’application

Le SDK d’application Microsoft Intune pour Android vous permet d’incorporer des stratégies de protection des applications Intune (également appelées stratégies GAM) dans votre application Android Java/Kotlin native. Une application gérée par Intune s’intègre au KIT de développement logiciel (SDK) Intune App. Intune administrateurs peuvent facilement déployer des stratégies de protection des applications sur votre application gérée par Intune lorsque Intune gère activement l’application.

Étape 7 : Fonctionnalités de participation aux applications

Objectifs de la phase

• Découvrez les fonctionnalités de participation d’application offertes par le SDK d’application Intune.
• Intégrez les fonctionnalités de participation d’application pertinentes pour votre application et vos utilisateurs.
• Testez l’intégration de ces fonctionnalités.

Que sont les « fonctionnalités de participation d’application » ?

Ce processus d’intégration du Kit de développement logiciel (SDK) tente de réduire la quantité de code spécifique à l’application que les développeurs doivent écrire. En effectuant correctement les étapes précédentes de l’intégration du SDK, votre application applique désormais la plupart des paramètres de stratégie de protection des applications, tels que le chiffrement des fichiers, les restrictions de copie/collage, le blocage de capture d’écran et les restrictions de transfert de données.

Toutefois, certains paramètres nécessitent que le code spécifique à l’application s’applique correctement ; ces paramètres sont appelés fonctionnalités de participation d’application. En règle générale, le KIT de développement logiciel (SDK) n’a pas suffisamment de contexte sur le code de votre application ou le scénario de l’utilisateur final pour appliquer automatiquement ces paramètres, et s’appuie donc sur les développeurs pour appeler les API du KIT de développement logiciel (SDK) de manière appropriée.

Les fonctionnalités de participation aux applications ne sont pas nécessairement facultatives. Selon les fonctionnalités existantes de votre application, ces fonctionnalités peuvent être nécessaires. Pour plus d’informations, consultez Décisions clés pour l’intégration du KIT de développement logiciel (SDK ).

Les étapes précédentes de ce guide décrivent déjà plusieurs fonctionnalités de participation d’application :

• Multi-identité, comme décrit à l’étape 5 : Identités multiples.
• Configuration de l’application comme décrit dans l’étape 6 : App Configuration.

Le reste de ce guide décrit l’ensemble restant des fonctionnalités de participation aux applications :

• Appliquez une stratégie limitant l’enregistrement des fichiers dans ou l’ouverture de fichiers à partir d’un stockage local ou cloud.
• Appliquer une stratégie limitant le contenu dans les notifications.
• Appliquez la stratégie protégeant les données de sauvegarde.
• Appliquer une stratégie limitant la capture d’écran (si votre application dispose d’un code de capture d’écran personnalisé).
• Prise en charge de l’autorité de certification App Protection.
• Inscrivez-vous aux notifications à partir du Kit de développement logiciel (SDK).
• Appliquer des thèmes d’application personnalisés.
• Utilisez des certificats approuvés provenant de Intune, ce qui garantit la chaîne de confiance aux points de terminaison locaux.

Concepts de base de la fonctionnalité de participation d’application

L’interface AppPolicy contient de nombreuses méthodes qui informent votre application si certaines actions sont autorisées.

La plupart des fonctionnalités de participation aux applications impliquent :

• L’identification de l’emplacement approprié dans le code de l’application pour case activée si une action est autorisée.
• L’appel d’une AppPolicy méthode à case activée si une action est autorisée, en fonction de la stratégie actuellement configurée.
• Selon le résultat, autorisez l’action à se terminer ou modifiez le comportement de l’application lorsque l’action est bloquée.

Pour récupérer un AppPolicy instance, utilisez l’une des méthodes MAMPolicyManager, telles que getPolicy(final Context context) ou getPolicyForIdentityOID(final String oid).

Méthodes d’information dans AppPolicy

Toutes les méthodes dans AppPolicy ne sont pas liées à une fonctionnalité de participation d’application. Certaines méthodes sont informatives et fournissent à votre application des données sur les stratégies actuellement configurées, même si ces stratégies sont automatiquement appliquées par le SDK. Ces méthodes permettent à votre application de présenter des expériences utilisateur personnalisées lorsque des stratégies spécifiques sont configurées.

Exemple : Déterminer si les captures d’écran sont bloquées

Si l’application dispose d’un contrôle qui permet à l’utilisateur de prendre une capture d’écran, envisagez de désactiver ou de masquer ce contrôle si la stratégie de protection des applications bloque les captures d’écran.

L’application peut case activée en appelant MAMPolicyManager.getPolicy(currentActivity).getIsScreenCaptureAllowed().

Stratégie de limitation du transfert de données entre les applications et les emplacements de stockage des appareils ou du cloud

De nombreuses applications permettent à l’utilisateur final d’enregistrer ou d’ouvrir des données à partir du stockage de fichiers local ou des services de stockage cloud. Le Kit de développement logiciel (SDK) d’application Intune permet aux administrateurs informatiques de se protéger contre l’entrée et la fuite de données en limitant l’emplacement où les applications peuvent enregistrer les données et les ouvrir.

Enregistrement sur un appareil ou un stockage cloud

L’API getIsSaveToLocationAllowedForOID permet à l’application de savoir si l’enregistrement dans certains emplacements est autorisé pour une identité donnée, en fonction de la stratégie configurée :

MAMPolicyManager.getPolicy(currentActivity).getIsSaveToLocationAllowedForOID(
SaveLocation service, String oid);

Pour déterminer si l’application doit implémenter le getIsSaveToLocationAllowedForOID case activée, déterminez si l’application prend en charge la sortie des données en consultant le tableau suivant :

Les fichiers placés dans un stockage d’application privé qui sont nécessaires au fonctionnement de l’application ou téléchargés temporairement pour l’affichage sont toujours autorisés . il n’est pas nécessaire d’case activée getIsSaveToLocationAllowedForOID. Ne case activée SaveLocation.LOCAL pour

1. Fichiers enregistrés en dehors du stockage d’application privé.
2. Fichiers téléchargés dans un stockage d’application privé qui ne sont pas nécessaires au fonctionnement de l’application (par exemple, lorsque l’utilisateur choisit explicitement de télécharger sur l’appareil).

Ouverture de données à partir d’un emplacement de stockage local ou cloud

L’API getIsOpenFromLocationAllowedForOID indique à l’application si l’ouverture à partir de certains emplacements est autorisée pour une identité donnée, en fonction de la stratégie configurée :

MAMPolicyManager.getPolicy(currentActivity).getIsOpenFromLocationAllowedForOID(
OpenLocation location, String oid);

Pour déterminer si l’application doit implémenter le getIsOpenFromLocationAllowedForOID case activée, déterminez si l’application prend en charge l’entrée des données en consultant le tableau suivant :

Boîte de dialogue bloquée de partage

Le Kit de développement logiciel (SDK) fournit une boîte de dialogue pour avertir l’utilisateur lorsque la stratégie GAM bloque une action de transfert de données.

La boîte de dialogue doit être affichée à l’utilisateur chaque fois que l’appel getIsSaveToLocationAllowedForOID d’API ou entraîne getIsOpenFromLocationAllowedForOID le blocage de l’action d’enregistrement/d’ouverture. La boîte de dialogue affiche un message générique et retourne à l’appel Activity lorsqu’il est ignoré.

Pour afficher la boîte de dialogue, ajoutez le code suivant :

MAMUIHelper.showSharingBlockedDialog(currentActivity)

Autoriser le partage de fichiers

Si l’enregistrement dans des emplacements de stockage publics n’est pas autorisé, votre application doit toujours permettre à l’utilisateur d’afficher les fichiers en les téléchargeant dans le stockage privé de l’application , puis en les ouvrant avec le sélecteur système.

Stratégie de restriction du contenu dans les notifications

Pour les applications à identité unique, le comportement par défaut du SDK d’application Intune tente de bloquer toutes les notifications lorsque la stratégie de protection des applications restreint les notifications.

Le comportement par défaut du KIT de développement logiciel (SDK) est limité. Le Kit de développement logiciel (SDK) ne peut pas respecter automatiquement la valeur « Bloquer les données d’organisation », qui est destinée à supprimer uniquement le contenu managé des notifications. Pour les applications à plusieurs identités, le SDK ne peut pas déterminer quelles notifications contiennent du contenu managé.

Si votre application affiche des notifications et qu’elle est multi-identité et/ou qu’elle doit respecter la valeur « Bloquer les données de l’organisation », elle doit case activée la stratégie de restriction de notification pour le compte associé à la notification avant d’afficher la notification.

Pour déterminer si la stratégie est appliquée, effectuez l’appel suivant :

NotificationRestriction notificationRestriction =
    MAMPolicyManager.getPolicyForIdentityOID(notificationIdentityOid).getNotificationRestriction();

L’énumération retournée NotificationRestriction a les valeurs suivantes :

Si votre application n’appelle getNotificationRestrictionpas correctement , le Kit de développement logiciel (SDK) MAM fait le meilleur effort pour restreindre automatiquement les notifications pour les applications à identité unique uniquement.

Dans ce cas, BLOCK_ORG_DATA est traité de la même façon que BLOCKED et la notification n’est pas affichée du tout.

Pour un contrôle plus précis, case activée la valeur des notifications d’application getNotificationRestriction et les modifier de manière appropriée.

Stratégie de protection des données de sauvegarde

Le SDK d’application Intune peut bloquer le chargement des données vers la fonctionnalité de sauvegarde et de restauration intégrée d’Android. Pour plus d’informations sur la sauvegarde et la restauration dans Android, consultez le guide de l’API Android et les modifications introduites dans Android S/12 dans Modifier la sauvegarde et la restauration.

Sauvegarde automatique pour les applications

À compter d’Android M, Android fournit des sauvegardes complètes automatiques sur Google Drive pour les applications, quelle que soit l’API cible de l’application.

Intune vous permet d’utiliser toutes les fonctionnalités de sauvegarde automatique fournies par Android, y compris la possibilité de définir des règles personnalisées en XML, avec des instructions d’intégration de Intune spécifiques pour garantir l’application de la protection des données.

Configuration du comportement de sauvegarde dans le manifeste de l’application

Par défaut, android:allowBackup est défini sur true comme indiqué dans Activer et désactiver la sauvegarde.

Si l’application ne nécessite pas de fonctionnalité complète de sauvegarde et de restauration, définissez sur android:allowBackupfalse. Dans ce cas, aucune autre action n’est nécessaire et les données d’entreprise restent dans l’application.

Si votre application nécessite des fonctionnalités de sauvegarde et de restauration complètes, définissez android:allowBackup sur true et effectuez les étapes suivantes :

1. Si votre application n’utilise pas son propre personnalisé BackupAgent, utilisez le MAMBackupAgent par défaut pour activer les sauvegardes complètes automatiques qui sont Intune conformes à la stratégie. Placez les éléments suivants dans le manifeste de l’application :

   <application
   ...
     android:fullBackupOnly="true"
     android:backupAgent="com.microsoft.intune.mam.client.app.backup.MAMDefaultBackupAgent"
     ...>
     </application>
   

2. Facultatif. Si vous implémentez un personnalisé BackupAgent, vous devez utiliser MAMBackupAgent ou MAMBackupAgentHelper. Consultez les sections suivantes. Envisagez de passer au MAMDefaultBackupAgent de Intune, décrit à l’étape 1, qui fournit une sauvegarde facile sur Android M et versions ultérieures.

3. Lorsque vous décidez du type de sauvegarde complète que votre application doit recevoir (non filtrée, filtrée ou aucune), définissez l’attribut android:fullBackupContenttruesur , falseou une ressource XML dans votre application.

4. Ensuite, vous devez copier la valeur de android:fullBackupContent dans la com.microsoft.intune.mam.FullBackupContent balise de métadonnées et, pour les applications qui prennent en charge le format de configuration XML ajouté dans API 31, dans la com.microsoft.intune.mam.DataExtractionRules balise de métadonnées.

   • Exemple 1 : Si vous souhaitez que votre application dispose de sauvegardes complètes sans exclusions, vous devez définir les attributs et les balises de métadonnées sur true :

     <application
       ...
       android:fullBackupContent="true"
       ...>
     </application>
     ...
     <meta-data android:name="com.microsoft.intune.mam.FullBackupContent" android:value="true" />
     <meta-data android:name="com.microsoft.intune.mam.DataExtractionRules" android:value="true" />
     

   • Exemple 2 : Si vous souhaitez que votre application utilise sa version personnalisée BackupAgent et refuse les sauvegardes automatiques complètes, Intune conformes à la stratégie, vous devez définir les attributs et les balises de métadonnées sur false :

     <application
       ...
       android:fullBackupContent="false"
       ...>
     </application>
     ...
     <meta-data android:name="com.microsoft.intune.mam.FullBackupContent" android:value="false" />
     <meta-data android:name="com.microsoft.intune.mam.DataExtractionRules" android:value="false" />
     

   • Exemple 3 : Si vous souhaitez que votre application dispose de sauvegardes complètes conformément à vos règles personnalisées définies dans un fichier XML, définissez l’attribut et la balise de métadonnées sur la même ressource XML :

     <application
       ...
       android:fullBackupContent="@xml/my_full_backup_content_scheme"
       android:dataExtractionRules="@xml/my_data_extraction_rules_scheme"
       ...>
     </application>
     ...
     <meta-data android:name="com.microsoft.intune.mam.FullBackupContent" android:resource="@xml/my_full_backup_content_scheme" />
     <meta-data android:name="com.microsoft.intune.mam.DataExtractionRules" android:resource="@xml/my_data_extraction_rules_scheme" />
     

Sauvegarde de clé/valeur

L’option De sauvegarde clé/valeur est disponible pour toutes les API 8+ et charge les données d’application vers le service de sauvegarde Android. La quantité de données par application est limitée à 5 Mo. Si vous utilisez key/value Backup, vous devez utiliser un BackupAgentHelper ou un BackupAgent.

BackupAgentHelper

BackupAgentHelper est plus facile à implémenter que BackupAgent, à la fois en termes de fonctionnalités Android natives et d’intégration mam Intune. BackupAgentHelper permet au développeur d’inscrire des fichiers entiers et des préférences partagées dans un FileBackupHelper et SharedPreferencesBackupHelper (respectivement) qui sont ensuite ajoutés à BackupAgentHelper lors de la création. Procédez comme suit pour utiliser un BackupAgentHelper avec Intune gam :

1. Pour utiliser la sauvegarde multi-identité avec un BackupAgentHelper, suivez le guide Android sur l’extension de BackupAgentHelper.

2. Faites en sorte que votre classe étende l’équivalent MAM de BackupAgentHelper, FileBackupHelper et SharedPreferencesBackupHelper.

Suivre ces instructions vous permet d’effectuer une sauvegarde et une restauration multi-identités réussies.

BackupAgent

Un BackupAgent vous permet d’être beaucoup plus explicite sur les données sauvegardées. Étant donné que le développeur est responsable de l’implémentation, d’autres étapes sont nécessaires pour garantir une protection appropriée des données contre Intune. Étant donné que la majeure partie du travail est sur vous en tant que développeur, Intune’intégration est légèrement plus impliquée.

Intégrer gam :

1. Lisez attentivement le guide Android pour la sauvegarde de clé/valeur et plus particulièrement l’extension de BackupAgent pour vous assurer que votre implémentation BackupAgent suit les instructions Android.

2. Faites en charge votre classe d’étendre MAMBackupAgent.

Sauvegarde multi-identité :

1. Avant de commencer votre sauvegarde, case activée que les fichiers ou mémoires tampons de données que vous envisagez de sauvegarder sont autorisés par l’administrateur informatique à être sauvegardés dans des scénarios multi-identités. Utilisez isBackupAllowed dans MAMFileProtectionManager et MAMDataProtectionManager pour déterminer ce comportement. Si la sauvegarde du fichier ou de la mémoire tampon de données n’est pas autorisée, vous ne devez pas l’inclure dans votre sauvegarde.

2. À un moment donné de votre sauvegarde, si vous souhaitez sauvegarder les identités des fichiers que vous avez archivés à l’étape 1, vous devez appeler backupMAMFileIdentity(BackupDataOutput data, File … files) avec les fichiers à partir desquels vous envisagez d’extraire des données. Cette méthode crée automatiquement de nouvelles entités de sauvegarde et les écrit dans le BackupDataOutput pour vous. Ces entités sont automatiquement consommées lors de la restauration.

Restauration multi-identité : Le guide de sauvegarde des données spécifie un algorithme général pour la restauration des données de votre application et fournit un exemple de code dans la section Extension de BackupAgent . Pour effectuer une restauration à plusieurs identités, vous devez suivre la structure générale fournie dans cet exemple de code avec une attention particulière aux points suivants :

1. Vous devez utiliser une while(data.readNextHeader())boucle * pour passer par les entités de sauvegarde.

2. Vous devez appeler data.skipEntityData()si data.getKey() ne correspond pas à la clé que vous avez écrite dans onBackup. Sans cette étape, vos restaurations risquent de ne pas réussir.

3. Évitez de retourner lors de la consommation d’entités de sauvegarde dans la while(data.readNextHeader())construction * , car toutes les entités que nous écrivons automatiquement sont perdues dans ce cas.

• Où data est le nom de la variable locale pour mamBackupDataInput que l’application reçoit lors de la restauration.

Restrictions de capture d’écran personnalisées

Si votre application contient une fonctionnalité de capture d’écran personnalisée qui contourne la restriction au niveau FLAG_SECURE d’AndroidWindow, vous devez case activée stratégie de capture d’écran avant d’autoriser l’accès complet à la fonctionnalité. Par exemple, si votre application utilise un moteur de rendu personnalisé pour afficher la vue actuelle dans un fichier PNG, vous devez d’abord case activée AppPolicy.getIsScreenCaptureAllowed().

Prise en charge de l’autorité de certification App Protection

L’autorité de certification App Protection (accès conditionnel), également appelée autorité de certification basée sur les applications, restreint l’accès aux ressources. Intune stratégies de protection des applications doivent gérer votre application avant qu’elle puisse accéder à ces ressources. Microsoft Entra ID applique cette stratégie en exigeant que l’application s’inscrive auprès des stratégies de protection des applications Intune et la gère avant d’accorder un jeton pour accéder à une ressource protégée par l’accès conditionnel.

Gérer la non-conformité avec MSAL

Lorsque l’application acquiert un jeton pour un compte, la bibliothèque MSAL peut retourner ou lever un MsalIntuneAppProtectionPolicyRequiredException pour indiquer une non-conformité avec la gestion des stratégies de protection des applications. Vous pouvez extraire d’autres paramètres de l’exception pour les utiliser pour corriger la conformité (voir MAMComplianceManager). Une fois la correction réussie, l’application peut réessayer l’acquisition de jeton via MSAL.

MAMComplianceManager

L’interface MAMComplianceManager est utilisée lorsque l’erreur requise par la stratégie est reçue de MSAL. Il contient la méthode [remediateCompliance] que vous devez appeler pour tenter de placer l’application dans un état conforme. Vous pouvez obtenir une référence au MAMComplianceManager comme suit :

MAMComplianceManager mgr = MAMComponents.get(MAMComplianceManager.class);

// make use of mgr

La MAMComplianceManager instance retournée est garantie de ne pas être null.

package com.microsoft.intune.mam.policy;

public interface MAMComplianceManager {
    void remediateCompliance(String upn, String aadId, String tenantId, String authority, boolean showUX);
}

La remediateCompliance() méthode tente de placer l’application sous gestion pour satisfaire aux conditions pour Microsoft Entra ID d’accorder le jeton demandé. Les quatre premiers paramètres peuvent être extraits de l’exception que la méthode MSAL AuthenticationCallback.onError() reçoit. Le dernier paramètre est une valeur booléenne qui contrôle si une expérience utilisateur s’affiche pendant la tentative de conformité.

remediateCompliance affiche une boîte de dialogue de progression de blocage simple pour que les applications n’ont pas besoin d’afficher des expériences personnalisées pendant cette opération. Cette boîte de dialogue s’affiche uniquement pendant que la correction de conformité est en cours. Il n’affiche pas le résultat final. Votre application peut inscrire un récepteur pour la COMPLIANCE_STATUS notification afin de gérer la réussite ou l’échec de la tentative de correction de conformité. Pour plus d’informations, consultez Notifications de status de conformité.

remediateCompliance() peut lancer une inscription GAM dans le cadre de l’établissement de la conformité. L’application peut recevoir une notification d’inscription si elle a inscrit un récepteur de notification pour les notifications d’inscription. La méthode inscrite MAMServiceAuthenticationCallback de l’application est acquireToken() appelée pour obtenir un jeton pour l’inscription. acquireToken() est appelé avant que l’application n’acquiert son propre jeton. Les tâches de comptabilité ou de création de compte effectuées par l’application après une acquisition de jeton réussie n’ont peut-être pas encore été effectuées. Dans ce cas, le rappel doit être en mesure d’acquérir un jeton.

Si vous ne pouvez pas retourner un jeton à partir de acquireToken(), la tentative de correction de conformité échoue.

Si vous appelez updateToken ultérieurement avec un jeton valide pour la ressource demandée, la correction de conformité reprend immédiatement avec le jeton donné.

Voici un exemple qui reçoit l’erreur requise par la stratégie dans la AuthenticationCallback.onError() méthode et appelle MAMComplianceManager pour gérer l’erreur.

public void onError(@Nullable MsalException exc) {
    if (exc instanceof MsalIntuneAppProtectionPolicyRequiredException) {

        final MsalIntuneAppProtectionPolicyRequiredException policyRequiredException =
            (MsalIntuneAppProtectionPolicyRequiredException) ex;

        final String upn = policyRequiredException.getAccountUpn();
        final String aadId = policyRequiredException.getAccountUserId();
        final String tenantId = policyRequiredException.getTenantId();
        final String authority = policyRequiredException.getAuthorityURL();

        MAMComplianceManager complianceManager = MAMComponents.get(MAMComplianceManager.class);
        complianceManager.remediateCompliance(upn, aadId, tenantId, authority, showUX);
    }
}

Notifications de status de conformité

Si l’application s’inscrit aux notifications de type COMPLIANCE_STATUS, le système envoie un MAMComplianceNotification pour informer l’application de la dernière status de la tentative de correction de conformité. Pour plus d’informations sur l’inscription, consultez S’inscrire aux notifications à partir du Kit de développement logiciel (SDK ).

public interface MAMComplianceNotification extends MAMUserNotification {
    MAMCAComplianceStatus getComplianceStatus();
    String getComplianceErrorTitle();
    String getComplianceErrorMessage();
}

La getComplianceStatus() méthode retourne le résultat de la tentative de correction de conformité en tant que valeur de l’énumération [MAMCAComplianceStatus].

Si la status de conformité est MAMCAComplianceStatus.COMPLIANT, l’application doit réinitialiser son acquisition de jeton d’origine (pour sa propre ressource).

Si la tentative de correction de conformité a échoué, les getComplianceErrorTitle() méthodes et getComplianceErrorMessage() retournent des chaînes localisées que l’application peut afficher à l’utilisateur final s’il le souhaite. L’application ne peut pas résoudre la plupart des cas d’erreur. En général, la création ou la connexion du compte échouent et autorisent l’utilisateur à réessayer ultérieurement.

Si une défaillance est persistante, les journaux Portail d'entreprise peuvent aider à en déterminer la cause. L’utilisateur final peut envoyer les journaux. Pour plus d’informations, consultez Charger et envoyer des journaux d’e-mail.

Voici un exemple d’inscription d’un récepteur à l’aide d’une classe anonyme pour implémenter l’interface MAMNotificationReceiver :

final MAMNotificationReceiverRegistry notificationRegistry = MAMComponents.get(MAMNotificationReceiverRegistry.class);
// create a receiver
final MAMNotificationReceiver receiver = new MAMNotificationReceiver() {
    public boolean onReceive(MAMNotification notification) {
        if (notification.getType() == MAMNotificationType.COMPLIANCE_STATUS) {
            MAMComplianceNotification complianceNotification = (MAMComplianceNotification) notification;

            // take appropriate action based on complianceNotification.getComplianceStatus()

            // unregister this receiver if no longer needed
            notificationRegistry.unregisterReceiver(this, MAMNotificationType.COMPLIANCE_STATUS);
        }
        return true;
    }
};
// register the receiver
notificationRegistry.registerReceiver(receiver, MAMNotificationType.COMPLIANCE_STATUS);

Déclaration de prise en charge de l’autorité de certification App Protection

Une fois que votre application est prête à gérer la correction de l’autorité de certification d’application, vous pouvez indiquer à Microsoft Identity que votre application est prête pour l’autorité de certification d’application. Pour ce faire dans l’application MSAL, générez le client public avec les fonctionnalités client de « protapp »

{
      "client_id" : "[YOUR_CLIENT_ID]",
      "authorization_user_agent" : "DEFAULT",
      "redirect_uri" : "[YOUR_REDIRECT_URI]",
      "multiple_clouds_supported":true,
      "broker_redirect_uri_registered": true,
      "account_mode": "MULTIPLE",
      "client_capabilities": "protapp",
      "authorities" : [
        {
          "type": "AAD",
          "audience": {
            "type": "AzureADandPersonalMicrosoftAccount"
          }
        }
      ]
    }

Une fois les étapes terminées, passez à Validation de l’autorité de certification App Protection.

Notes d’implémentation

AcquireTokenSilentParameters acquireTokenSilentParameters =
        builder.withScopes(Arrays.asList(scopes))
               .forceRefresh(false)
               .build();

acquireTokenSilentAsync(acquireTokenSilentParameters);

S’inscrire aux notifications à partir du KIT de développement logiciel (SDK)

Le guide du Kit de développement logiciel (SDK) d’application Intune décrit plusieurs scénarios dans lesquels votre application peut être tenue de s’inscrire aux notifications à partir du SDK, par exemple :

• Gestion des WRONG_USER applications multi-identités (voir Identités managées et non managées)
• Gestion des MANAGEMENT_REMOVED applications multi-identités (consultez Protection de la mémoire tampon de données).
• Gestion des WIPE_USER_DATA applications multi-identités ou WIPE_USER_AUXILIARY_DATA (voir Réinitialisation sélective).
• Applications qui implémentent la gestion de la configuration des REFRESH_APP_CONFIG applications (consultez Récupération de la configuration d’application à partir du SDK).

Cette section décrit chaque type de notification que le SDK peut envoyer, quand et pourquoi votre application souhaite l’écouter, et comment implémenter un récepteur de notification.

Types de notifications

Toutes les notifications du SDK implémentent l’interface MAMNotification , qui a une seule fonction, getType(), qui retourne une énumération MAMNotificationType .

La plupart des notifications sont des instances MAMUserNotification , qui fournissent des informations spécifiques à une seule identité. L’OID de l’identité peut être récupéré via la getUserOid() fonction , et l’UPN de l’identité peut être récupéré via getUserIdentity().

MAMEnrollmentNotification et MAMComplianceNotification étendent MAMUserNotificationdavantage , qui contient les résultats des tentatives d’inscription d’un utilisateur ou d’un appareil auprès du service GAM et les résultats des tentatives de correction de la conformité pour l’autorité de certification App Protection, respectivement.

(*) Les réinitialisations peuvent se produire pour de nombreuses raisons, par exemple :

• Votre application a appelé unregisterAccountForMAM.
• Un administrateur informatique a lancé une réinitialisation à distance.
• Administration stratégies d’accès conditionnel requises n’ont pas été satisfaites.

MANAGEMENT_REMOVED

La MANAGEMENT_REMOVED notification informe l’application qu’un compte précédemment géré par une stratégie est sur le point de devenir non géré. Une fois que le compte n’est pas géré, l’application ne peut plus lire les fichiers chiffrés de ce compte, lire les données du compte chiffrées avec MAMDataProtectionManager, interagir avec le Presse-papiers chiffré ou participer à l’écosystème d’application managée.

Cela ne nécessite pas d’effacement des données utilisateur ou de déconnexion de l’utilisateur (si une réinitialisation était nécessaire, une WIPE_USER_DATA notification serait envoyée). De nombreuses applications n’ont peut-être pas besoin de gérer cette notification, mais les applications qui utilisent MAMDataProtectionManager doivent gérer cela. Pour plus d’informations, consultez Protection de la mémoire tampon de données.

Lorsque le Kit de développement logiciel (SDK) appelle le récepteur de MANAGEMENT_REMOVED l’application, les conditions suivantes sont remplies :

• Le SDK a déjà déchiffré des fichiers précédemment chiffrés (mais pas des mémoires tampons de données protégées) qui appartiennent à l’application. Les fichiers situés dans des emplacements publics sur le carte SD qui n’appartiennent pas directement à l’application (par exemple, les dossiers Documents ou Télécharger) ne sont pas déchiffrés.

• Les nouveaux fichiers ou mémoires tampons de données protégées créés par la méthode du récepteur (ou tout autre code qui s’exécute après le démarrage du récepteur) ne sont pas chiffrés.

• L’application ayant toujours accès aux clés de chiffrement, les opérations telles que le déchiffrement des mémoires tampons de données réussissent.

Une fois le récepteur de votre application retourné, il n’a plus accès aux clés de chiffrement.

Implémentation de MAMNotificationReceiver

Pour s’inscrire aux notifications à partir du SDK, votre application doit créer un MAMNotificationReceiver et l’inscrire auprès de MAMNotificationReceiverRegistry.

Pour inscrire le récepteur, appelez registerReceiver avec votre récepteur et le type de notification souhaité dans votre Application.onCreate méthode :

@Override
public void onCreate() {
  super.onCreate();
  MAMComponents.get(MAMNotificationReceiverRegistry.class)
    .registerReceiver(
      new ToastNotificationReceiver(),
      MAMNotificationType.WIPE_USER_DATA);
}

L’implémentation MAMNotificationReceiver de votre application doit inclure la onReceive(MAMNotification notification) méthode . Cette méthode appelle individuellement pour chaque notification reçue, et elle doit retourner un boolean. En règle générale, cette méthode doit toujours retourner true, sauf si votre application a rencontré un échec de réponse à une notification.

Comme avec d’autres types de récepteurs Android, votre application offre une certaine flexibilité dans la gestion des notifications :

• Il peut créer des implémentations MAMNotificationReceiver distinctes pour des types de notification distincts. Dans ce cas, veillez à inscrire chaque implémentation et chaque type de notification séparément.
• Il peut utiliser une implémentation MAMNotificationReceiver unique qui contient une logique pour répondre à plusieurs types de notification distincts. Dans ce cas, il doit être inscrit pour chaque type de notification auquel il peut répondre.
• Il peut créer plusieurs implémentations MAMNotificationReceiver qui répondent chacune au même type de notification. Dans ce cas, les deux doivent être inscrits dans le même type de notification.

Thèmes personnalisés

Un thème personnalisé peut être fourni au KIT de développement logiciel (SDK) d’application Intune ; ce thème personnalisé s’applique à tous les écrans et boîtes de dialogue du SDK. Si aucun thème n’est fourni, le thème sdk par défaut est utilisé.

Fourniture d’un thème personnalisé

Pour fournir un thème, ajoutez la ligne de code suivante dans la Application.onMAMCreate méthode :

MAMThemeManager.setAppTheme(R.style.AppTheme);

Dans l’exemple, remplacez par R.style.AppTheme le thème de style que le SDK doit appliquer.

Gestion des certificats racines approuvés

Si l’application nécessite des certificats SSL/TLS émis par une autorité de certification locale ou privée pour fournir un accès sécurisé aux applications et sites web internes, le KIT de développement logiciel (SDK) d’application Intune a ajouté la prise en charge de la gestion des approbations de certificats avec les classes d’API MAMTrustedRootCertsManager et MAMCertTrustWebViewClient.

La gestion des certificats racines approuvés prend en charge les éléments suivants :

• SSLContext
• SSLSocketFactory
• TrustManager
• WebView

Configuration requise

• La gestion des certificats racines approuvés nécessite une licence Microsoft Tunnel for Mobile Application Management. Pour en savoir plus, consultez : Microsoft Tunnel avec la gestion des applications mobiles.
• Configurez des stratégies de Intune App Configuration pour fournir des certificats racines approuvés aux applications métier et à Microsoft Edge sur Android. Voir : Utiliser le VPN Microsoft Tunnel avec des appareils Android qui ne s’inscrivent pas avec Microsoft Intune.

Utilisation de certificats racines approuvés à partir de Intune pour établir des ancres de confiance

La gestion des certificats racines approuvés permet à votre application d’utiliser des certificats racines approuvés de Intune en combinaison avec les certificats de l’appareil.

Les classes d’API MAMTrustedRootCertsManager et MAMCertTrustWebViewClient utilisent les Intune certificats racines approuvés fournis via App Configuration Policy comme option de secours si les magasins de certificats racines approuvés de l’appareil ne contiennent pas les certificats racines approuvés requis pour établir une connexion sécurisée aux ressources locales. De cette façon, l’application peut utiliser des certificats d’appareil et Intune pour vérifier la sécurisation des connexions et des communications avec des sources approuvées.

Pour améliorer ses paramètres de sécurité réseau, une application peut utiliser le fichier XML de configuration de la sécurité réseau. La gestion des certificats racines approuvés respecte cette sécurité supplémentaire en vérifiant si le xml de configuration de la sécurité réseau de l’application dispose de l’une des fonctionnalités suivantes :

• Ancres de confiance personnalisées avec des autorités de certification supplémentaires telles que des certificats auto-signés.
• Règles spécifiques au domaine pour limiter les autorités de certification approuvées.
• Ensembles d’épingles pour les certificats pour des domaines spécifiques.

Si l’un de ces éléments s’applique à un domaine qui fait l’objet d’une vérification d’approbation, la gestion des certificats racines approuvés ignore les vérifications d’approbation personnalisées pour ce domaine et laisse uniquement les gestionnaires d’approbation par défaut de la plateforme effectuer les vérifications.

Classe MAMTrustedRootCertsManager

Cette classe fournit les API suivantes :

• createSSLContextForOID(String oid, String protocol): crée un SSLContext objet qui utilise des certificats racines approuvés pour l’identité spécifiée et le protocole SSL/TLS spécifié. L’objet retourné SSLContext à partir de cette classe est déjà initialisé correctement avec X509TrustManager les objets qui utilisent les certificats racines approuvés combinés de l’appareil et du service GAM.
• createSSLSocketFactoryForOID(String oid, String protocol): crée un SSLSocketFactory objet qui utilise des certificats racines approuvés pour l’identité spécifiée et le protocole SSL/TLS spécifié. L’objet retourné SSLSocketFactory est référencé à partir du même SSLContext objet dans cette classe.
• createX509TrustManagersForOID(String oid): crée un tableau d’objets X509TrustManager qui utilisent les certificats racines approuvés combinés de l’appareil et du service GAM pour l’identité spécifiée.

Voici quelques exemples d’utilisation de cette classe.

Exemple d’utilisation de HttpsUrlConnection

// Create an SSL socket factory using supplying the optional parameters identity and protocol
SSLSocketFactory sslSocketFactory = MAMTrustedRootCertsManager.createSSLSocketFactoryForOID(oid, "TLSv1.3");

// Create a URL object for the desired endpoint
URL url = new URL("https://example.com");

// Open a connection using the URL object
HttpsURLConnection httpsURLConnection = (HttpsURLConnection) url.openConnection();

// Set the SSL socket factory for the connection
httpsURLConnection.setSSLSocketFactory(sslSocketFactory);

// Perform any other configuration or operations on the connection as needed
...

Exemple d’utilisation d’OkHttpClient

// Get the TrustManager instances for an identity from the SDK
TrustManager[] trustManagers = MAMTrustedRootCertsManager.createX509TrustManagersForOID(oid);

// Get SSLContext from the platform
SSLContext sslContext = SSLContext.getInstance("TLSv1.3");

// Initialize the SSLContext with the trust managers from the Intune App SDK
sslContext.init(null, trustManagers, null);

// Create an OkHttpClient.Builder object
OkHttpClient.Builder builder = new OkHttpClient.Builder();

// Set the SSLSocketFactory and the trust managers from the SDK
builder.sslSocketFactory(sslContext.socketFactory, trustManagers[0] as X509TrustManager).build();

// Build an OkHttpClient object from the builder
OkHttpClient okHttpClient = builder.build();

// Create a Request object for the desired endpoint
Request request = new Request.Builder().url("https://example.com").build();

// Execute the request using the OkHttpClient object and get a Response object
Response response = okHttpClient.newCall(request).execute();

// Perform any other operations on the response as needed
...

Classe MAMCertTrustWebViewClient

Cette classe fournit une implémentation personnalisée de la classe android.webkit.WebViewClientAndroid . La classe fournit un moyen de gérer l’erreur android.net.http.SslError.SSL_UNTRUSTED SSL dans WebView.

Lors de la gestion de l’erreur, la classe utilise des certificats racines approuvés que Intune configure et que le service GAM fournit. Cette approche vérifie la fiabilité de l’hôte à partir de l’URL cible qui a généré l’erreur SSL dans WebView. Si l’implémentation personnalisée ne gère pas l’erreur SSL, le système appelle le comportement par défaut hérité de la superclasse.

Lorsque vous utilisez cette classe, créez une instance de celle-ci, puis appelez WebView.setWebViewClient(WebViewClient) pour l’inscrire auprès d’un WebView instance.

Voici un exemple d’utilisation de cette classe.

Exemple d’utilisation de WebView

// Get the MAM implementation of WebViewClient from the Intune App SDK
MAMCertTrustWebViewClient mamCertTrustWebViewClient = new MAMCertTrustWebViewClient();

// Set the MAM WebViewClient from the SDK as the current handler on the instance of WebView
webView.setWebViewClient(mamCertTrustWebViewClient);

// Perform any other operations on WebView
...

Critères de sortie

Pour plus d’informations, consultez Tests rapides avec changement de stratégie pour faciliter les tests.

Validation de l’enregistrement et de l’ouverture à partir des restrictions

Ignorez cette section si vous n’avez pas implémenté de stratégie pour limiter le transfert de données entre les applications et les emplacements de stockage des appareils ou du cloud.

Refamiliez-vous avec chaque scénario où votre application peut enregistrer des données dans des services cloud ou des données locales et ouvrir des données à partir de services cloud ou de données locales.

Par souci de simplicité, ces tests supposent que votre application prend uniquement en charge l’enregistrement et l’ouverture de données à partir de OneDrive à partir d’un emplacement unique au sein de l’application. Toutefois, vous devez valider chaque combinaison : chaque emplacement d’enregistrement pris en charge par rapport à chaque emplacement que votre application permet d’enregistrer des données, et chaque emplacement ouvert pris en charge pour chaque emplacement où votre application autorise l’ouverture de données.

Pour ces tests, installez votre application et le Portail d'entreprise Intune ; connectez-vous avec un compte managé avant de commencer le test. En outre :

• Définissez la stratégie du compte managé comme suit :
  • « Envoyer des données d’organisation à d’autres applications » défini sur « Applications gérées par une stratégie ».
  • « Recevoir des données d’autres applications » défini sur « Applications gérées par une stratégie ».

Validation des restrictions de notification

Ignorez cette section si vous n’avez pas implémenté la stratégie de restriction du contenu dans les notifications.

En ce qui concerne la stratégie de protection des applications, votre application peut déclencher trois types de notifications différents :

1. Notifications qui ne contiennent pas de données de compte.
2. Notifications qui contiennent des données appartenant à un compte managé.
3. Notifications qui contiennent des données appartenant à un compte non managé.

Si votre application est à identité unique, seules les deux premières sont pertinentes, car aucune protection n’est appliquée si le seul compte n’est pas géré.

Vous pouvez valider les restrictions de notification en déclenchant les trois types de notifications avec différentes valeurs de stratégie configurées.

Pour ces tests, installez votre application et le Portail d'entreprise Intune ; connectez-vous avec un compte managé avant de commencer le test. Si votre application est multi-identité, connectez-vous également à votre application avec un compte non managé.

Validation de la sauvegarde et de la restauration des données

Ignorez cette section si vous n’avez pas implémenté la stratégie de protection des données de sauvegarde.

Refamiliez-vous avec le contenu (fichiers et paires clé-valeur) que votre application a configuré pour la sauvegarde. Vous devez vérifier que seul le contenu attendu fait partie de la restauration. Le contenu supplémentaire de la restauration peut entraîner une fuite de données.

Pour ces tests, installez votre application et le Portail d'entreprise Intune ; connectez-vous avec un compte managé avant de commencer le test. Si votre application est multi-identité, connectez-vous également à votre application avec un compte non managé.

Suivez les instructions officielles d’Android pour tester la sauvegarde. Ces instructions diffèrent pour les sauvegardes de sauvegarde automatique et de clé/valeur. Par conséquent, suivez-les attentivement.

Validation de la capture d’écran personnalisée par rapport à la stratégie

Ignorez cette section si vous n’avez pas implémenté de restrictions de capture d’écran personnalisées.

Si votre application dispose d’une fonctionnalité qui contourne le niveau FLAG_SECUREd’AndroidWindow, vérifiez que cette fonctionnalité est bloquée par les restrictions de capture d’écran de la stratégie de protection des applications.

Pour ces tests, installez votre application et le Portail d'entreprise Intune ; connectez-vous avec un compte managé avant de commencer le test.

Validation de l’autorité de certification App Protection

Ignorez cette section si vous n’avez pas implémenté l’autorité de certification De protection des applications.

En plus des étapes de validation classiques de la création et de l’attribution d’une stratégie de protection des applications à votre compte d’application et de test, vous devez également créer et affecter une stratégie d’accès conditionnel Protection des applications à votre compte de test. Pour plus d’informations, consultez Configurer des stratégies d’accès conditionnel basées sur une application avec Intune.

Étapes de test :

1. Désinstallez Microsoft Authenticator et Portail d'entreprise Intune avant de commencer ce test.
2. Installez votre application.
3. Connectez-vous à votre application avec votre compte de test ciblé à l’aide d’une stratégie de protection des applications et d’une stratégie d’autorité de certification basée sur l’application.
4. Vérifiez que votre application vous invite à installer le Portail d'entreprise.
5. Reconnectez-vous.
6. Confirmez que votre application vous invite à inscrire votre appareil. Suivez les invites. Si votre application n’invite pas à s’inscrire ici, vérifiez que votre appareil de test a d’abord désinstallé d’autres applications compatibles sdk, Portail d'entreprise et Authenticator. Si cela ne vous invite toujours pas, passez en revue les instructions d’implémentation.
7. Vérifiez que vous êtes en mesure d’accéder à toutes les données de l’application après l’inscription.

Validation des récepteurs de notification

Ignorez cette section si vous n’avez pas implémenté s’inscrire aux notifications à partir du Kit de développement logiciel (SDK).

Les étapes de validation dépendent des types de notifications pour lesquelles votre application a été inscrite. Pour tous les types de notifications, ajoutez la journalisation pour vous assurer que votre récepteur est correctement appelé.

MAM_ENROLLMENT_RESULT peut être déclenché en vous connectant à votre application avec un compte ciblé par la stratégie de protection des applications.

Vous pouvez déclencher REFRESH_APP_CONFIG et REFRESH_POLICY en mettant à jour la stratégie de App Configuration et la stratégie de protection des applications respectives qui ciblent votre compte de test et en attendant que le SDK reçoive la stratégie mise à jour.

Vous pouvez déclencher des MANAGEMENT_REMOVEDnotifications , WIPE_USER_DATA, WIPE_USER_AUXILIARY_DATAet WIPE_COMPLETEDen émettant une réinitialisation sélective à partir de Microsoft Intune.

Validation des thèmes personnalisés

Ignorez cette section si vous n’avez pas implémenté de thèmes personnalisés.

Vous pouvez valider la prise en charge des thèmes personnalisés en inspectant les couleurs dans les boîtes de dialogue du SDK. La boîte de dialogue la plus simple à case activée est l’écran du code PIN MAM.

Conditions préalables:

• Définissez la stratégie du compte managé comme suit :
  • « CODE CONFIDENTIEL pour l’accès » défini sur « Obligatoire ».
• Installez votre application et le Portail d'entreprise Intune.

Étapes de test :

1. Lancez votre application et connectez-vous avec le compte de test.
2. Vérifiez que l’écran du code PIN MAM s’affiche et qu’il a un thème basé sur le thème personnalisé que vous avez fourni au SDK.

Étapes suivantes

Si vous avez suivi ce guide dans l’ordre et que vous avez rempli tous les critères de sortie plus haut dans cet article, votre application est désormais entièrement intégrée au SDK d’application Intune et peut appliquer des stratégies de protection des applications. Si vous avez ignoré l’une des sections précédentes de participation à l’application, Étape 5 : Multi-Identité et Étape 6 : App Configuration, et que vous ne savez pas si votre application doit prendre en charge ces fonctionnalités, passez en revue les décisions clés pour l’intégration du SDK.

Protection d'applications est désormais un scénario de base pour votre application. Continuez à vous référer à ce guide et à l’annexe lorsque vous continuez à développer votre application.