SDK de aplicaciones de Intune para iOS: multiinquilino

Nota:

Esta guía se divide en varias fases distintas. Para empezar, revise La fase 1: Planear la integración.

Fase 5: Multi-Identity (opcional)

De forma predeterminada, el SDK aplica una directiva a la aplicación en su conjunto. La identidad múltiple es una característica mam que puede habilitar para aplicar una directiva en un nivel por identidad. Esto requiere más participación de aplicaciones que otras características de MAM.

La aplicación debe informar al SDK de la aplicación cuando quiera cambiar la identidad activa. El SDK también notifica a la aplicación cuando se requiere un cambio de identidad. Actualmente, solo se admite una identidad administrada. Una vez que el usuario inscribe el dispositivo o la aplicación, el SDK usa esta identidad y la considera la identidad administrada principal. Otros usuarios de la aplicación se tratarán como no administrados con una configuración de directiva sin restricciones.

Tenga en cuenta que una identidad se define simplemente como una cadena. Las identidades no distinguen mayúsculas de minúsculas. Es posible que las solicitudes al SDK para una identidad no devuelvan el mismo uso de mayúsculas y minúsculas que se usó originalmente cuando se estableció la identidad.

Objetivos de fase

• Determine si la aplicación necesita compatibilidad con varias identidades.
• Comprenda cómo el SDK de aplicaciones de Intune percibe las identidades.
• Refactorice la aplicación para el reconocimiento de identidad.
• Agregue código para informar al SDK de identidades activas y cambiantes en toda la aplicación.
• Pruebe exhaustivamente la aplicación de directivas de protección de aplicaciones para identidades administradas y no administradas.

Introducción a la identidad

Una identidad es simplemente el nombre de usuario de una cuenta (por ejemplo, user@contoso.com). Los desarrolladores pueden establecer la identidad de la aplicación en los siguientes niveles:

• Identidad de proceso: establece la identidad de todo el proceso y se usa principalmente para aplicaciones de identidad única. Esta identidad afecta a todas las tareas, archivos e interfaz de usuario.

• Identidad de la interfaz de usuario: determina qué directivas se aplican a las tareas de la interfaz de usuario en el subproceso principal, como cortar, copiar y pegar, PIN, autenticación y uso compartido de datos. La identidad de la interfaz de usuario no afecta a las tareas de archivo, como el cifrado y la copia de seguridad.

• Identidad del subproceso: afecta a las directivas que se aplican en el subproceso actual. Esta identidad afecta a todas las tareas, archivos e interfaz de usuario.

La aplicación es responsable de establecer las identidades correctamente, independientemente de si el usuario se administra o no.

En cualquier momento, cada subproceso tiene una identidad efectiva para las tareas de interfaz de usuario y las tareas de archivo. Esta es la identidad que se usa para comprobar qué directivas, si las hay, se deben aplicar. Si la identidad es "sin identidad" o el usuario no se administra, no se aplicará ninguna directiva. En los diagramas siguientes se muestra cómo se determinan las identidades efectivas.

Colas de subprocesos

Las aplicaciones suelen enviar tareas asincrónicas y sincrónicas a colas de subprocesos. El SDK intercepta las llamadas de Grand Central Dispatch (GCD) y asocia la identidad del subproceso actual a las tareas enviadas. Cuando finalizan las tareas, el SDK cambia temporalmente la identidad del subproceso a la identidad asociada a las tareas, finaliza las tareas y, a continuación, restaura la identidad del subproceso original.

Dado que NSOperationQueue se basa en GCD, NSOperations se ejecutará en la identidad del subproceso en el momento en que se agreguen las tareas a NSOperationQueue. NSOperations las funciones enviadas directamente a través de GCD también pueden cambiar la identidad del subproceso actual a medida que se ejecutan. Esta identidad invalidará la identidad heredada del subproceso de distribución.

Rápidamente, debido a una consecuencia de cómo el SDK propaga identidades para DispatchWorkItem, la identidad asociada a es DispatchWorkItem la identidad del subproceso que creó el elemento y no el subproceso que lo envía.

Propietario del archivo

