SDK de aplicación de Intune para iOS: multiidentidad

Nota:

Esta guía se divide en varias etapas distintas. Comience por revisar la Etapa 1: Planifique la integración.

Fase 5: Multiidentidad (opcional)

De forma predeterminada, el SDK aplica una directiva a la aplicación como un todo. Multiidentidad es una característica de MAM que puede habilitar para aplicar una directiva a nivel por identidad. Esto requiere más participación en la aplicación que otras características de MAM.

La aplicación debe informar al SDK de la aplicación cuando tiene previsto 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 de una identidad al SDK no devuelvan el mismo uso de mayúsculas y minúsculas que se usó originalmente cuando se estableció la identidad.

Objetivos de la etapa

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

Información general sobre 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 interfaz de usuario en el subproceso principal, como cortar, copiar y pegar, el PIN, la autenticación y el uso compartido de datos. La identidad de interfaz de usuario no afecta a las tareas de archivos 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 de forma adecuada, independientemente de si se administra o no el usuario.

En cualquier momento, cada subproceso tiene una identidad efectiva para las tareas de interfaz de usuario y las tareas de archivo. Es la identidad que se usa para comprobar qué directivas, en caso de aplicarse. Si la identidad es "sin identidad" o el usuario no está administrado, no se aplicarán directivas. Los diagramas siguientes muestran cómo se determinan las identidades eficaces.

Colas de conversación

Las aplicaciones suelen distribuir tareas asincrónicas y sincrónicas a las colas de subprocesos. El SDK intercepta las llamadas de Grand Central Dispatch (GCD) y asocia la identidad de subproceso actual con las tareas asignadas. 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 compila sobre GCD, NSOperations se ejecutará en la identidad del subproceso en el momento en que se agreguen las NSOperationQueuetareas. NSOperations o las funciones distribuidas 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.

En Swift, debido a una consecuencia de cómo el SDK propaga las identidades para DispatchWorkItem, la identidad asociada con a es DispatchWorkItem la identidad del subproceso que creó el elemento, 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. El propietario de un archivo se establece cuando se crea un archivo o cuando se abre un archivo en modo truncado. El propietario se establece en la identidad de tarea de archivo efectiva del subproceso que realiza la tarea.

Como alternativa, las aplicaciones pueden establecer la identidad del propietario del archivo explícitamente 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 datos mediante las API y unprotect en IntuneMAMDataProtectionManager.protect

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 uso compartido, el propietario del elemento que se comparte se puede recuperar a través del protectionInfoForItemProvider método de IntuneMAMDataProtectionManager. Si el elemento compartido es un archivo, el SDK se encargará de establecer el 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 API antes de setUIPolicyAccountId mostrar estos datos en la interfaz de usuario.

Activar varias identidades

De forma predeterminada, las aplicaciones se consideran de identidad única. 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 YES al diccionario IntuneMAMSettings en el archivo Info.plist de la aplicación.

Nota:

Cuando se habilita la identidad múltiple, la identidad de proceso, la identidad de interfaz de usuario y las identidades de subproceso se establecen en cero. La aplicación es responsable de configurarlos correctamente.

Cambiar identidades

Importante

El SDK no puede detectar cambios de identidad de forma independiente. Depende completamente de la aplicación para informarlos. Si la aplicación no notifica correctamente al SDK de un cambio de identidad:

• Es posible que las directivas de protección de aplicaciones no se apliquen al usuario activo, dejando los datos administrados desprotegidos.
• Los datos no administrados podrían estar restringidos incorrectamente.

La aplicación debe llamar a las API de cambio de identidad adecuadas (como setUIPolicyAccountId) cada vez que cambie el usuario activo, incluso al iniciar la aplicación, al cambiar de cuenta y al mostrar datos para un usuario diferente.

