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

Remarque

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

Étape 5 : Multi-identité (facultatif)

Par défaut, le Kit de développement logiciel (SDK) applique une stratégie à l’application dans son ensemble. La fonctionnalité Gestion des identités multiples est une fonctionnalité GAM que vous pouvez activer pour appliquer une stratégie au niveau de chaque identité. Cela nécessite davantage de participation de l’application que d’autres fonctionnalités MAM.

L’application doit informer le SDK d’application lorsqu’elle a l’intention de modifier l’identité active. Le Kit de développement logiciel (SDK) avertit également l’application lorsqu’un changement d’identité est requis. Actuellement, une seule identité managée est prise en charge. Une fois que l’utilisateur a inscrit l’appareil ou l’application, le SDK utilise cette identité et la considère comme l’identité managée principale. Les autres utilisateurs de l’application sont traités comme non gérés avec des paramètres de stratégie non restreints.

Notez qu’une identité est simplement définie sous la forme d’une chaîne. Les identités ne sont pas sensibles à la casse. Les demandes d’identité adressées au SDK peuvent ne pas renvoyer la même casse que celle utilisée à l’origine lors de la définition de l’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.

Vue d’ensemble de l’identité

Une identité est simplement le nom d’utilisateur d’un compte (par exemple, user@contoso.com). Les développeurs peuvent définir l’identité de l’application aux niveaux suivants :

• Identité de processus : définit l’identité à l’échelle du processus et est principalement utilisée pour les applications d’identité unique. Cette identité affecte toutes les tâches, tous les fichiers et l’interface utilisateur.

• Identité de l’interface utilisateur : détermine les stratégies appliquées aux tâches d’interface utilisateur sur le thread principal, telles que couper/copier/coller, le code confidentiel, l’authentification et le partage de données. L’identité de l’interface utilisateur n’affecte pas les tâches de fichier telles que le chiffrement et la sauvegarde.

• Identité du thread : affecte les stratégies appliquées sur le thread actuel. Cette identité affecte toutes les tâches, tous les fichiers et l’interface utilisateur.

L’application est chargée de définir les identités de manière appropriée, que l’utilisateur soit géré ou non.

À tout moment, chaque thread dispose d’une identité effective pour les tâches d’interface utilisateur et les tâches de fichiers. Il s’agit de l’identité utilisée pour vérifier la case activée des stratégies à appliquer, le cas échéant. Si l’identité est « aucune identité » ou si l’utilisateur n’est pas géré, aucune stratégie n’est appliquée. Les diagrammes ci-dessous montrent comment les identités effectives sont déterminées.

Files d’attente de thread

Les applications distribuent souvent des tâches asynchrones et synchrones aux files d’attente de threads. Le SDK intercepte les appels du Grand Central Dispatch (GCD) et associe l’identité de thread actuelle aux tâches distribuées. Lorsque les tâches sont terminées, le SDK remplace temporairement l’identité de thread par l’identité associée aux tâches, termine les tâches, puis restaure l’identité de thread d’origine.

Parce qu’est NSOperationQueue construit sur GCD, NSOperations s’exécutera sur l’identité du thread au moment où les tâches sont ajoutées à NSOperationQueue. NSOperations ou les fonctions distribuées directement via GCD peuvent également modifier l’identité du thread actuel pendant leur exécution. Cette identité remplacera l’identité héritée du thread de distribution.

En rapide, en raison d’une conséquence de la façon dont le SDK propage les identités pour DispatchWorkItem, l’identité associée à a DispatchWorkItem est l’identité du thread qui a créé l’élément et non le thread qui le distribue.

Propriétaire du fichier

Le Kit de développement logiciel (SDK) suit l’identité des propriétaires de fichiers locaux et applique des stratégies en conséquence. Un propriétaire de fichier est établi lors de la création d’un fichier ou lorsqu’un fichier est ouvert en mode tronqué. Le propriétaire est défini sur l’identité de tâche de fichier effective du thread qui exécute la tâche.