El SDK realiza un seguimiento de las identidades de los propietarios de archivos locales y aplica las directivas en consecuencia. Se establece un propietario de archivo cuando se crea un archivo o cuando se abre un archivo en modo truncado. El propietario se establece en la identidad efectiva de la tarea de archivo del subproceso que realiza la tarea.

Como alternativa, las aplicaciones pueden establecer explícitamente la identidad del propietario del archivo mediante IntuneMAMFilePolicyManager. Las aplicaciones pueden usar IntuneMAMFilePolicyManager para recuperar el propietario del archivo y establecer la identidad de la interfaz de usuario antes de mostrar el contenido del archivo.

Datos compartidos

Si la aplicación crea archivos que tienen datos de usuarios administrados y no administrados, la aplicación es responsable de cifrar los datos del usuario administrado. Puede cifrar los datos mediante las protect API y unprotect en IntuneMAMDataProtectionManager.

El protect método acepta una identidad que puede ser un usuario administrado o no administrado. Si se administra el usuario, los datos se cifrarán. Si el usuario no está administrado, se agregará un encabezado a los datos que codifican la identidad, pero los datos no se cifrarán. Puede usar el protectionInfo método para recuperar el propietario de los datos.

Compartir extensiones

Si la aplicación tiene una extensión de recurso compartido, el propietario del elemento que se comparte se puede recuperar a través del protectionInfoForItemProvider método en IntuneMAMDataProtectionManager. Si el elemento compartido es un archivo, el SDK controlará la configuración del propietario del archivo. Si el elemento compartido son datos, la aplicación es responsable de establecer el propietario del archivo si estos datos se conservan en un archivo y de llamar a la setUIPolicyAccountId API antes de mostrar estos datos en la interfaz de usuario.

Activar varias identidades

De forma predeterminada, las aplicaciones se consideran una única identidad. El SDK establece la identidad del proceso en el usuario inscrito. Para habilitar la compatibilidad con varias identidades, agregue una configuración booleana con el nombre MultiIdentity y un valor de SÍ al diccionario IntuneMAMSettings en el archivo Info.plist de la aplicación.

Nota:

Cuando se habilita la multiinquilino, la identidad del proceso, la identidad de la interfaz de usuario y las identidades de subproceso se establecen en nil. La aplicación es responsable de configurarlas correctamente.

Cambiar identidades

• Conmutador de identidad iniciado por la aplicación:

  Al iniciarse, se considera que las aplicaciones de varias identidades se ejecutan en una cuenta desconocida y no administrada. La interfaz de usuario de inicio condicional no se ejecutará y no se aplicará ninguna directiva en la aplicación. La aplicación es responsable de notificar al SDK cada vez que se debe cambiar la identidad. Normalmente, esto ocurrirá siempre que la aplicación esté a punto de mostrar los datos de una cuenta de usuario específica.

  Un ejemplo es cuando el usuario intenta abrir un documento, un buzón o una pestaña en un cuaderno. La aplicación debe notificar al SDK antes de que se abra realmente el archivo, el buzón o la pestaña. Esto se hace a través de la setUIPolicyAccountId API en IntuneMAMPolicyManager. Se debe llamar a esta API tanto si se administra el usuario como si no. Si el usuario está administrado, el SDK realizará las comprobaciones de inicio condicional, como la detección de jailbreak, el PIN y la autenticación.

  El resultado del modificador de identidad se devuelve a la aplicación de forma asincrónica a través de un controlador de finalización. La aplicación debe posponer la apertura del documento, buzón o pestaña hasta que se devuelva un código de resultado correcto. Si se produce un error en el modificador de identidad, la aplicación debe cancelar la tarea.

  Las aplicaciones de varias identidades deben evitar el uso setProcessAccountId como una manera de establecer la identidad. Las aplicaciones que usan UIScenes deben usar la setUIPolicyAccountId:forWindow API para establecer la identidad.

  Las aplicaciones también pueden establecer la identidad del subproceso actual mediante setCurrentThreadIdentity: y setCurrentThreadIdentity:forScope:. Por ejemplo, la aplicación puede generar un subproceso en segundo plano, establecer la identidad en la identidad administrada y, a continuación, realizar operaciones de archivo en archivos administrados. Si la aplicación usa setCurrentThreadAccountId:, la aplicación también debe usar getCurrentThreadAccountId para que pueda restaurar la identidad original una vez que haya terminado. Sin embargo, si la aplicación usa setCurrentThreadAccountId:forScope: , la restauración de la identidad antigua se produce automáticamente. Es preferible usar setCurrentThreadAccountId:forScope:.

  Rápidamente, debido a async/await, [IntuneMAMPolicyManager setCurrentThreadAccountId:] y [IntuneMAMPolicyManager setCurrentThreadAccountId:forScope:] no están disponibles. En su lugar, en swift para establecer la identidad actual, use IntuneMAMSwiftContextManager.setAccountId(_, forScope:). Hay variantes de esta API para que se pasen cierres asincrónicos, de lanzamiento y de lanzamiento asincrónicos.

