Kit de développement logiciel (SDK) d’application Intune pour Android - Multi-identité

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 MAM) dans votre application Android Java/Kotlin native. Une application gérée par Intune est une application intégrée 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.

Remarque

Ce guide est divisé en plusieurs étapes distinctes. Commencez par passer en revue l’étape 1 : Planifiez l’intégration.

Stade 5 : Multi-identité

Objectifs de la scène

• Déterminez si votre application a besoin d’une prise en charge multi-identités.
• Comprendre comment le SDK d’application Intune perçoit les identités.
• Refactorisez votre application pour la reconnaissance des identités.
• Ajoutez du code pour informer le Kit de développement logiciel (SDK) des identités actives et modifiées dans votre application.
• Testez minutieusement l’application des stratégies de protection des applications pour les identités gérées et non gérées.

Terminologie identitaire

Les termes « utilisateur », « compte » et « identité » sont souvent utilisés de manière interchangeable. Ce guide tente d’établir la différenciation suivante :

• Utilisateur : l’être humain qui utilise le produit logiciel. Différencié en tant qu’utilisateur final, l’humain utilisant l’application Android, et / l’utilisateur / administrateur administrateurAdministrateur / informatiqueIT Pro, l’humain utilisant le centre d’administration Microsoft Intune.
• Compte : enregistrement logiciel appartenant à une organisation qui identifie de manière unique l’entité d’un utilisateur. Un utilisateur humain peut avoir plusieurs comptes.
• Identité : ensemble de données que le Kit de développement logiciel (SDK) d’application Intune utilise pour identifier de manière unique un compte.

Arrière-plan

Par défaut, le Kit de développement logiciel (SDK) de l’application Intune applique la stratégie à l’ensemble de votre application. Une fois que vous avez inscrit un compte avec la stratégie de protection des applications ciblée, le Kit de développement logiciel (SDK) associe chaque fichier et chaque activité à l’identité de ce compte et applique la stratégie ciblée de ce compte de manière universelle.

Pour de nombreux développeurs, il s’agit du comportement de protection d’application souhaité pour leur application. Ces applications sont considérées comme ayant une identité unique. En effectuant les étapes précédentes, votre application s’est intégrée avec succès en tant qu’identité unique et peut appliquer toutes les stratégies de base. Les applications destinées à rester à identité unique peuvent ignorer cette section et passer à l’étape 6 : App Configuration.

Le SDK d’application Intune peut éventuellement appliquer la stratégie au niveau de chaque identité. Si votre application prend déjà en charge plusieurs comptes connectés simultanément et que vous souhaitez conserver cette prise en charge de plusieurs comptes avec des stratégies de protection des applications, votre application est considérée comme multi-identités.

Conseil

Si vous ne savez pas si l’application doit prendre en charge les protections à identité unique ou à identités multiples, consultez à nouveau la page Mon application est-elle à identité unique ou à identités multiples ?

Avertissement

La prise en charge de la gestion de plusieurs identités est beaucoup plus complexe que les autres fonctionnalités de protection des applications. Une intégration incorrecte de la multi-identité peut entraîner des fuites de données et d’autres problèmes de sécurité. Examinez attentivement cette section et prévoyez suffisamment de temps pour les tests avant de passer à l’étape suivante.

« identité » au SDK

Lorsqu’une application intégrée au SDK enregistre un compte à l’aide de registerAccountForMAM, le SDK enregistre tous les paramètres fournis (upn, aadId, tenantId et authority) en tant qu’identité. Toutefois, la plupart des API d’identité du SDK utilisent l’OID fourni (également appelé Microsoft Entra ID ou AAD ID) comme identificateur de l’identité. Les API DU KIT DE DÉVELOPPEMENT LOGICIEL (SDK) GAM retournent la chaîne OID en tant qu’identité et nécessitent le paramètre de chaîne OID pour l’identité. Certaines méthodes peuvent également prendre ou renvoyer une chaîne UPN, auquel cas l’UPN est à des fins d’information uniquement.

Les paramètres d’identité ne sont pas sensibles à la casse. Les demandes adressées au SDK pour une identité peuvent ne pas renvoyer la même casse que celle utilisée lors de l’inscription ou de la définition de l’identité.

Attention

Pour les applications utilisant des méthodes déconseillées qui prennent ou renvoient une chaîne UPN, les applications doivent s’assurer que la chaîne UPN d’identité transmise aux différents appels d’API est cohérente. La transmission de chaînes UPN incohérentes peut entraîner des fuites de données.

Identités gérées et non gérées

Comme décrit dans la section Inscription à la stratégie de protection des applications, votre application est chargée d’informer le Kit de développement logiciel (SDK) lorsqu’un utilisateur se connecte. Au moment de la connexion, le compte de l’utilisateur peut ou non être ciblé par la stratégie de protection de l’application. Si le compte est ciblé par une stratégie de protection d’application, le Kit de développement logiciel (SDK) le considère comme géré ; sinon, il n’est pas géré.

Le Kit de développement logiciel (SDK) applique la stratégie pour les identités qu’il considère comme gérées. Le Kit de développement logiciel (SDK) n’applique pas de stratégie pour les identités qu’il considère comme non gérées.

Actuellement, le SDK de l’application Intune ne prend en charge qu’une seule identité gérée par appareil. Dès qu’une application intégrée au SDK enregistre une identité managée, toutes les identités enregistrées ultérieurement, même si elles sont actuellement ciblées par des stratégies de protection des applications, sont traitées comme non gérées.

Si une identité managée a déjà été inscrite sur l’appareil et que votre application inscrit une autre identité qui est également ciblée par la stratégie de protection des applications, le Kit de développement logiciel (SDK) retourne MAMEnrollmentManager.Result.WRONG_USER et invite l’utilisateur final avec des options de correction. Pour plus d’informations, consultez S’inscrire aux notifications du Kit de développement logiciel (SDK ).

Remarque

Un compte qui n’est pas ciblé par la stratégie de protection des applications au moment de l’inscription est considéré comme non géré. Même si le compte n’est pas sous licence ou ciblé par la stratégie de protection des applications, le Kit de développement logiciel (SDK) case activée régulièrement si ce compte devient sous licence et ciblé ultérieurement. Si aucune autre identité managée n’a été enregistrée, le Kit de développement logiciel (SDK) commence à traiter cette identité comme managée une fois qu’elle est ciblée par la stratégie. L’utilisateur n’a pas besoin de se déconnecter puis de se reconnecter à ce compte pour effectuer cette modification.

L’identité active

Votre application doit toujours garder le SDK informé de l’identité en cours d’utilisation, autrement appelée identité active. Si l’identité active est gérée, le Kit de développement logiciel (SDK) applique des protections. Si l’identité active n’est pas gérée, le Kit de développement logiciel (SDK) n’applique pas de protections.

Étant donné que le SDK ne possède aucune connaissance spécifique à l’application, il doit faire confiance à l’application pour partager l’identité active correcte.

• Si l’application indique à tort au SDK qu’une identité non managée est active alors que l’identité managée est en cours d’utilisation, le SDK n’appliquera pas de protections. Cela pourrait entraîner une fuite de données qui met en danger les données des utilisateurs.

• Si l’application indique à tort au SDK que l’identité managée est active alors qu’une identité non managée est en cours d’utilisation, le SDK appliquera des protections inappropriées. Il ne s’agit pas d’une fuite de données, mais cela peut restreindre inutilement les utilisateurs non gérés et exposer les données des utilisateurs non gérés au risque de suppression.

Si votre application affiche les données d’un utilisateur, elle doit afficher uniquement les données qui appartiennent à l’identité active. Si votre application ne connaît pas actuellement le propriétaire des données affichées, vous devrez peut-être refactoriser votre application pour une meilleure prise en charge de l’identité avant de commencer à intégrer la prise en charge de plusieurs identités.

Organisation des données d’application par identité

