SDK de la aplicación de Intune para Android: multiidentidad

El SDK de aplicaciones de Microsoft Intune para Android le permite incorporar directivas de protección de aplicaciones de Intune (también conocidas como directivas MAM) en su aplicación nativa de Android Java/Kotlin. Una aplicación administrada por Intune es aquella que está integrada con el SDK de la aplicación de Intune. Los administradores de Intune pueden implementar fácilmente directivas de protección de aplicaciones en la aplicación administrada por Intune cuando Intune administra activamente la aplicación.

Nota:

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

Etapa 5: Multi-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.

Terminología de identidad

Los términos "usuario", "cuenta" e "identidad" a menudo se usan indistintamente. Esta guía intenta diferenciar lo siguiente:

• Usuario: el ser humano que utiliza el producto de software. Diferenciado aún más como usuario final, el humano / que usa la aplicación Android, y usuario administrador / administradorde TIEl administrador / de TI profesional de TI, el humano que usa el centro de administración de Microsoft Intune.
• Cuenta: el registro de software que pertenece a una organización que identifica de manera única la entidad de un usuario. Un usuario humano puede tener varias cuentas.
• Identidad: el conjunto de datos que usa el SDK de aplicaciones de Intune para identificar una cuenta de forma exclusiva.

Información previa

De forma predeterminada, el SDK de aplicaciones de Intune aplica la directiva a toda la aplicación. Después de registrar una cuenta con la directiva de protección de aplicaciones de destino, el SDK asocia cada archivo y cada actividad con la identidad de esa cuenta y aplicará la directiva de destino de esa cuenta universalmente.

Para muchos desarrolladores, este es el comportamiento de protección de aplicaciones deseado para su aplicación. Estas aplicaciones se consideran de identidad única. Al completar las etapas anteriores, la aplicación se ha integrado correctamente como identidad única y puede aplicar todas las directivas básicas. Las aplicaciones diseñadas para seguir siendo de identidad única pueden omitir esta sección y continuar con la Fase 6: App Configuration.

Opcionalmente, el SDK de aplicaciones de Intune puede aplicar la directiva a nivel por identidad. Si su aplicación ya admite varias cuentas que han iniciado sesión simultáneamente y desea conservar este soporte de varias cuentas con las directivas de protección de aplicaciones, su aplicación se considera multiidentidad.

Sugerencia

Si no tiene claro si la solicitud debe admitir protecciones de identidad única o multiidentidad, vuelva a visitar ¿Mi solicitud es de identidad única o de identidad múltiple?

Advertencia

La compatibilidad con identidades múltiples es significativamente más compleja que otras características de protección de aplicaciones. La integración incorrecta de múltiples identidades puede provocar fugas de datos y otros problemas de seguridad. Revise esta sección cuidadosamente y planifique suficiente tiempo para las pruebas antes de continuar con la siguiente etapa.

"identity" al SDK

Cuando una aplicación integrada en SDK registra una cuenta con registerAccountForMAM, el SDK guarda todos los parámetros proporcionados (upn, aadId, tenantId y authority) como identidad. Sin embargo, la mayoría de las API de identidad del SDK usan el OID proporcionado (también conocido como Microsoft Entra ID o AAD ID) como identificador de la identidad. Las API del SDK de MAM devolverán la cadena OID como identidad y requerirán el parámetro de cadena OID para la identidad. Algunos métodos también pueden tomar o devolver una cadena UPN, en cuyo caso el UPN es solo para fines informativos.

Los parámetros de identidad 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ó al registrar o establecer la identidad.

Precaución

En el caso de las aplicaciones que usan métodos en desuso que toman o devuelven una cadena UPN, las aplicaciones deben asegurarse de que la cadena UPN de identidad pasada a varias llamadas API sea coherente. El paso de cadenas UPN incoherentes puede dar lugar a pérdidas de datos.

Identidades administradas frente a identidades no administradas

Como se describe en Registro para la directiva de protección de aplicaciones, la aplicación es responsable de informar al SDK cuando un usuario inicia sesión. En el momento del inicio de sesión, la cuenta del usuario puede o no ser objeto de la directiva de protección de aplicaciones. Si la cuenta está de destino con la directiva de protección de aplicaciones, el SDK la considera administrada; de lo contrario, no está administrado.

El SDK aplicará la directiva para las identidades que considere administradas. El SDK no aplicará la directiva para las identidades que considere no administradas.

Actualmente, el SDK de la aplicación de Intune solo admite una única identidad administrada por dispositivo. Tan pronto como cualquier aplicación integrada en SDK registre una identidad administrada, todas las identidades registradas posteriormente, incluso si actualmente están destinadas a directivas de protección de aplicaciones, se tratarán como no administradas.

Si ya se ha registrado una identidad administrada en el dispositivo y la aplicación registra otra identidad que también está destinada a la directiva de protección de aplicaciones, el SDK devolverá MAMEnrollmentManager.Result.WRONG_USER y solicitará al usuario final las opciones para corregir. Consulte Registro para notificaciones desde el SDK para obtener más detalles.

Nota:

Una cuenta que no esté de destino con la directiva de protección de aplicaciones en el momento del registro se considerará no administrada. Incluso si la cuenta no tiene licencia ni está dirigida a la directiva de protección de aplicaciones, el SDK comprobará periódicamente si esta cuenta se convierte en una licencia y un destino posteriores. Si no se ha registrado ninguna otra identidad administrada, el SDK comenzará a tratar esta identidad como administrada una vez que se destine a la directiva. El usuario no necesita cerrar sesión y volver a iniciar sesión en esta cuenta para realizar este cambio.

La identidad activa

La aplicación siempre debe mantener informado al SDK de la identidad que se usa actualmente, también conocida como identidad activa. Si se administra la identidad activa, el SDK aplicará protecciones. Si la identidad activa no está administrada, el SDK no aplicará protecciones.

Dado que el SDK no tiene conocimientos específicos de la aplicación, debe confiar en la aplicación para compartir la identidad activa correcta.