• Conmutador de identidad iniciado por el SDK:

  A veces, el SDK debe pedir a la aplicación que cambie a una identidad específica. Las aplicaciones de varias identidades deben implementar el identitySwitchRequiredForAccountId método en IntuneMAMPolicyDelegate para controlar esta solicitud.

  Cuando se llama a este método, si la aplicación puede controlar la solicitud para cambiar a la identidad especificada, debe pasar IntuneMAMAddIdentityResultSuccess al controlador de finalización. Si no puede controlar el cambio de la identidad, la aplicación debe pasar IntuneMAMAddIdentityResultFailed al controlador de finalización.

  La aplicación no tiene que llamar setUIPolicyAccountId a en respuesta a esta llamada. Si el SDK necesita que la aplicación cambie a una cuenta de usuario no administrada, la cadena vacía se pasará a la identitySwitchRequiredForAccountId llamada.

• Inscripción automática de identidad iniciada por el SDK:

  Cuando el SDK necesita inscribir automáticamente a un usuario en la aplicación para realizar una acción, las aplicaciones deben implementar el addIdentity:completionHandler: método en IntuneMAMPolicyDelegate. A continuación, la aplicación debe llamar al controlador de finalización y pasar IntuneMAMAddIdentityResultSuccess si la aplicación puede agregar la identidad o IntuneMAMAddIdentityResultFailed en caso contrario.

• Borrado selectivo:

  Cuando la aplicación se borra de forma selectiva, el SDK llamará al wipeDataForAccountId método en IntuneMAMPolicyDelegate. La aplicación es responsable de quitar la cuenta del usuario especificado y los datos asociados a ella. El SDK es capaz de quitar todos los archivos propiedad del usuario y lo hará si la aplicación devuelve FALSE de la wipeDataForAccountId llamada.

  Tenga en cuenta que se llama a este método desde un subproceso en segundo plano. La aplicación no debe devolver un valor hasta que se hayan quitado todos los datos del usuario (con la excepción de los archivos si la aplicación devuelve FALSE).

Criterios de salida

Planea dedicar un tiempo significativo para validar la integración de varias identidades de la aplicación. Antes de empezar a realizar las pruebas:

• Cree y asigne una directiva de protección de aplicaciones a una cuenta. Esta será la cuenta administrada de prueba.
• Cree, pero no asigne la directiva de protección de aplicaciones a otra cuenta. Esta será la cuenta no administrada de prueba. Como alternativa, si la aplicación admite varios tipos de cuenta más allá de las cuentas de Microsoft Entra, puede usar una cuenta existente que no sea de AAD como cuenta de prueba no administrada.
• Familiarícese con cómo se aplica la directiva dentro de la aplicación. Las pruebas de varias identidades requieren que distinga fácilmente cuándo está y no funciona la aplicación con la directiva aplicada. La configuración de directiva de protección de aplicaciones para bloquear capturas de pantalla es eficaz para probar rápidamente la aplicación de directivas.
• Ten en cuenta todo el conjunto de interfaces de usuario que ofrece la aplicación. Enumera las pantallas donde se muestran los datos de la cuenta. ¿La aplicación solo presenta los datos de una sola cuenta a la vez o puede presentar datos que pertenecen a varias cuentas al mismo tiempo?
• Tenga en cuenta todo el conjunto de archivos que crea la aplicación. Enumera cuál de estos archivos contiene datos que pertenecen a una cuenta, en lugar de datos de nivel de sistema.
  • Determine cómo validará el cifrado en cada uno de estos archivos.