Chaque fois que votre application écrit un nouveau fichier, le SDK associe (également appelé « balises ») une identité à ce fichier en fonction du thread actif et de l’identité du processus actuels. Votre application peut également appeler directement le SDK pour baliser manuellement un fichier avec une identité particulière (consultez la section Écriture de Files protégés pour plus de détails). Le Kit de développement logiciel (SDK) utilise cette identité de fichier balisée pour le chiffrement de fichier et l’effacement sélectif.

Si l’identité managée est ciblée avec une stratégie de chiffrement, seuls les fichiers étiquetés avec l’identité managée seront chiffrés.

Si l’action de l’administrateur ou la stratégie configurée demande que les données gérées soient effacées, seuls les fichiers étiquetés avec l’identité gérée seront supprimés.

Le SDK ne peut pas associer plusieurs identités à un seul fichier. Si votre application stocke des données appartenant à plusieurs utilisateurs dans le même fichier, le comportement par défaut du Kit de développement logiciel (SDK) entraîne une sous-protection ou une surprotection de ces données. Nous vous encourageons vivement à organiser les données de votre application par identité.

Si votre application doit absolument stocker des données appartenant à différentes identités dans le même fichier, le SDK fournit des fonctionnalités pour les sous-ensembles de données d’étiquetage d’identité dans un fichier. Pour plus d’informations, consultez Protection de la mémoire tampon de données .

Implémentation de la multi-identité

Pour déclarer la prise en charge de plusieurs identités pour votre application, commencez par placer les métadonnées suivantes dans AndroidManifest.xml.

  <meta-data
    android:name="com.microsoft.intune.mam.MAMMultiIdentity"
    android:value="true" />

Définition de l’identité active

Votre application peut définir l’identité active aux niveaux suivants en priorité décroissante :

1. Niveau de thread
2. Context (généralités Activity) Level (Niveau)
3. Niveau de processus

Une identité définie au niveau du thread remplace une identité définie au Context niveau qui remplace une identité définie au niveau du processus.

Une identité définie sur un n’est Context utilisée que dans les scénarios associés appropriés. Les opérations d’E/S de fichier, par exemple, n’ont pas de fichier associé Context. Le plus souvent, les applications définissent l’identité Context sur un Activity. Envisagez de définir l’identité Context dans Activity.onCreate. Une application ne doit pas afficher les données d’une identité, sauf si l’identité Activity est définie sur cette même identité.

En général, l’identité au niveau du processus n’est utile que si l’application fonctionne uniquement avec une seule identité à la fois sur tous les threads. Il ne s’agit pas d’un comportement typique pour les applications qui prennent en charge plusieurs comptes. Nous vous encourageons vivement à séparer les données de compte et à définir l’identité active dans le thread ou Context les niveaux.

Si votre application utilise le Application contexte pour acquérir des services système, assurez-vous que l’identité du thread ou du processus a été définie, ou que vous avez défini l’identité d’interface utilisateur sur le contexte de Application votre application.

Si votre application utilise un contexte pour lancer des Service intentions, utilise des programmes de résolution de contenu ou exploite d’autres services système, veillez à définir l’identité sur le Service contexte. De même, si votre application utilise un JobService contexte pour effectuer ces actions, veillez à définir l’identité sur le contexte ou le thread, comme l’exige JobService votre JobService implémentation. Par exemple, si vos JobService processus fonctionnent pour une identité unique, envisagez de définir l’identité dans le JobService contexte. Si vos JobService traitements traitent des tâches pour plusieurs identités, envisagez de définir l’identité au niveau du thread.

Attention

Les applications qui utilisent WorkManager doivent faire particulièrement attention lors de la définition de l’identité. Plus précisément, ces applications doivent éviter de définir une identité sur le Context passé dans le Worker constructeur. Ce Context instance peut être partagé entre plusieurs Worker instances simultanément. Pour éviter les comportements non définis, les applications doivent plutôt définir une identité de thread dans Worker.doWork() comme l’exige l’implémentation Worker .

Remarque

Étant donné qu’il est utilisé pour les CLIPBOARD_SERVICE opérations de l’interface utilisateur, le Kit de développement logiciel (SDK) utilise l’identité d’interface utilisateur de l’activité de premier plan pour ClipboardManager les opérations.

Les méthodes suivantes dans MAMPolicyManager peuvent être utilisées pour définir l’identité active et récupérer les valeurs d’identité précédemment définies.

public static void setUIPolicyIdentityOID(final Context context, final String oid,
                    final MAMSetUIIdentityCallback mamSetUIIdentityCallback, final EnumSet<IdentitySwitchOption> options);

public static String getUIPolicyIdentityOID(final Context context);

public static MAMIdentitySwitchResult setProcessIdentityOID(final String oid);

public static String getProcessIdentityOID();

public static MAMIdentitySwitchResult setCurrentThreadIdentityOID(final String oid);

public static String getCurrentThreadIdentityOID();

/**
 * Get the current app policy. This does NOT take the UI (Context) identity into account.
 * If the current operation has any context (e.g. an Activity) associated with it, use the overload below.
 */
public static AppPolicy getCurrentThreadPolicy();

/**
 * Get the current app policy. This DOES take the UI (Context) identity into account.
 * If the current operation has any context (e.g. an Activity) associated with it, use this function.
 */
public static AppPolicy getPolicy(final Context context);


public static AppPolicy getPolicyForIdentityOID(final String oid);

public static boolean getIsIdentityOIDManaged(final String oid);

Par souci de commodité, vous pouvez également définir l’identité d’une activité directement via une méthode dans MAMActivity au lieu d’appeler MAMPolicyManager.setUIPolicyIdentityOID. Utilisez la méthode suivante pour ce faire :

     public final void switchMAMIdentityOID(final String newIdentityOid, final EnumSet<IdentitySwitchOption> options);

Remarque

Si votre application n’a pas déclaré la prise en charge de la multi-identité dans le manifeste, l’appel de ces méthodes pour définir l’identité n’exécutera aucune action et, si elles renvoient un , renverra FAILEDtoujours .MAMIdentitySwitchResult

Les pièges courants du commutateur d’identité

• Pour les appels à startActivity, le SDK d’application Intune suppose que l’identité active au Context niveau est associée au paramètre fourniIntent. Nous recommandons vivement de définir l’identité de niveau Context avec un Activitycontexte , et non le Applicationcontexte de .

• Il est recommandé de définir l’identité pendant la Context méthode d’une onCreate activité. Toutefois, veillez à couvrir également d’autres points d’entrée tels que onNewIntent. Dans le cas contraire, lorsque la même activité est réutilisée pour afficher des données d’identités gérées et non gérées, la stratégie peut être appliquée de manière incorrecte, ce qui peut entraîner des données d’entreprise non protégées ou des données personnelles indûment restreintes.

Résultats du commutateur d’identité

Toutes les méthodes utilisées pour définir les valeurs de résultat du rapport d’identité via MAMIdentitySwitchResult. Quatre valeurs peuvent être renvoyées :

Valeur renvoyée	Scénario
SUCCEEDED	Le changement d’identité a réussi.
NOT_ALLOWED	Le changement d’identité n’est pas autorisé. Cela se produit si une tentative de définition de l’identité d’interface utilisateur (Context) est effectuée alors qu’une identité différente est définie sur le thread actuel.
CANCELLED	L’utilisateur annulait le changement d’identité, généralement en appuyant sur le bouton Précédent d’un code confidentiel ou d’une invite d’authentification.
FAILED	Le changement d’identité a échoué pour une raison non spécifiée.

L’application doit vérifier que le MAMIdentitySwitchResult est SUCCEEDED présent avant d’afficher ou d’utiliser les données d’un compte géré.

La plupart des méthodes de définition de l’identité active retournent MAMIdentitySwitchResult de façon synchrone. Dans le cas de la définition d’une Context identité via setUIPolicyIdentityOID, le résultat est signalé de manière asynchrone. L’application peut implémenter un MAMSetUIIdentityCallback pour recevoir ce résultat ou peut transmettre la valeur nulle pour l’objet de rappel. Si un appel est effectué alors setUIPolicyIdentityOID que le résultat d’un appel précédent sur setUIPolicyIdentityOIDle même Context n’a pas encore été remis, le nouveau rappel remplace l’ancien et le rappel d’origine ne reçoit jamais de résultat.