• Si la aplicación indica incorrectamente al SDK que una identidad no administrada está activa cuando la identidad administrada está realmente en uso, el SDK no aplicará protecciones. Esto podría provocar una pérdida de datos que ponga en riesgo los datos de los usuarios.

• Si la aplicación indica incorrectamente al SDK que la identidad administrada está activa cuando una identidad no administrada está realmente en uso, el SDK aplicará protecciones de forma inapropiada. No se trata de una filtración de datos, pero puede restringir innecesariamente a los usuarios no administrados y poner los datos de los usuarios no administrados en riesgo de eliminación.

Si la aplicación muestra los datos de cualquier usuario, solo debe mostrar los datos que pertenecen a la identidad activa. Si la aplicación no sabe actualmente quién es el propietario de los datos que se muestran, es posible que tenga que refactorizar la aplicación para obtener un mayor reconocimiento de identidad antes de empezar a integrar la compatibilidad con varias identidades.

Organización de los datos de la aplicación por identidad

Cada vez que la aplicación escribe un archivo nuevo, el SDK asocia (también conocidas como "etiquetas") una identidad con ese archivo en función del subproceso activo actual y la identidad del proceso. Como alternativa, la aplicación puede llamar directamente al SDK para etiquetar manualmente un archivo con una identidad determinada (consulta Escritura de Files protegidos para obtener más información). El SDK usa esta identidad de archivo etiquetada para el cifrado de archivos y el borrado selectivo.

Si la identidad administrada se destina con una directiva de cifrado, solo se cifrarán los archivos etiquetados con la identidad administrada.

Si la acción del administrador o la directiva configurada solicita que se borren los datos administrados, solo se eliminarán los archivos etiquetados con la identidad administrada.

El SDK no puede asociar varias identidades a un único archivo. Si la aplicación almacena datos que pertenecen a varios usuarios en el mismo archivo, el comportamiento predeterminado del SDK dará como resultado una protección insuficiente o excesiva de estos datos. Se recomienda encarecidamente que organice los datos de la aplicación por identidad.

Si es indispensable que la aplicación almacene datos que pertenecen a identidades diferentes en el mismo archivo, el SDK proporciona características para etiquetar con identidad subconjuntos de datos dentro de un archivo. Consulte Protección de búfer de datos para obtener más información.

Implementación de identidades múltiples

Para declarar la compatibilidad con varias identidades para la aplicación, empiece por colocar los siguientes metadatos en AndroidManifest.xml.

  <meta-data
    android:name="com.microsoft.intune.mam.MAMMultiIdentity"
    android:value="true" />

Configuración de la identidad activa

La aplicación puede establecer la identidad activa en los siguientes niveles de prioridad descendente:

1. Nivel de subproceso
2. Context (generalmente Activity) nivel
3. Nivel de proceso

Un conjunto de identidades en el nivel de subproceso reemplaza a un conjunto de identidades en el Context nivel, que reemplaza a un conjunto de identidades en el nivel de proceso.

Un conjunto de identidades en a Context solo se usa en escenarios asociados adecuados. Las operaciones de E/S de archivos, por ejemplo, no tienen un Contextarchivo . Por lo general, las aplicaciones establecerán la Context identidad en un Activityarchivo . Considere la posibilidad de establecer la Context identidad en Activity.onCreate. Una aplicación no debe mostrar datos para una identidad a menos que la Activity identidad se establezca en esa misma identidad.

En general, la identidad de nivel de proceso solo es útil si la aplicación funciona con una sola identidad a la vez en todos los subprocesos. Este no es el comportamiento típico de las aplicaciones que admiten varias cuentas. Se recomienda encarecidamente segregar los datos de la cuenta y establecer la identidad activa en el subproceso o Context niveles.

Si su aplicación usa el contexto para adquirir servicios del Application sistema, asegúrese de que se haya establecido la identidad de subproceso o proceso, o de que haya establecido la identidad de interfaz de usuario en el contexto de su Application aplicación.

Si la aplicación usa un Service contexto para lanzar intenciones, usa solucionadores de contenido o aprovecha otros servicios del sistema, asegúrate de establecer la identidad en el Service contexto. De forma similar, si la aplicación usa un JobService contexto para realizar estas acciones, asegúrese de establecer la identidad en el contexto o subproceso según lo JobService requiera JobService la implementación. Por ejemplo, si procesa JobService trabajos para una sola identidad, considere la posibilidad de establecer la identidad en el JobService contexto. Si procesa JobService trabajos para varias identidades, considere la posibilidad de establecer la identidad en el nivel de subproceso.

Precaución

Las aplicaciones que usan WorkManager deben tener especial cuidado al establecer la identidad. En concreto, estas aplicaciones deben evitar establecer una identidad en el Context pasado en el Worker constructor. Esta Context instancia se puede compartir entre varias Worker instancias simultáneamente. Para evitar un comportamiento indefinido, las aplicaciones deben establecer en su lugar una identidad de subproceso según Worker.doWork() lo requiera la Worker implementación.

Nota:

Dado que se CLIPBOARD_SERVICE usa para operaciones de interfaz de usuario, el SDK usa la identidad de interfaz de usuario de la actividad en primer plano para ClipboardManager las operaciones.

Los siguientes métodos en MAMPolicyManager se pueden utilizar para establecer la identidad activa y recuperar los valores de identidad establecidos previamente.

public static void setUIPolicyIdentityOID(final Context context, final String oid,
                    final MAMSetUIIdentityCallback mamSetUIIdentityCallback, final EnumSet<IdentitySwitchOption> options);

public static String getUIPolicyIdentityOID(final Context context);

public static MAMIdentitySwitchResult setProcessIdentityOID(final String oid);

public static String getProcessIdentityOID();

public static MAMIdentitySwitchResult setCurrentThreadIdentityOID(final String oid);

public static String getCurrentThreadIdentityOID();

/**
 * Get the current app policy. This does NOT take the UI (Context) identity into account.
 * If the current operation has any context (e.g. an Activity) associated with it, use the overload below.
 */