Les applications peuvent également définir explicitement l’identité du propriétaire du fichier à l’aide de IntuneMAMFilePolicyManager. Les applications peuvent utiliser IntuneMAMFilePolicyManager pour récupérer le propriétaire du fichier et définir l’identité de l’interface utilisateur avant d’afficher le contenu du fichier.

Données partagées

Si l’application crée des fichiers contenant des données d’utilisateurs gérés et non gérés, l’application est responsable du chiffrement des données de l’utilisateur géré. Vous pouvez chiffrer les données à l’aide de l’API et protectunprotect dans IntuneMAMDataProtectionManager.

La protect méthode accepte une identité qui peut être un utilisateur géré ou non géré. Si l’utilisateur est géré, les données sont chiffrées. Si l’utilisateur n’est pas géré, un en-tête est ajouté aux données qui codent l’identité, mais les données ne sont pas chiffrées. Vous pouvez utiliser cette protectionInfo méthode pour retrouver le propriétaire des données.

Partager des extensions

Si l’application a une extension de partage, le propriétaire de l’élément partagé peut être récupéré via la méthode de IntuneMAMDataProtectionManager.protectionInfoForItemProvider Si l’élément partagé est un fichier, le SDK gère la définition du propriétaire du fichier. Si l’élément partagé est constitué de données, l’application est chargée de définir le propriétaire du fichier si ces données sont conservées dans un fichier et d’appeler l’API setUIPolicyAccountId avant d’afficher ces données dans l’interface utilisateur.

Activer la multi-identité

Par défaut, les applications sont considérées comme une identité unique. Le Kit de développement logiciel (SDK) définit l’identité du processus sur l’utilisateur inscrit. Pour activer la prise en charge multi-identités, ajoutez un paramètre booléen avec le nom MultiIdentity et la valeur YES au dictionnaire IntuneMAMSettings dans le fichier Info.plist de l’application.

Remarque

Lorsque la multi-identité est activée, l’identité de processus, l’identité d’interface utilisateur et les identités de thread sont définies sur néant. L’application est chargée de les définir correctement.

Changer d’identité

Importante

Le Kit de développement logiciel (SDK) ne peut pas détecter indépendamment les modifications d’identité. Il dépend entièrement de l’application pour les signaler. Si l’application n’avertit pas correctement le SDK d’un commutateur d’identité :

• Les stratégies de protection d’applications peuvent ne pas être appliquées pour l’utilisateur actif, laissant les données gérées sans protection.
• Les restrictions des données non gérées peuvent être incorrectes.

L’application doit appeler les API de changement d’identité appropriées (telles que setUIPolicyAccountId) chaque fois que l’utilisateur actif change, notamment lors du lancement de l’application, lors du changement de compte et lors de l’affichage de données pour un autre utilisateur.

• Commutateur d’identité initié par l’application :

  Au lancement, les applications multi-identités sont considérées comme s’exécutant sous un compte inconnu et non géré. L’interface utilisateur de lancement conditionnel ne s’exécute pas et aucune stratégie n’est appliquée à l’application. L’application est chargée d’avertir le SDK chaque fois que l’identité doit être modifiée. En règle générale, cela se produit chaque fois que l’application est sur le point d’afficher des données pour un compte d’utilisateur spécifique.

  Par exemple, lorsque l’utilisateur tente d’ouvrir un document, une boîte aux lettres ou un onglet dans un bloc-notes. L’application doit avertir le Kit de développement logiciel (SDK) avant l’ouverture du fichier, de la boîte aux lettres ou de l’onglet. Cela se fait via l’API setUIPolicyAccountId dans IntuneMAMPolicyManager. Cette API doit être appelée que l’utilisateur soit géré ou non. Si l’utilisateur est géré, le Kit de développement logiciel (SDK) effectue les vérifications de lancement conditionnel, telles que la détection de jailbreak, le code PIN et l’authentification.

  Le résultat du commutateur d’identité est renvoyé à l’application de manière asynchrone via un gestionnaire d’achèvement. L’application doit reporter l’ouverture du document, de la boîte aux lettres ou de l’onglet jusqu’à ce qu’un code de résultat de réussite soit renvoyé. Si le commutateur d’identité a échoué, l’application doit annuler la tâche.

  Les applications multi-identités doivent éviter setProcessAccountId de définir l’identité. Les applications qui utilisent UIScenes doivent utiliser l’API setUIPolicyAccountId:forWindow pour définir l’identité.

  Les applications peuvent également définir l’identité du thread actuel à l’aide de setCurrentThreadIdentity: et setCurrentThreadIdentity:forScope:. Par exemple, l’application peut générer un thread d’arrière-plan, définir l’identité sur l’identité gérée, puis effectuer des opérations de fichier sur les fichiers gérés. Si l’application utilise setCurrentThreadAccountId:, l’application doit également utiliser getCurrentThreadAccountId afin de pouvoir restaurer l’identité d’origine une fois l’opération terminée. Toutefois, si l’application utilise setCurrentThreadAccountId:forScope: , la restauration de l’ancienne identité se fait automatiquement. Il est préférable d’utiliser setCurrentThreadAccountId:forScope:.

  En rapide, en raison de async/await, [IntuneMAMPolicyManager setCurrentThreadAccountId:] et [IntuneMAMPolicyManager setCurrentThreadAccountId:forScope:] ne sont pas disponibles. Au lieu de cela, dans swift pour définir l’identité actuelle, utilisez IntuneMAMSwiftContextManager.setAccountId(_, forScope:). Il existe des variantes de cette API pour les fermetures asynchrones, de lancer et de lancer asynchrones à transmettre.