• Tenga en cuenta todo el conjunto de formas en que la aplicación puede interactuar con otras aplicaciones. Enumera todos los puntos de entrada y salida. ¿Qué tipos de datos puede ingerir la aplicación? ¿Qué intenciones difunde? ¿Qué proveedores de contenido implementa?
  • Determine cómo va a ejercer cada una de estas características de uso compartido de datos.
  • Prepare un dispositivo de prueba que tenga aplicaciones administradas y no administradas que puedan interactuar con la aplicación.
• Considere cómo la aplicación permite al usuario final interactuar con todas las cuentas que han iniciado sesión. ¿Necesita el usuario cambiar manualmente a una cuenta antes de que se muestren los datos de esa cuenta?

Una vez que haya evaluado exhaustivamente el comportamiento actual de la aplicación, valide la integración de varias identidades mediante la ejecución del siguiente conjunto de pruebas. Tenga en cuenta que esta no es una lista completa y no garantiza que la implementación de varias identidades de la aplicación esté libre de errores.

Validación de escenarios de inicio de sesión y cierre de sesión

La aplicación de varias identidades admite hasta una cuenta administrada y varias cuentas no administradas. Estas pruebas ayudan a garantizar que la integración de varias identidades no cambia de forma incorrecta las protecciones cuando los usuarios inician sesión o cierran sesión.

Para estas pruebas, instale la aplicación en un dispositivo de prueba; no inicie sesión antes de iniciar la prueba.

Escenario	Pasos
Inicio de sesión administrado primero	- Inicie sesión primero con una cuenta administrada y valide que los datos de la cuenta se administran. - Inicie sesión con una cuenta no administrada y valide que los datos de la cuenta no se administran.
Inicio de sesión no administrado primero	- Inicie sesión primero con una cuenta no administrada y valide que los datos de la cuenta no se administran. - Inicie sesión con una cuenta administrada y valide que los datos de la cuenta se administran.
Iniciar sesión en varias instancias administradas	- Inicie sesión primero con una cuenta administrada y valide que los datos de la cuenta se administran. - Inicie sesión con una segunda cuenta administrada y valide que el usuario está bloqueado para iniciar sesión sin quitar primero la cuenta administrada original.
Cierre de sesión administrado	- Inicie sesión en la aplicación con una cuenta administrada y no administrada. - Cierre la sesión de la cuenta administrada. - Confirme que la cuenta administrada se ha quitado de la aplicación y que se han quitado todos los datos de esa cuenta. : confirme que la cuenta no administrada todavía está iniciada, que no se ha quitado ninguno de los datos de la cuenta no administrada y que todavía no se aplica la directiva.
Cierre la sesión no administrada	- Inicie sesión en la aplicación con una cuenta administrada y no administrada. - Cierre la sesión de la cuenta no administrada. - Confirme que la cuenta no administrada se ha quitado de la aplicación y que se han quitado todos los datos de esa cuenta. : confirme que la cuenta administrada todavía está iniciada, que no se han quitado los datos de la cuenta no administrada y que la directiva se sigue aplicando.

Validación de la identidad activa y el ciclo de vida de la aplicación

La aplicación de varias identidades puede presentar vistas con los datos de una sola cuenta y permitir que el usuario cambie explícitamente la cuenta actual en uso. También puede presentar vistas con datos de varias cuentas al mismo tiempo. Estas pruebas ayudan a garantizar que la integración de varias identidades proporciona las protecciones adecuadas para la identidad activa en todas las páginas durante todo el ciclo de vida de la aplicación.

Para estas pruebas, instale la aplicación en un dispositivo de prueba; inicie sesión con una cuenta administrada y no administrada antes de iniciar la prueba.