Attention

Si le Context fourni à setUIPolicyIdentityOID est un Activity, le SDK ne sait pas si la modification d’identité a réussi tant qu’il n’a pas effectué les vérifications de lancement conditionnel configurées par l’administrateur. Cela peut nécessiter que l’utilisateur entre un code confidentiel ou des informations d’identification d’entreprise.

Actuellement, les commutateurs d’identité de processus et de thread réussiront toujours pour une application prenant en charge plusieurs identités. Le Kit de développement logiciel (SDK) se réserve le droit d’ajouter des conditions d’échec à l’avenir.

Le commutateur d’identité de l’interface utilisateur peut échouer pour les arguments non valides, s’il est en conflit avec l’identité du thread ou si l’utilisateur annule les exigences de lancement conditionnel (par exemple, en appuyant sur le bouton Retour sur l’écran du code PIN).

Le comportement par défaut d’un commutateur d’identité de l’interface utilisateur échoué sur une activité consiste à terminer l’activité. Pour modifier ce comportement et recevoir des notifications lors des tentatives de changement d’identité pour une activité, vous pouvez remplacer une méthode dans MAMActivity.

    public void onSwitchMAMIdentityComplete(final MAMIdentitySwitchResult result);

Si vous remplacez onSwitchMAMIdentityComplete (ou appelez la super méthode), vous devez vous assurer que les données d’un compte géré ne s’affichent pas après l’échec d’un changement d’identité.

Remarque

Le changement d’identité peut nécessiter la recréation de l’activité. Dans ce cas, le onSwitchMAMIdentityComplete rappel sera remis à la nouvelle instance de l’activité.

Identity, Intents, and IdentitySwitchOptions

En plus de baliser automatiquement les nouveaux fichiers avec l’identité active, le Kit de développement logiciel (SDK) balise également les intentions avec l’identité active. Par défaut, le Kit de développement logiciel (SDK) case activée l’identité d’une intention entrante et la compare à l’identité active. Si ces identités ne correspondent pas, le SDK demande généralement(*) un commutateur d’identité (consultez la section Modifications d’identité implicites ci-dessous pour plus d’informations).

Le Kit de développement logiciel (SDK) stocke également cette identité d’intention entrante pour une utilisation ultérieure. Lorsque l’application modifie explicitement l’identité de l’interface utilisateur, le Kit de développement logiciel (SDK) compare l’identité vers laquelle l’application tente de basculer à l’identité d’intention entrante la plus récente. Si ces identités ne correspondent pas, le SDK échoue généralement (*) au commutateur d’identité.

Le Kit de développement logiciel (SDK) effectue cette case activée, car il considère que l’application affiche toujours du contenu à partir de l’intention qui appartient à l’identité associée à l’intention. Cette hypothèse protège contre le fait que l’application désactive involontairement les protections lors de l’affichage de données gérées ; Toutefois, cette hypothèse peut ne pas être correcte par rapport au comportement réel de l’application.

Les énumérations IdentitySwitchOption facultatives peuvent être transmises aux API setUIPolicyIdentityOID et switchMAMIdentityOID pour modifier le comportement par défaut du kit de développement logiciel (SDK).

• IGNORE_INTENT: lors de la demande d’un commutateur d’identité au niveau de la couche d’interface utilisateur, cette option informe le SDK d’ignorer la comparaison du paramètre d’identité demandé avec l’identité d’intention stockée le plus récemment. Cela est utile lorsque votre application n’affiche plus le contenu appartenant à cette identité et que le SDK ne doit pas bloquer ce commutateur d’identité. Par exemple :

  1. Votre application est une visionneuse de documents. Il peut restituer les documents transmis à partir d’autres applications. Il contient également une fonctionnalité permettant aux utilisateurs de changer de compte. Chaque fois que l’utilisateur utilise cette fonctionnalité de changement de compte, l’application accède à une page d’accueil spécifique au compte avec les documents récents de ce compte.
  2. Votre application reçoit une intention d’afficher un document. Cette intention est marquée avec l’identité managée.
  3. Votre application bascule vers l’identité gérée et affiche ce document, avec les protections correctement appliquées.
  4. L’utilisateur utilise le sélecteur de compte pour accéder à son compte personnel.

  Votre application doit modifier l’identité de l’interface utilisateur à l’étape 4. Dans ce cas, étant donné que le comportement de l’application est de quitter les données du compte géré (le document dans l’intention), elle doit l’utiliser IGNORE_INTENT dans l’appel de commutateur d’identité. Cela permet d’éviter l’échec inapproprié du Kit de développement logiciel (SDK) lors de cet appel.

• DATA_FROM_INTENT: lors de la demande d’un commutateur d’identité au niveau de la couche d’interface utilisateur, cette option informe le SDK que les données de l’identité d’intention stockée la plus récente continueront d’être affichées une fois le changement d’identité réussi. Par conséquent, le Kit de développement logiciel (SDK) évalue entièrement la stratégie de réception par rapport à l’identité d’intention précédente pour déterminer si elle est autorisée à être affichée. Par exemple :

  1. Votre application est une visionneuse de documents. Il peut restituer les documents transmis à partir d’autres applications. Il contient également une fonctionnalité permettant aux utilisateurs de changer de compte. Contrairement à l’exemple précédent, chaque fois que l’utilisateur utilise cette fonction de changement de compte, l’application accède à une page partagée qui affiche les documents récents pour tous les comptes ».
  2. Votre application reçoit une intention d’afficher un document. Cette intention est marquée avec l’identité managée.
  3. Votre application bascule vers l’identité gérée et affiche ce document, avec les protections correctement appliquées.
  4. L’utilisateur utilise le sélecteur de compte pour accéder à son compte personnel.

  Votre application doit modifier l’identité de l’interface utilisateur à l’étape 4. Dans ce cas, étant donné que le comportement de l’application est de continuer à afficher les données de l’identité managée (un aperçu du document dans l’intention), elle doit l’utiliser DATA_FROM_INTENT dans l’appel de commutateur d’identité. Ceci informe le Kit de développement logiciel (SDK) pour case activée la stratégie de protection des applications configurée afin de déterminer s’il est approprié que les données continuent d’être affichées.

(*) Le comportement par défaut du Kit de développement logiciel (SDK) inclut une casse spéciale qui ignore cette entrée de données case activée si, par exemple, l’intention provient de la même application ou du lanceur système.

Effacement de l’identité active

Votre application peut avoir des scénarios qui sont indépendants du compte. Votre application peut également avoir des scénarios pour des scénarios locaux non gérés qui ne nécessitent aucune connexion. Dans ces deux cas, votre application peut ne pas vouloir que le SDK applique les stratégies de l’identité managée, mais vous n’avez peut-être pas d’identité explicite vers laquelle basculer.

Vous pouvez effacer l’identité active en appelant l’une des méthodes d’identité définies avec le paramètre OID d’identité défini sur null. L’effacement de l’identité à un niveau amène le Kit de développement logiciel (SDK) à rechercher l’identité active à d’autres niveaux, en fonction de l’ordre de priorité.

Vous pouvez également transmettre une chaîne vide en tant que paramètre OID d’identité, ce qui définit l’identité sur une valeur vide spéciale traitée comme une identité non managée. La définition de l’identité active sur une chaîne vide indique au SDK de n’appliquer aucune stratégie de protection des applications.

Modifications implicites de l’identité

La section ci-dessus décrit les différentes façons dont votre application peut définir explicitement l’identité active au niveau du thread, du contexte et du processus. Toutefois, l’identité active dans votre application peut également changer sans que votre application appelle l’une de ces méthodes. Cette section décrit comment votre application peut écouter et répondre à ces modifications d’identité implicites.

