Découvrez le framework ManagedApp

Bonjour, je suis Bob Whiteman, ingénieur en gestion des appareils iOS. Je suis heureux de vous présenter un nouveau framework pour simplifier et sécuriser les apps dans les déploiements gérés. Partout, des organisations utilisent des appareils Apple dans les bureaux, les magasins et les écoles. Ils servent à apprendre, enseigner, travailler et créer. Les apps qui s’exécutent sur ces appareils rendent tout cela possible. Les administrateurs utilisent la gestion des appareils pour garantir que leurs équipes ont les apps nécessaires à leur succès. Les utilisateurs maîtrisent rapidement les apps de leur organisation. Ils ne configurent généralement ces apps qu’une seule fois, ce qui peut être intimidant. Ils doivent saisir un serveur, un nom d’utilisateur, un mot de passe et un code d’authentification à deux facteurs. Ils doivent ensuite configurer les paramètres de l’app selon les exigences de leur organisation. Il y a plusieurs étapes, et en cas de problème ou d’erreur, ça finit rarement bien. Ils peuvent renoncer à utiliser l’app par frustration. Le contact avec le support fait perdre du temps et alourdit les coûts pour l’organisation. L’organisation peut même décider de ne plus prendre en charge l’app. En tant que développeur, améliorer cette expérience demande des efforts qui ne font pas partie des fonctionnalités principales de votre app. Imaginez tout ce qu’il faudrait développer pour rendre cette expérience fluide. Vous implémentez la fédération avec le fournisseur d’identité de l’organisation. Vous créez et gérez un site de configuration permettant à l’administrateur de définir les paramètres qu’il transmet aux apps installées sur les appareils. Vous intégrez l’autorité de certification et l’infrastructure d’authentification de l’organisation pour que l’app puisse communiquer avec ses serveurs. Vous publiez des versions personnalisées de votre app pour offrir la marque et les fonctionnalités exigées par certaines organisations. Et si vous n’aviez pas besoin de faire tout ça ? Éliminons cette expérience de configuration complexe. L’app peut désormais être préconfigurée pour cette organisation, cet appareil et cette personne. Il n’y a plus besoin d’un processus de configuration. Dès le premier lancement, l’app est prête à l’emploi. Les premières impressions de l’app sont meilleures et elle est plus utilisée. Les administrateurs ont plus envie de la déployer, car leurs utilisateurs l’apprécient et les coûts de support sont réduits. Comment rendre cela possible ? J’ai le plaisir de vous présenter le framework ManagedApp. Il peut configurer automatiquement les apps gérées et leurs extensions. Les apps peuvent l’utiliser pour authentifier les appareils et simplifier l’authentification. L’utilisation du framework aide les apps à répondre aux exigences en sécurité des données et contrôle d’accès.

Pour cela, le framework ManagedApp permet à l’administrateur de fournir une configuration personnalisée des apps et de gérer les mots de passe, certificats et identités. Il est compatible avec d’autres technologies comme l’authentification unique extensible, l’attestation d’appareil géré et l’authentification unique. Le framework ManagedApp peut fournir 4 types de données. La configuration spécifique à une app correspond aux données particulières qu’elle peut gérer. Cela inclut les paramètres, options et petits éléments qui ont une importance pour cette app. Les 3 autres types sont des secrets : mots de passe, certificats et identités. Les identités peuvent être des fichiers PKCS #12, des identités SCEP ou des identités ACME. Les identités ACME prennent en charge les clés liées au matériel et l’attestation. Tous ces types de données sont stockés en toute sécurité et ne sont fournis qu’aux apps ou extensions gérées spécifiées par l’administrateur. Le framework ManagedApp est disponible avec iOS 18.4, iPadOS 18.4 et visionOS 2.4. Il nécessite un serveur MDM pour gérer l’app via la gestion déclarative des appareils. Il fonctionne dès l’installation de l’app ou lorsqu’il prend en charge la gestion d’une app déjà installée. Il fonctionne avec tous les types d’inscription MDM. Il prend en charge la plupart des extensions d’app, mais ne fonctionne pas avec celles s’exécutant dans un environnement très restreint. Une extension de clavier ne peut pas utiliser le framework ManagedApp sauf si elle bénéficie d’un accès complet. Dans cette séance, je vais décrire le workflow de développement et de déploiement, explorer certains scénarios où ce framework est utile, plonger dans du code, et partager de bonnes pratiques. D’abord, comment ça marche ? Commençons par un appareil qui est géré. L’administrateur utilise un serveur MDM pour envoyer des commandes et des requêtes de gestion à l’appareil avec le protocole MDM.