public static AppPolicy getCurrentThreadPolicy();

/**
 * Get the current app policy. This DOES take the UI (Context) identity into account.
 * If the current operation has any context (e.g. an Activity) associated with it, use this function.
 */
public static AppPolicy getPolicy(final Context context);


public static AppPolicy getPolicyForIdentityOID(final String oid);

public static boolean getIsIdentityOIDManaged(final String oid);

Para mayor comodidad, también puede establecer la identidad de una actividad directamente a través de un método en MAMActivity en lugar de llamar a MAMPolicyManager.setUIPolicyIdentityOID. Utilice el siguiente método para hacerlo:

     public final void switchMAMIdentityOID(final String newIdentityOid, final EnumSet<IdentitySwitchOption> options);

Nota:

Si la aplicación no ha declarado compatibilidad con identidades múltiples en el manifiesto, llamar a estos métodos para establecer la identidad no ejecutará ninguna acción y, si devuelven un MAMIdentitySwitchResult, siempre devolverá FAILED.

Errores comunes del cambio de identidad

• Para las llamadas a startActivity, el SDK de la aplicación de Intune supone que la identidad activa en el Context nivel está asociada al parámetro proporcionadoIntent. Recomendamos encarecidamente establecer la identidad de Context nivel con un Activitycontexto de , no con el Applicationcontexto de .

• Se recomienda establecer la Context identidad durante el método de onCreate una actividad. Sin embargo, asegúrese de cubrir también otros puntos de entrada como onNewIntent. De lo contrario, cuando se reutiliza la misma actividad para mostrar datos de identidades administradas y no administradas, la directiva puede aplicarse incorrectamente, lo que da lugar a datos corporativos desprotegidos o datos personales restringidos incorrectamente.

Resultados del cambio de identidad

Todos los métodos utilizados para establecer los valores de resultados del informe de identidad a través de MAMIdentitySwitchResult. Se pueden devolver cuatro valores:

Valor devuelto	Escenario
SUCCEEDED	El cambio de identidad se realizó correctamente.
NOT_ALLOWED	No se permite el cambio de identidad. Esto sucedía si se intenta establecer la identidad de UI (Context) cuando se establece una identidad diferente en el subproceso actual.
CANCELLED	El usuario ha cancelado el cambio de identidad, por lo general presionando el botón Atrás de un PIN o un mensaje de autenticación.
FAILED	Se produjo un error en el cambio de identidad por un motivo no especificado.

La aplicación debe comprobar que MAMIdentitySwitchResult es SUCCEEDED antes de mostrar o usar los datos de una cuenta administrada.

La mayoría de los métodos para establecer la identidad activa devuelven MAMIdentitySwitchResult de forma sincrónica. En el caso de establecer una Context identidad a través de setUIPolicyIdentityOID, el resultado se notifica de forma asincrónica. La aplicación puede implementar una devolución MAMSetUIIdentityCallback para recibir este resultado o puede pasar null para el objeto de devolución de llamada. Si se realiza una llamada mientras que el resultado de una llamada anterior a la misma Context aún no se ha entregado, la nueva devolución de llamada reemplazará a setUIPolicyIdentityOIDsetUIPolicyIdentityOID la anterior y la devolución de llamada original nunca recibirá un resultado.

Precaución

Si el Context proporcionado a setUIPolicyIdentityOID es un Activity, el SDK no sabe si el cambio de identidad se realizó correctamente hasta después de realizar las comprobaciones de inicio condicional configuradas por el administrador. Esto puede requerir que el usuario escriba un PIN o credenciales corporativas.

Actualmente, los modificadores de identidad de proceso y subproceso siempre se realizarán correctamente para una aplicación habilitada para identidades múltiples. El SDK se reserva el derecho de agregar condiciones de error en el futuro.

El modificador de identidad de la interfaz de usuario puede fallar por argumentos no válidos, si entra en conflicto con la identidad del subproceso o si el usuario cancela los requisitos de inicio condicional (por ejemplo, presiona el botón Atrás en la pantalla del PIN).

El comportamiento predeterminado para un cambio de identidad de interfaz de usuario fallido en una actividad es finalizar la actividad. Para cambiar este comportamiento y recibir notificaciones sobre intentos de cambio de identidad para una actividad, puede invalidar un método en MAMActivity.

    public void onSwitchMAMIdentityComplete(final MAMIdentitySwitchResult result);

Si invalida onSwitchMAMIdentityComplete (o llama al super método), debe asegurarse de que los datos de una cuenta administrada no se muestren después de un cambio de identidad fallido.

Nota:

Cambiar la identidad puede requerir volver a crear la actividad. En este caso, la onSwitchMAMIdentityComplete devolución de llamada se entregará a la nueva instancia de la actividad.

Identity, Intents, and IdentitySwitchOptions

Además de etiquetar automáticamente los nuevos archivos con la identidad activa, el SDK también etiqueta las intenciones con la identidad activa. De forma predeterminada, el SDK comprobará la identidad en una intención entrante y la comparará con la identidad activa. Si estas identidades no coinciden, el SDK típicamente(*) solicita un cambio de identidad (consulte Cambios de identidad implícitos a continuación para obtener más detalles).

El SDK también almacena esta identidad de intención entrante para su uso posterior. Cuando la aplicación cambia explícitamente la identidad de la interfaz de usuario, el SDK compara la identidad a la que la aplicación intenta cambiar con la identidad de intención entrante más reciente. Si estas identidades no coinciden, el SDK normalmente producirá un error (*) en el cambio de identidad.

El SDK realiza esta comprobación porque supone que la aplicación sigue mostrando contenido de la intención que pertenece a la identidad etiquetada en la intención. Esta suposición protege contra la desactivación involuntaria de protecciones por parte de la aplicación al mostrar datos administrados; Sin embargo, es posible que esta suposición no sea correcta para el comportamiento real de la aplicación.