L’écoute de ces modifications d’identité implicites est facultative, mais recommandée. Le Kit de développement logiciel (SDK) ne modifiera jamais l’identité active sans fournir ces notifications implicites de modification d’identité.

Attention

Si votre application choisit de ne pas écouter les modifications d’identité implicites, veillez à ne pas supposer l’identité active. En cas de doute, utilisez les getCurrentThreadIdentityOIDméthodes , getUIPolicyIdentityOIDet pour getProcessIdentityOID confirmer l’identité active.

Sources de modifications d’identité implicites

• L’entrée de données à partir d’autres applications gérées par le Intune peut modifier l’identité active au niveau du thread et du contexte.

  • Si une activité est lancée à partir d’une activité envoyée par une Intent autre application GAM, l’identité de l’activité est définie en fonction de l’identité active dans l’autre application au moment de l’envoi Intent .

    • Par exemple, une activité permettant d’afficher un document Word est lancée à partir d’une intention de Microsoft Outlook lorsqu’un utilisateur sélectionne une pièce jointe d’un document. L’identité de l’activité de visionneuse de documents d’Office est basculée vers l’identité à partir d’Outlook.

  • Pour les services, l’identité du thread sera définie de la même façon pour la durée d’un onStart appel ou onBind . Les appels dans les Binder éléments onBind renvoyés définissent également temporairement l’identité du thread.

  • Les appels à un ContentProvider testament définissent de la même manière l’identité du thread pour leur durée.

• L’interaction de l’utilisateur avec une activité peut modifier l’identité active au niveau du contexte. Par exemple :

  • L’annulation d’une invite d’autorisation entraîne Resume un basculement implicite vers une identité vide.

Gestion des modifications d’identité implicites

Votre application peut éventuellement écouter et réagir à ces modifications d’identité implicites. Par exemple, votre application peut nécessiter plusieurs étapes avant qu’un compte supplémentaire soit utilisable, comme une application de courrier électronique définissant une nouvelle boîte de réception. Lors d’une tentative de changement d’identité vers l’identité de ce compte incomplet, le gestionnaire de votre application peut rediriger l’utilisateur vers l’activité de configuration de compte avant d’accepter le changement d’identité. Le gestionnaire de votre application peut également afficher une boîte de dialogue d’erreur et bloquer le commutateur d’identité.

Votre application peut implémenter l’interface MAMIdentityRequirementListener sur un ou ContextProvider pour Service les changements d’identité s’appliquant à ce thread. Votre implémentation doit remplacer :

public abstract void onMAMIdentitySwitchRequired(String upn, String oid,
        AppIdentitySwitchResultCallback callback);

Votre application peut implémenter l’interface MAMActivityIdentityRequirementListener sur un Activity pour les modifications d’identité s’appliquant à cette activité. Votre implémentation doit remplacer :

public abstract void onMAMIdentitySwitchRequired(String upn, String oid,
        AppIdentitySwitchReason reason,
        AppIdentitySwitchResultCallback callback);

Le AppIdentitySwitchReason paramètre enum décrit la source du commutateur d’identité implicite.

Valeur d’énumération	Comportement du Kit de développement logiciel (SDK) par défaut	Description
CREATE	Autorisez le commutateur d’identité.	Le changement d’identité se produit en raison de la création d’une activité.
NEW_INTENT	Autorisez le commutateur d’identité.	Le commutateur d’identité se produit car une nouvelle intention est affectée à une activité.
RESUME_CANCELLED	Bloquez le commutateur d’identité.	Le changement d’identité se produit car un CV a été annulé. Cela se produit le plus souvent lorsque l’utilisateur final appuie sur le bouton Précédent de l’interface utilisateur du code confidentiel, de l’authentification ou de la conformité.

Le paramètre AppIdentitySwitchResultCallback permet aux développeurs de remplacer le comportement par défaut du commutateur d’identité :

public interface AppIdentitySwitchResultCallback {
  /**
    * @param result
    *            whether the identity switch can proceed.
    */
  void reportIdentitySwitchResult(AppIdentitySwitchResult result);
}
// Where [AppIdentitySwitchResult] is either `SUCCESS` or `FAILURE`.

onMAMIdentitySwitchRequired est appelé pour toutes les modifications d’identité implicites, à l’exception de celles effectuées via un classeur renvoyé à partir de MAMService.onMAMBind. Les implémentations par défaut de onMAMIdentitySwitchRequired immédiatement appellent :

• callback.reportIdentitySwitchResult(FAILURE) quand la raison est RESUME_CANCELLED.

• callback.reportIdentitySwitchResult(SUCCESS) dans tous les autres cas.

Il n’est pas prévu que la plupart des applications doivent bloquer ou retarder un commutateur d’identité d’une manière différente, mais si une application doit le faire, les points suivants doivent être pris en compte :

• Si un commutateur d’identité est bloqué, le comportement de l’utilisateur final est le même que si le paramètre de protection de l’application « recevoir des données d’autres applications » du SDK avait interdit l’entrée de données.

• Si un service s’exécute sur le thread principal, reportIdentitySwitchResultelle doit être appelée de façon synchrone, sinon le thread d’interface utilisateur cesse de répondre.

• Pour Activity la création, onMAMIdentitySwitchRequired sera appelé avant onMAMCreate. Si l’application doit afficher l’interface utilisateur pour déterminer si le changement d’identité doit être autorisé, cette interface utilisateur doit être affichée à l’aide d’une activité différente .

• Dans un Activity, lorsqu’un commutateur vers l’identité vide est demandé avec la raison comme RESUME_CANCELLED, l’application doit modifier l’activité reprise pour afficher des données cohérentes avec ce commutateur d’identité. Si cela n’est pas possible, l’application doit refuser le changement et l’utilisateur est invité à se conformer à la stratégie pour la reprise de l’identité (par exemple, en voyant l’écran de saisie du code confidentiel de l’application).

Attention

Une application à identités multiples peut recevoir des données entrantes d’applications gérées et non gérées. Il incombe à l’application de traiter les données des identités gérées de manière gérée.

Si une identité demandée est gérée (utilisez MAMPolicyManager.getIsIdentityOIDManaged to case activée), mais que l’application n’est pas en mesure d’utiliser ce compte (par exemple, parce que les comptes, tels que les comptes de messagerie, doivent d’abord être configurés dans l’application), le commutateur d’identité doit être refusé.

Le comportement MAMActivity.onMAMIdentitySwitchRequired par défaut de est accessible en appelant la méthode MAMActivity.defaultOnMAMIdentitySwitchRequired(activity, upn, oid, reason, callback)static .

De même, si vous devez remplacer MAMActivity.onSwitchMAMIdentityComplete, vous pouvez implémenter MAMActivityIdentitySwitchListener sans hériter explicitement de MAMActivity.

Commutateurs d’identité et restrictions de capture d’écran

Le Kit de développement logiciel (SDK) de l’application Intune utilise l’indicateur FLAG_SECURE pour appliquer la Window stratégie de capture d’écran. Certaines applications peuvent également définir FLAG_SECURE à leurs propres fins. Lorsque la stratégie de protection des applications ne limite pas les captures d’écran, le Kit de développement logiciel (SDK) ne modifie FLAG_SECUREpas.

Sur un commutateur d’identité d’une identité dont la stratégie nécessite la désactivation des captures d’écran vers une identité dont la stratégie ne le fait pas, le SDK efface FLAG_SECURE. Par conséquent, votre application ne doit pas rester FLAG_SECURE en place après un changement d’identité.

Préservation de l’identité dans les opérations asynchrones

Les applications distribuent souvent des tâches en arrière-plan à partir du thread d’interface utilisateur pour gérer les opérations sur d’autres threads. Une application multi-identité doit s’assurer que ces tâches en arrière-plan fonctionnent avec l’identité appropriée, qui est souvent la même identité utilisée par l’activité qui les a distribuées.

Le Kit de développement logiciel (SDK) d’application Intune fournit MAMAsyncTask et MAMIdentityExecutors pour faciliter la préservation de l’identité dans les opérations asynchrones. Votre application doit utiliser ces (ou définir explicitement l’identité de thread sur les tâches) si ses opérations asynchrones peuvent :