Escenario	Pasos
Vista de cuenta única, administrada	- Cambie a la cuenta administrada. - Vaya a todas las páginas de la aplicación que presentan los datos de una sola cuenta. - Confirme que la directiva se aplica en todas las páginas.
Vista de cuenta única, no administrada	- Cambie a la cuenta no administrada. - Vaya a todas las páginas de la aplicación que presentan los datos de una sola cuenta. - Confirme que la directiva no se aplica en ninguna página.
Vista de varias cuentas	- Vaya a todas las páginas de la aplicación que presentan varios datos de cuentas simultáneamente. - Confirme que la directiva se aplica en todas las páginas.
Pausa administrada	- En una pantalla con los datos administrados mostrados y la directiva activa, detenga la aplicación; para ello, vaya a la pantalla principal del dispositivo u otra aplicación. - Reanudar la aplicación. - Confirme que la directiva se sigue aplicando.
Pausa no administrada	- En una pantalla con datos no administrados mostrados y sin directiva activa, detenga la aplicación navegando a la pantalla principal del dispositivo u otra aplicación. - Reanudar la aplicación. - Confirme que no se aplica la directiva.
Eliminación administrada	- En una pantalla con los datos administrados mostrados y la directiva activa, fuerza la eliminación de la aplicación. - Reinicie la aplicación. - Confirme que, si la aplicación se reanuda en una pantalla con los datos de la cuenta administrada (esperada), se sigue aplicando la directiva. Si la aplicación se reanuda en una pantalla con los datos de la cuenta no administrada, confirme que la directiva no se aplica.
Eliminación no administrada	- En una pantalla con los datos no administrados mostrados y la directiva activa, fuerza la eliminación de la aplicación. - Reinicie la aplicación. - Confirme que, si la aplicación se reanuda en una pantalla con los datos (esperados) de la cuenta no administrada, no se aplica la directiva. Si la aplicación se reanuda en una pantalla con los datos de la cuenta administrada, confirme que la directiva se sigue aplicando.
Conmutador de identidad ad hoc	- Cambio de experimento entre cuentas y pausas, reanudación, ejecución o reinicio de la aplicación. : confirme que los datos de la cuenta administrada siempre están protegidos y que los datos de la cuenta no administrada nunca están protegidos.

Validación de escenarios de uso compartido de datos

La aplicación de varias identidades puede enviar datos y recibir datos de otras aplicaciones. Las directivas de protección de aplicaciones de Intune tienen una configuración que determina este comportamiento. Estas pruebas ayudan a garantizar que la integración de varias identidades respeta esta configuración de uso compartido de datos.

Para estas pruebas, instale la aplicación en un dispositivo de prueba; inicie sesión con una cuenta administrada y no administrada antes de iniciar la prueba. Además:

• Establezca la directiva de la cuenta administrada como:
  • "Enviar datos de la organización a otras aplicaciones" a "Aplicaciones administradas por directivas".
  • "Recibir datos de otras aplicaciones" a "Aplicaciones administradas por directivas".
• Instale otras aplicaciones en el dispositivo de prueba:
  • Una aplicación administrada, dirigida con la misma directiva que la aplicación, que puede enviar y recibir datos (como Microsoft Outlook).
  • Cualquier aplicación no administrada que pueda enviar y recibir datos.
• Inicie sesión en la otra aplicación administrada con la cuenta de prueba administrada. Incluso si la otra aplicación administrada es de varias identidades, solo inicie sesión con la cuenta administrada.

Si la aplicación tiene la capacidad de enviar datos a otras aplicaciones, como Microsoft Outlook que envía datos adjuntos a un documento a Microsoft Office:

Escenario	Pasos
Envío de identidad administrada a una aplicación no administrada	- Cambie a la cuenta administrada. - Vaya a donde la aplicación puede enviar datos. - Intento de enviar datos a una aplicación no administrada. - Debería bloquearse el envío de datos a la aplicación no administrada.
Envío de identidad administrada a una aplicación administrada	- Cambie a la cuenta administrada. - Vaya a donde la aplicación puede enviar datos. - Intente enviar datos a la otra aplicación administrada con la cuenta administrada que ha iniciado sesión. - Debería poder enviar datos a la aplicación administrada.
Envío de identidades no administradas a una aplicación administrada	- Cambie a la cuenta no administrada. - Vaya a donde la aplicación puede enviar datos. - Intente enviar datos a la otra aplicación administrada con la cuenta administrada que ha iniciado sesión. - Debería bloquearse el envío de datos a la otra aplicación administrada.
Envío de identidades no administradas a una aplicación no administrada	- Cambie a la cuenta no administrada. - Vaya a donde la aplicación puede enviar datos. - Intento de enviar datos a una aplicación no administrada. - Siempre debe tener permiso para enviar los datos de una cuenta no administrada a una aplicación no administrada.