• Cambio de identidad iniciado por la aplicación:

  En el inicio, se considera que las aplicaciones de identidades múltiples se ejecutan en una cuenta desconocida y no administrada. La interfaz de usuario de inicio condicional no se ejecutará y no se aplicarán directivas en la aplicación. La aplicación es responsable de notificar al SDK cada vez que se debe cambiar la identidad. Normalmente, esto ocurrirá cuando la aplicación esté a punto de mostrar 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 de un bloc de notas. La aplicación debe notificar al SDK antes de abrir 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 independientemente de si el usuario está administrado o 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 cambio 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, el buzón o la pestaña hasta que se devuelva un código de resultado correcto. Si se produce un error en el cambio de identidad, la aplicación debe cancelar la tarea.

  Las aplicaciones de varias identidades deben evitar su uso setProcessAccountId como forma 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 usarse 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 anterior se realiza automáticamente. Es preferible usar setCurrentThreadAccountId:forScope:.

  En swift, 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 los cierres asincrónicos, de lanzamiento y de lanzamiento asincrónico.

• Cambio de identidad iniciado por el SDK:

  A veces, el SDK necesita pedir a la aplicación que cambie a una identidad específica. Las aplicaciones de identidades múltiples deben implementar el identitySwitchRequiredForAccountId método para IntuneMAMPolicyDelegate 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 identidad, la aplicación debe pasar IntuneMAMAddIdentityResultFailed al controlador de finalización.

  La aplicación no tiene que llamar setUIPolicyAccountId 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 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 selectivamente, el SDK llamará al wipeDataForAccountId método en IntuneMAMPolicyDelegate. La aplicación es responsable de quitar la cuenta del usuario especificado y cualquier dato asociado 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 este método se llama desde un subproceso en segundo plano. La aplicación no debería devolver un valor hasta que se hayan quitado todos los datos del usuario (a excepción de los archivos si la aplicación devuelve FALSE).

Criterios de salida

Planee dedicar mucho tiempo a validar la integración de múltiples identidades de su aplicación. Antes de comenzar las pruebas:

• Cree y asigne la directiva de protección de aplicaciones a una cuenta. Esta será la cuenta administrada de prueba.
• Crea, pero no asignes 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, además de las cuentas de Microsoft Entra, puede usar una cuenta existente que no sea de AAD como cuenta de prueba no administrada.
• Vuelva a familiarizarse con la forma en que se aplica la directiva dentro de la aplicación. Las pruebas de identidad múltiple requieren que distinga fácilmente cuándo su aplicación está y no está funcionando con la directiva impuesta. La configuración de la directiva de protección de aplicaciones para bloquear capturas de pantalla es eficaz para probar rápidamente la aplicación de directivas.
• Considere todo el conjunto de interfaz de usuario que ofrece su aplicación. Enumere 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. Enumerar cuáles de estos archivos contienen 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.
• Considere todo el conjunto de formas en que la aplicación puede interactuar con otras aplicaciones. Enumere todos los puntos de entrada y salida. ¿Qué tipos de datos puede ingerir tu aplicación? ¿Qué intenciones transmite? ¿Qué proveedores de contenido implementa?
  • Determine cómo ejercitará 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 ejecutando el siguiente conjunto de pruebas. Ten en cuenta que esta no es una lista completa y no garantiza que la implementación de múltiples identidades de tu aplicación esté libre de errores.

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

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

Para realizar estas pruebas, instala 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 esa cuenta estén administrados. - Inicia sesión con una cuenta no administrada y valida que los datos de esa cuenta no estén administrados.
Inicio de sesión no administrado primero	- Inicie sesión primero con una cuenta no administrada y valide que los datos de esa cuenta no estén administrados. - Inicie sesión con una cuenta administrada y valide que los datos de esa cuenta estén administrados.
Inicie sesión en múltiples instancias administradas	- Inicie sesión primero con una cuenta administrada y valide que los datos de esa cuenta estén administrados. - Inicie sesión con una segunda cuenta administrada y valide que el usuario no pueda iniciar sesión sin antes eliminar la cuenta administrada original.
Cerrar sesión administrada	- Inicie sesión en la aplicación con una cuenta administrada y una no administrada. - Cierre sesión en la cuenta administrada. - Confirme que la cuenta administrada se haya quitado de la aplicación y que se hayan quitado todos los datos de esa cuenta. - Confirme que la cuenta no administrada sigue teniendo sesión, que no se ha quitado ninguno de los datos de la cuenta no administrada y que la directiva aún no se ha aplicado.
Cerrar sesión sin administrar	- Inicie sesión en la aplicación con una cuenta administrada y una 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 aún tiene la sesión iniciada, que no se ha quitado ninguno de los datos de la cuenta no administrada y que la directiva aún se aplica.