• Écrire dans un fichier les données appartenant à une identité managée
• Communiquer avec d’autres applications

MAMAsyncTask

Pour utiliser MAMAsyncTask, il suffit d’en hériter au lieu de AsyncTask remplacer les substitutions de doInBackground et onPreExecute avec doInBackgroundMAM et onPreExecuteMAM respectivement. Le MAMAsyncTask constructeur prend un contexte d’activité. Par exemple :

AsyncTask<Object, Object, Object> task = new MAMAsyncTask<Object, Object, Object>(thisActivity) {

    @Override
    protected Object doInBackgroundMAM(final Object[] params) {
        // Do operations.
    }

    @Override
    protected void onPreExecuteMAM() {
        // Do setup.
    };
}

MAMAsyncTask assumera l’identité active en fonction de l’ordre de priorité normal.

MAMIdentityExecutors

MAMIdentityExecutorsvous permet d’encapsuler une ou une instance existante Executor en ExecutorService tant qu’identité en préservantExecutorService/Executor l’identité avec wrapExecutor et wrapExecutorService les méthodes. Par exemple

Executor wrappedExecutor = MAMIdentityExecutors.wrapExecutor(originalExecutor, activity);
ExecutorService wrappedService = MAMIdentityExecutors.wrapExecutorService(originalExecutorService, activity);

MAMIdentityExecutors assumera l’identité active en fonction de l’ordre de priorité normal.

Protection des fichiers

Écriture de Files protégés

Comme mentionné dans Organisation des données d’application par identité ci-dessus, le SDK d’application Intune associe l’identité active (du niveau thread/processus) aux fichiers au fur et à mesure de leur écriture. Il est essentiel que la bonne identité soit définie au moment de la création du fichier pour garantir un chiffrement approprié et une fonctionnalité d’effacement sélectif.

Votre application peut interroger ou modifier l’identité d’un fichier à l’aide de la classe MAMFileProtectionManager , spécifiquement MAMFileProtectionManager.getProtectionInfo pour l’interrogation et MAMFileProtectionManager.protectForOID la modification.

Cette protectForOID méthode peut également être utilisée pour protéger les répertoires. La protection d’annuaire s’applique récursivement à tous les fichiers et sous-répertoires contenus dans le répertoire. Lorsqu’un répertoire est protégé, tous les nouveaux fichiers créés dans le répertoire bénéficient automatiquement de la même protection. Étant donné que la protection d’annuaire est appliquée récursivement, l’exécution de l’appel protectForOID peut prendre un certain temps pour les répertoires volumineux. Pour cette raison, les applications appliquant une protection à un répertoire qui contient un grand nombre de fichiers peuvent souhaiter s’exécuter protectForOID de manière asynchrone sur un thread d’arrière-plan.

L’appel protectForOID avec une chaîne vide pour le paramètre identity marque le fichier/répertoire avec l’identité non managée. Cette opération supprime le chiffrement du fichier/répertoire s’il était précédemment chiffré. Lorsqu’une commande d’effacement sélectif est émise, le fichier/répertoire ne sera pas supprimé.

Avertissement

Il est important de s’assurer que seuls les fichiers appartenant à une identité particulière sont protégés par cette identité. Dans le cas contraire, d’autres identités risquent de subir une perte de données lorsque l’identité propriétaire se déconnecte, car les fichiers seront effacés et l’accès aux clés de chiffrement sera perdu.

Affichage du contenu de fichier protégé

Il est tout aussi essentiel que la bonne identité soit définie lors de l’affichage du contenu du fichier pour empêcher les utilisateurs non autorisés d’afficher les données gérées. Le Kit de développement logiciel (SDK) ne peut pas déduire automatiquement une relation entre les fichiers en cours de lecture et les données affichées dans un Activityfichier . Les applications doivent définir l’identité de l’interface utilisateur de manière appropriée avant d’afficher les données gérées. Cela inclut les données lues dans les fichiers.

Si un fichier provient de l’extérieur de l’application (à partir d’un ContentProvider emplacement accessible en écriture ou lu à partir d’un emplacement accessible en écriture publique), l’application doit tenter de déterminer l’identité du fichier (à l’aide de la surcharge MAMFileProtectionManager.getProtectionInfo correcte pour la source de données) avant d’afficher les informations lues à partir du fichier.

Si getProtectionInfo elle signale une identité non null et non vide, l’application doit définir l’identité de l’interface utilisateur pour qu’elle corresponde à cette identité à l’aide de MAMActivity.switchMAMIdentityOID ou MAMPolicyManager.setUIPolicyIdentityOID. Si le commutateur d’identité échoue, les données du fichier ne doivent pas être affichées.

Lors de la lecture à partir d’un URI de contenu, il peut être nécessaire de lire d’abord l’identité (via la getProtectionInfo surcharge en prenant un Uri), puis de définir le contexte ou l’identité du thread de manière appropriée. Cette opération doit être effectuée avant l’ouverture d’un descripteur de fichier ou d’un flux d’entrée sur le ContentResolver, sinon l’opération peut échouer.

Un exemple de flux peut se présenter comme suit :

• L’utilisateur sélectionne un document à ouvrir dans l’application.

• Pendant le flux ouvert, avant de lire les données à partir du disque, l’application confirme l’identité qui doit être utilisée pour afficher le contenu :

  MAMFileProtectionInfo info = MAMFileProtectionManager.getProtectionInfo(docPath)
  if (info != null)
      MAMPolicyManager.setUIPolicyIdentityOID(activity, info.getIdentityOID(), callback, EnumSet.noneOf<IdentitySwitchOption.class>)
  

• L’application attend qu’un résultat soit signalé pour rappeler.

• Si le résultat signalé est un échec, l’application n’affiche pas le document.

• L’application ouvre et affiche le fichier.

Si une application utilise Android DownloadManager pour télécharger des fichiers, le Kit de développement logiciel (SDK) tente de protéger ces fichiers automatiquement à l’aide de la priorité d’identité décrite précédemment. Le contexte utilisé pour récupérer le DownloadManager sera utilisé si l’identité du thread n’est pas définie. Si les fichiers téléchargés contiennent des données d’entreprise, il incombe à l’application d’appeler protectForOID si les fichiers sont déplacés ou recréés après le téléchargement.

Single-Identity transition vers plusieurs identités

Si une application précédemment publiée avec l’intégration d’Intune à identité unique intègre ultérieurement la multi-identité, les applications précédemment installées subiront une transition. Cette transition n’est pas visible pour l’utilisateur.

L’application n’est pas nécessaire pour gérer cette transition. Tous les fichiers créés avant la transition continueront d’être considérés comme gérés (ils resteront donc chiffrés si la stratégie de chiffrement est activée).

Si vous ne souhaitez pas que toutes les données d’application précédentes soient associées à l’identité gérée, vous pouvez détecter cette transition et supprimer explicitement la protection.

• Détectez la mise à niveau en comparant la version de votre application à une version connue dans laquelle la prise en charge de plusieurs identités a été ajoutée.
• Appelez protectForOID avec une chaîne vide pour le paramètre d’identité sur les fichiers ou les répertoires que vous ne souhaitez pas associer à l’identité managée.

Scénarios hors connexion

Le SDK de l’application Intune s’exécute en mode « hors connexion » lorsque l’application Portail d'entreprise n’est pas installée. Le balisage d’identité de fichier est sensible au mode hors connexion :

• Si le Portail d’entreprise n’est pas installé, l’identité des fichiers ne peut pas être marquée. L’appel de MAMFileProtectionManager.protectForOID en mode hors connexion est sûr, mais il n’aura aucun effet.

• Si le Portail d’entreprise est installé, mais que l’application n’a pas de stratégie de protection des applications, l’identité des fichiers ne peut pas être marquée de manière fiable.

