Sdk d’application Intune pour iOS - Identités multiples

Étape 5 : Identités multiples (facultatif)

Par défaut, le Kit de développement logiciel (SDK) applique une stratégie à l’application dans son ensemble. Multi-identité est une fonctionnalité GAM que vous pouvez activer pour appliquer une stratégie à un niveau par identité. Cela nécessite plus de participation à l’application que d’autres fonctionnalités GAM.

L’application doit informer le SDK de l’application quand 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 nécessaire. 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 seront traités comme non gérés avec des paramètres de stratégie illimités.

Notez qu’une identité est simplement définie comme une chaîne. Les identités ne respectent pas la casse. Les demandes adressées au Kit de développement logiciel (SDK) pour une identité peuvent ne pas retourner la casse utilisée à l’origine lorsque l’identité a été définie.

Objectifs de la phase

• Déterminez si votre application a besoin de la prise en charge de plusieurs 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 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.

Vue d’ensemble des identités

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é du processus : définit l’identité à l’échelle du processus et est principalement utilisée pour les applications à identité unique. Cette identité affecte toutes les tâches, fichiers et interface utilisateur.

• Identité de l’interface utilisateur : détermine les stratégies appliquées aux tâches de l’interface utilisateur sur le thread principal, comme couper/copier/coller, code confidentiel, authentification et 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 au thread actuel. Cette identité affecte toutes les tâches, fichiers et 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 a une identité effective pour les tâches d’interface utilisateur et les tâches de fichier. Il s’agit de l’identité utilisée pour vérifier quelles stratégies, le cas échéant, doivent être appliquées. Si l’identité n’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 threads

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

Étant donné que NSOperationQueue est basé sur GCD, NSOperations s’exécute 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 au fur et à mesure qu’elles sont en cours d’exécution. Cette identité remplace l’identité héritée du thread de distribution.

En rapidité, en raison d’une conséquence de la façon dont le Kit de développement logiciel (SDK) propage les identités pour DispatchWorkItem, l’identité associée à un 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) effectue le suivi des identités des propriétaires de fichiers locaux et applique des stratégies en conséquence. Un propriétaire de fichier est établi lorsqu’un fichier est créé 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 effectue la tâche.

Les applications peuvent également définir explicitement l’identité du propriétaire du fichier à l’aide IntuneMAMFilePolicyManagerde . 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 qui ont des données provenant à la fois d’utilisateurs gérés et non managés, l’application est chargée de chiffrer les données de l’utilisateur géré. Vous pouvez chiffrer des données à l’aide des protect API et unprotect dans IntuneMAMDataProtectionManager.

La protect méthode accepte une identité qui peut être un utilisateur managé ou non managé. 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 encodent l’identité, mais les données ne sont pas chiffrées. Vous pouvez utiliser la protectionInfo méthode pour récupérer 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 protectionInfoForItemProvider méthode dans IntuneMAMDataProtectionManager. Si l’élément partagé est un fichier, le Kit de développement logiciel (SDK) gère la définition du propriétaire du fichier. Si l’élément partagé est des 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 plusieurs identités

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 de plusieurs 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.

Changer d’identité

• Changement 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 managé. L’interface utilisateur de lancement conditionnel ne s’exécute pas et aucune stratégie n’est appliquée sur l’application. L’application est chargée d’informer le KIT de développement logiciel (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 SDK avant que le fichier, la boîte aux lettres ou l’onglet ne soit réellement ouvert. Cette opération s’effectue 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 confidentiel et l’authentification.

  Le résultat du changement d’identité est retourné à l’application de manière asynchrone par le biais d’un gestionnaire de saisie semi-automatique. L’application doit différer 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 retourné. Si le changement d’identité a échoué, l’application doit annuler la tâche.

  Les applications multi-identités doivent éviter d’utiliser setProcessAccountId comme moyen 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 setCurrentThreadIdentity: de et setCurrentThreadIdentity:forScope:. Par exemple, l’application peut générer un thread d’arrière-plan, définir l’identité sur l’identité managée, puis effectuer des opérations de fichier sur des fichiers managés. Si l’application utilise setCurrentThreadAccountId:, l’application doit également utiliser getCurrentThreadAccountId pour 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 produit automatiquement. Il est préférable d’utiliser setCurrentThreadAccountId:forScope:.

  En rapidité, en raison de async/await, [IntuneMAMPolicyManager setCurrentThreadAccountId:] et [IntuneMAMPolicyManager setCurrentThreadAccountId:forScope:] ne sont pas disponibles. Utilisez plutôt rapidement pour définir l’identité IntuneMAMSwiftContextManager.setAccountId(_, forScope:)actuelle. Il existe des variantes de cette API pour les fermetures async, throwing et async throwing à passer.

• Commutateur d’identité initié par le SDK :

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

  Lorsque cette méthode est appelée, si l’application peut gérer la demande de basculer vers l’identité spécifiée, elle doit passer IntuneMAMAddIdentityResultSuccess dans le gestionnaire de saisie semi-automatique. Si elle ne peut pas gérer le changement d’identité, l’application doit passer IntuneMAMAddIdentityResultFailed dans le gestionnaire de saisie semi-automatique.

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

• Inscription automatique de l’identité initiée par le SDK :

  Lorsque le 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 de saisie semi-automatique et passer 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 réinitialise de manière sélective, le SDK appelle la wipeDataForAccountId méthode dans IntuneMAMPolicyDelegate. L’application est chargée de supprimer le compte d’utilisateur spécifié et 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 retourne FALSE à partir 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 retourner de valeur tant que toutes les données de l’utilisateur n’ont pas été supprimées (à l’exception des fichiers si l’application retourne FALSE).

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à des comptes Microsoft Entra, vous pouvez utiliser un compte non-AAD 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.

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

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 sur un appareil de test . ne vous connectez pas avant de commencer le test.

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 sur un appareil de test . Connectez-vous avec un compte managé et non managé avant de commencer le test.

Validation des scénarios de partage de données

Votre application multi-identité peut envoyer des données à d’autres applications et en recevoir. Les stratégies de protection des applications d’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 sur un appareil de test . 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 :

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 :

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

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.

É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 : Prise en charge de l’accès conditionnel de protection des applications et Étape 7 : Fonctionnalités d’affichage web, peuvent être nécessaires ou non, en fonction de la prise en charge de la stratégie de protection des applications souhaitée par votre application.