SDK de aplicaciones de Intune para Android: multiinquilino

El SDK de aplicaciones Microsoft Intune para Android le permite incorporar directivas de protección de aplicaciones de Intune (también conocidas como directivas de APLICACIÓN o MAM) en la aplicación nativa de Java/Kotlin para Android. Una aplicación administrada por Intune es una que se integra con el SDK de aplicaciones 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 fases distintas. Para empezar, revise La fase 1: Planear la integración.

Fase 5: Multi-Identity

Goals de fase

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

Terminología de identidad

Los términos "user", "account" e "identity" se usan a menudo indistintamente. Esta guía intenta diferenciar de la siguiente manera:

• Usuario: el ser humano que usa el producto de software. Además, se diferencia como usuario final, el usuario que usa la aplicación Android y el administrador administrador / / deTI 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 forma única la entidad de un usuario. Un usuario humano puede tener varias cuentas.
• Identidad: conjunto de datos que el SDK de aplicaciones de Intune usa para identificar de forma única una cuenta.

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 dirigida, el SDK asocia todos los archivos y todas las actividades con la identidad de esa cuenta y aplicará la directiva de destino de esa cuenta de forma universal.

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 fases anteriores, la aplicación se ha integrado correctamente como identidad única y puede aplicar todas las directivas básicas. Las aplicaciones destinadas a mantener una identidad única pueden omitir esta sección y pasar a la fase 6: App Configuration.

El SDK de aplicaciones de Intune puede aplicar opcionalmente la directiva en un nivel por identidad. Si la aplicación ya admite varias cuentas iniciadas simultáneamente y quiere conservar esta compatibilidad con varias cuentas con directivas de protección de aplicaciones, la aplicación se considera multiinquilino.

Sugerencia

Si no está claro si la aplicación debe admitir protecciones de identidad única o multiinquilino, revise ¿Mi aplicación es una identidad única o una identidad múltiple?

Advertencia

La compatibilidad con varias identidades es significativamente más compleja que otras características de protección de aplicaciones. La integración incorrecta de varias identidades puede dar lugar a pérdidas de datos y otros problemas de seguridad. Revise esta sección cuidadosamente y planee el tiempo suficiente para las pruebas antes de pasar a la siguiente fase.

"Identidad" en el SDK

Cuando una aplicación integrada en el SDK registra una cuenta mediante 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 solo usan la cadena upn proporcionada como abreviatura para la identidad. Estas API devolverán solo la cadena upn como identidad y solo requieren el parámetro de cadena upn para la identidad.

Las identidades no distinguen mayúsculas de minúsculas. Es posible que las solicitudes al SDK para una identidad no devuelvan el mismo uso de mayúsculas y minúsculas que se usó al registrar o establecer la identidad.

Sugerencia

En el futuro, las API del SDK pueden presentar una estructura de identidad más holística que incluya todos los campos proporcionados en el momento del registro de la cuenta, no solo upn. Al integrar la compatibilidad con varias identidades, asegúrese de que la aplicación también tenga acceso a aadId, tenantId y authority al establecer la identidad mediante las API actuales.

Identidades administradas frente a no administradas

Como se describe en Registro de 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 estar destinada a la directiva de protección de aplicaciones. Si la cuenta está destinada a la directiva de protección de aplicaciones, el SDK la considera administrada; De lo contrario, no se administra.

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 aplicaciones de Intune solo admite una única identidad administrada por dispositivo. En cuanto cualquier aplicación integrada en el SDK registre una identidad administrada, todas las identidades registradas posteriormente, aunque estén destinadas actualmente 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 opciones para corregir. Para obtener más información, consulte Registro de notificaciones desde el SDK .

Nota:

Una cuenta que no esté destinada a la directiva de protección de aplicaciones en el momento del registro se considerará no administrada. Incluso si la cuenta no tiene licencia o está destinada a la directiva de protección de aplicaciones, el SDK comprobará periódicamente si esta cuenta se licencia y se dirige más adelante. Si no se ha registrado ninguna otra identidad administrada, el SDK comenzará a tratar esta identidad como administrada una vez que se haya dirigido a la directiva. El usuario no necesita cerrar la 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 está en uso actual; de lo contrario, se conoce como identidad activa. Si se administra la identidad activa, el SDK aplicará protecciones. Si no se administra la identidad activa, 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 pone 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. Esto no es una fuga de datos, pero esto puede restringir innecesariamente 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 conoce 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 datos de aplicaciones por identidad

Cada vez que la aplicación escribe un nuevo archivo, el SDK asocia (también conocido 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 (consulte Escritura de archivos 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 está destinada a la directiva de cifrado, solo se cifrarán los archivos etiquetados con la identidad administrada.

Si la acción del administrador o las solicitudes de directiva configuradas que eliminan los datos administrados, solo se eliminarán los archivos etiquetados con la identidad administrada.

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

Si la aplicación debe almacenar datos que pertenecen a identidades diferentes en el mismo archivo, el SDK proporciona características para subconjuntos de datos de etiquetado de identidades dentro de un archivo. Consulte Protección del búfer de datos para obtener más información.

Implementación de varias identidades

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

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

Establecimiento de la identidad activa

La aplicación puede establecer la identidad activa en los siguientes niveles en 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 un Context solo se usa en escenarios asociados adecuados. Las operaciones de E/S de archivo, por ejemplo, no tienen un asociado Context. Normalmente, las aplicaciones establecerán la Context identidad en .Activity 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 esté establecida en esa misma identidad.

En general, la identidad de nivel de proceso solo es útil si la aplicación solo funciona con una única 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 separar los datos de la cuenta y establecer la identidad activa en el subproceso o Context los niveles.

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

Si la aplicación usa un Service contexto para iniciar intenciones, usa solucionadores de contenido o aprovecha otros servicios del sistema, asegúrese de establecer la identidad en el Service contexto. Del mismo modo, si la aplicación usa un JobService contexto para realizar estas acciones, asegúrese de establecer la identidad en el JobService contexto o subproceso según sea necesario para la JobService implementación. Por ejemplo, si JobService procesa trabajos para una única identidad, considere la posibilidad de establecer la identidad en el JobService contexto. JobService Si procesa 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 objeto 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 en Worker.doWork() según sea necesario para la Worker implementación.

Nota:

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

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

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

public static String getUIPolicyIdentity(final Context context);

public static MAMIdentitySwitchResult setProcessIdentity(final String identity);

public static String getProcessIdentity();

public static MAMIdentitySwitchResult setCurrentThreadIdentity(final String identity);

public static String getCurrentThreadIdentity();

/**
 * 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 getPolicyForIdentity(final String identity);

public static boolean getIsIdentityManaged(final String identity);

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.setUIPolicyIdentity. Use el siguiente método para hacerlo:

     public final void switchMAMIdentity(final String newIdentity, final EnumSet<IdentitySwitchOption> options);

Nota:

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

Problemas comunes del conmutador de identidad

• En el caso de las llamadas a startActivity, el SDK de aplicaciones de Intune supone que la identidad activa en el Context nivel está asociada al parámetro proporcionado Intent . Se recomienda encarecidamente establecer la Context identidad de 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 para identidades administradas y no administradas, la directiva puede aplicarse incorrectamente, lo que da lugar a datos corporativos no protegidos o a datos personales incorrectamente restringidos.

Resultados del modificador de identidad

Todos los métodos usados para establecer los valores de resultado del informe de identidad mediante MAMIdentitySwitchResult. Hay cuatro valores que se pueden devolver:

Valor devuelto	Escenario
SUCCEEDED	El cambio de identidad se realizó correctamente.
NOT_ALLOWED	No se permite el cambio de identidad. Esto ocurre si se intenta establecer la identidad de la interfaz de usuario (Context) cuando se establece una identidad diferente en el subproceso actual.
CANCELLED	El usuario canceló el cambio de identidad, por lo general presionando el botón Atrás en un PIN o símbolo del sistema de autenticación.
FAILED	Error en el cambio de identidad por un motivo no especificado.

La aplicación debe comprobar que MAMIdentitySwitchResult está 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 setUIPolicyIdentity, el resultado se notifica de forma asincrónica. La aplicación puede implementar un MAMSetUIIdentityCallback para recibir este resultado o puede pasar null para el objeto de devolución de llamada. Si se realiza una llamada a setUIPolicyIdentity mientras el resultado de una llamada anterior a setUIPolicyIdentityen el mismo contexto aún no se ha entregado, la nueva devolución de llamada reemplazará a la antigua y la devolución de llamada original nunca recibirá un resultado.

Precaución

Si el Context proporcionado para setUIPolicyIdentity es , Activityel SDK no sabe si el cambio de identidad se realizó correctamente hasta que realiza 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 subproceso y proceso siempre se realizarán correctamente para una aplicación habilitada para varias identidades. El SDK se reserva el derecho de agregar condiciones de error en el futuro.

El modificador de identidad de la interfaz de usuario puede producir un error para los 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 de un conmutador de identidad de interfaz de usuario con error en una actividad es finalizar la actividad. Para cambiar este comportamiento y recibir notificaciones sobre los intentos de cambio de identidad de 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 muestran después de un cambio de identidad con errores.

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 e IdentitySwitchOptions

Además de etiquetar automáticamente 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 normalmente (*) solicita un modificador 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 intenta cambiar la aplicación con la identidad de intención entrante más reciente. Si estas identidades no coinciden, el SDK normalmente producirá un error (*) en el modificador 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 aplicación desactivando involuntariamente las protecciones 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 setUIPolicyIdentity y switchMAMIdentity para modificar el comportamiento predeterminado del SDK.

• IGNORE_INTENT: al solicitar un modificador 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 resulta útil cuando la aplicación ya no muestra el contenido que pertenece a esa identidad y el SDK no debe bloquear este modificador de identidad. Por ejemplo:

  1. La 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. Cada vez 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 protecciones aplicadas correctamente.
  4. El usuario usa el modificador de cuenta 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 de la intención), debe usarse IGNORE_INTENT en la llamada del modificador de identidad. Esto evita que el SDK falle de forma inapropiada en esta llamada.

• DATA_FROM_INTENT: al solicitar un modificador 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 se seguirán mostrando después de que el modificador 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. La 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, cada vez que el usuario usa esta característica de cambio de cuenta, la aplicación navega a una página compartida que muestra documentos recientes para 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 protecciones aplicadas correctamente.
  4. El usuario usa el modificador de cuenta 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 continuar mostrando los datos de la identidad administrada (una vista previa del documento en la intención), debe usarse DATA_FROM_INTENT en la llamada del modificador de identidad. Esto informa al SDK de que compruebe la directiva de protección de aplicaciones configurada para determinar si es adecuado que se sigan mostrando los datos.

(*) El comportamiento predeterminado del SDK incluye mayúsculas y minúsculas especiales que omiten esta comprobación de entrada de datos si, por ejemplo, la intención procede 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 requieren 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 de identidad establecido en null. Borrar la identidad en un nivel hará que el SDK busque la identidad activa en otros niveles, en función del orden de precedencia.

Como alternativa, puede pasar una cadena vacía como parámetro 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 formas 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 de 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 implícitos de identidad.

La escucha de estos cambios implícitos de identidad es opcional, pero se recomienda. 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 implícitos de identidad, tenga cuidado adicional de no asumir la identidad activa. En caso de duda, use los getCurrentThreadIdentitymétodos , getUIPolicyIdentityy getProcessIdentity para confirmar la identidad activa.

Orígenes de cambios implícitos de identidad

• 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 una Intent enviada 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 en que se envió.Intent

    • Por ejemplo, una actividad para ver un documento Word se inicia desde una intención de Microsoft Outlook cuando un usuario selecciona un documento adjunto. 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 una onStart llamada o onBind . Las llamadas al Binder elemento devuelto desde onBind también establecerán temporalmente la identidad del subproceso.

  • Las llamadas a a 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:

  • Si un usuario cancela una solicitud de autorización durante Resume , se cambiará implícitamente a una identidad vacía.

Control de cambios implícitos de identidad

Opcionalmente, la aplicación puede escuchar y reaccionar ante estos cambios implícitos de identidad. Por ejemplo, la aplicación puede requerir varios pasos antes de que se pueda usar una cuenta agregada, 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 modificador 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 o ServiceContextProvider para los cambios de identidad que se aplican a este subproceso. La implementación debe invalidar:

public abstract void onMAMIdentitySwitchRequired(String identity,
        AppIdentitySwitchResultCallback callback);

La aplicación puede implementar la interfaz MAMActivityIdentityRequirementListener en un Activity objeto para los cambios de identidad que se aplican a esta actividad. La implementación debe invalidar:

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

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

Valor de enumeración	Comportamiento predeterminado del SDK	Descripción
CREATE	Permitir el modificador de identidad.	El modificador de identidad se produce debido a la creación de una actividad.
NEW_INTENT	Permitir el modificador 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 modificador de identidad se está produciendo 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 a para todos los cambios de identidad implícitos, excepto para los realizados a través de un enlazador devuelto de MAMService.onMAMBind. Las implementaciones predeterminadas de onMAMIdentitySwitchRequired llamada inmediata:

• callback.reportIdentitySwitchResult(FAILURE) cuando el motivo es RESUME_CANCELLED.

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

No se espera que la mayoría de las aplicaciones deba bloquear o retrasar un cambio de identidad de otra manera, pero si una aplicación necesita hacerlo, se deben tener en cuenta 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 aplicaciones "Recibir datos de otras aplicaciones" del SDK hubiera prohibido la entrada de datos.

• Si un servicio se ejecuta en el subproceso principal, reportIdentitySwitchResultdebe llamarse de forma sincrónica o el subproceso de interfaz de usuario deja de responder.

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

• En , Activitycuando 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 los datos coherentes con ese modificador de identidad. Si esto no es posible, la aplicación debe rechazar el cambio y se le pedirá de nuevo al usuario que cumpla con la directiva de reanudación de la identidad (por ejemplo, al presentarse con 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 identidades administradas de forma administrada.

Si se administra una identidad solicitada (use MAMPolicyManager.getIsIdentityManaged para comprobar), 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 modificador de identidad.

Se puede acceder al comportamiento predeterminado de MAMActivity.onMAMIdentitySwitchRequired mediante una llamada al método MAMActivity.defaultOnMAMIdentitySwitchRequired(activity, identity, reason, callback)estático .

Del mismo modo, 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 aplicaciones 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 propósitos. 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 en una identidad cuya directiva no lo hace, el SDK borrará FLAG_SECURE. Como resultado, la aplicación no debe basarse en el FLAG_SECURE conjunto restante después de un cambio de identidad.

Conservación de la identidad en operaciones asincrónicas

Las aplicaciones suelen enviar tareas en segundo plano desde el subproceso de interfaz de usuario para controlar las operaciones en otros subprocesos. Una aplicación de varias identidades debe asegurarse de 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 aplicaciones de Intune proporciona MAMAsyncTask y MAMIdentityExecutors como una comodidad para ayudar a conservar la identidad en operaciones asincrónicas. La aplicación debe usarlas (o establecer explícitamente la identidad del subproceso en las tareas) si sus operaciones asincrónicas pueden:

• Escritura de datos que pertenecen a una identidad administrada en un archivo
• Comunicación con otras aplicaciones

MAMAsyncTask

Para usar MAMAsyncTask, simplemente herede de él 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 precedencia.

MAMIdentityExecutors

MAMIdentityExecutorspermite encapsular una instancia existente Executor o ExecutorService como una conservación deExecutorService/Executor identidad con wrapExecutor métodos y wrapExecutorService . 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 precedencia.

Protección de archivos

Escritura de archivos protegidos

Como se mencionó anteriormente en Organización de datos de aplicaciones por identidad , el SDK de aplicaciones 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 de archivos para garantizar el 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 consultar y MAMFileProtectionManager.protect cambiar.

El protect método también se puede usar para proteger directorios. La protección de directorios se aplica de forma recursiva a todos los archivos y subdirectorios contenidos en el directorio. Cuando se protege un directorio, todos los archivos nuevos creados dentro del directorio tendrán aplicada automáticamente la misma protección. Dado que la protección de directorios se aplica de forma recursiva, la protect 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 quieran ejecutarse protect de forma asincrónica en un subproceso en segundo plano.

Al llamar a protect 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ó anteriormente. Cuando se emite un comando de borrado selectivo, no se eliminará el archivo o directorio.

Mostrar contenido de archivo protegido

Es igualmente fundamental establecer la identidad correcta cuando se muestra el contenido del archivo para evitar que los usuarios no autorizados vean los datos administrados. El SDK no puede deducir automáticamente una relación entre los archivos que se leen y los datos que se muestran en .Activity Las aplicaciones deben establecer la identidad de la interfaz de usuario correctamente antes de mostrar los datos administrados. Esto incluye los datos leídos de los archivos.

Si un archivo procede de fuera de la aplicación (desde o ContentProvider leído desde una ubicación que se puede escribir 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 la información leída del archivo.

Si getProtectionInfo notifica 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.switchMAMIdentity o MAMPolicyManager.setUIPolicyIdentity. Si se produce un error en el modificador 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, a continuación, establecer el contexto o la identidad del subproceso correctamente. Esto debe realizarse antes de abrir un descriptor de archivo o un flujo de entrada en o ContentResolver, de lo contrario, la operación puede producir un error.

Un flujo de ejemplo podría tener un aspecto similar al siguiente:

• El usuario selecciona un documento que se va a abrir 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.setUIPolicyIdentity(activity, info.getIdentity(), callback, EnumSet.noneOf<IdentitySwitchOption.class>)
  

• La aplicación espera hasta que se notifica un resultado para la devolución de llamada.

• Si el resultado notificado 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 estos archivos automáticamente con la prioridad de identidad descrita anteriormente. El contexto usado para recuperar el DownloadManager objeto 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 protect si los archivos se mueven o se vuelven a crear después de la descarga.

transición de Single-Identity a varias identidades

Si una aplicación que se publicó anteriormente con la integración de Intune de identidad única más adelante integra varias identidades, 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 seguirán considerándose 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 anteriores estén asociados 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.
• Llame a protect con una cadena vacía para el parámetro identity en los archivos o directorios que no desea asociar a la identidad administrada.

Escenarios sin conexión

El SDK de aplicaciones de Intune se ejecuta en modo "sin conexión" cuando la aplicación de Portal de empresa no está instalada. El etiquetado de identidades 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.protect 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 directiva de protección de aplicaciones, los archivos no se pueden etiquetar de forma confiable con identidad.

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

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

Protección del búfer de datos

Advertencia

No se recomienda escribir datos que pertenecen a varias cuentas en un solo 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 byte[] formato o InputStream .

MAMDataProtectionManager.protect permite que una aplicación asocie datos con una identidad y, si la identidad está destinada actualmente a la directiva de cifrado, cifre los datos. Estos datos cifrados son adecuados para almacenarlos en disco en un archivo.

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

Las aplicaciones que usan MAMDataProtectionManager deben implementar un receptor para la MANAGEMENT_REMOVED notificación. Para obtener más información, consulte Registro de notificaciones desde el SDK .

Una vez completada esta notificación, los búferes protegidos a través de esta clase ya no se podrán leer (si el cifrado de archivos se ha habilitado cuando se han protegido los búferes). Una aplicación puede evitar que estos búferes se vuelvan ilegibles llamando a MAMDataProtectionManager.unprotect todos los búferes al controlar la MANAGEMENT_REMOVED notificación. También es seguro llamar protect a 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 protect en el controlador no cifrará los búferes de datos.

Proveedores de contenido

Una aplicación de varias identidades también debe proteger los datos compartidos a través ContentProviderde s para evitar el uso compartido inadecuado de contenido administrado.

La aplicación debe llamar al método isProvideContentAllowed(provider, contentIdentity)MAMContentProvider estático antes de devolver contenido. Si esta función devuelve false, el contenido no debe devolverse al autor de la llamada.

La llamada isProvideContentAllowed no es necesaria si ContentProvider está devolviendo un ParcelFileDescriptorobjeto . 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 aplicaciones 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, finalizando las actividades y finalizando 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 los 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 información sobre la implementación de controladores de notificaciones.

Complementar el comportamiento de borrado predeterminado

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

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

Las aplicaciones deben considerar la posibilidad de 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 varias identidades.

Invalidar el comportamiento de borrado predeterminado

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

Advertencia

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

Reemplazar el comportamiento de borrado predeterminado del SDK supone un riesgo considerable en 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 completamente todos los datos administrados, los archivos administrados restantes permanecerán cifrados. Estos datos serán inaccesibles y es posible que la aplicación no controle el intento de leer los datos cifrados correctamente.
• El controlador de borrado de la aplicación puede dar lugar a la pérdida de datos de 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.protect) a una identidad no administrada o una cadena vacía.

El controlador de borrado invalidado debe borrar los datos sincrónicamente y no devolverlos 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

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

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

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

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

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

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

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

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

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

Validación de escenarios de uso compartido de datos

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

Para estas pruebas, instale la aplicación y el Portal de empresa de Intune; inicie sesión con una cuenta administrada y no administrada antes de iniciar la prueba. Además:

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

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

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

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

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

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

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

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

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

Validación de escenarios de borrado selectivo

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

Advertencia

Recordatorio: si la aplicación ha aprovechado MAMDataProtectionManager.protect, debe implementar un controlador para WIPE_USER_AUXILIARY_DATA o WIPE_USER_DATA.

Para 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, haga ejercicio de escenarios de aplicación que almacenen datos de cuenta.

Escenario	Condiciones previas	Pasos
Controlador de borrado 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 (normalmente a través del registro) que el controlador de borrado se ha ejecutado correctamente. - Confirme que la cuenta administrada se ha quitado de la aplicación y que se han quitado todos los datos de esa cuenta. : confirme que la cuenta no administrada todavía está iniciada, que no se ha quitado ninguno de los datos de la cuenta no administrada y que todavía no se aplica la directiva.
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 (normalmente a través del registro) que el controlador de borrado se ha ejecutado correctamente. - Confirme que la cuenta administrada se ha quitado de la aplicación y que se han quitado todos los datos de esa cuenta. : confirme que la cuenta no administrada todavía está iniciada, que no se ha quitado ninguno de los datos de la cuenta no administrada y que todavía no se aplica la directiva. - Confirme que la aplicación ha salido correctamente o que sigue en un estado correcto una vez que finalice el controlador de borrado.
Protección manual de archivos	- Llamadas a la aplicación MAMFileProtectionManager.protect - La aplicación ha implementado un controlador para WIPE_USER_DATA	- Asegúrese de que ha realizado escenarios en los que la 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 han quitado.
Protección manual del búfer de datos	- Llamadas a la aplicación MAMDataProtectionManager.protect - La aplicación ha implementado un controlador para o WIPE_USER_AUXILIARY_DATAWIPE_USER_DATA	- Asegúrese de que ha realizado escenarios en los que la aplicación protegería manualmente al menos un búfer de datos que pertenezca a la cuenta administrada. - Emita un borrado selectivo desde el centro de administración de Microsoft Intune. - Confirme que los búferes de datos se quitan de los archivos en los que se almacenaron y que la aplicación todavía puede leer los datos no administrados de esos archivos.

Pasos siguientes

Después de completar todos los criterios de salida anteriores, la aplicación ahora se integra correctamente como multiinquilino y puede aplicar directivas de protección de aplicaciones por identidad. Las secciones siguientes, Fase 6: App Configuration y Fase 7: Características de participación de aplicaciones, pueden ser necesarias o no, en función de la compatibilidad deseada de la directiva de protección de aplicaciones de la aplicación. Si no está seguro de si alguna de estas secciones se aplica a la aplicación, vuelva a consultar Decisiones clave para la integración del SDK.