• Lorsque le balisage d’identité de fichier devient disponible, tous les fichiers créés précédemment sont traités comme personnels/non gérés (appartenant à l’identité de chaîne vide), sauf dans les cas où l’application a été précédemment installée en tant qu’application gérée à identité unique, comme décrit dans Transition d’identité unique à identité multiple.

Pour éviter ces cas, les applications doivent éviter de créer des fichiers contenant des données de compte jusqu’à ce que l’enregistrement du compte soit terminé avec succès. Si votre application doit absolument créer des fichiers hors connexion, elle peut utiliser MAMFileProtectionManager.protectForOID pour corriger l’identité associée du fichier une fois le kit de développement logiciel (SDK) en ligne.

Protection de la mémoire tampon de données

Avertissement

L’écriture de données appartenant à plusieurs comptes dans un seul fichier n’est pas recommandée. Si possible, organisez les fichiers de votre application par identité.

Le Kit de développement logiciel (SDK) MAMDataProtectionManager fournit des méthodes de vérification et de modification de l’identité balisée sur des mémoires tampons de données spécifiques au format ou InputStream oubyte[].

MAMDataProtectionManager.protectForOID Permet à une application d’associer des données à une identité et, si l’identité est actuellement ciblée par une stratégie de chiffrement, de chiffrer les données. Ces données chiffrées peuvent être stockées sur disque dans un fichier.

MAMDataProtectionManager vous permet également d’interroger les données associées à l’identité et de les déchiffrer.

Les applications qui utilisent MAMDataProtectionManager doivent implémenter un récepteur pour la MANAGEMENT_REMOVED notification. Pour plus d’informations, consultez S’inscrire aux notifications du Kit de développement logiciel (SDK ).

Une fois cette notification terminée, les mémoires tampons qui étaient protégées via cette classe ne seront plus lisibles (si le chiffrement de fichier a été activé lorsque les mémoires tampons étaient protégées). Une application peut empêcher ces mémoires tampons de devenir illisibles en appelant MAMDataProtectionManager.unprotect toutes les mémoires tampons lors du traitement de la MANAGEMENT_REMOVED notification. Il est également prudent d’appeler protectForOID pendant cette notification, si vous souhaitez préserver les informations d’identité. Il est garanti que le chiffrement sera désactivé pendant la notification et que l’appel protectForOID du gestionnaire ne chiffrera pas les mémoires tampons de données.

Avertissement

Les opérations de chiffrement doivent être évitées au début du processus de l’application. Le Kit de développement logiciel (SDK) effectue l’initialisation du chiffrement de façon asynchrone dès que possible après le démarrage de l’application. Toutefois, si une application effectue une demande de chiffrement au démarrage de l’application, elle peut être bloquée jusqu’à ce que l’initialisation du chiffrement soit terminée.

Remarque

L’API de chiffrement du SDK d’application Intune doit être utilisée uniquement pour chiffrer les données, comme l’exige la stratégie Intune. Aucune protection ne sera appliquée aux comptes qui ne sont pas ciblés par la stratégie de chiffrement activée. Il ne peut donc pas être utilisé comme bibliothèque de chiffrement à usage général.

Fournisseurs de contenu

Une application multi-identités doit également protéger les données partagées via ContentProviders pour empêcher le partage inapproprié du contenu géré.

Votre application doit appeler la méthode isProvideContentAllowedForOid(provider, oid) statique MAMContentProvider avant de renvoyer du contenu. Si cette fonction renvoie false, le contenu ne doit pas être renvoyé à l’appelant.

L’appel isProvideContentAllowedForOid n’est pas nécessaire si vous ContentProvider renvoyez un ParcelFileDescriptor. Les descripteurs de fichier renvoyés par un fournisseur de contenu sont gérés automatiquement en fonction de l’identité du fichier.

Réinitialisation sélective

Par défaut, le SDK de l’application Intune gère automatiquement les réinitialisations sélectives, en supprimant tous les fichiers qui ont été associés à l’identité gérée. Ensuite, le SDK ferme l’application correctement, mettant fin aux activités et mettant fin au processus d’application.

Le Kit de développement logiciel (SDK) offre à votre application la possibilité facultative de compléter (recommandé) ou de remplacer le comportement d’effacement par défaut.

Le gestionnaire d’effacement par défaut du SDK ne gère pas les mémoires tampons de données protégées par MAMDataProtectionManager. Si votre application utilise cette fonctionnalité, elle doit compléter ou remplacer le gestionnaire d’effacement par défaut pour supprimer ces données.

Remarque

Compléter et remplacer le comportement d’effacement par défaut nécessitent la gestion de notifications spécifiques du Kit de développement logiciel (SDK). Pour plus d’informations sur l’implémentation des gestionnaires de notifications, consultez S’inscrire aux notifications du Kit de développement logiciel (SDK ).

Complément du comportement d’effacement par défaut

Pour compléter le comportement d’effacement par défaut du Kit de développement logiciel (SDK), votre application peut s’inscrire pour MAMNotificationTypeWIPE_USER_AUXILIARY_DATA.

Cette notification sera envoyée par le Kit de développement logiciel (SDK) avant d’effectuer l’effacement sélectif par défaut. Le SDK attend que le gestionnaire de notification de votre application se termine avant de supprimer les données et de mettre fin à l’application. Votre application doit effacer les données de façon synchrone et ne pas revenir tant que le nettoyage n’est pas terminé.

Les applications doivent fortement envisager de compléter le comportement d’effacement par défaut avec WIPE_USER_AUXILIARY_DATA, car le nettoyage spécifique à l’application est courant pour les applications multi-identités.

Remplacement du comportement d’effacement par défaut

Pour remplacer le comportement d’effacement par défaut du SDK, votre application peut s’inscrire pour MAMNotificationTypeWIPE_USER_DATA.

Avertissement

Une application ne doit jamais s’inscrire à la fois WIPE_USER_DATAWIPE_USER_AUXILIARY_DATAet .

Le remplacement du comportement d’effacement par défaut du SDK fait peser un risque considérable sur votre application. Votre application est entièrement responsable de la suppression de toutes les données associées à l’identité managée, y compris tous les fichiers et mémoires tampons de données qui ont été marqués pour cette identité.

• Si l’identité managée était protégée par le chiffrement et que le gestionnaire d’effacement personnalisé de votre application ne supprime pas entièrement toutes les données gérées, les fichiers gérés restants restent chiffrés. Ces données deviendront inaccessibles et votre application ne gérera peut-être pas les tentatives de lecture correcte des données chiffrées.
• Le gestionnaire de réinitialisation de votre application peut entraîner une perte de données pour les utilisateurs non gérés, s’il supprime les fichiers qui ne sont pas marqués avec l’identité gérée.

Si le gestionnaire de réinitialisation personnalisé de votre application supprime les données gérées d’un fichier mais souhaite laisser d’autres données dans le fichier, il doit remplacer l’identité du fichier (via MAMFileProtectionManager.protectForOID) par une identité non gérée ou une chaîne vide.

Votre gestionnaire d’effacement remplacé doit effacer les données de façon synchrone et ne pas revenir tant que tout le nettoyage n’est pas terminé.

Envisagez de fermer votre application manuellement après avoir effectué vos étapes de gestionnaire de réinitialisation personnalisée pour empêcher l’utilisateur d’accéder aux données en mémoire après une réinitialisation.

Critères de sortie

Prévoyez de consacrer beaucoup de temps à la validation de l’intégration de la multi-identité dans votre application. Avant de commencer les tests :