• Commutateur d’identité initié par le Kit de développement logiciel (SDK) :

  Parfois, le SDK doit demander à l’application de basculer vers une identité spécifique. Les applications multi-identités doivent implémenter la identitySwitchRequiredForAccountId méthode pour IntuneMAMPolicyDelegate gérer cette requête.

  Lorsque cette méthode est appelée, si l’application peut gérer la demande de basculement vers l’identité spécifiée, elle doit passer IntuneMAMAddIdentityResultSuccess au gestionnaire de complétion. S’il ne peut pas gérer le changement d’identité, l’application doit passer IntuneMAMAddIdentityResultFailed au gestionnaire de complétion.

  L’application n’a pas besoin d’appeler setUIPolicyAccountId en réponse à cet appel. Si le Kit de développement logiciel (SDK) a besoin que l’application bascule vers un compte d’utilisateur non géré, la chaîne vide est passée à l’appel identitySwitchRequiredForAccountId .

• Inscription automatique des identités initiée par le Kit de développement logiciel (SDK) :

  Lorsque le Kit de développement logiciel (SDK) doit inscrire automatiquement un utilisateur dans l’application pour effectuer une action, les applications doivent implémenter la addIdentity:completionHandler: méthode dans IntuneMAMPolicyDelegate. L’application doit ensuite appeler le gestionnaire d’achèvement et transmettre IntuneMAMAddIdentityResultSuccess si l’application est en mesure d’ajouter l’identité ou IntuneMAMAddIdentityResultFailed dans le cas contraire.

• Réinitialisation sélective :

  Lorsque l’application est effacée de manière sélective, le Kit de développement logiciel (SDK) appelle la wipeDataForAccountId méthode dans IntuneMAMPolicyDelegate. L’application est responsable de la suppression du compte de l’utilisateur spécifié et de toutes les données qui lui sont associées. Le Kit de développement logiciel (SDK) est capable de supprimer tous les fichiers appartenant à l’utilisateur et le fera si l’application renvoie FALSE de l’appel wipeDataForAccountId .

  Notez que cette méthode est appelée à partir d’un thread d’arrière-plan. L’application ne doit pas renvoyer de valeur tant que toutes les données de l’utilisateur n’ont pas été supprimées (à l’exception des fichiers si l’application renvoie FAUX).

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. Sinon, si votre application prend en charge plusieurs types de comptes au-delà des comptes Microsoft Entra, vous pouvez utiliser un compte non AAD 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 sur un appareil de test ; 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 sur un appareil de test ; Connectez-vous avec un compte géré et un compte 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 sur un appareil de test ; Connectez-vous avec un compte géré et un compte 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.

É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 : Prise en charge de l’accès conditionnel à la protection des applications et Étape 7 : fonctionnalités d’affichage Web, 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.