Las enumeraciones IdentitySwitchOption opcionales se pueden pasar a las API setUIPolicyIdentityOID y switchMAMIdentityOID para modificar el comportamiento predeterminado del SDK.

• IGNORE_INTENT: al solicitar un cambio de identidad en la capa de interfaz de usuario, esta opción informa al SDK de que omita la comparación del parámetro de identidad solicitado con la identidad de intención almacenada más recientemente. Esto es útil cuando la aplicación ya no muestra contenido que pertenezca a esa identidad y el SDK no debe bloquear este cambio de identidad. Por ejemplo:

  1. Su aplicación es un visor de documentos. Puede representar documentos pasados desde otras aplicaciones. También contiene una característica en la que los usuarios pueden cambiar de cuenta. Siempre que el usuario usa esta característica de cambio de cuenta, la aplicación navega a una página de aterrizaje específica de la cuenta con los documentos recientes de esa cuenta.
  2. La aplicación recibe una intención de mostrar un documento. Esta intención se etiqueta con la identidad administrada.
  3. La aplicación se cambia a la identidad administrada y muestra este documento, con las protecciones aplicadas correctamente.
  4. El usuario usa el conmutador de cuentas para cambiar a su cuenta personal.

  La aplicación debe cambiar la identidad de la interfaz de usuario en el paso 4. En este caso, dado que el comportamiento de la aplicación es salir de los datos de la cuenta administrada (el documento en la intención), debe usarse IGNORE_INTENT en la llamada de cambio de identidad. Esto evita que el SDK falle inapropiadamente esta llamada.

• DATA_FROM_INTENT: al solicitar un cambio de identidad en la capa de interfaz de usuario, esta opción informa al SDK de que los datos de la identidad de intención almacenada más recientemente seguirán mostrándose después de que el cambio de identidad se realice correctamente. Como resultado, el SDK evaluará completamente la directiva de recepción con respecto a la identidad de intención anterior para determinar si se permite mostrarla. Por ejemplo:

  1. Su aplicación es un visor de documentos. Puede representar documentos pasados desde otras aplicaciones. También contiene una característica en la que los usuarios pueden cambiar de cuenta. A diferencia del ejemplo anterior, siempre que el usuario usa esta característica de cambio de cuenta, la aplicación navega a una página compartida que muestra documentos recientes de todas las cuentas.
  2. La aplicación recibe una intención de mostrar un documento. Esta intención se etiqueta con la identidad administrada.
  3. La aplicación se cambia a la identidad administrada y muestra este documento, con las protecciones aplicadas correctamente.
  4. El usuario usa el conmutador de cuentas para cambiar a su cuenta personal.

  La aplicación debe cambiar la identidad de la interfaz de usuario en el paso 4. En este caso, dado que el comportamiento de la aplicación es seguir mostrando los datos de la identidad administrada (una vista previa del documento en la intención), debe usarse DATA_FROM_INTENT en la llamada de cambio de identidad. Esto informa al SDK de que compruebe la directiva de protección de aplicaciones configurada para determinar si es apropiado que los datos se sigan mostrando.

(*) El comportamiento predeterminado del SDK incluye una carcasa especial que omite esta verificación de entrada de datos si, por ejemplo, la intención proviene del interior de la misma aplicación o del iniciador del sistema.

Borrar la identidad activa

La aplicación puede tener escenarios independientes de la cuenta. La aplicación también puede tener escenarios para escenarios locales no administrados que no requieran ningún inicio de sesión. En ambos casos, es posible que la aplicación no quiera que el SDK aplique las directivas de la identidad administrada, pero es posible que no tenga una identidad explícita a la que cambiar.

Puede borrar la identidad activa llamando a cualquiera de los métodos de identidad establecidos con el parámetro OID de identidad establecido en null. Al borrar la identidad en un nivel, el SDK buscará la identidad activa en otros niveles, en función del orden de prioridad.

Como alternativa, puede pasar una cadena vacía como parámetro OID de identidad, que establece la identidad en un valor vacío especial que se trata como una identidad no administrada. Al establecer la identidad activa en una cadena vacía, se indica al SDK que no aplique ninguna directiva de protección de aplicaciones.

Cambios de identidad implícitos

En la sección anterior se describen las distintas maneras en que la aplicación puede establecer explícitamente la identidad activa en los niveles de subproceso, contexto y proceso. Sin embargo, la identidad activa en la aplicación también puede cambiar sin que la aplicación llame a ninguno de estos métodos. En esta sección, se describe cómo la aplicación puede escuchar y responder a estos cambios de identidad implícitos.

Escuchar estos cambios de identidad implícitos es opcional, pero recomendado. El SDK nunca cambiará la identidad activa sin proporcionar estas notificaciones implícitas de cambio de identidad.

Precaución

Si la aplicación decide no escuchar los cambios de identidad implícitos, tenga mucho cuidado de no asumir la identidad activa. En caso de duda, use los getCurrentThreadIdentityOIDmétodos , getUIPolicyIdentityOID, y getProcessIdentityOID para confirmar la identidad activa.

Fuentes de cambios de identidad implícitos

• La entrada de datos de otras aplicaciones administradas por Intune puede cambiar la identidad activa en el nivel de subproceso y contexto.

  • Si se inicia una actividad desde un Intent enviado por otra aplicación MAM, la identidad de la actividad se establecerá en función de la identidad activa de la otra aplicación en el momento Intent en que se envió.

    • Por ejemplo, una actividad para ver un documento de Word se inicia desde una intención de Microsoft Outlook cuando un usuario selecciona los datos adjuntos de un documento. La identidad de la actividad del visor de documentos de Office se cambia a la identidad de Outlook.

  • En el caso de los servicios, la identidad del subproceso se establecerá de forma similar durante la duración de una onStart llamada o onBind . Las llamadas al Binder devuelto onBind desde también establecerán temporalmente la identidad del subproceso.

  • Las llamadas a un ContentProvider establecerán de forma similar la identidad del subproceso durante su duración.