• Créez et attribuez une stratégie de protection des applications à un compte. Il s’agit de votre compte géré de test.
• Créez un autre compte, mais n’attribuez pas de stratégie de protection des applications à celui-ci. Il s’agit de votre compte non géré de test. Si votre application prend en charge plusieurs types de comptes au-delà de Microsoft Entra comptes, vous pouvez également utiliser un compte non Entra existant comme compte de test non géré.
• Familiarisez-vous à nouveau avec la façon dont la stratégie est appliquée dans votre application. Les tests multi-identités vous obligent à distinguer facilement quand votre application fonctionne et quand elle ne fonctionne pas avec une stratégie appliquée. Le paramètre de stratégie de protection des applications pour bloquer les captures d’écran est efficace pour tester rapidement l’application de la stratégie.
• Tenez compte de l’ensemble de l’interface utilisateur proposée par votre application. Énumérer les écrans sur lesquels les données de compte sont affichées. Votre application présente-t-elle uniquement les données d’un seul compte à la fois ou peut-elle présenter des données appartenant à plusieurs comptes en même temps ?
• Prenez en compte l’ensemble des fichiers créés par votre application. Énumérez les fichiers contenant des données appartenant à un compte, par opposition aux données au niveau du système.
  • Déterminez comment vous validerez le chiffrement sur chacun de ces fichiers.
• Considérez l’ensemble des façons dont votre application peut interagir avec d’autres applications. Énumérez tous les points d’entrée et de sortie. Quels types de données votre application peut-elle ingérer ? Quelles intentions diffuse-t-elle ? Quels fournisseurs de contenu implémente-t-il ?
  • Déterminez la façon dont vous exercerez chacune de ces fonctionnalités de partage de données.
  • Préparez un appareil de test qui a des applications gérées et non gérées qui peuvent interagir avec votre application.
• Réfléchissez à la façon dont votre application permet à l’utilisateur final d’interagir avec tous les comptes connectés. L’utilisateur doit-il basculer manuellement vers un compte pour que les données de ce compte s’affichent ?

Une fois que vous avez soigneusement évalué le comportement actuel de votre application, validez l’intégration multi-identité en exécutant la série de tests suivante. Notez qu’il ne s’agit pas d’une liste complète et que cela ne garantit pas que l’implémentation multi-identité de votre application est exempte de bogues.

Validation des scénarios de connexion et de déconnexion

Votre application multi-identité prend en charge jusqu’à 1 compte géré et plusieurs comptes non gérés. Ces tests permettent de s’assurer que votre intégration multi-identité ne modifie pas de manière inappropriée les protections lorsque les utilisateurs se connectent ou se déconnectent.

Pour ces tests, installez votre application et le Portail d’entreprise Intune. Ne vous connectez pas avant de commencer le test.

Scénario	Étapes
Connexion gérée d’abord	- Connectez-vous d’abord avec un compte géré et vérifiez que les données de ce compte sont gérées. - Connectez-vous avec un compte non géré et vérifiez que les données de ce compte ne sont pas gérées.
Se connecter d’abord non géré	- Connectez-vous d’abord avec un compte non géré et vérifiez que les données de ce compte ne sont pas gérées. - Connectez-vous avec un compte géré et vérifiez que les données de ce compte sont gérées.
Se connecter à plusieurs comptes gérés	- Connectez-vous d’abord avec un compte géré et vérifiez que les données de ce compte sont gérées. - Connectez-vous avec un deuxième compte géré et validez que l’utilisateur est bloqué sans supprimer au préalable le compte géré d’origine.
Déconnexion gérée	- Connectez-vous à votre application avec un compte géré et non géré. - Déconnectez-vous du compte géré. - Vérifiez que le compte géré est supprimé de votre application et que toutes les données de ce compte ont été supprimées. - Vérifiez que le compte non géré est toujours connecté, qu’aucune des données du compte non géré n’a été supprimée et que la stratégie n’est toujours pas appliquée.
Déconnexion non géré	- Connectez-vous à votre application avec un compte géré et non géré. - Déconnectez-vous du compte non géré. - Vérifiez que le compte non géré est supprimé de votre application et que toutes les données de ce compte ont été supprimées. - Vérifiez que le compte géré est toujours connecté, qu’aucune des données du compte non géré n’a été supprimée et que la stratégie est toujours appliquée.

Validation de l’identité active et du cycle de vie de l’application

Votre application multi-identités peut présenter des vues avec les données d’un seul compte et permettre à l’utilisateur de modifier explicitement le compte en cours d’utilisation. Il peut également présenter des vues avec les données de plusieurs comptes en même temps. Ces tests permettent de garantir que votre intégration multi-identité offre les protections appropriées pour l’identité active sur chaque page tout au long du cycle de vie de l’application.

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

Scénario	Étapes
Vue de compte unique, managée	- Passez au compte géré. - Accédez à toutes les pages de votre application qui présentent les données d’un seul compte. - Confirmez que la politique est appliquée sur chaque page.
Vue de compte unique, non gérée	- Passez au compte non géré. - Accédez à toutes les pages de votre application qui présentent les données d’un seul compte. - Confirmez que la politique n’est appliquée sur aucune page.
Vue multi-comptes	- Accédez à toutes les pages de votre application qui présentent simultanément les données de plusieurs comptes. - Confirmez que la politique est appliquée sur chaque page.
Pause gérée	- Sur un écran avec les données gérées affichées et la stratégie active, suspendez l’application en accédant à l’écran d’accueil de l’appareil ou à une autre application. - Reprenez l’application. - Confirmez que la politique est toujours appliquée.
Pause non gérée	- Sur un écran avec des données non gérées affichées et aucune stratégie active, suspendez l’application en accédant à l’écran d’accueil de l’appareil ou à une autre application. - Reprenez l’application. - Confirmez que la politique n’est pas appliquée.
Managed kill	- Sur un écran avec des données gérées affichées et une stratégie active, forcez l’arrêt de l’application. - Redémarrez l’application. - Confirmez que, si l’application reprend sur un écran avec les données du compte géré (attendues), la stratégie est toujours appliquée. Si l’application reprend sur un écran avec les données du compte non géré, confirmez que cette stratégie n’est pas appliquée.
Meurtre non géré	- Sur un écran avec des données non gérées affichées et une stratégie active, forcez l’arrêt de l’application. - Redémarrez l’application. - Confirmez que, si l’application reprend sur un écran avec les données du compte non géré (attendues), la stratégie n’est pas appliquée. Si l’application reprend sur un écran avec les données du compte géré, confirmez que la stratégie est toujours appliquée.
Commutateur d’identité ad hoc	- Expérimentez le basculement entre les comptes et mettez en pause / reprenez / tuez / redémarrez l’application. - Confirmez que les données du compte géré sont toujours protégées et que les données du compte non géré ne sont jamais protégées.

Validation des scénarios de partage de données

Votre application multi-identités peut envoyer et recevoir des données d’autres applications. Intune stratégies de protection des applications de ont des paramètres qui dictent ce comportement. Ces tests permettent de s’assurer que votre intégration multi-identité respecte ces paramètres de partage de données.

Pour ces tests, installez votre application et le Portail d’entreprise Intune ; connectez-vous avec un compte géré et non géré avant de commencer le test. De plus :

• Définissez la stratégie du compte géré comme suit :
  • « Envoyer des données d’organisation à d’autres applications » à « Applications gérées par une stratégie ».
  • « Recevoir des données d’autres applications » sur « Applications gérées par une stratégie ».
• Installez d’autres applications sur l’appareil de test :
  • Une application gérée, ciblée avec la même stratégie que votre application, qui peut envoyer et recevoir des données (comme Microsoft Outlook).
  • Toute application non gérée qui peut envoyer et recevoir des données.
• Connectez-vous à l’autre application gérée avec le compte de test géré. Même si l’autre application gérée est multi-identités, connectez-vous uniquement avec le compte géré.

Si votre application a la possibilité d’envoyer des données à d’autres applications, comme Microsoft Outlook envoyant une pièce jointe à Microsoft Office :