Validar la identidad activa y el ciclo de vida de las aplicaciones

La aplicación de identidades múltiples puede presentar vistas con los datos de una sola cuenta y permitir que el usuario cambie explícitamente la cuenta en uso actual. 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 proporcione las protecciones adecuadas para la identidad activa en cada página durante todo el ciclo de vida de la aplicación.

Para realizar estas pruebas, instala 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	- Cambiar a la cuenta administrada. - Navegue a todas las páginas de su aplicación que presentan los datos de una sola cuenta. - Confirme que la política se aplica en todas las páginas.
Vista de cuenta única, no administrada	- Cambiar a la cuenta no administrada. - Navegue a todas las páginas de su aplicación que presentan los datos de una sola cuenta. - Confirme que la política no se aplica en ninguna página.
Vista de varias cuentas	- Navegue a todas las páginas de su aplicación que presentan datos de varias cuentas simultáneamente. - Confirme que la política se aplica en todas las páginas.
Pausa administrada	- En una pantalla con datos administrados mostrados y directiva activa, pause la aplicación navegando a la pantalla principal del dispositivo u otra aplicación. - Reanude la aplicación. - Confirme que la directiva aún se aplica.
Pausa no administrada	- En una pantalla en la que se muestren datos no administrados y sin ninguna directiva activa, pause la aplicación yendo a la pantalla principal del dispositivo o a otra aplicación. - Reanude la aplicación. - Confirme que la directiva no se aplica.
Apagado administrado	- En una pantalla con datos administrados mostrados y política activa, forzar la eliminación de la aplicación. - Reinicia la aplicación. - Confirme que, si la aplicación se reanuda en una pantalla con los datos de la cuenta administrada (previstos), la directiva seguirá aplicándose. Si la aplicación se reanuda en una pantalla con los datos de la cuenta no administrada, confirme que no se aplica la directiva.
Eliminación no administrada	- En una pantalla con datos no administrados mostrados y una directiva activa, fuerce la eliminación de la aplicación. - Reinicia la aplicación. - Confirme que, si la aplicación se reanuda en una pantalla con los datos de la cuenta no administrada (previstos), 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 sigue aplicada.
Cambio de identidad ad hoc	- Experimente cambiar entre cuentas y pausar / reanudar / matar / reiniciar 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 identidades múltiples puede enviar y recibir datos de otras aplicaciones. Las directivas de protección de aplicaciones de Intune tienen configuraciones que dictan este comportamiento. Estas pruebas ayudan a garantizar que la integración de identidades múltiples respete esta configuración de uso compartido de datos.

Para realizar estas pruebas, instala 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:

• Establece 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".
• Instala otras aplicaciones en el dispositivo de prueba:
  • Una aplicación administrada, segmentada 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, inicie sesión solo con la cuenta administrada.

Si la aplicación tiene la capacidad de enviar datos a otras aplicaciones, como Microsoft Outlook enviando datos adjuntos de documentos a Microsoft Office:

Escenario	Pasos
Envío de identidades administradas a una aplicación no administrada	- Cambiar a la cuenta administrada. - Navegue hasta donde su aplicación puede enviar datos. - Intentar enviar datos a una aplicación no administrada. - Se debería bloquear el envío de datos a la aplicación no administrada.
Envío de identidades administradas a la aplicación administrada	- Cambiar a la cuenta administrada. - Navegue hasta donde su aplicación puede enviar datos. - Intente enviar datos a la otra aplicación administrada con la cuenta administrada iniciada. - Debería tener permiso para enviar datos a la aplicación administrada.
Envío de identidades no administradas a la aplicación administrada	- Cambiar a la cuenta no administrada. - Navegue hasta donde su aplicación puede enviar datos. - Intente enviar datos a la otra aplicación administrada con la cuenta administrada iniciada. - Se le debería bloquear el envío de datos a la otra aplicación administrada.
Envío de identidades no administradas a una aplicación no administrada	- Cambiar a la cuenta no administrada. - Navegue hasta donde su aplicación puede enviar datos. - Intentar enviar datos a una aplicación no administrada. - Siempre debería tener permiso para enviar datos de una cuenta no administrada a una aplicación no administrada.