La aplicación puede importar datos de forma activa desde otras aplicaciones, como Microsoft Outlook que adjunta un archivo desde Microsoft OneDrive. La aplicación también puede recibir datos de otras aplicaciones de forma pasiva, como Microsoft Office, que abre un documento de datos adjuntos de Microsoft Outlook. La configuración de directiva de protección de aplicaciones de recepción abarca ambos escenarios.

Si la aplicación tiene la capacidad de importar datos de forma activa desde otras aplicaciones:

Escenario	Pasos
Importación de identidad administrada desde una aplicación no administrada	- Cambie a la cuenta administrada. - Vaya a donde la aplicación puede importar datos de otras aplicaciones. - Intento de importar datos desde una aplicación no administrada. - Debería bloquearse la importación de datos desde aplicaciones no administradas.
Importación de identidad administrada desde una aplicación administrada	- Cambie a la cuenta administrada. - Vaya a donde la aplicación puede importar datos de otras aplicaciones. - Intente importar datos de la otra aplicación administrada con la cuenta administrada que ha iniciado sesión. - Debería tener permiso para importar datos de la otra aplicación administrada.
Importación de identidades no administradas desde una aplicación administrada	- Cambie a la cuenta no administrada. - Vaya a donde la aplicación puede importar datos de otras aplicaciones. - Intente importar datos de la otra aplicación administrada con la cuenta administrada que ha iniciado sesión. - Debería bloquearse la importación de datos desde la otra aplicación administrada.
Importación de identidades no administradas desde una aplicación no administrada	- Cambie a la cuenta no administrada. - Vaya a donde la aplicación puede importar datos de otras aplicaciones. - Intento de importar datos desde una aplicación no administrada. - Siempre debe tener permiso para importar datos desde una aplicación no administrada para una cuenta no administrada.

Si la aplicación tiene la capacidad de recibir pasivamente datos de otras aplicaciones:

Escenario	Pasos
Recepción de identidad administrada desde una aplicación no administrada	- Cambie a la cuenta administrada. - Cambie a la aplicación no administrada. - Vaya a donde puede enviar datos. - Intente enviar datos desde la aplicación no administrada a la aplicación. - La cuenta administrada de la aplicación no debería poder recibir datos de la aplicación no administrada.
Recepción de identidad administrada desde una aplicación administrada	- Cambie a la cuenta administrada. - Cambie a la otra aplicación administrada con la cuenta administrada que ha iniciado sesión. - Vaya a donde puede enviar datos. - Intente enviar datos desde la aplicación administrada a la aplicación. - Se debe permitir que la cuenta administrada de la aplicación reciba datos de la otra aplicación administrada.
Recepción de identidades no administradas desde una aplicación administrada	- Cambie a la cuenta no administrada. - Cambie a la otra aplicación administrada con la cuenta administrada que ha iniciado sesión. - Vaya a donde puede enviar datos. - Intente enviar datos desde la aplicación administrada a la aplicación. - La cuenta no administrada de la aplicación no debería poder recibir datos de la aplicación administrada.
Recepción de identidades no administradas desde una aplicación no administrada	- Cambie a la cuenta no administrada. - Cambie a la aplicación no administrada. - Vaya a donde puede enviar datos. - Intente enviar datos desde la aplicación no administrada a la aplicación. - Siempre se debe permitir que la cuenta no administrada de la aplicación reciba datos de la aplicación no administrada.

Los errores de estas pruebas pueden indicar que la aplicación no tiene la identidad activa adecuada establecida cuando intenta enviar o recibir datos. Para investigar esto, aproveche las API de obtención de identidad del SDK en el momento de enviar o recibir para confirmar que la identidad activa se ha establecido correctamente.

Pasos siguientes

Después de completar todos los criterios de salida anteriores, la aplicación ahora se integra correctamente como multiinquilino y puede aplicar directivas de protección de aplicaciones por identidad. Las secciones siguientes, Fase 6: Compatibilidad con el acceso condicional de App Protection y Fase 7: Características de vista web, pueden ser necesarias o no, en función de la compatibilidad deseada de la directiva de protección de aplicaciones de la aplicación.