Il gère l’app, ce qui entraîne généralement son installation. En gérant l’app, l’administrateur définit la configuration et les secrets à fournir à l’app et à ses extensions.

Au lancement, l’app demande sa configuration et ses secrets à ManagedApp, qui lui en fournit une copie. L’app applique immédiatement la configuration et utilise les secrets selon les besoins. Par la suite, l’administrateur peut mettre à jour la configuration ou les secrets. Si l’app était en cours d’exécution, le framework la notifie et elle applique aussitôt les mises à jour. Mais avant tout cela, c’est à vous, en tant que développeur, d’écrire l’app. Vous créez un décodeur pour la configuration et le code pour l’appliquer et utiliser les secrets. Puis, vous écrivez et publiez une spécification qui indique aux administrateurs comment configurer votre app. Cette spécification décrit les clés et valeurs prises en charge dans la configuration de l’app, ce qu’elles contrôlent, les secrets attendus par l’app et leur utilisation. C’est ce qui me plaît vraiment avec ce framework. La configuration ne vient ni d’Apple, ni d’un protocole, ni du serveur MDM. Cela le rendrait générique dans toutes les apps et pas très utile. C’est vous, qui définissez comment votre app peut être configurée. Cela ouvre la voie à de nouvelles opportunités. Vous seul connaissez vraiment votre app. Vous êtes le mieux placé pour proposer des méthodes de configuration puissantes, utiles et innovantes afin d’optimiser votre app. ManagedApp n’est pas une solution clé en main. C’est une plate-forme où vous pouvez facilement créer votre solution. Dans cette optique, voyons quelques scénarios où le framework ManagedApp s’avère particulièrement utile. Et il y a tellement de scénarios où nous pouvons l’utiliser. Fournir des identifiants en toute sécurité à un navigateur tiers. Personnaliser une app interne selon le rôle de l’utilisateur. Configurer une extension Safari. Sécuriser les communications entre le service de gestion des appareils et son app de gestion. Je vais détailler 3 de ces scénarios, en commençant par la gestion des licences. Souvent, un développeur a besoin que le serveur de son app puisse attribuer les requêtes au bon client. Une solution courante est un jeton de licence. Lorsque l’organisation octroie une licence pour utiliser le serveur, le développeur lui fournit un jeton de licence unique. L’administrateur utilise MDM pour distribuer ce jeton à toutes les instances de l’app utilisées dans l’organisation. Lorsque l’app envoie une requête au serveur, elle y inclut le jeton de licence. Le serveur peut alors attribuer la requête à la bonne organisation. Cela pose un souci de sécurité. L’organisation doit protéger ce jeton lorsqu’il est stocké et distribué. Si une personne extérieure obtient le jeton, elle pourrait utiliser le serveur aux frais de l’organisation. Développeurs et administrateurs peuvent utiliser la configuration ManagedApp pour distribuer ce jeton aux appareils gérés. Toutefois, le framework ManagedApp est conçu pour protéger la configuration contre toute extraction ou manipulation. Plus important encore, le framework ManagedApp offre une meilleure option qu’un jeton de licence : une clé de licence. Le framework ManagedApp peut fournir une identité cryptographique à des fins de licence, plus sécurisée qu’un jeton. L’administrateur installe une identité cryptographique sur l’appareil, avec un certificat émis par l’organisation ou le développeur de l’app. La clé privée est générée sur l’appareil et n’en sort jamais, ce qui est plus sûr que de transmettre des jetons dans toute l’architecture. L’ancienne fonctionnalité de configuration ManagedApp ne prend pas en charge les clés de licence. Le framework ManagedApp est plus sécurisé, prend en charge les identités et les extensions d’app. Si votre app utilise la configuration ManagedApp, vous devriez passer au framework ManagedApp. Passons maintenant aux extensions VPN. Le framework ManagedApp est particulièrement utile pour ces extensions. Un serveur VPN exige une authentification renforcée pour s’assurer que l’appareil appartient à l’organisation et est autorisé à accéder au réseau. L’architecture est très similaire au scénario précédent, mais l’identité est fournie à une extension VPN plutôt qu’à une app. ManagedApp peut fournir le type de données d’authentification le plus sécurisé pris en charge par Apple. Grâce à l’attestation d’appareil géré, l’administrateur fournit une clé liée au matériel, attestée et propre à l’appareil. Le framework ManagedApp la transmet directement, et uniquement, à l’extension VPN concernée. Elle utilise cette identité pour s’authentifier auprès du serveur VPN. Cela élimine plusieurs menaces potentielles qui inquiètent les administrateurs VPN. Dernier scénario : un fournisseur d’identité. Il utilise l’authentification unique extensible pour simplifier la connexion aux comptes fédérés dans les apps et sites web. Il peut aussi fonctionner avec des comptes Apple fédérés pour les inscriptions basées sur un compte. Chaque fournisseur d’identité conçoit son protocole d’authentification, souvent basé sur la saisie manuelle des identifiants. Avec le framework ManagedApp, un fournisseur d’identité peut désormais intégrer d’autres types de données d’authentification. Il peut s’agir d’une identité liée au matériel, utilisée pour vérifier que la connexion se fait depuis un appareil autorisé. Si le compte est nouveau, cela peut être un mot de passe temporaire pour une 1ère authentification. Il peut s’agir d’un jeton ou d’une identité qui lie la connexion à l’organisation. Ou plus largement, tout type de secret requis par le fournisseur d’identité. ManagedApp les prend tous en charge. Si le fournisseur d’identité prend en charge l’authentification unique, la configuration et les secrets sont disponibles dès l’inscription. J’espère que vous voyez tout ce que le framework ManagedApp peut apporter aux apps gérées. Il est temps de voir comment l’intégrer dans votre app. L’API du framework ManagedApp vise à fournir la configuration et les secrets à l’app de façon simple et sécurisée. Le framework a 4 classes indépendantes, une pour chaque type de données. Ces 3 premières fournissent le type de données intégré dont votre app a besoin : une chaîne contenant le mot de passe, un SecCertificate ou une SecIdentity. La 4è est un peu différente. Le fournisseur de configuration ManagedApp fournit une configuration spécifique à l’app. Il n’y a pas de type intégré pour cela. Il s’agit du type de données dont l’app a besoin. En tant que développeur, vous définissez la structure de ces données. Je vais donner un exemple avec une configuration, puis un autre avec une identité. Puis, nous verrons la publication des spécifications de votre app.