• La interacción del usuario con una actividad puede cambiar la identidad activa en el nivel de contexto. Por ejemplo:

  • Un usuario que cancela tras una solicitud de autorización durante Resume dará lugar a un cambio implícito a una identidad vacía.

Control de cambios de identidad implícitos

Opcionalmente, la aplicación puede escuchar y reaccionar a estos cambios de identidad implícitos. Por ejemplo, la aplicación puede requerir varios pasos antes de que una cuenta agregada pueda usarse, como una aplicación de correo electrónico que configura una nueva bandeja de entrada. Al ver un intento de cambio de identidad a la identidad de esta cuenta incompleta, el controlador de la aplicación podría redirigir al usuario a la actividad de configuración de la cuenta antes de aceptar el cambio de identidad. Como alternativa, el controlador de la aplicación podría mostrar un cuadro de diálogo de error y bloquear el modificador de identidad.

La aplicación puede implementar la interfaz MAMIdentityRequirementListener en un Service o ContextProvider para los cambios de identidad que se aplican a este subproceso. Su implementación debe invalidar:

public abstract void onMAMIdentitySwitchRequired(String upn, String oid,
        AppIdentitySwitchResultCallback callback);

La aplicación puede implementar la interfaz MAMActivityIdentityRequirementListener en una Activity for identity changes que se aplique a esta actividad. Su implementación debe invalidar:

public abstract void onMAMIdentitySwitchRequired(String upn, String oid,
        AppIdentitySwitchReason reason,
        AppIdentitySwitchResultCallback callback);

El AppIdentitySwitchReason parámetro enum describe el origen del modificador de identidad implícito.

Valor de enumeración	Comportamiento predeterminado de SDK	Descripción
CREATE	Permita el cambio de identidad.	El cambio de identidad se produce debido a la creación de una actividad.
NEW_INTENT	Permita el cambio de identidad.	El cambio de identidad se produce porque se asigna una nueva intención a una actividad.
RESUME_CANCELLED	Bloquee el modificador de identidad.	El cambio de identidad se produce porque se canceló una reanudación. Esto es más común cuando el usuario final presiona el botón Atrás en el PIN, la autenticación o la interfaz de usuario de cumplimiento.

El parámetro AppIdentitySwitchResultCallback permite a los desarrolladores invalidar el comportamiento predeterminado del modificador de identidad:

public interface AppIdentitySwitchResultCallback {
  /**
    * @param result
    *            whether the identity switch can proceed.
    */
  void reportIdentitySwitchResult(AppIdentitySwitchResult result);
}
// Where [AppIdentitySwitchResult] is either `SUCCESS` or `FAILURE`.

onMAMIdentitySwitchRequired se llama para todos los cambios de identidad implícitos, excepto los realizados a través de un Binder devuelto de MAMService.onMAMBind. Las implementaciones predeterminadas de onMAMIdentitySwitchRequired llamada inmediata:

• callback.reportIdentitySwitchResult(FAILURE) cuando la razón es RESUME_CANCELLED.

• callback.reportIdentitySwitchResult(SUCCESS) en todos los demás casos.

No se espera que la mayoría de las aplicaciones necesiten bloquear o retrasar un cambio de identidad de una manera diferente, pero si una aplicación necesita hacerlo, se deben considerar los siguientes puntos:

• Si se bloquea un modificador de identidad, el comportamiento del usuario final es el mismo que si la configuración de protección de la aplicación "Recibir datos de otras aplicaciones" del SDK hubiera prohibido la entrada de datos.

• Si se ejecuta un servicio en el subproceso principal, reportIdentitySwitchResultse le debe llamar sincrónicamente o el subproceso de la interfaz de usuario dejará de responder.

• Para Activity la creación, se llamará a onMAMIdentitySwitchRequired antes onMAMCreatede . Si la aplicación debe mostrar la interfaz de usuario para determinar si se permite el cambio de identidad, esa interfaz de usuario debe mostrarse con una actividad diferente .

• En un Activity, cuando se solicita un cambio a la identidad vacía con el motivo como RESUME_CANCELLED, la aplicación debe modificar la actividad reanudada para mostrar datos coherentes con ese cambio de identidad. Si esto no es posible, la aplicación debe rechazar el cambio y se le volverá a pedir al usuario que cumpla con la directiva para la reanudación de la identidad (por ejemplo, cuando se le presenta la pantalla de entrada del PIN de la aplicación).

Precaución

Una aplicación de varias identidades puede recibir datos entrantes de aplicaciones administradas y no administradas. Es responsabilidad de la aplicación tratar los datos de las identidades administradas de manera administrada.

Si se administra una identidad solicitada (use MAMPolicyManager.getIsIdentityOIDManaged para comprobarlo), pero la aplicación no puede usar esa cuenta (por ejemplo, porque las cuentas, como las cuentas de correo electrónico, deben configurarse primero en la aplicación), se debe rechazar el cambio de identidad.

Se puede acceder al comportamiento MAMActivity.onMAMIdentitySwitchRequired predeterminado llamando al método MAMActivity.defaultOnMAMIdentitySwitchRequired(activity, upn, oid, reason, callback)estático .

De forma similar, si necesita invalidar MAMActivity.onSwitchMAMIdentityComplete, puede implementar MAMActivityIdentitySwitchListener sin heredar explícitamente de MAMActivity.

Modificadores de identidad y restricciones de captura de pantalla

El SDK de la aplicación de Intune usa la marca FLAG_SECURE para aplicar la Window directiva de captura de pantalla. Algunas aplicaciones también pueden establecerse FLAG_SECURE para sus propios fines. Cuando la directiva de protección de aplicaciones no restringe las capturas de pantalla, el SDK no modificará FLAG_SECURE.

En un cambio de identidad de una identidad cuya directiva requiere deshabilitar capturas de pantalla a una identidad cuya directiva no, el SDK borrará FLAG_SECURE. Como resultado, la aplicación no debería depender de FLAG_SECURE permanecer establecido después de un cambio de identidad.