La aplicación puede importar datos activamente de otras aplicaciones, como Microsoft Outlook adjuntando un archivo de Microsoft OneDrive. La aplicación también puede recibir datos de forma pasiva de otras aplicaciones, como Microsoft Office que abre un documento desde datos adjuntos de Microsoft Outlook. La configuración de directiva de protección de la aplicación 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 identidades administradas desde una aplicación no administrada	- Cambiar a la cuenta administrada. - Navegue hasta donde su aplicación puede importar datos de otras aplicaciones. - Intentar importar datos de una aplicación no administrada. - Debería tener bloqueado la importación de datos de aplicaciones no administradas.
Importación de identidades administradas desde una aplicación administrada	- Cambiar a la cuenta administrada. - Navegue hasta donde su aplicación puede importar datos de otras aplicaciones. - Intente importar datos de la otra aplicación administrada con la cuenta administrada iniciada. - Debería tener permiso para importar datos de la otra aplicación administrada.
Importación de identidades no administradas desde una aplicación administrada	- Cambiar a la cuenta no administrada. - Navegue hasta donde su aplicación puede importar datos de otras aplicaciones. - Intente importar datos de la otra aplicación administrada con la cuenta administrada iniciada. - Debería estar bloqueado para importar datos de la otra aplicación administrada.
Importación de identidades no administradas desde una aplicación no administrada	- Cambiar a la cuenta no administrada. - Navegue hasta donde su aplicación puede importar datos de otras aplicaciones. - Intentar importar datos de una aplicación no administrada. - Siempre debería tener permiso para importar datos de una aplicación no administrada para una cuenta no administrada.

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

Escenario	Pasos
Identidad administrada recibida de una aplicación no administrada	- Cambiar a la cuenta administrada. - Cambiar a la aplicación no administrada. - Navegue hasta donde pueda enviar datos. - Intente enviar datos de 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.
Identidad administrada recibida de una aplicación administrada	- Cambiar a la cuenta administrada. - Cambie a la otra aplicación administrada con la cuenta administrada con la sesión iniciada. - Navegue hasta donde pueda enviar datos. - Intente enviar datos de la aplicación administrada a la aplicación. - La cuenta administrada de la aplicación debe poder recibir datos de la otra aplicación administrada.
Identidad no administrada recibida de una aplicación administrada	- Cambiar a la cuenta no administrada. - Cambie a la otra aplicación administrada con la cuenta administrada con la sesión iniciada. - Navegue hasta donde pueda enviar datos. - Intente enviar datos de 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.
Identidad no administrada recibida de una aplicación no administrada	- Cambiar a la cuenta no administrada. - Cambiar a la aplicación no administrada. - Navegue hasta donde pueda enviar datos. - Intente enviar datos de la aplicación no administrada a la aplicación. - La cuenta no administrada de la aplicación siempre debe poder recibir datos de la aplicación no administrada.

Los errores en estas pruebas pueden indicar que la aplicación no tiene la identidad activa correcta establecida cuando intenta enviar o recibir datos. Puede investigar esto aprovechando las API de obtener identidad del SDK en el momento de envío o recepción para confirmar que la identidad activa está establecida correctamente.

Pasos siguientes

Una vez que haya completado todos los criterios de salida anteriores, la aplicación ahora está correctamente integrada como multi-identidad y puede aplicar directivas de protección de aplicaciones por identidad. Las secciones siguientes, a saber, la Fase 6: Protección de aplicaciones, la compatibilidad con el acceso condicional y la Fase 7: Las características de vista web pueden o no ser necesarias, en función de la compatibilidad con la directiva de protección de aplicaciones deseada de la aplicación.