Commençons par l’app Landmarks. Nous allons la rendre configurable pour l’utiliser en classe. Première étape : déterminer ce que l’administrateur peut configurer. Voici la vue des collections dans l’app Landmarks. Offrons à l’administrateur la possibilité de configurer une nouvelle collection. Un enseignant peut ainsi rassembler les points d’intérêt que les élèves utiliseront pour un cours de géographie.

En code, on commence par écrire une struct qui représente tout ce que l’administrateur a configuré pour une instance de l’app. Elle contient une propriété en lecture seule pour la collection gérée. Le type de propriétés est facultatif. Cela est dû au fait que l’app n’est peut-être pas gérée, ou que l’administrateur n’a peut-être pas appliqué de configuration, ou qu’il a appliqué une configuration qui n’inclut pas de collection gérée. La plupart des propriétés seront facultatives ou auront une valeur par défaut.

Quand le framework ManagedApp reçoit une configuration du serveur MDM, il doit décoder le format transmis, d’où l’adoption du protocole Decodable par la struct. Nous spécifions une CodingKey pour la collection. Une fois la classe de collection conforme à Decodable, on pourrait s’arrêter là et laisser le compilateur générer automatiquement l’initialiseur de la classe de configuration. Mais la plupart des apps ont besoin de validations personnalisées. Nous allons donc écrire un initialiseur explicite. Et voilà pour la classe de configuration. Comment votre app reçoit-elle cette configuration ? L’API repose sur la concurrence Swift, donc on commence par créer une tâche. Dans cette tâche, nous utilisons la classe ManagedAppConfigurationProvider dans le framework ManagedApp. La méthode configurations fournit les configurations via une séquence asynchrone. Le paramètre que vous passez à la méthode configurations est le type de votre struct de configuration. Pour commencer à recevoir les configurations, utilisez une boucle for await. La séquence asynchrone renvoie un optionnel de votre type de configuration. Dans cet exemple, le type de config est un optionnel de LandmarksManagedConfig. Voyons comment ces éléments s’articulent en suivant ce qui se passe sur l’appareil. Tout d’abord, l’administrateur crée une configuration codée et l’envoie à l’appareil, qui la stocke. Quand l’app parcourt la séquence asynchrone avec une boucle for await, l’appareil transmet une copie de la configuration encodée à votre méthode de décodage. Cela instancie votre struct de configuration avec les propriétés nécessaires à l’app. Enfin, le framework transmet cette instance à la séquence asynchrone. Par la suite, si l’administrateur envoie une configuration mise à jour, le processus se répète automatiquement. Si l’app n’est pas gérée, si aucune configuration n’a été définie ou si le décodage échoue, la séquence renvoie nil. En bref, votre app n’a pas à se soucier de ces conditions. Chaque fois que la séquence renvoie une valeur ou nil, cela correspond à la configuration gérée de votre app. Il suffit donc, dans le corps de la boucle for await, de copier la valeur de la configuration dans une propriété de collection gérée au sein des données du modèle. Comme la configuration peut être mise à jour à tout moment, la boucle for await n’a pas de condition d’arrêt. Rassurez-vous, une boucle infinie ne gaspille pas de ressources. Le corps de la boucle for await s’exécute uniquement lorsqu’une valeur est renvoyée. Où lancer cette tâche ? Elle peut être lancée n’importe où dans votre application. En général, elle se trouve dans une méthode appelée tôt lors du lancement de l’app. Pour l’app Landmarks, nous l’intégrerons à la méthode Load Collections de Model Data. Les collections sont chargées peu après le lancement de l’app. On ajoute la collection gérée à la vue, et c’est terminé. Voici le résultat. La vue Collections affiche désormais une section Managed Collection avec le titre et les points d’intérêt définis par l’administrateur. Et voici un bonus. Le code que nous avons écrit suffit à prendre en charge les mises à jour. Quand l’administrateur modifie la configuration, la vue se met à jour pour afficher les nouveaux points d’intérêt. Passons à un exemple qui utilise des identités. Supposons que l’administrateur puisse ajouter bien plus de points d’intérêt. L’app téléchargera les points d’intérêt depuis un serveur de ressources. Nous laisserons l’administrateur indiquer l’URL d’hébergement des ressources. Cela lui offre la liberté d’héberger les ressources où il le souhaite. Nous pouvons facilement ajouter une URL de ressources à la configuration développée. Nous permettrons également à l’administrateur de fournir une identité que l’app utilisera pour s’authentifier via TLS mutuel lors de la connexion au serveur de ressources. Les 3 fournisseurs de secrets du framework utilisent le même modèle. Chaque secret a un ID sous forme de chaîne. Il existe une méthode pour rechercher le secret par son ID. Vous choisissez les ID que votre app prend en charge. La plupart du temps, vous pouvez coder en dur les ID. Pour que votre app soit informée des changements des secrets disponibles, vous pouvez utiliser une AsyncSequence. Elle renvoie un tableau de tous les ID des secrets de ce type actuellement provisionnés. L’AsyncSequence est aussi utile si votre app gère une liste dynamique d’ID. Quand l’app Landmarks télécharge les ressources, cette complexité supplémentaire n’est pas nécessaire, donc nous utiliserons un ID codé en dur. L’app envoie une requête à l’aide de l’URL de session. Lors de la mise en œuvre du TLS mutuel, la majeure partie du code est standard. Nous ne nous intéressons qu’à l’obtention de l’identité, représentée par ces lignes au milieu. Nous avons utilisé le fournisseur d’identités ManagedApp et un ID codé en dur pour récupérer une identité secondaire. Si l’administrateur n’a pas fourni d’identité, nous annulons la requête. C’est tout ! Avec ces quelques lignes de code, notre app a obtenu l’identité dont elle avait besoin. Nous n’avons pas eu à gérer les propriétés de la clé, la demande de signature de certificat ni aucun autre aspect lié à la provision de l’identité. Nous avons juste utilisé celle que l’administrateur a provisionnée pour nous. La dernière étape est de publier une spécification expliquant comment un administrateur peut configurer l’app Landmarks. Nous documentons le format de la configuration. Une méthode simple consiste à fournir un exemple. Voici un exemple de format encodé pour la configuration. Le format transmis pour les configurations est une liste de propriétés. La spécification doit documenter les détails, comme la liste des valeurs valides pour les ID des points d’intérêt. Si notre décodeur fait une validation personnalisée, nous documentons les codes d’erreur pour aider les administrateurs à diagnostiquer les problèmes. Nous documentons tous les ID de secrets pris en charge par notre app. Pour l’app Landmarks, il s’agit de l’ID codé en dur utilisé précédemment. Nous précisons qu’il sert à télécharger les ressources, et c’est un bon endroit pour documenter le format attendu des ressources Landmark. Nous publions ces informations, généralement sous forme de document ou de site web accessible aux administrateurs. Et c’est terminé. Voici des bonnes pratiques à garder en tête lorsque vous développez votre app. La configuration n’est pas conçue pour le transfert de gros volumes de données. Pensez en kilo-octets, pas en mégaoctets. Privilégiez un téléchargement des données par l’app depuis un serveur, avec l’URL indiquée dans la configuration, comme nous l’avons fait avec l’app Landmarks. Ne gardez pas de secrets plus longtemps que nécessaire. Il suffit de récupérer le secret quand vous en avez besoin. C’est une bonne pratique en matière de sécurité, mais cela garantit aussi que votre app utilise toujours le secret le plus récent en cas de mise à jour par l’administrateur. Lors de la conception de votre configuration, évitez d’avoir un simple interrupteur indiquant si votre app est gérée, ce qui modifie plusieurs comportements dans l’app. Privilégiez des options de configuration individuelles, chacune contrôlant un aspect du comportement de votre app. Cela offre aux administrateurs une flexibilité maximale. Pensez à la compatibilité ascendante et descendante. Lors des nouvelles versions de votre app, vous pouvez ajouter, modifier ou supprimer des options dans la configuration. Il serait difficile pour un administrateur de fournir des configurations différentes selon les versions de votre app. Pour éviter cela, assurez-vous que votre décodeur gère les anciennes configurations et ignore les clés inconnues. Cela permet à l’administrateur de fournir une seule configuration à l’ensemble de ses appareils. Si votre app utilise encore l’ancienne fonctionnalité de configuration gérée, il est temps d’en changer. Pendant cette transition, votre app peut prendre en charge les 2 fonctionnalités, en donnant priorité à la configuration du framework ManagedApp. Cela permet à un administrateur de passer au framework ManagedApp sans interruption. Lorsque vous soumettez votre app pour vérification, l’évaluateur teste ses fonctionnalités. Si certaines fonctionnalités ne sont accessibles que lorsque l’app est gérée avec une configuration ou des secrets appliqués, cela peut empêcher l’évaluateur de tester votre app. Il y a plusieurs façons de résoudre cela. Ajoutez un mode démo à votre app, qui simule une configuration pour présenter ses fonctionnalités. Cela peut aussi servir à présenter votre app aux clients. Une autre option consiste à enregistrer une vidéo de votre app montrant ces fonctionnalités. Vous pouvez l’envoyer à App Store Connect, dans la section des notes pour l’examen de l’app. Vous devrez aussi fournir des instructions et des identifiants pour que l’évaluateur enregistre son appareil auprès d’un service de gestion qui configurera l’app correctement. Surtout, soyez créatif. Imaginez à quel point le framework ManagedApp facilite l’utilisation de votre app pour tout le monde. Discutez avec vos clients de leurs attentes. Adoptez le framework et migrez depuis la configuration ManagedApp. Merci de nous envoyer vos commentaires sur le framework. Pour en savoir plus sur la gestion des appareils, regardez la séance « What’s new in managing Apple devices ». Merci et profitez bien de la WWDC !