SDK d’application Intune pour Android - Multi-Identity

Article
10/31/2024

Le SDK d’application Microsoft Intune pour Android vous permet d’incorporer Intune stratégies de protection des applications (également appelées stratégies APP ou GAM) dans votre application Android Java/Kotlin native. Une application gérée par Intune est 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 : Planifier l’intégration.

Étape 5 : Identités multiples

Goals de phase

Déterminez si votre application a besoin de la prise en charge de plusieurs identités.
Comprendre comment le SDK Intune App perçoit les identités.
Refactorisez votre application pour la reconnaissance des identités.
Ajoutez du code pour informer le SDK des identités actives et changeantes dans votre application.
Testez minutieusement l’application de la stratégie de protection des applications pour les identités managées et non managées.

Terminologie relative aux identités

Les termes « utilisateur », « compte » et « identité » sont souvent utilisés indifféremment. Ce guide tente de différencier comme suit :

Utilisateur : l’être humain qui utilise le produit logiciel. En outre différencié en tant qu’utilisateur final, l’humain utilisant l’application Android et / l’administrateur administrateur utilisateur / administrateur Administrateur informatique / Professionnel de l’informatique, l’humain utilisant le centre d’administration Microsoft Intune.
Compte : l’enregistrement logiciel appartenant à un organization 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 SDK d’application Intune utilise pour identifier un compte de manière unique.

Arrière-plan

Par défaut, le SDK d’application Intune applique la stratégie à l’ensemble de votre application. Après avoir inscrit un compte avec la stratégie de protection des applications ciblée, le 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 des applications souhaité pour leur application. Ces applications sont considérées comme une identité unique. En effectuant les étapes précédentes, votre application s’est correctement intégrée 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 une stratégie à un niveau par identité. Si votre application prend déjà en charge plusieurs comptes connectés simultanément et que vous souhaitez conserver cette prise en charge multicomptes avec des stratégies de protection des applications, votre application est considérée comme multi-identité.

Conseil

Si vous n’êtes pas certain que l’application doit prendre en charge les protections à identité unique ou multi-identité, revisitez l’identité unique ou multi-identité de mon application ?

Avertissement

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

« Identité » dans le KIT de développement logiciel (SDK)

Lorsqu’une application intégrée au Kit de développement logiciel (SDK) inscrit 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 Kit de développement logiciel (SDK) utilisent l’OID fourni (également appelé ID Microsoft Entra ID ou AAD) comme identificateur de l’identité. Les API du SDK MAM 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 retourner une chaîne UPN, auquel cas l’UPN est à titre d’information uniquement.

Les paramètres d’identité ne respectent pas la casse. Les demandes adressées au SDK pour une identité peuvent ne pas retourner la casse utilisée lors de l’inscription ou de la définition de l’identité.

Attention

Pour les applications qui utilisent des méthodes déconseillées qui prennent ou retournent une chaîne UPN, les applications doivent s’assurer que la chaîne UPN d’identité passée à différents appels d’API est cohérente. Le passage de chaînes UPN incohérentes peut entraîner des fuites de données.

Identités managées et non managées

Comme décrit dans 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 une stratégie de protection des applications. Si le compte est ciblé avec une stratégie de protection des applications, 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 une 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 managées.

Actuellement, le KIT de développement logiciel (SDK) Intune App ne prend en charge qu’une seule identité managée par appareil. Dès qu’une application intégrée au Kit de développement logiciel (SDK) inscrit une identité managée, toutes les identités inscrites par la suite, même si elles sont actuellement ciblées avec des stratégies de protection des applications, sont traitées comme non managé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 avec la stratégie de protection des applications, le Kit de développement logiciel (SDK) retourne MAMEnrollmentManager.Result.WRONG_USER et invite l’utilisateur final à corriger. Pour plus d’informations, consultez S’inscrire aux notifications à partir du Kit de développement logiciel (SDK ).

Remarque

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

L’identité active