Conservar la identidad en operaciones asincrónicas

Las aplicaciones suelen distribuir tareas en segundo plano desde el subproceso de la interfaz de usuario para controlar las operaciones en otros subprocesos. Una aplicación de varias identidades debe garantizar que estas tareas en segundo plano funcionan con la identidad adecuada, que suele ser la misma identidad usada por la actividad que las envió.

El SDK de la aplicación de Intune proporciona MAMAsyncTask y MAMIdentityExecutors para la comodidad de ayudar a conservar la identidad en operaciones asincrónicas. La aplicación debe usarlos (o establecer explícitamente la identidad del subproceso en las tareas) si sus operaciones asincrónicas pueden:

• Escribir datos pertenecientes a una identidad administrada en un archivo
• Comunicarse con otras aplicaciones

MAMAsyncTask

Para usar MAMAsyncTask, simplemente herede de ella en lugar de AsyncTask y reemplace las invalidaciones de doInBackground y onPreExecute con doInBackgroundMAM y onPreExecuteMAM respectivamente. El MAMAsyncTask constructor toma un contexto de actividad. Por ejemplo:

AsyncTask<Object, Object, Object> task = new MAMAsyncTask<Object, Object, Object>(thisActivity) {

    @Override
    protected Object doInBackgroundMAM(final Object[] params) {
        // Do operations.
    }

    @Override
    protected void onPreExecuteMAM() {
        // Do setup.
    };
}

MAMAsyncTask asumirá la identidad activa en función del orden normal de prioridad.

MAMIdentityExecutors

MAMIdentityExecutorsPermite ajustar una instancia OR existente Executor como una conservación ExecutorExecutorService/de la identidad con wrapExecutor métodos AND.wrapExecutorServiceExecutorService Por ejemplo

Executor wrappedExecutor = MAMIdentityExecutors.wrapExecutor(originalExecutor, activity);
ExecutorService wrappedService = MAMIdentityExecutors.wrapExecutorService(originalExecutorService, activity);

MAMIdentityExecutors asumirá la identidad activa en función del orden normal de prioridad.

Protección de archivos

Escritura de Files protegidos

Como se mencionó en Organizar los datos de la aplicación por identidad anteriormente, el SDK de la aplicación de Intune asocia la identidad activa (desde el nivel de subproceso o proceso) con los archivos a medida que se escriben. Es fundamental tener la identidad correcta establecida en el momento de la creación del archivo para garantizar un cifrado adecuado y la funcionalidad de borrado selectivo.

La aplicación puede consultar o cambiar la identidad de un archivo mediante la clase MAMFileProtectionManager , específicamente MAMFileProtectionManager.getProtectionInfo para realizar consultas y MAMFileProtectionManager.protectForOID cambios.

Este protectForOID método también se puede utilizar para proteger directorios. La protección de directorios se aplica de forma recursiva a todos los archivos y subdirectorios contenidos en el directorio. Cuando un directorio está protegido, todos los archivos nuevos creados dentro del directorio tendrán automáticamente la misma protección aplicada. Como la protección de directorios se aplica de forma recursiva, la protectForOID llamada puede tardar algún tiempo en completarse para directorios grandes. Por ese motivo, es posible que las aplicaciones que aplican protección a un directorio que contiene un gran número de archivos deseen ejecutarse protectForOID de forma asincrónica en un subproceso en segundo plano.

Si se llama protectForOID con una cadena vacía para el parámetro identity, se etiquetará el archivo o directorio con la identidad no administrada. Esta operación quitará el cifrado del archivo o directorio si se cifró previamente. Cuando se emite un comando de borrado selectivo, el archivo/directorio no se eliminará.

Advertencia

Es importante asegurarse de que solo los archivos que pertenecen a una identidad determinada estén protegidos con esa identidad. De lo contrario, otras identidades pueden experimentar una pérdida de datos cuando la identidad propietaria cierre sesión, ya que se borrarán los archivos y se perderá el acceso a la clave de cifrado.

Mostrar contenido de archivos protegidos

Es igualmente crítico tener la identidad correcta establecida cuando se muestra contenido de archivo para evitar que usuarios no autorizados vean los datos administrados. El SDK no puede inferir automáticamente una relación entre los archivos que se leen y los datos que se muestran en un Activityarchivo . Las aplicaciones deben establecer la identidad de la interfaz de usuario correctamente antes de mostrar cualquier dato administrado. Esto incluye los datos leídos de archivos.

Si un archivo proviene de fuera de la aplicación (ya sea de una ContentProvider ubicación o leído desde una ubicación grabable públicamente), la aplicación debe intentar determinar la identidad del archivo (mediante la sobrecarga MAMFileProtectionManager.getProtectionInfo correcta para el origen de datos) antes de mostrar información leída del archivo.

Si getProtectionInfo informa de una identidad no nula y no vacía, la aplicación debe establecer la identidad de la interfaz de usuario para que coincida con esta identidad mediante MAMActivity.switchMAMIdentityOID o MAMPolicyManager.setUIPolicyIdentityOID. Si se produce un error en el cambio de identidad, no se deben mostrar los datos del archivo.

Al leer desde un URI de contenido, puede ser necesario leer primero la identidad (a través de la getProtectionInfo sobrecarga que toma un Uri) y luego establecer el contexto o la identidad del subproceso correctamente. Esto debe hacerse antes de abrir un descriptor de archivo o un flujo de entrada en el ContentResolver, de lo contrario, se puede producir un error en la operación.

Un flujo de ejemplo podría parecerse al siguiente:

• El usuario selecciona un documento para abrirlo en la aplicación.

• Durante el flujo abierto, antes de leer los datos del disco, la aplicación confirma la identidad que se debe usar para mostrar el contenido:

  MAMFileProtectionInfo info = MAMFileProtectionManager.getProtectionInfo(docPath)
  if (info != null)
      MAMPolicyManager.setUIPolicyIdentityOID(activity, info.getIdentityOID(), callback, EnumSet.noneOf<IdentitySwitchOption.class>)
  