Scénario	Étapes
Identité gérée envoyée à une application non gérée	- Passez au compte géré. - Accédez à l’endroit où votre application peut envoyer des données. - Tentative d’envoi de données vers une application non gérée. - Vous devriez être bloqué pour envoyer des données à l’application non gérée.
Envoi d’identité managée à l’application managée	- Passez au compte géré. - Accédez à l’endroit où votre application peut envoyer des données. - Essayez d’envoyer des données à l’autre application gérée avec le compte géré connecté. - Vous devez être autorisé à envoyer des données à l’application gérée.
Identité non gérée envoyée à l’application gérée	- Passez au compte non géré. - Accédez à l’endroit où votre application peut envoyer des données. - Essayez d’envoyer des données à l’autre application gérée avec le compte géré connecté. - Vous devriez être bloqué pour envoyer des données à l’autre application gérée.
Identité non gérée Envoyer à une application non gérée	- Passez au compte non géré. - Accédez à l’endroit où votre application peut envoyer des données. - Tentative d’envoi de données vers une application non gérée. - Vous devez toujours être autorisé à envoyer les données d’un compte non géré à une application non gérée.

Votre application peut importer activement des données à partir d’autres applications, comme Microsoft Outlook joignant un fichier à partir de Microsoft OneDrive. Votre application peut également recevoir passivement des données d’autres applications, comme Microsoft Office ouvrant un document à partir d’une pièce jointe Microsoft Outlook. Le paramètre de stratégie de protection de l’application de réception couvre les deux scénarios.

Si votre application a la possibilité d’importer activement des données à partir d’autres applications :

Scénario	Étapes
Importation d’identité gérée à partir d’une application non gérée	- Passez au compte géré. - Accédez à l’endroit où votre application peut importer des données à partir d’autres applications. - Tentative d’importation de données à partir d’une application non gérée. - Vous devriez être bloqué pour importer des données à partir d’applications non gérées.
Importation d’identités managées à partir de l’application managée	- Passez au compte géré. - Accédez à l’endroit où votre application peut importer des données à partir d’autres applications. - Essayez d’importer des données de l’autre application gérée avec le compte géré connecté. - Vous devez être autorisé à importer des données à partir de l’autre application gérée.
Importation d’identité non gérée à partir d’une application gérée	- Passez au compte non géré. - Accédez à l’endroit où votre application peut importer des données à partir d’autres applications. - Essayez d’importer des données de l’autre application gérée avec le compte géré connecté. - Vous devriez être bloqué dans l’importation de données à partir de l’autre application gérée.
Importation d’identité non gérée à partir d’une application non gérée	- Passez au compte non géré. - Accédez à l’endroit où votre application peut importer des données à partir d’autres applications. - Tentative d’importation de données à partir d’une application non gérée. - Vous devez toujours être autorisé à importer des données à partir d’une application non gérée pour un compte non géré.

Si votre application a la possibilité de recevoir passivement des données d’autres applications :

Scénario	Étapes
Identité managée reçue d’une application non gérée	- Passez au compte géré. - Passez à l’application non gérée. - Accédez à l’endroit où il peut envoyer des données. - Essayez d’envoyer des données de l’application non gérée à votre application. - Le compte géré de votre application ne doit pas être en mesure de recevoir des données de l’application non gérée.
Identité managée reçue depuis l’application managée	- Passez au compte géré. - Basculez vers l’autre application gérée avec le compte géré connecté. - Accédez à l’endroit où il peut envoyer des données. - Essayez d’envoyer des données de l’application gérée à votre application. - Le compte géré de votre application doit être autorisé à recevoir des données de l’autre application gérée.
Identité non gérée Recevoir à partir d’une application gérée	- Passez au compte non géré. - Basculez vers l’autre application gérée avec le compte géré connecté. - Accédez à l’endroit où il peut envoyer des données. - Essayez d’envoyer des données de l’application gérée à votre application. - Le compte non géré de votre application ne doit pas être en mesure de recevoir des données de l’application gérée.
Identité non gérée Recevoir à partir d’une application non gérée	- Passez au compte non géré. - Passez à l’application non gérée. - Accédez à l’endroit où il peut envoyer des données. - Essayez d’envoyer des données de l’application non gérée à votre application. - Le compte non géré de votre application doit toujours être autorisé à recevoir des données de l’application non gérée.

Les échecs de ces tests peuvent indiquer que votre application n’a pas la bonne identité active définie lorsqu’elle tente d’envoyer ou de recevoir des données. Vous pouvez examiner ce problème en tirant parti des API d’obtention d’identité du Kit de développement logiciel (SDK) au moment de l’envoi/de la réception pour confirmer que l’identité active est correctement définie.

Validation des scénarios de réinitialisation sélective

Votre application multi-identité peut avoir complété ou remplacé le comportement d’effacement par défaut du kit de développement logiciel (SDK). Ces tests permettent de garantir que votre intégration multi-identité supprime correctement les données gérées lorsque des réinitialisations sont lancées, sans affecter les données non gérées.

Avertissement

Rappel, si votre application a tiré parti de , elle doit implémenter MAMDataProtectionManager.protectForOIDun gestionnaire pour soit WIPE_USER_AUXILIARY_DATA ou .WIPE_USER_DATA

Pour ces tests, installez votre application et le Portail d’entreprise Intune ; connectez-vous avec un compte géré et non géré avant de commencer le test. Pour les deux comptes, exercez des scénarios d’application qui stockent des données de compte.

Scénario	Conditions préalables	Étapes
Gestionnaire d’effacement supplémentaire	Votre application a implémenté un gestionnaire pour WIPE_USER_AUXILIARY_DATA	- Effectuez une réinitialisation sélective à partir du Centre d’administration Microsoft Intune. - Confirmez (généralement via la journalisation) que votre gestionnaire d’effacement a été exécuté avec succès. - Vérifiez que le compte géré est supprimé de votre application et que toutes les données de ce compte ont été supprimées. - Vérifiez que le compte non géré est toujours connecté, qu’aucune des données du compte non géré n’a été supprimée et que la stratégie n’est toujours pas appliquée.
Remplacer le gestionnaire de réinitialisation	Votre application a implémenté un gestionnaire pour WIPE_USER_DATA	- Effectuez une réinitialisation sélective à partir du Centre d’administration Microsoft Intune. - Confirmez (généralement via la journalisation) que votre gestionnaire d’effacement a été exécuté avec succès. - Vérifiez que le compte géré est supprimé de votre application et que toutes les données de ce compte ont été supprimées. - Vérifiez que le compte non géré est toujours connecté, qu’aucune des données du compte non géré n’a été supprimée et que la stratégie n’est toujours pas appliquée. - Vérifiez que votre application s’est correctement arrêtée ou qu’elle est toujours dans un état sain une fois votre gestionnaire de réinitialisation terminé.
Protection manuelle des fichiers	- Vos appels d’application MAMFileProtectionManager.protectForOID - Votre application a implémenté un gestionnaire pour WIPE_USER_DATA	- Assurez-vous d’avoir exercé des scénarios où votre application protégerait manuellement au moins un fichier appartenant au compte géré. - Effectuez une réinitialisation sélective à partir du Centre d’administration Microsoft Intune. - Vérifiez que les fichiers sont supprimés.
Protection manuelle de la mémoire tampon des données	- Vos appels d’application MAMDataProtectionManager.protectForOID - Votre application a implémenté un gestionnaire pour soit WIPE_USER_AUXILIARY_DATAWIPE_USER_DATA	- Assurez-vous d’avoir exercé des scénarios où votre application protégerait manuellement au moins un tampon de données appartenant au compte géré. - Effectuez une réinitialisation sélective à partir du Centre d’administration Microsoft Intune. - Vérifiez que les tampons de données sont supprimés des fichiers dans lesquels ils ont été stockés et que votre application peut toujours lire les données non gérées de ces fichiers.

Étapes suivantes

Une fois que vous avez rempli tous les critères de sortie ci-dessus, votre application est désormais intégrée en tant que multi-identité et peut appliquer des stratégies de protection des applications pour chaque identité. Les sections suivantes, Étape 6 : App Configuration et Étape 7 : Fonctionnalités de participation des applications, peuvent être requises ou non, en fonction de la prise en charge de la stratégie de protection des applications souhaitée par votre application. Si vous n’êtes pas sûr que l’une de ces sections s’applique à votre application, consultez à nouveau les décisions clés pour l’intégration du Kit de développement logiciel (SDK).