Votre application doit toujours tenir le KIT de développement logiciel (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 Kit de développement logiciel (SDK) n’a pas de connaissances spécifiques à l’application, il doit approuver l’application pour partager l’identité active correcte.

Si l’application indique incorrectement au KIT de développement logiciel (SDK) qu’une identité non managée est active lorsque l’identité managée est en cours d’utilisation, le SDK n’applique pas de protections. Cela peut entraîner une fuite de données qui met les données des utilisateurs en danger.
Si l’application indique de manière incorrecte au KIT de développement logiciel (SDK) que l’identité managée est active lorsqu’une identité non managée est en cours d’utilisation, le SDK applique des protections de manière inappropriée. Il ne s’agit pas d’une fuite de données, mais cela peut inutilement restreindre les utilisateurs non gérés et exposer les données des utilisateurs non gérés à un risque de suppression.

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

Organisation des données d’application par identité

Chaque fois que votre application écrit un nouveau fichier, le Kit de développement logiciel (SDK) associe (également appelé « balises ») une identité à ce fichier en fonction de l’identité actuelle du thread et du processus actifs. Votre application peut également appeler directement le Kit de développement logiciel (SDK) pour étiqueter manuellement un fichier avec une identité particulière (pour plus d’informations, consultez Écriture de fichiers protégés ). Le Kit de développement logiciel (SDK) utilise cette identité de fichier balisée pour le chiffrement de fichier et la réinitialisation sélective.

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

Si l’action de l’administrateur ou la stratégie configurée demande que les données managées soient réinitialisées, seuls les fichiers marqués avec l’identité managée sont supprimés.

Le Kit de développement logiciel (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 SDK entraîne une sous-protection ou une protection excessive 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 Kit de développement logiciel (SDK) fournit des fonctionnalités pour l’étiquetage des sous-ensembles de données dans un fichier. Pour plus d’informations, consultez Protection de la mémoire tampon de données.

Implémentation de plusieurs identités

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 sur les niveaux suivants en priorité décroissante :

Niveau de thread
Context (généralement Activity) niveau
Niveau du processus

Un jeu d’identités au niveau du thread remplace un jeu d’identités au Context niveau, qui remplace un jeu d’identités au niveau du processus.

Une identité définie sur un Context est utilisée uniquement dans les scénarios associés appropriés. Les opérations d’E/S de fichier, par exemple, n’ont pas de 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 classique 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 sur le ou Context les niveaux du thread.

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

Si votre application utilise un Service contexte pour lancer des intentions, utilise des programmes de résolution de contenu ou utilise 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 JobService thread comme requis par votre JobService implémentation. Par exemple, si vous traitez JobService des travaux pour une seule identité, envisagez de définir l’identité sur le JobService contexte. Si vous JobService traitez des travaux pour plusieurs identités, envisagez de définir l’identité au niveau du thread.

Attention

Les applications qui utilisent WorkManager doivent faire l’objet d’une attention particulière 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. Cette Context instance peut être partagée entre plusieurs Worker instances simultanément. Pour éviter tout comportement non défini, les applications doivent à la place définir une identité de thread dans en Worker.doWork() fonction des besoins de l’implémentation Worker .

Remarque

Étant donné que le CLIPBOARD_SERVICE est utilisé pour les opérations d’interface utilisateur, le KIT de développement logiciel (SDK) utilise l’identité de l’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);

Pour plus 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. Pour ce faire, utilisez la méthode suivante :

     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 plusieurs identités dans le manifeste, l’appel de ces méthodes pour définir l’identité n’exécutera aucune action et, si elles retournent un MAMIdentitySwitchResult, retournera FAILEDtoujours .

Pièges courants du changement 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 vous recommandons vivement de définir l’identité Context de niveau avec un Activitycontexte, et non le Applicationcontexte de .
Il est recommandé de définir l’identité Context pendant la méthode d’une onCreate activité. Toutefois, veillez également à couvrir d’autres points d’entrée tels que onNewIntent. Sinon, lorsque la même activité est réutilisée pour afficher des données pour les identités managées et non managé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 incorrectement 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 retourné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é de l’interface utilisateur (`Context`) est effectuée lorsqu’une identité différente est définie sur le thread actuel.
`CANCELLED`	L’utilisateur a annulé le changement d’identité, généralement en appuyant sur le bouton Précédent sur un code confidentiel ou une invite d’authentification.
`FAILED`	La modification de l’identité a échoué pour une raison non spécifiée.

L’application doit vérifier que MAMIdentitySwitchResult est SUCCEEDED avant d’afficher ou d’utiliser les données d’un compte managé.

La plupart des méthodes de définition de l’identité active retournent MAMIdentitySwitchResult de manière 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 passer la valeur Null pour l’objet de rappel. Si un appel est effectué à setUIPolicyIdentityOID alors que le résultat d’un appel précédent à setUIPolicyIdentityOIDsur le 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 le changement 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 changements d’identité de processus et de thread réussissent 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, appuie sur le bouton Précédent sur l’écran du code confidentiel).

Le comportement par défaut d’un commutateur d’identité d’interface utilisateur ayant échoué sur une activité consiste à terminer l’activité. Pour modifier ce comportement et recevoir des notifications sur les tentatives de modification 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 managé ne sont pas affichées après un basculement d’identité ayant échoué.

Remarque

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

Identity, Intents et IdentitySwitchOptions