• La aplicación espera hasta que se notifique un resultado para devolver la llamada.

• Si el resultado informado es un error, la aplicación no muestra el documento.

• La aplicación abre y representa el archivo.

Si una aplicación usa Android DownloadManager para descargar archivos, el SDK intentará proteger esos archivos automáticamente con la prioridad de identidad descrita anteriormente. El contexto usado para recuperar el DownloadManager se usará si la identidad del subproceso no está establecida. Si los archivos descargados contienen datos corporativos, es responsabilidad de la aplicación llamar a protectForOID si los archivos se mueven o se vuelven a crear después de la descarga.

Single-Identity a la transición de múltiples identidades

Si una aplicación que se lanzó anteriormente con integración de Intune de identidad única posteriormente integra multiidentidad, las aplicaciones instaladas anteriormente experimentarán una transición. Esta transición no es visible para el usuario.

La aplicación no es necesaria para controlar esta transición. Todos los archivos creados antes de la transición se seguirán considerando administrados (por lo que permanecerán cifrados si la directiva de cifrado está activada).

Si no desea que todos los datos de la aplicación anterior se asocien a la identidad administrada, puede detectar esta transición y quitar explícitamente la protección.

• Detecte la actualización comparando la versión de la aplicación con una versión conocida en la que se agregó compatibilidad con varias identidades.
• Llamada protectForOID con una cadena vacía para el parámetro identity en archivos o directorios que no desea asociar a la identidad administrada.

Escenarios sin conexión

El SDK de la aplicación de Intune se ejecuta en modo "sin conexión" cuando la aplicación del Portal de empresa no está instalada. El etiquetado de identidad de archivo es sensible al modo sin conexión:

• Si el Portal de empresa no está instalado, los archivos no se pueden etiquetar con identidad. Llamar a MAMFileProtectionManager.protectForOID en modo sin conexión es seguro, pero no tendrá ningún efecto.

• Si el Portal de empresa está instalado, pero la aplicación no tiene una directiva de protección de aplicaciones, los archivos no se pueden etiquetar con la identidad de manera confiable.

• Cuando el etiquetado de identidad de archivo está disponible, todos los archivos creados previamente se tratan como personales/no administrados (pertenecientes a la identidad de cadena vacía), excepto en los casos en que la aplicación se instaló anteriormente como una aplicación administrada de identidad única, como se describe en Transición de identidad única a identidad múltiple.

Para evitar estos casos, las aplicaciones deben evitar la creación de archivos que contengan datos de la cuenta hasta que el registro de la cuenta se complete correctamente. Si es indispensable que la aplicación cree archivos mientras está sin conexión, puede usar MAMFileProtectionManager.protectForOID para corregir la identidad asociada al archivo una vez que el SDK esté en línea.

Protección del búfer de datos

Advertencia

No se recomienda escribir datos que pertenezcan a varias cuentas en un único archivo. Si es posible, organice los archivos de la aplicación por identidad.

MAMDataProtectionManager del SDK proporciona métodos para comprobar y cambiar la identidad etiquetada en búferes de datos específicos en cualquiera byte[]InputStream de los dos formatos.

MAMDataProtectionManager.protectForOID Permite a una aplicación asociar datos a una identidad y, si la identidad está actualmente destinada con una directiva de cifrado, cifrar los datos. Estos datos cifrados son adecuados para almacenarse en disco en un archivo.

MAMDataProtectionManager también permite consultar los datos asociados a la identidad y descifrarlos.

Las aplicaciones que hacen uso de MAMDataProtectionManager deben implementar un receptor para la MANAGEMENT_REMOVED notificación. Consulte Registro para notificaciones desde el SDK para obtener más detalles.

Una vez completada esta notificación, los búferes protegidos mediante esta clase dejarán de ser legibles (si se habilitó el cifrado de archivos cuando se protegieron los búferes). Una aplicación puede evitar que estos búferes sean ilegibles llamando a MAMDataProtectionManager.unprotect todos los búferes al controlar la MANAGEMENT_REMOVED notificación. También es seguro llamar protectForOID durante esta notificación, si desea conservar la información de identidad. Se garantiza que el cifrado se deshabilitará durante la notificación y que la llamada protectForOID al controlador no cifrará los búferes de datos.

Advertencia

Las operaciones de cifrado deben evitarse al principio del proceso de la aplicación. El SDK realizará la inicialización del cifrado de forma asincrónica tan pronto como sea posible después de iniciar la aplicación. Sin embargo, si una aplicación realiza una solicitud de cifrado al iniciar la aplicación, es posible que se bloquee hasta que se complete la inicialización del cifrado.

Nota:

La API de cifrado del SDK de la aplicación de Intune solo debe usarse para cifrar datos según lo requiera la directiva de Intune. No se aplicará ninguna protección a las cuentas que no tengan como destino la directiva de cifrado habilitada, por lo que no se puede usar como biblioteca de cifrado de uso general.

Proveedores de contenido

Una aplicación de varias identidades también debe proteger los datos compartidos a través ContentProviderde para evitar que se comparta incorrectamente el contenido administrado.

La aplicación debe llamar al método isProvideContentAllowedForOid(provider, oid)estático MAMContentProvider antes de devolver contenido. Si esta función devuelve false, el contenido no se debe devolver al llamador.

La llamada isProvideContentAllowedForOid no es necesaria si devuelve ContentProvider un ParcelFileDescriptor. Los descriptores de archivo devueltos a través de un proveedor de contenido se controlan automáticamente en función de la identidad del archivo.

Borrado selectivo

De forma predeterminada, el SDK de la aplicación de Intune controlará automáticamente los borrados selectivos y eliminará todos los archivos asociados a la identidad administrada. Después, el SDK cerrará la aplicación correctamente, finalizará las actividades y finalizará el proceso de la aplicación.

El SDK proporciona la capacidad opcional para que la aplicación complemente (recomendado) o invalide el comportamiento de borrado predeterminado.

El controlador de borrado predeterminado del SDK no controla búferes de datos protegidos por MAMDataProtectionManager. Si la aplicación usó esta característica, debe complementar o invalidar el controlador de borrado predeterminado para quitar esos datos.

Nota:

Para complementar e invalidar el comportamiento de borrado predeterminado, es necesario controlar notificaciones específicas del SDK. Consulte Registro de notificaciones desde el SDK para obtener más detalles sobre la implementación de controladores de notificaciones.

Complementar el comportamiento de borrado predeterminado

Para complementar el comportamiento de borrado del SDK predeterminado, la WIPE_USER_AUXILIARY_DATA aplicación puede registrarse para MAMNotificationType.

El SDK enviará esta notificación antes de realizar el borrado selectivo predeterminado. El SDK esperará a que finalice el controlador de notificaciones de la aplicación antes de eliminar los datos y finalizar la aplicación. La aplicación debe borrar los datos de forma sincrónica y no devolver hasta que se complete toda la limpieza.

Las aplicaciones deben considerar seriamente complementar el comportamiento de borrado predeterminado con WIPE_USER_AUXILIARY_DATA, ya que la limpieza específica de la aplicación es común para las aplicaciones de identidades múltiples.

Reemplazar el comportamiento de borrado predeterminado

Para invalidar el comportamiento de borrado predeterminado del SDK, la WIPE_USER_DATA aplicación puede registrarse para MAMNotificationType.

Advertencia

Una aplicación nunca debe registrarse para ambos WIPE_USER_DATA y WIPE_USER_AUXILIARY_DATA.

La invalidación del comportamiento de borrado predeterminado del SDK supone un riesgo considerable para la aplicación. La aplicación será totalmente responsable de quitar todos los datos asociados a la identidad administrada, incluidos todos los archivos y búferes de datos etiquetados para esa identidad.

• Si la identidad administrada estaba protegida con cifrado y el controlador de borrado personalizado de la aplicación no quita por completo todos los datos administrados, los archivos administrados restantes permanecerán cifrados. Estos datos se volverán inaccesibles y es posible que la aplicación no controle los intentos de leer datos cifrados correctamente.
• El controlador de borrado de la aplicación puede provocar la pérdida de datos para los usuarios no administrados si quita los archivos que no están etiquetados con la identidad administrada.

Si el controlador de borrado personalizado de la aplicación quita los datos administrados de un archivo, pero desea dejar otros datos en el archivo, debe cambiar la identidad del archivo (a través de MAMFileProtectionManager.protectForOID) a una identidad no administrada o a una cadena vacía.

El controlador de borrado invalidado debe borrar los datos sincrónicamente y no volver hasta que se complete toda la limpieza.

Considere la posibilidad de cerrar la aplicación manualmente después de completar los pasos del controlador de borrado personalizado para evitar que el usuario acceda a los datos en memoria después de que se produzca un borrado.

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 Entra 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, instale la aplicación y el Portal de empresa de Intune; 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, instale la aplicación y el Portal de empresa de Intune; 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, instale la aplicación y el Portal de empresa de Intune; 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.

Validación de escenarios de borrado selectivo

Es posible que la aplicación de identidades múltiples haya complementado o invalidado el comportamiento de borrado predeterminado del SDK. Estas pruebas ayudan a garantizar que la integración de múltiples identidades quite correctamente los datos administrados cuando se inician los borrados, sin afectar a los datos no administrados.

Advertencia

Recordatorio, si la aplicación aprovechó MAMDataProtectionManager.protectForOID, debe implementar un controlador para o WIPE_USER_AUXILIARY_DATAWIPE_USER_DATA.

Para realizar estas pruebas, instale la aplicación y el Portal de empresa de Intune; inicie sesión con una cuenta administrada y no administrada antes de iniciar la prueba. Para ambas cuentas, ejerza escenarios de aplicaciones que almacenen datos de cuenta.

Escenario	Condiciones previas	Pasos
Controlador de barrido complementario	La aplicación ha implementado un controlador para WIPE_USER_AUXILIARY_DATA	- Emita un borrado selectivo desde el Centro de administración de Microsoft Intune. - Confirme (generalmente a través del registro) que su controlador de borrado se ha ejecutado correctamente. - 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.
Controlador de borrado invalidado	La aplicación ha implementado un controlador para WIPE_USER_DATA	- Emita un borrado selectivo desde el Centro de administración de Microsoft Intune. - Confirme (generalmente a través del registro) que su controlador de borrado se ha ejecutado correctamente. - 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. - Confirma que la aplicación ha salido correctamente o sigue en un estado correcto cuando finalice el controlador de barrido.
Protección manual de archivos	- Las llamadas de la aplicación MAMFileProtectionManager.protectForOID - La aplicación ha implementado un controlador para WIPE_USER_DATA	- Asegúrate de haber ejercido escenarios en los que tu aplicación protegería manualmente al menos un archivo que pertenece a la cuenta administrada. - Emita un borrado selectivo desde el Centro de administración de Microsoft Intune. - Confirme que los archivos se hayan eliminado.
Protección manual del búfer de datos	- Las llamadas de la aplicación MAMDataProtectionManager.protectForOID - Tu app ha implementado un controlador para o WIPE_USER_AUXILIARY_DATAWIPE_USER_DATA	- Asegúrese de haber ejercido escenarios en los que la aplicación protegería manualmente al menos un búfer de datos que pertenece a la cuenta administrada. - Emita un borrado selectivo desde el Centro de administración de Microsoft Intune. - Confirma que los búferes de datos se quitan de los archivos en los que se almacenaron y que tu app aún puede leer los datos no administrados de esos archivos.

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, Fase 6: App Configuration y Fase 7: Características de participación en la aplicación, pueden ser necesarias o no, en función del soporte de directiva de protección de aplicaciones deseado de la aplicación. Si no está seguro de si alguna de estas secciones se aplica a la aplicación, vuelva a visitar Decisiones clave para la integración del SDK.