En plus de marquer automatiquement les nouveaux fichiers avec l’identité active, le Kit de développement logiciel (SDK) étiquette également les intentions avec l’identité active. Par défaut, le Kit de développement logiciel (SDK) case activée l’identité sur une intention entrante et la compare à l’identité active. Si ces identités ne correspondent pas, le SDK demande généralement (*) un changement d’identité (voir 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 SDK compare l’identité vers laquelle l’application tente de basculer avec l’identité d’intention entrante la plus récente. Si ces identités ne correspondent pas, le SDK échoue généralement (*) au changement d’identité.

Le Kit de développement logiciel (SDK) effectue cette case activée, car il suppose que l’application affiche toujours le contenu de l’intention qui appartient à l’identité étiquetée sur l’intention. Cette hypothèse protège contre la désactivation involontaire des protections par l’application lors de l’affichage de données managées ; Toutefois, cette hypothèse peut ne pas être correcte pour le comportement réel de l’application.

Les énumérations IdentitySwitchOption facultatives peuvent être passées aux API setUIPolicyIdentityOID et switchMAMIdentityOID pour modifier le comportement par défaut du SDK.

IGNORE_INTENT: lors de la demande d’un commutateur d’identité au niveau de la couche d’interface utilisateur, cette option indique au SDK d’ignorer la comparaison du paramètre d’identité demandé avec l’identité d’intention la plus récemment stockée. Cela est utile lorsque votre application n’affiche plus le contenu appartenant à cette identité et que le KIT de développement logiciel (SDK) ne doit pas bloquer ce changement d’identité. Par exemple :
1. Votre application est une visionneuse de documents. Il peut afficher les documents transmis à partir d’autres applications. Il contient également une fonctionnalité dans laquelle les utilisateurs peuvent 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 est basculée vers l’identité managée et affiche ce document, avec des protections correctement appliquées.
4. L’utilisateur utilise le sélecteur de compte pour passer à 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 consiste à s’éloigner des données du compte managé (le document dans l’intention), elle doit utiliser IGNORE_INTENT dans l’appel du commutateur d’identité. Cela évite que le KIT de développement logiciel (SDK) échoue de manière inappropriée à 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 la dernière identité d’intention stockée 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 afficher les documents transmis à partir d’autres applications. Il contient également une fonctionnalité dans laquelle les utilisateurs peuvent changer de compte. Contrairement à l’exemple précédent, chaque fois que l’utilisateur utilise cette fonctionnalité 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 est basculée vers l’identité managée et affiche ce document, avec des protections correctement appliquées.
4. L’utilisateur utilise le sélecteur de compte pour passer à 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 consiste à continuer à afficher les données de l’identité managée (un aperçu du document dans l’intention), elle doit utiliser DATA_FROM_INTENT dans l’appel de commutateur d’identité. Cela indique au SDK de case activée la stratégie de protection des applications configurée pour déterminer si elle est appropriée pour que les données continuent d’être affichées.

(*) Le comportement par défaut du 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 indépendants du compte. Votre application peut également avoir 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 set identity avec le paramètre OID d’identité défini sur null. L’effacement de l’identité à un niveau amènera le SDK à rechercher l’identité active à d’autres niveaux, en fonction de l’ordre de priorité.

Vous pouvez également passer une chaîne vide en tant que paramètre OID d’identité, ce qui définit l’identité sur une valeur vide spéciale qui est traitée comme une identité non managée. La définition de l’identité active sur une chaîne vide indique au SDK de ne pas appliquer de 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 celle-ci appelle l’une de ces méthodes. Cette section décrit comment votre application peut écouter ces modifications d’identité implicites et y répondre.

L’écoute de ces modifications d’identité implicites est facultative, mais recommandée. Le Kit de développement logiciel (SDK) ne modifie jamais l’identité active sans fournir ces notifications implicites de changement 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 getProcessIdentityOID pour confirmer l’identité active.

Sources des modifications d’identité implicites

L’entrée de données à partir d’autres applications gérées par Intune peut modifier l’identité active au niveau du thread et du contexte.
- Si une activité est lancée à partir d’un Intent envoyé par une autre application GAM, l’identité de l’activité est définie en fonction de l’identité active dans l’autre application au point où le Intent a été envoyé.
  - Par exemple, une activité pour afficher un document Word est lancée à partir d’une intention à partir de Microsoft Outlook lorsqu’un utilisateur sélectionne une pièce jointe de document. L’identité de l’activité visionneuse de documents d’Office est basculée vers l’identité à partir d’Outlook.
- Pour les services, l’identité du thread est définie de la même façon pendant la durée d’un onStart appel ou onBind . Les appels dans le Binder retourné à partir de onBind définissent également temporairement l’identité du thread.
- Les appels dans un ContentProvider définissent de la même façon 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 :
- Un utilisateur annulant une invite d’autorisation pendant Resume entraîne un basculement implicite vers une identité vide.

Gestion des modifications d’identité implicites

Votre application peut éventuellement écouter ces modifications d’identité implicites et y réagir. Par exemple, votre application peut nécessiter plusieurs étapes avant qu’un compte ajouté soit utilisable, comme une application de messagerie qui configure une nouvelle boîte de réception. Après avoir vu une tentative de basculement d’identité vers l’identité de ce compte incomplet, le gestionnaire de votre application peut rediriger l’utilisateur vers l’activité de configuration du 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 les Service modifications d’identité appliquées à 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 pour les modifications d’identité Activity 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 changement d’identité.	Le changement d’identité se produit en raison d’une création d’activité.
`NEW_INTENT`	Autorisez le changement d’identité.	Le changement d’identité se produit parce qu’une nouvelle intention est affectée à une activité.
`RESUME_CANCELLED`	Bloquez le commutateur d’identité.	Le changement d’identité se produit parce qu’un CV a été annulé. Cela est le plus courant lorsque l’utilisateur final appuie sur le bouton Précédent sur le code confidentiel, l’authentification ou l’interface utilisateur de 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 par le biais d’un binder retourné à partir de MAMService.onMAMBind. Les implémentations par défaut de onMAMIdentitySwitchRequired appellent immédiatement :

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 devront bloquer ou retarder un changement 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 changement d’identité est bloqué, le comportement de l’utilisateur final est le même que si le paramètre de protection des applications « recevoir des données d’autres applications » du SDK avait interdit l’entrée des données.
Si un service s’exécute sur le thread main, reportIdentitySwitchResultdoit être appelé de manière synchrone, sinon le thread d’interface utilisateur cesse de répondre.
Pour Activity la création, onMAMIdentitySwitchRequired est appelé avant onMAMCreate. Si l’application doit afficher l’interface utilisateur pour déterminer s’il faut autoriser le changement d’identité, cette interface utilisateur doit être affichée à l’aide d’une activité différente .
Dans un Activity, lorsqu’un basculement vers l’identité vide est demandé avec la raison , RESUME_CANCELLEDl’application doit modifier l’activité reprise pour afficher des données cohérentes avec ce commutateur d’identité. Si ce n’est pas possible, l’application doit refuser le commutateur et l’utilisateur est invité à nouveau à se conformer à la stratégie de reprise d’identité (par exemple, en affichant l’écran d’entrée du code confidentiel de l’application).

Attention

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

Si une identité demandée est gérée (utilisez MAMPolicyManager.getIsIdentityOIDManaged pour 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 changement d’identité doit être refusé.

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

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 SDK d’application Intune utilise l’indicateur FLAG_SECURE pour appliquer la Window stratégie de capture d’écran. Certaines applications peuvent également être définies FLAG_SECURE à leurs propres fins. Lorsque la stratégie de protection des applications ne limite pas les captures d’écran, le SDK ne modifie FLAG_SECUREpas .

Sur une identité, passez d’une identité dont la stratégie nécessite la désactivation des captures d’écran à une identité dont la stratégie ne l’est pas, le KIT de développement logiciel (SDK) efface FLAG_SECURE. Par conséquent, votre application ne doit pas s’appuyer sur FLAG_SECURE l’ensemble restant après un changement d’identité.

Conservation 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 à plusieurs identités doit s’assurer que ces tâches en arrière-plan fonctionnent avec l’identité appropriée, qui est souvent la même identité que celle utilisée par l’activité qui les a distribuées.

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

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

MAMAsyncTask

Pour utiliser MAMAsyncTask, héritez simplement de celui-ci au lieu de AsyncTask et remplacez les remplacements de doInBackground et onPreExecute par 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 suppose l’identité active en fonction de l’ordre de priorité normal.

MAMIdentityExecutors

MAMIdentityExecutorsvous permet d’encapsuler un instance existant Executor en ExecutorService tant que méthode de préservation de l’identité/ExecutorServiceExecutoravec wrapExecutor et wrapExecutorService . Par exemple

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

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

Protection des fichiers

Écriture de fichiers 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 (à partir du niveau thread/processus) aux fichiers au fur et à mesure qu’ils sont écrits. Il est essentiel d’avoir l’identité correcte définie au moment de la création du fichier pour garantir un chiffrement approprié et une fonctionnalité de réinitialisation sélective.

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

La protectForOID méthode peut également être utilisée pour protéger les répertoires. La protection de répertoire s’applique de manière récursive à tous les fichiers et sous-répertoires contenus dans le répertoire. Lorsqu’un répertoire est protégé, la même protection est appliquée automatiquement à tous les nouveaux fichiers créés dans le répertoire. Étant donné que la protection d’annuaire est appliquée de manière récursive, l’appel protectForOID peut prendre un certain temps pour les répertoires volumineux. Pour cette raison, les applications appliquant la 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 a été précédemment chiffré. Lorsqu’une commande de réinitialisation sélective est émise, le fichier/répertoire n’est pas supprimé.

Avertissement

Il est important de s’assurer que seuls les fichiers appartenant à une identité particulière sont protégés avec cette identité. Sinon, d’autres identités peuvent subir une perte de données lorsque l’identité propriétaire se déconnecte, car les fichiers sont effacés et l’accès à la clé de chiffrement est perdu.

Affichage du contenu de fichier protégé

Il est tout aussi essentiel d’avoir l’identité correcte définie lorsque le contenu du fichier est affiché pour empêcher les utilisateurs non autorisés d’afficher les données managé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 Activity. Les applications doivent définir l’identité de l’interface utilisateur de manière appropriée avant d’afficher des données managées. Cela inclut les données lues à partir de fichiers.

Si un fichier provient de l’extérieur de l’application (à partir d’un ContentProvider ou lu à partir d’un emplacement accessible publiquement en écriture), 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 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 prenant un Uri), puis de définir l’identité de contexte ou de thread de manière appropriée. Cette opération doit être effectuée avant d’ouvrir un descripteur de fichier ou un flux d’entrée sur le ContentResolver, sinon l’opération risque d’échouer.

Un exemple de flux peut ressembler à ce qui 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 le rappel.
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 en utilisant 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 à la transition multi-identité

Si une application précédemment publiée avec une seule identité Intune intégration ultérieure intègre plusieurs identités, les applications précédemment installées connaissent une transition. Cette transition n’est pas visible par l’utilisateur.

L’application n’est pas tenue de gérer cette transition. Tous les fichiers créés avant la transition continueront d’être considérés comme gérés (ils restent 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é managé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 où 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 répertoires que vous ne souhaitez pas associer à l’identité managée.

Scénarios hors connexion

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

Si le Portail d'entreprise n’est pas installé, les fichiers ne peuvent pas être étiquetés d’identité. L’appel de MAMFileProtectionManager.protectForOID en mode hors connexion est sans échec, mais 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, les fichiers ne peuvent pas être étiquetés d’identité de manière fiable.
Lorsque l’étiquetage d’identité de fichier devient disponible, tous les fichiers créés précédemment sont traités comme personnels/non managé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 par une seule identité, comme décrit dans Transition d’identité unique à multi-identité.

Pour éviter ces cas, les applications doivent éviter de créer des fichiers contenant des données de compte jusqu’à ce que l’inscription du compte se termine correctement. Si votre application doit absolument créer des fichiers en mode hors connexion, elle peut utiliser MAMFileProtectionManager.protectForOID pour corriger l’identité associée du fichier une fois que le Kit de développement logiciel (SDK) est en ligne.

Protection de la mémoire tampon des données

Avertissement

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

MamDataProtectionManager du Kit de développement logiciel (SDK) fournit des méthodes permettant de vérifier et de modifier l’identité étiquetée sur des mémoires tampons de données spécifiques au byte[] format ou InputStream .

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, chiffrer les données. Ces données chiffrées sont adaptées au stockage 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 doivent MAMDataProtectionManager implémenter un récepteur pour la MANAGEMENT_REMOVED notification. Pour plus d’informations, consultez S’inscrire aux notifications à partir du Kit de développement logiciel (SDK ).

Une fois cette notification terminée, les mémoires tampons protégées via cette classe ne sont plus lisibles (si le chiffrement de fichier a été activé lorsque les mémoires tampons ont été protégées). Une application peut empêcher ces mémoires tampons de devenir illisibles en appelant MAMDataProtectionManager.unprotect sur toutes les mémoires tampons lors de la gestion de la MANAGEMENT_REMOVED notification. Il est également sûr d’appeler protectForOID pendant cette notification, si vous souhaitez conserver les informations d’identité. Le chiffrement est assuré d’être désactivé pendant la notification et l’appel protectForOID dans le gestionnaire ne chiffre pas les mémoires tampons de données.

Avertissement

Les opérations de chiffrement doivent être évitées au début du processus d’application. Le Kit de développement logiciel (SDK) effectue l’initialisation du chiffrement de manière asynchrone le plus tôt 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 Intune stratégie. Aucune protection n’est appliquée aux comptes qui ne sont pas ciblés avec la stratégie de chiffrement activée. Elle ne peut donc pas être utilisée comme bibliothèque de chiffrement à usage général.

Fournisseurs de contenu

Une application multi-identité doit également protéger les données partagées par le biais ContentProviderde pour empêcher le partage inapproprié de contenu managé.

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

L’appel isProvideContentAllowedForOid n’est pas obligatoire si votre ContentProvider retourne un ParcelFileDescriptor. Les descripteurs de fichiers retournés par le biais d’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 Intune App gère automatiquement les réinitialisations sélectives, en supprimant tous les fichiers qui ont été associés à l’identité managée. Ensuite, le SDK ferme l’application correctement, terminant les activités et tuant le processus de l’application.

Le SDK offre la possibilité facultative pour votre application de compléter (recommandé) ou de remplacer le comportement de réinitialisation par défaut.

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

Remarque

Pour compléter et remplacer le comportement de réinitialisation par défaut, vous devez gérer des notifications spécifiques du Kit de développement logiciel (SDK). Pour plus d’informations sur l’implémentation des gestionnaires de notification, consultez S’inscrire aux notifications à partir du Kit de développement logiciel (SDK ).

Complément au comportement de réinitialisation par défaut

Pour compléter le comportement de réinitialisation du SDK par défaut, votre application peut s’inscrire à MAMNotificationTypeWIPE_USER_AUXILIARY_DATA.

Cette notification est envoyée par le Kit de développement logiciel (SDK) avant d’effectuer la réinitialisation sélective par défaut. Le SDK attend que le gestionnaire de notifications 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 retourner tant que tout le nettoyage n’est pas terminé.

Les applications doivent fortement envisager de compléter le comportement de réinitialisation 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 de réinitialisation par défaut

Pour remplacer le comportement de réinitialisation du SDK par défaut, votre application peut s’inscrire à MAMNotificationTypeWIPE_USER_DATA.

Avertissement

Une application ne doit jamais s’inscrire à la fois WIPE_USER_DATA pour et WIPE_USER_AUXILIARY_DATA.

Le remplacement du comportement de réinitialisation du KIT de développement logiciel (SDK) par défaut expose votre application à des risques considérables. Votre application sera 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é étiquetés pour cette identité.

Si l’identité managée a été protégée par chiffrement et que le gestionnaire de réinitialisation personnalisé de votre application ne supprime pas entièrement toutes les données managées, tous les fichiers managés restants restent chiffrés. Ces données deviendront inaccessibles et votre application risque de ne pas gérer les tentatives de lecture des données chiffrées correctement.
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 étiquetés avec l’identité managée.

Si le gestionnaire de réinitialisation personnalisé de votre application supprime des données managé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 managée ou une chaîne vide.

Votre gestionnaire de réinitialisation remplacée doit effacer les données de façon synchrone et ne pas retourner tant que tout le nettoyage n’est pas terminé.

Envisagez de fermer votre application manuellement après avoir effectué les étapes de votre 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 multi-identité de votre application. Avant de commencer le test :

Créez et affectez 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. Il s’agit de votre compte non managé de test. Si votre application prend en charge plusieurs types de comptes au-delà de Microsoft Entra comptes, vous pouvez utiliser un compte non Entra existant comme compte de test non managé.
Refamiliez-vous avec la façon dont la stratégie est appliquée à l’intérieur de votre application. Les tests multi-identités vous obligent à distinguer facilement quand votre application fonctionne et 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 des stratégies.
Tenez compte de l’ensemble de l’interface utilisateur proposée par votre application. Énumérez les écrans dans lesquels les données de compte sont affichées. Votre application ne présente-t-elle jamais les données d’un seul compte à la fois ou peut-elle présenter des données appartenant à plusieurs comptes en même temps ?
Considérez l’ensemble des fichiers créés par votre application. Énumérez les fichiers qui contiennent des données appartenant à un compte, par opposition aux données au niveau du système.
- Déterminez comment vous allez valider le chiffrement sur chacun de ces fichiers.
Tenez compte de 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-il ? Quels fournisseurs de contenu implémente-t-il ?
- Déterminez comment vous allez exercer chacune de ces fonctionnalités de partage de données.
- Préparez un appareil de test qui dispose à la fois d’applications managées et non managé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 avant que les données de ce compte ne s’affichent ?

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

Votre application multi-identité prend en charge jusqu’à 1 compte managé et plusieurs comptes non managés. Ces tests permettent de s’assurer que votre intégration à plusieurs identités ne modifie pas incorrectement 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
Se connecter d’abord géré	- Connectez-vous d’abord avec un compte managé et vérifiez que les données de ce compte sont gérées. - Connectez-vous avec un compte non managé et vérifiez que les données de ce compte ne sont pas gérées.
Se connecter d’abord non managé	- Connectez-vous d’abord avec un compte non managé et vérifiez que les données de ce compte ne sont pas gérées. - Connectez-vous avec un compte managé et vérifiez que les données de ce compte sont gérées.
Se connecter à plusieurs gérés	- Connectez-vous d’abord avec un compte managé et vérifiez que les données de ce compte sont gérées. - Connectez-vous avec un deuxième compte managé et vérifiez que l’utilisateur ne peut pas se connecter sans supprimer au préalable le compte managé d’origine.
Déconnexion gérée	- Connectez-vous à votre application avec un compte géré et non managé. - Déconnectez-vous du compte managé. - 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 managé n’a été supprimée et que la stratégie n’est toujours pas appliquée.
Déconnexion non managée	- Connectez-vous à votre application avec un compte géré et non managé. - 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 managé n’a été supprimée et que la stratégie est toujours appliquée.

Validation de l’identité active et du cycle de vie des applications

Votre application multi-identité peut présenter des vues avec les données d’un seul compte et permettre à l’utilisateur de modifier explicitement le compte actuel en cours d’utilisation. Il peut également présenter des vues avec des données de plusieurs comptes en même temps. Ces tests permettent de garantir que votre intégration à plusieurs identités fournit 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 managé et non managé avant de commencer le test.

Scénario	Étapes
Vue de compte unique, gérée	- Basculez vers le compte managé. - Accédez à toutes les pages de votre application qui présentent les données d’un seul compte. - Vérifiez que la stratégie est appliquée à chaque page.
Vue de compte unique, non managée	- Basculez vers le compte non managé. - Accédez à toutes les pages de votre application qui présentent les données d’un seul compte. - Vérifiez que la stratégie n’est appliquée sur aucune page.
Affichage multi-comptes	- Accédez à toutes les pages de votre application qui présentent simultanément les données de plusieurs comptes. - Vérifiez que la stratégie est appliquée à chaque page.
Pause managée	- Sur un écran avec les données managé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. - Reprendre l’application. - Vérifiez que la stratégie est toujours appliquée.
Pause non managée	- Sur un écran avec des données non managé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. - Reprendre l’application. - Vérifiez que la stratégie n’est pas appliquée.
Kill managé	- Sur un écran avec les données managées affichées et la stratégie active, forcez l’arrêt de l’application. - Redémarrez l’application. - Vérifiez que, si l’application reprend sur un écran avec les données du compte managé (attendu), la stratégie est toujours appliquée. Si l’application reprend sur un écran avec les données du compte non géré, vérifiez que la stratégie n’est pas appliquée.
Destruction non managée	- Sur un écran avec des données non managées affichées et une stratégie active, forcez l’arrêt de l’application. - Redémarrez l’application. - Vérifiez que, si l’application reprend sur un écran avec les données du compte non managé (attendu), la stratégie n’est pas appliquée. Si l’application reprend sur un écran avec les données du compte géré, vérifiez que la stratégie est toujours appliquée.
Commutateur d’identité ad hoc	- Essayez de basculer entre les comptes et de suspendre/reprendre/tuer/redémarrer l’application. - Vérifiez que les données du compte géré sont toujours protégées et que les données du compte non managé ne sont jamais protégées.

Votre application multi-identité peut envoyer des données à d’autres applications et en recevoir. Les stratégies de protection des applications de Intune 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 managé et non managé avant de commencer le test. De plus :

Définissez la stratégie du compte managé 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 » en « Applications gérées par une stratégie ».
Installez d’autres applications sur l’appareil de test :
- Une application managé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 managée qui peut envoyer et recevoir des données.
Connectez-vous à l’autre application managée avec le compte de test managé. Même si l’autre application gérée est multi-identité, connectez-vous uniquement avec le compte managé.

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

Scénario	Étapes
Envoi d’identité managée à une application non managée	- Basculez vers le compte managé. - Accédez à l’emplacement où votre application peut envoyer des données. - Tentative d’envoi de données à une application non managée. - Vous devez être empêché d’envoyer des données à l’application non managée.
Envoi d’identité managée à une application managée	- Basculez vers le compte managé. - Accédez à l’emplacement où votre application peut envoyer des données. - Essayez d’envoyer des données à l’autre application managée avec le compte managé connecté. - Vous devez être autorisé à envoyer des données à l’application gérée.
Envoi d’identité non managée à une application managée	- Basculez vers le compte non managé. - Accédez à l’emplacement où votre application peut envoyer des données. - Essayez d’envoyer des données à l’autre application managée avec le compte managé connecté. - Vous devez être empêché d’envoyer des données à l’autre application gérée.
Envoi d’identité non managée à une application non managée	- Basculez vers le compte non managé. - Accédez à l’emplacement où votre application peut envoyer des données. - Tentative d’envoi de données à une application non managée. - Vous devez toujours être autorisé à envoyer les données d’un compte non managé à une application non managée.

Votre application peut importer activement des données à partir d’autres applications, comme Microsoft Outlook en 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 des applications 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é managée à partir d’une application non managée	- Basculez vers le compte managé. - Accédez à l’emplacement où votre application peut importer des données à partir d’autres applications. - Tentative d’importation de données à partir d’une application non managée. - Vous devez être empêché d’importer des données à partir d’applications non managées.
Importation d’identité managée à partir d’une application managée	- Basculez vers le compte managé. - Accédez à l’emplacement où votre application peut importer des données à partir d’autres applications. - Tentative d’importation de données à partir de l’autre application managée avec le compte managé connecté. - Vous devez être autorisé à importer des données à partir de l’autre application gérée.
Importation d’identité non managée à partir d’une application managée	- Basculez vers le compte non managé. - Accédez à l’emplacement où votre application peut importer des données à partir d’autres applications. - Tentative d’importation de données à partir de l’autre application managée avec le compte managé connecté. - Vous devez être empêché d’importer des données à partir de l’autre application gérée.
Importation d’identité non managée à partir d’une application non managée	- Basculez vers le compte non managé. - Accédez à l’emplacement où votre application peut importer des données à partir d’autres applications. - Tentative d’importation de données à partir d’une application non managée. - Vous devez toujours être autorisé à importer des données à partir d’une application non managée pour un compte non managé.

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

Scénario	Étapes
Réception d’identité managée à partir d’une application non managée	- Basculez vers le compte managé. - Basculez vers l’application non managée. - Accédez à l’emplacement où il peut envoyer des données. - Essayez d’envoyer des données de l’application non managé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 managée.
Réception de l’identité managée à partir d’une application managée	- Basculez vers le compte managé. - Basculez vers l’autre application gérée avec le compte managé connecté. - Accédez à l’emplacement où il peut envoyer des données. - Essayez d’envoyer des données de l’application gérée à votre application. - Le compte managé de votre application doit être autorisé à recevoir des données de l’autre application gérée.
Réception d’identité non managée à partir d’une application managée	- Basculez vers le compte non managé. - Basculez vers l’autre application gérée avec le compte managé connecté. - Accédez à l’emplacement où il peut envoyer des données. - Essayez d’envoyer des données de l’application gérée à votre application. - Le compte non managé de votre application ne doit pas être en mesure de recevoir des données de l’application gérée.
Réception d’identité non managée d’une application non managée	- Basculez vers le compte non managé. - Basculez vers l’application non managée. - Accédez à l’emplacement où il peut envoyer des données. - Essayez d’envoyer des données de l’application non managée à votre application. - Le compte non managé de votre application doit toujours être autorisé à recevoir des données de l’application non managée.

Les échecs de ces tests peuvent indiquer que votre application n’a pas l’identité active appropriée définie lorsqu’elle tente d’envoyer ou de recevoir des données. Vous pouvez examiner cela en tirant parti des API d’obtention d’identité du SDK au point d’envoi/réception pour vérifier que l’identité active est correctement définie.

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

Votre application multi-identité a peut-être complété ou remplacé le comportement de réinitialisation par défaut du SDK. Ces tests permettent de s’assurer que votre intégration multi-identité supprime correctement les données managées lorsque des réinitialisations sont lancées, sans affecter les données non managées.

Avertissement

Pour rappel, si votre application a MAMDataProtectionManager.protectForOIDutilisé , elle doit implémenter un gestionnaire pour 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 managé et non managé avant de commencer le test. Pour les deux comptes, exercice de scénarios d’application qui stockent des données de compte.

Scénario	Conditions préalables	Étapes
Gestionnaire de réinitialisation 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. - Vérifiez (généralement par le biais de la journalisation) que votre gestionnaire de réinitialisation s’est exécuté correctement. - 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 managé n’a été supprimée et que la stratégie n’est toujours pas appliquée.
Gestionnaire de réinitialisation remplacée	Votre application a implémenté un gestionnaire pour `WIPE_USER_DATA`	- Effectuez une réinitialisation sélective à partir du centre d’administration Microsoft Intune. - Vérifiez (généralement par le biais de la journalisation) que votre gestionnaire de réinitialisation s’est exécuté correctement. - 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 managé n’a été supprimée et que la stratégie n’est toujours pas appliquée. - Vérifiez que votre application s’est arrêtée correctement ou qu’elle est toujours dans un état sain une fois votre gestionnaire de réinitialisation terminé.
Protection manuelle des fichiers	- Votre application appelle `MAMFileProtectionManager.protectForOID` - Votre application a implémenté un gestionnaire pour `WIPE_USER_DATA`	- Vérifiez que vous avez des scénarios d’exercice dans lesquels votre application protégerait manuellement au moins un fichier appartenant au compte managé. - Effectuez une réinitialisation sélective à partir du centre d’administration Microsoft Intune. - Vérifiez que les fichiers sont supprimés.
Protection manuelle des mémoires tampons de données	- Votre application appelle `MAMDataProtectionManager.protectForOID` - Votre application a implémenté un gestionnaire pour `WIPE_USER_AUXILIARY_DATA` ou `WIPE_USER_DATA`	- Vérifiez que vous disposez de scénarios d’exercice dans lesquels votre application protégerait manuellement au moins une mémoire tampon de données appartenant au compte managé. - Effectuez une réinitialisation sélective à partir du centre d’administration Microsoft Intune. - Vérifiez que les mémoires tampons de données sont supprimées des fichiers dans lesquels elles ont été stockées et que votre application peut toujours lire les données non managées de ces fichiers.

Étapes suivantes

Une fois que vous avez rempli tous les critères de sortie ci-dessus, votre application est intégrée avec succès en tant que multi-identité et peut appliquer des stratégies de protection des applications par 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 ne savez pas si l’une de ces sections s’applique à votre application, passez en revue les décisions clés pour l’intégration du SDK.

Partager via

SDK d’application Intune pour Android - Multi-Identity

Étape 5 : Identités multiples

Goals de phase

Terminologie relative aux identités

Arrière-plan

« Identité » dans le KIT de développement logiciel (SDK)

Identités managées et non managées

L’identité active

Organisation des données d’application par identité

Implémentation de plusieurs identités

Définition de l’identité active

Pièges courants du changement d’identité

Résultats du commutateur d’identité

Identity, Intents et IdentitySwitchOptions

Effacement de l’identité active

Modifications implicites de l’identité

Sources des modifications d’identité implicites

Gestion des modifications d’identité implicites

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

Conservation de l’identité dans les opérations asynchrones

MAMAsyncTask

MAMIdentityExecutors

Protection des fichiers

Écriture de fichiers protégés

Affichage du contenu de fichier protégé

Single-Identity à la transition multi-identité

Scénarios hors connexion

Protection de la mémoire tampon des données

Fournisseurs de contenu

Réinitialisation sélective

Complément au comportement de réinitialisation par défaut

Remplacement du comportement de réinitialisation par défaut

Critères de sortie

Validation de l’identité active et du cycle de vie des applications

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

Étapes suivantes

Commentaires

Ressources supplémentaires

Partager via

SDK d’application Intune pour Android - Multi-Identity

Étape 5 : Identités multiples

Goals de phase

Terminologie relative aux identités

Arrière-plan

« Identité » dans le KIT de développement logiciel (SDK)

Identités managées et non managées

L’identité active

Organisation des données d’application par identité

Implémentation de plusieurs identités

Définition de l’identité active

Pièges courants du changement d’identité

Résultats du commutateur d’identité

Identity, Intents et IdentitySwitchOptions

Effacement de l’identité active

Modifications implicites de l’identité

Sources des modifications d’identité implicites

Gestion des modifications d’identité implicites

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

Conservation de l’identité dans les opérations asynchrones

MAMAsyncTask

MAMIdentityExecutors

Protection des fichiers

Écriture de fichiers protégés

Affichage du contenu de fichier protégé

Single-Identity à la transition multi-identité

Scénarios hors connexion

Protection de la mémoire tampon des données

Fournisseurs de contenu

Réinitialisation sélective

Complément au comportement de réinitialisation par défaut

Remplacement du comportement de réinitialisation par défaut

Critères de sortie

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

Validation de l’identité active et du cycle de vie des applications

Validation des scénarios de partage de données

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

Étapes suivantes

Commentaires

Ressources supplémentaires