SDK do aplicativo do Intune para Android - várias identidades

O SDK do aplicativo do Microsoft Intune para Android permite incorporar políticas de proteção do aplicativo do Intune (também conhecidas como políticas de MAM) em seu aplicativo nativo Java/Kotlin para Android. Um aplicativo gerenciado do Intune é aquele que é integrado ao SDK do aplicativo do Intune. Os administradores do Intune podem facilmente implantar políticas de proteção de aplicativo em seu aplicativo gerenciado pelo Intune quando o Intune gerencia ativamente o aplicativo.

Observação

Este guia é dividido em várias etapas distintas. Comece revisando o Estágio 1: Planeje a integração.

Estágio 5: Identidade múltipla

Objetivos do Estágio

• Determine se o aplicativo precisa de suporte a várias identidades.
• Entenda como o SDK do aplicativo do Intune percebe as identidades.
• Refatorar seu aplicativo para reconhecimento de identidade.
• Adicione código para informar o SDK sobre identidades ativas e alteradas em todo o aplicativo.
• Teste minuciosamente a imposição da política de proteção do aplicativo para identidades gerenciadas e não gerenciadas.

Terminologia de identidade

Os termos "usuário", "conta" e "identidade" são frequentemente usados de forma intercambiável. Este guia tenta diferenciar da seguinte maneira:

• Usuário: o ser humano que usa o produto de software. Diferenciado ainda mais como usuário final, o humano que usa o aplicativo Android eo usuário / administrador administrador / de TI Administrador / de TI Pro, o humano que usa o centro de administração do Microsoft Intune.
• Conta: o registro de software pertencente a uma organização que identifica exclusivamente a entidade de um usuário. Um usuário humano pode ter várias contas.
• Identidade: o conjunto de dados que o SDK do aplicativo do Intune usa para identificar exclusivamente uma conta.

Histórico

Por padrão, o SDK do aplicativo do Intune aplica a política a todo o aplicativo. Depois de registrar uma conta com a política de proteção do aplicativo direcionada, o SDK associa todos os arquivos e todas as atividades à identidade dessa conta e aplicará a política direcionada dessa conta universalmente.

Para muitos desenvolvedores, esse é o comportamento de proteção de aplicativo desejado para o aplicativo. Esses aplicativos são considerados de identidade única. Ao concluir os estágios anteriores, seu aplicativo foi integrado com êxito como identidade única e pode impor todas as políticas básicas. Os aplicativos que se destinam a permanecer com identidade única podem ignorar esta seção e prosseguir para o Estágio 6: Configuração de Aplicativos.

Opcionalmente, o SDK do aplicativo do Intune pode impor a política em um nível por identidade. Se o aplicativo já der suporte a várias contas conectadas simultaneamente e você quiser manter esse suporte a várias contas com políticas de proteção de aplicativo, seu aplicativo será considerado com várias identidades.

Dica

Se você não tiver certeza se o aplicativo deve dar suporte a proteções de identidade única ou multiidentidade, consulte novamente Meu aplicativo tem identidade única ou várias identidades?

Aviso

O suporte a várias identidades é significativamente mais complexo do que outros recursos de proteção de aplicativo. A integração inadequada de várias identidades pode resultar em vazamentos de dados e outros problemas de segurança. Revise esta seção cuidadosamente e planeje bastante tempo para o teste antes de prosseguir para o próximo estágio.

"Identidade" para o SDK

Quando um aplicativo integrado ao SDK registra uma conta usando registerAccountForMAM, o SDK salva todos os parâmetros fornecidos (upn, aadId, tenantId e autoridade) como a identidade. No entanto, a maioria das APIs de identidade do SDK usa o OID fornecido (também conhecido como Microsoft Entra ID ou AAD ID) como o identificador para a identidade. As APIs do MAM SDK retornarão a cadeia de caracteres OID como a identidade e exigirão o parâmetro de cadeia de caracteres OID para a identidade. Alguns métodos também podem usar ou retornar uma cadeia de caracteres UPN, caso em que o UPN é apenas para fins informativos.

Os parâmetros de identidade não diferenciam maiúsculas de minúsculas. As solicitações ao SDK para uma identidade podem não retornar o mesmo uso de maiúsculas e minúsculas que foi usado ao registrar ou definir a identidade.

Cuidado

Para aplicativos que usam métodos preteridos que usam ou retornam uma cadeia de caracteres UPN, os aplicativos devem verificar se a cadeia de caracteres UPN de identidade passada para várias chamadas de API é consistente. A transmissão de cadeias de caracteres UPN inconsistentes pode resultar em vazamentos de dados.

Identidades gerenciadas versus não gerenciadas

Conforme descrito em Registrando-se para Política de Proteção de Aplicativo, seu aplicativo é responsável por informar o SDK quando um usuário faz login. No momento do logon, a conta do usuário pode ou não ser direcionada com a política de proteção do aplicativo. Se a conta for direcionada com política de proteção de aplicativo, o SDK a considerará gerenciada; caso contrário, ele não será gerenciado.

O SDK aplicará a política para identidades que ele considera gerenciadas. O SDK não aplicará a política para identidades que ele considera não gerenciadas.

Atualmente, o SDK do aplicativo do Intune dá suporte apenas a uma única identidade gerenciada por dispositivo. Assim que qualquer aplicativo integrado ao SDK registrar uma identidade gerenciada, todas as identidades registradas subsequentemente, mesmo que no momento estejam direcionadas a políticas de proteção de aplicativo, serão tratadas como não gerenciadas.

Se uma identidade gerenciada já tiver sido registrada no dispositivo e seu aplicativo registrar outra identidade que também seja direcionada à política de proteção do aplicativo, o SDK retornará MAMEnrollmentManager.Result.WRONG_USER e solicitará ao usuário final opções de correção. Consulte Registrar-se para notificações do SDK para obter mais detalhes.

Observação

Uma conta que não seja direcionada com a política de proteção do aplicativo no momento do registro será considerada não gerenciada. Mesmo que a conta não esteja licenciada ou direcionada com a política de proteção de aplicativo, o SDK marcará periodicamente se essa conta se tornará licenciada e direcionada posteriormente. Se nenhuma outra identidade gerenciada tiver sido registrada, o SDK começará a tratar essa identidade como gerenciada assim que ela for direcionada com a política. O usuário não precisa fazer logoff e logon novamente nesta conta para fazer essa alteração.

A identidade ativa

Seu aplicativo deve sempre manter o SDK informado sobre a identidade que está em uso atual, também conhecida como identidade ativa. Se a identidade ativa for gerenciada, o SDK aplicará proteções. Se a identidade ativa não for gerenciada, o SDK não aplicará proteções.

Como o SDK não tem conhecimento específico do aplicativo, ele deve confiar que o aplicativo compartilhe a identidade ativa correta.

• Se o aplicativo informar incorretamente ao SDK que uma identidade não gerenciada está ativa quando a identidade gerenciada estiver realmente em uso, o SDK não aplicará proteções. Isso pode causar um vazamento de dados que coloca os dados dos usuários em risco.

• Se o aplicativo informar incorretamente ao SDK que a identidade gerenciada está ativa quando uma identidade não gerenciada estiver realmente em uso, o SDK aplicará as proteções de forma inadequada. Isso não é um vazamento de dados, mas pode restringir desnecessariamente usuários não gerenciados e colocar os dados de usuários não gerenciados em risco de exclusão.

Se o aplicativo exibir dados de qualquer usuário, ele deverá exibir apenas os dados que pertencem à identidade ativa. Se seu aplicativo não estiver ciente de quem possui os dados exibidos, talvez seja necessário refatorar seu aplicativo para maior reconhecimento de identidade antes de começar a integrar o suporte a várias identidades.

Organizando dados de aplicativos por identidade

Sempre que seu aplicativo grava um novo arquivo, o SDK associa (também conhecido como "marcas") uma identidade a esse arquivo com base no thread ativo atual e na identidade do processo. Como alternativa, seu aplicativo pode chamar diretamente o SDK para marcar manualmente um arquivo com uma identidade específica (consulte Gravação protegida Files para obter detalhes). O SDK usa essa identidade de arquivo marcado para criptografia de arquivos e apagamento seletivo.

Se a identidade gerenciada for direcionada com política de criptografia, somente os arquivos marcados com a identidade gerenciada serão criptografados.

Se a ação do administrador ou a política configurada solicitar que os dados gerenciados sejam apagados, somente os arquivos marcados com a identidade gerenciada serão excluídos.

O SDK não pode associar várias identidades a um único arquivo. Se o seu aplicativo armazena dados pertencentes a vários usuários no mesmo arquivo, o comportamento padrão do SDK resultará em subproteção ou superproteção desses dados. É altamente recomendável organizar os dados do seu aplicativo por identidade.

Se o seu aplicativo precisar armazenar dados pertencentes a identidades diferentes no mesmo arquivo, o SDK fornecerá recursos para subconjuntos de dados de marcação de identidade em um arquivo. Consulte Proteção de Buffer de Dados para obter detalhes.

Implementação de várias identidades

Para declarar o suporte a várias identidades para seu aplicativo, comece colocando os metadados a seguir em AndroidManifest.xml.

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

Definir a identidade ativa

Seu aplicativo pode definir a identidade ativa nos seguintes níveis de prioridade decrescente:

1. Nível do tópico
2. Context (geralmente Activity) de nível
3. Nível de processo

Uma identidade definida no nível do thread substitui uma identidade definida no Context nível, que substitui uma identidade definida no nível do processo.

Uma identidade definida em a Context é usada apenas em cenários associados apropriados. As operações de E/S de arquivo, por exemplo, não têm um Contextarquivo . Mais comumente, os aplicativos definirão a Context identidade em um Activityarquivo . Considere definir a Context identidade no Activity.onCreate. Um aplicativo não deve exibir dados de uma identidade, a menos que a Activity identidade esteja definida para essa mesma identidade.

Em geral, a identidade no nível do processo só será útil se o aplicativo funcionar apenas com uma única identidade por vez em todos os threads. Esse não é um comportamento típico para aplicativos que dão suporte a várias contas. É altamente recomendável separar os dados da conta e definir a identidade ativa no thread ou Context nos níveis.

Se o aplicativo usar o contexto para adquirir serviços do Application sistema, verifique se a identidade do thread ou do processo foi definida ou se você definiu a identidade da interface do usuário no contexto do Application aplicativo.

Se o aplicativo usar um Service contexto para iniciar intenções, usar resolvedores de conteúdo ou aproveitar outros serviços do sistema, certifique-se de definir a identidade no Service contexto. Da mesma forma, se o aplicativo usar um JobService contexto para executar essas ações, certifique-se de definir a identidade no JobService contexto ou no thread, conforme exigido pela implementação JobService . Por exemplo, se seus JobService processos processam trabalhos para uma única identidade, considere definir a identidade no JobService contexto. Se seus JobService processos são trabalhos para várias identidades, considere definir a identidade no nível do thread.

Cuidado

Os aplicativos que usam WorkManager devem ter um cuidado especial ao definir a identidade. Especificamente, esses aplicativos devem evitar a configuração de uma identidade no Context passado no Worker construtor. Essa Context instância pode ser compartilhada entre várias Worker instâncias simultaneamente. Para evitar comportamento indefinido, os aplicativos devem, em vez disso, definir uma identidade Worker.doWork() de thread conforme exigido pela Worker implementação.

Observação

Como o CLIPBOARD_SERVICE é usado para operações de interface do usuário, o SDK usa a identidade da interface do usuário da atividade em primeiro plano para ClipboardManager operações.

Os métodos a seguir no MAMPolicyManager podem ser usados para definir a identidade ativa e recuperar os valores de identidade definidos anteriormente.

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);

Por conveniência, você também pode definir a identidade de uma atividade diretamente por meio de um método no MAMActivity em vez de chamar MAMPolicyManager.setUIPolicyIdentityOID. Use o seguinte método para fazer isso:

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

Observação

Se o aplicativo não tiver declarado suporte a várias identidades no manifesto, chamar esses métodos para definir a identidade não executará nenhuma ação e, se eles retornarem um MAMIdentitySwitchResult, sempre retornará FAILED.

Armadilhas comuns da troca de identidade

• Para chamadas para startActivity, o SDK do Aplicativo do Intune pressupõe que a identidade ativa no nível está associada ao Context parâmetro fornecidoIntent. É altamente recomendável definir a identidade de Context nível com um contexto de , Activitynão o Applicationcontexto de .

• É recomendável definir a Context identidade durante o método de onCreate uma atividade. No entanto, certifique-se de também abordar outros pontos de entrada, como onNewIntent. Caso contrário, quando a mesma Atividade for reutilizada para exibir dados para identidades gerenciadas e não gerenciadas, a política poderá ser aplicada incorretamente, levando a dados corporativos desprotegidos ou a dados pessoais restritos indevidamente.

Resultados da Troca de Identidade

Todos os métodos usados para definir o relatório de identidade de volta os valores do resultado por meio de MAMIdentitySwitchResult. Existem quatro valores que podem ser retornados:

Valor de retorno	Cenário
SUCCEEDED	A alteração de identidade foi bem-sucedida.
NOT_ALLOWED	A alteração de identidade não é permitida. Isso ocorrerá se for feita uma tentativa de definir a identidade da interface do usuário (Context) quando uma identidade diferente for definida no thread atual.
CANCELLED	O usuário cancelou a alteração de identidade, geralmente pressionando o botão voltar em um PIN ou em um prompt de autenticação.
FAILED	A alteração de identidade falhou por um motivo não especificado.

O aplicativo deve verificar se o MAMIdentitySwitchResult existe SUCCEEDED antes de exibir ou usar os dados de uma conta gerenciada.

A maioria dos métodos para definir a identidade ativa retorna MAMIdentitySwitchResult de forma síncrona. No caso de definir uma Context identidade por meio de setUIPolicyIdentityOID, o resultado é relatado de forma assíncrona. O aplicativo pode implementar um MAMSetUIIdentityCallback para receber esse resultado ou pode passar null para o objeto de retorno de chamada. Se uma chamada for feita para setUIPolicyIdentityOID enquanto o resultado de uma chamada anterior para setUIPolicyIdentityOIDna mesma Context ainda não tiver sido entregue, o novo retorno de chamada substituirá o antigo e o retorno de chamada original nunca receberá um resultado.

Cuidado

Se o Context fornecido para setUIPolicyIdentityOID for um Activity, o SDK não saberá se a alteração de identidade foi bem-sucedida até depois de executar as verificações de inicialização condicional configuradas pelo administrador. Isso pode exigir que o usuário insira um PIN ou credenciais corporativas.

Atualmente, as opções de identidade de processo e thread sempre serão bem-sucedidas para um aplicativo habilitado para várias identidades. O SDK reserva-se o direito de adicionar condições de falha no futuro.

A opção de identidade da interface do usuário pode falhar por argumentos inválidos, se entrar em conflito com a identidade do thread ou se o usuário cancelar os requisitos de inicialização condicional (por exemplo, pressionar o botão voltar na tela PIN).

O comportamento padrão para uma opção de identidade de interface do usuário com falha em uma atividade é concluir a atividade. Para alterar esse comportamento e receber notificações sobre tentativas de alteração de identidade de uma atividade, você pode substituir um método no MAMActivity.

    public void onSwitchMAMIdentityComplete(final MAMIdentitySwitchResult result);

Se você substituir onSwitchMAMIdentityComplete (ou chamar o super método), deverá garantir que os dados de uma conta gerenciada não sejam exibidos após uma falha na troca de identidade.

Observação

A alternância da identidade pode exigir a recriação da atividade. Nesse caso, o onSwitchMAMIdentityComplete retorno de chamada será entregue à nova instância da atividade.

Identidade, intenções e IdentitySwitchOptions

Além de marcar automaticamente novos arquivos com a identidade ativa, o SDK também marca intenções com a identidade ativa. Por padrão, o SDK irá marcar a identidade em uma intenção de entrada e compará-la com a identidade ativa. Se essas identidades não corresponderem, o SDK normalmente (*) solicitará uma troca de identidade (consulte Alterações de identidade implícitas abaixo para obter mais detalhes).

O SDK também armazena essa identidade de intenção de entrada para uso posterior. Quando o aplicativo altera explicitamente a identidade da interface do usuário, o SDK compara a identidade para a qual o aplicativo está tentando alternar com a identidade de intenção de entrada mais recente. Se essas identidades não corresponderem, o SDK normalmente (*) falhará na troca de identidade.

O SDK executa essa marca porque pressupõe que o aplicativo ainda esteja exibindo conteúdo da intenção que pertence à identidade marcada na intenção. Essa suposição protege contra o aplicativo desativar involuntariamente as proteções ao exibir dados gerenciados; No entanto, essa suposição pode não estar correta ao comportamento real do aplicativo.

As enumerações opcionais IdentitySwitchOption podem ser passadas para as APIs setUIPolicyIdentityOID e switchMAMIdentityOID para modificar o comportamento padrão do SDK.

• IGNORE_INTENT: ao solicitar uma troca de identidade na camada de interface do usuário, essa opção informa ao SDK para ignorar a comparação do parâmetro de identidade solicitado com a identidade de intenção armazenada mais recentemente. Isso é útil quando seu aplicativo não está mais exibindo conteúdo pertencente a essa identidade e o SDK não deve bloquear essa troca de identidade. Por exemplo:

  1. Seu aplicativo é um visualizador de documentos. Ele pode renderizar documentos passados de outros aplicativos. Ele também contém um recurso em que os usuários podem alternar contas. Sempre que o usuário usa esse recurso de troca de conta, o aplicativo navega para uma página de aterrissagem específica da conta com os documentos recentes dessa conta.
  2. Seu aplicativo recebe a intenção de exibir um documento. Essa intenção é marcada com a identidade gerenciada.
  3. Seu aplicativo é alternado para a identidade gerenciada e exibe este documento, com as proteções aplicadas corretamente.
  4. O usuário usa o alternador de conta para mudar para sua conta pessoal.

  Seu aplicativo deve alterar a identidade da interface do usuário na etapa 4. Nesse caso, como o comportamento do aplicativo é navegar para fora dos dados da conta gerenciada (o documento na intenção), ele deve ser usado IGNORE_INTENT na chamada de opção de identidade. Isso evita que o SDK falhe inadequadamente nessa chamada.

• DATA_FROM_INTENT: ao solicitar uma troca de identidade na camada de interface do usuário, essa opção informa ao SDK que os dados da identidade de intenção armazenada mais recentemente continuarão a ser exibidos depois que a troca de identidade for bem-sucedida. Como resultado, o SDK avaliará totalmente a política de recebimento em relação à identidade de intenção anterior para determinar se ela tem permissão para ser exibida. Por exemplo:

  1. Seu aplicativo é um visualizador de documentos. Ele pode renderizar documentos passados de outros aplicativos. Ele também contém um recurso em que os usuários podem alternar contas. Ao contrário do exemplo anterior, sempre que o usuário usa esse recurso de troca de conta, o aplicativo navega para uma página compartilhada que mostra documentos recentes de todas as contas.
  2. Seu aplicativo recebe a intenção de exibir um documento. Essa intenção é marcada com a identidade gerenciada.
  3. Seu aplicativo é alternado para a identidade gerenciada e exibe este documento, com as proteções aplicadas corretamente.
  4. O usuário usa o alternador de conta para mudar para sua conta pessoal.

  Seu aplicativo deve alterar a identidade da interface do usuário na etapa 4. Nesse caso, como o comportamento do aplicativo é continuar exibindo os dados da identidade gerenciada (uma visualização do documento na intenção), ele deve ser usado DATA_FROM_INTENT na chamada de opção de identidade. Isso informa o SDK para marcar a política de proteção do aplicativo configurada para determinar se é apropriado que os dados continuem a ser exibidos.

(*) O comportamento padrão do SDK inclui maiúsculas e minúsculas especiais que ignoram essa entrada de dados, marcando se, por exemplo, a intenção vier de dentro do mesmo aplicativo ou do inicializador do sistema.

Limpando a identidade ativa

Seu aplicativo pode ter cenários independentes de conta. Seu aplicativo também pode ter cenários para cenários locais não gerenciados que não exigem nenhum logon. Em ambos os casos, seu aplicativo pode não querer que o SDK aplique as políticas da identidade gerenciada, mas você pode não ter uma identidade explícita para a qual alternar.

Você pode limpar a identidade ativa chamando qualquer um dos métodos de identidade definidos com o parâmetro OID de identidade definido como null. Limpar a identidade em um nível fará com que o SDK procure a identidade ativa em outros níveis, com base na ordem de precedência.

Como alternativa, você pode passar uma cadeia de caracteres vazia como o parâmetro OID de identidade, que define a identidade como um valor vazio especial que é tratado como uma identidade não gerenciada. Definir a identidade ativa como cadeia de caracteres vazia informa ao SDK para não impor nenhuma política de proteção de aplicativo.

Alterações Implícitas de Identidade

A seção acima descreve as diferentes maneiras pelas quais seu aplicativo pode definir explicitamente a identidade ativa nos níveis de thread, contexto e processo. No entanto, a identidade ativa em seu aplicativo também pode ser alterada sem que seu aplicativo chame nenhum desses métodos. Esta seção descreve como seu aplicativo pode escutar e responder a essas alterações de identidade implícitas.

Escutar essas alterações de identidade implícitas é opcional, mas recomendado. O SDK nunca alterará a identidade ativa sem fornecer essas notificações de alteração de identidade implícitas.

Cuidado

Se o aplicativo optar por não escutar alterações implícitas de identidade, tenha cuidado extra para não assumir a identidade ativa. Em caso de dúvida, use o , getUIPolicyIdentityOIDe getProcessIdentityOID métodos getCurrentThreadIdentityOIDpara confirmar a identidade ativa.

Fontes de alterações de identidade implícitas

• A entrada de dados de outros aplicativos gerenciados pelo Intune pode alterar a identidade ativa no nível do thread e do contexto.

  • Se uma atividade for iniciada a partir de um Intent enviado por outro aplicativo MAM, a identidade da atividade será definida com base na identidade ativa no outro aplicativo no momento em que foi Intent enviada.

    • Por exemplo, uma atividade para exibir um documento do Word é iniciada a partir de uma intenção do Microsoft Outlook quando um usuário seleciona um anexo de documento. A identidade da atividade do visualizador de documentos do Office é alternada para a identidade do Outlook.

  • Para serviços, a identidade do thread será definida de forma semelhante para a duração de uma onStart chamada OR onBind . As chamadas para o Binder retornado de também definirão temporariamente a identidade do onBind thread.

  • As chamadas para um ContentProvider definirão da mesma forma a identidade do thread para sua duração.

• A interação do usuário com uma atividade pode alterar a identidade ativa no nível do contexto. Por exemplo:

  • Um usuário cancelando um prompt de autorização durante Resume resultará em uma opção implícita para uma identidade vazia.

Como lidar com alterações de identidade implícitas

Opcionalmente, seu aplicativo pode escutar e reagir a essas alterações de identidade implícitas. Por exemplo, seu aplicativo pode exigir várias etapas antes que uma conta adicionada seja utilizável, como um aplicativo de email configurando uma nova caixa de entrada. Ao ver uma tentativa de troca de identidade para a identidade dessa conta incompleta, o manipulador do aplicativo pode redirecionar o usuário para a atividade de configuração da conta antes de aceitar a troca de identidade. Como alternativa, o manipulador do aplicativo pode exibir uma caixa de diálogo de erro e bloquear a troca de identidade.

Seu aplicativo pode implementar a interface MAMIdentityRequirementListener em um Service ou ContextProvider para alterações de identidade que se aplicam a esse thread. Sua implementação deve substituir:

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

Seu aplicativo pode implementar a interface MAMActivityIdentityRequirementListener em uma Activity para alterações de identidade aplicáveis a essa atividade. Sua implementação deve substituir:

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

O AppIdentitySwitchReason parâmetro enum descreve a origem da opção de identidade implícita.

Valor de enumeração	Comportamento padrão do SDK	Descrição
CREATE	Permitir a troca de identidade.	A troca de identidade está ocorrendo devido a uma criação de atividade.
NEW_INTENT	Permitir a troca de identidade.	A troca de identidade está ocorrendo porque uma nova intenção está sendo atribuída a uma atividade.
RESUME_CANCELLED	Bloqueie a troca de identidade.	A troca de identidade está ocorrendo porque um resumo foi cancelado. Isso é mais comum quando o usuário final pressiona o botão voltar no PIN, na autenticação ou na interface do usuário de conformidade.

O parâmetro AppIdentitySwitchResultCallback permite que os desenvolvedores substituam o comportamento padrão da opção de identidade:

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

onMAMIdentitySwitchRequired é chamado para todas as alterações de identidade implícitas, exceto aquelas feitas por meio de um Binder retornado de MAMService.onMAMBind. As implementações padrão de onMAMIdentitySwitchRequired chamada imediata:

• callback.reportIdentitySwitchResult(FAILURE) quando a razão é RESUME_CANCELLED.

• callback.reportIdentitySwitchResult(SUCCESS) em todos os outros casos.

Não se espera que a maioria dos aplicativos precise bloquear ou atrasar uma troca de identidade de uma maneira diferente, mas se um aplicativo precisar fazer isso, os seguintes pontos deverão ser considerados:

• Se uma opção de identidade for bloqueada, o comportamento do usuário final será o mesmo como se a configuração de proteção do aplicativo "receber dados de outros aplicativos" do SDK tivesse proibido a entrada de dados.

• Se um Serviço estiver em execução no thread principal, reportIdentitySwitchResultdeverá ser chamado de forma síncrona ou o thread da interface do usuário deixará de responder.

• Para Activity criação, onMAMIdentitySwitchRequired será chamado antes de onMAMCreate. Se o aplicativo precisar mostrar a interface do usuário para determinar se é possível permitir a troca de identidade, essa interface do usuário deverá ser mostrada usando uma atividade diferente .

• Em um Activity, quando uma alteração para a identidade vazia é solicitada com o motivo como RESUME_CANCELLED, o aplicativo deve modificar a atividade retomada para exibir dados consistentes com essa opção de identidade. Se isso não for possível, o aplicativo deverá recusar a alternância e o usuário será solicitado novamente a cumprir a política para a retomada da identidade (por exemplo, sendo apresentado a tela de entrada do PIN do aplicativo).

Cuidado

Um aplicativo de várias identidades pode receber dados de entrada de aplicativos gerenciados e não gerenciados. É responsabilidade do aplicativo tratar os dados de identidades gerenciadas de maneira gerenciada.

Se uma identidade solicitada for gerenciada (use MAMPolicyManager.getIsIdentityOIDManaged para marcar), mas o aplicativo não puder usar essa conta (por exemplo, porque as contas, como contas de email, devem ser configuradas no aplicativo primeiro), a troca de identidade deverá ser recusada.

O comportamento padrão para MAMActivity.onMAMIdentitySwitchRequired pode ser acessado chamando o método MAMActivity.defaultOnMAMIdentitySwitchRequired(activity, upn, oid, reason, callback)estático .

Da mesma forma, se você precisar substituir MAMActivity.onSwitchMAMIdentityCompleteo , poderá implementar MAMActivityIdentitySwitchListener sem herdar explicitamente do MAMActivity.

Comutadores de identidade e restrições de captura de tela

O SDK do aplicativo do Intune usa o Window sinalizador FLAG_SECURE para impor a política de captura de tela. Alguns aplicativos também podem ser configurados FLAG_SECURE para suas próprias finalidades. Quando a política de proteção do aplicativo não restringe capturas de tela, o SDK não modifica FLAG_SECURE.

Em uma opção de identidade de uma identidade cuja política requer a desabilitação de capturas de tela para uma identidade cuja política não, o SDK limpará FLAG_SECURE. Como resultado, seu aplicativo não deve depender de FLAG_SECURE permanecer definido após uma troca de identidade.

Preservando a identidade em operações assíncronas

Geralmente, os aplicativos despacham tarefas em segundo plano do thread da interface do usuário para lidar com operações em outros threads. Um aplicativo de várias identidades deve garantir que essas tarefas em segundo plano operem com a identidade apropriada, que geralmente é a mesma identidade usada pela atividade que as despachou.

O SDK do Aplicativo do Intune fornece MAMAsyncTask e MAMIdentityExecutors como uma conveniência para ajudar a preservar a identidade em operações assíncronas. Seu aplicativo deverá usá-los (ou definir explicitamente a identidade do thread nas tarefas) se suas operações assíncronas puderem:

• Gravar dados pertencentes a uma identidade gerenciada em um arquivo
• Comunicar-se com outros aplicativos

MAMAsyncTask

Para usar MAMAsyncTask, simplesmente herde dele em vez de AsyncTask e substitua as substituições de doInBackground e onPreExecute com doInBackgroundMAM e onPreExecuteMAM respectivamente. O MAMAsyncTask construtor usa um contexto de atividade. Por exemplo:

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 assumirá a identidade ativa com base na ordem normal de precedência.

MAMIdentityExecutors

MAMIdentityExecutorsPermite encapsular uma instância OR existente Executor como uma identidade preservando ExecutorExecutorService/com wrapExecutor métodos AND.wrapExecutorServiceExecutorService Por exemplo,

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

MAMIdentityExecutors assumirá a identidade ativa com base na ordem normal de precedência.

Proteção de arquivo

Gravando Files protegidos

Conforme mencionado em Organizando dados de aplicativo por identidade acima, o SDK do aplicativo do Intune associa a identidade ativa (do nível de thread/processo) aos arquivos à medida que eles são gravados. É fundamental ter a identidade correta definida no momento da criação do arquivo para garantir a criptografia adequada e a funcionalidade de limpeza seletiva.

Seu aplicativo pode consultar ou alterar a identidade de um arquivo usando a classe MAMFileProtectionManager , especificamente MAMFileProtectionManager.getProtectionInfo para consultas e MAMFileProtectionManager.protectForOID alterações.

O protectForOID método também pode ser usado para proteger diretórios. A proteção de diretório aplica-se recursivamente a todos os arquivos e subdiretórios contidos no diretório. Quando um diretório é protegido, todos os novos arquivos criados nele terão automaticamente a mesma proteção aplicada. Como a proteção de diretório é aplicada recursivamente, a protectForOID chamada pode levar algum tempo para ser concluída para diretórios grandes. Por esse motivo, os aplicativos que aplicam proteção a um diretório que contém um grande número de arquivos podem querer ser executados protectForOID de forma assíncrona em um thread em segundo plano.

Chamar protectForOID com cadeia de caracteres vazia para o parâmetro de identidade marcará o arquivo/diretório com a identidade não gerenciada. Esta operação removerá a criptografia do arquivo/diretório se ele tiver sido criptografado anteriormente. Quando um comando de apagamento seletivo é emitido, o arquivo/diretório não será excluído.

Aviso

É importante garantir que somente os arquivos pertencentes a uma identidade específica sejam protegidos com essa identidade. Caso contrário, outras identidades poderão sofrer perda de dados quando a identidade proprietária sair, pois os arquivos serão apagados e o acesso à chave de criptografia será perdido.

Exibindo conteúdo de arquivo protegido

É igualmente crítico ter a identidade correta definida quando o conteúdo do arquivo estiver sendo exibido para impedir que usuários não autorizados exibam dados gerenciados. O SDK não pode inferir automaticamente uma relação entre os arquivos lidos e os dados exibidos em um arquivo Activity. Os aplicativos devem definir a identidade da interface do usuário adequadamente antes de exibir quaisquer dados gerenciados. Isso inclui dados lidos de arquivos.

Se um arquivo vier de fora do aplicativo (de um ContentProvider local gravável publicamente ou for lido de um), o aplicativo deverá tentar determinar a identidade do arquivo (usando a sobrecarga MAMFileProtectionManager.getProtectionInfo correta para a fonte de dados) antes de exibir as informações lidas do arquivo.

Se getProtectionInfo relatar uma identidade não nula e não vazia, o aplicativo deverá definir a identidade da interface do usuário para corresponder a essa identidade usando MAMActivity.switchMAMIdentityOID ou MAMPolicyManager.setUIPolicyIdentityOID. Se a troca de identidade falhar, os dados do arquivo não deverão ser exibidos.

Ao ler de um URI de conteúdo, pode ser necessário primeiro ler a identidade (por meio da getProtectionInfo sobrecarga que leva um Uri) e, em seguida, definir a identidade de contexto ou thread adequadamente. Isso deve ser feito antes de abrir um descritor de arquivo ou fluxo de entrada no ContentResolver, caso contrário, a operação poderá falhar.

Um fluxo de exemplo pode ser semelhante ao seguinte:

• O usuário seleciona um documento para abrir no aplicativo.

• Durante o fluxo de abertura, antes de ler os dados do disco, o aplicativo confirma a identidade que deve ser usada para exibir o conteúdo:

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

• O aplicativo aguarda até que um resultado seja relatado para retorno de chamada.

• Se o resultado relatado for uma falha, o aplicativo não exibirá o documento.

• O aplicativo é aberto e renderiza o arquivo.

Se um app usar o Android DownloadManager para baixar arquivos, o SDK tentará proteger esses arquivos automaticamente usando a prioridade de identidade descrita anteriormente. O contexto usado para recuperar o DownloadManager será usado se a identidade do thread não for definida. Se os arquivos baixados contiverem dados corporativos, será responsabilidade do aplicativo chamar protectForOID se os arquivos forem movidos ou recriados após o download.

Single-Identity para a transição de várias identidades

Se um aplicativo lançado anteriormente com integração de identidade única do Intune integrar posteriormente várias identidades, os aplicativos instalados anteriormente passarão por uma transição. Essa transição não está visível para o usuário.

O aplicativo não é necessário para lidar com essa transição. Todos os arquivos criados antes da transição continuarão sendo considerados gerenciados (portanto, eles permanecerão criptografados se a política de criptografia estiver ativada).

Se você não quiser que todos os dados anteriores do aplicativo sejam associados à identidade gerenciada, poderá detectar essa transição e remover explicitamente a proteção.

• Detecte a atualização comparando a versão do aplicativo com uma versão conhecida em que o suporte a várias identidades foi adicionado.
• Chame protectForOID com cadeia de caracteres vazia para o parâmetro de identidade em arquivos ou diretórios que você não deseja associar à identidade gerenciada.

Cenários offline

O SDK do Aplicativo do Intune é executado no modo "offline" quando o aplicativo do Portal da Empresa não está instalado. A marcação de identidade do arquivo é sensível ao modo offline:

• Se o Portal da Empresa não estiver instalado, os arquivos não poderão ser marcados com a identidade. Chamar MAMFileProtectionManager.protectForOID no modo offline é seguro, mas não terá efeito.

• Se o Portal da Empresa estiver instalado, mas o aplicativo não tiver uma Política de Proteção do Aplicativo, os arquivos não poderão ser marcados de forma confiável.

• Quando a marcação de identidade do arquivo se torna disponível, todos os arquivos criados anteriormente são tratados como pessoais/não gerenciados (pertencentes à identidade de cadeia de caracteres vazia), exceto nos casos em que o aplicativo foi instalado anteriormente como um aplicativo gerenciado de identidade única, conforme descrito em Transição de identidade única para várias identidades.

Para evitar esses casos, os aplicativos devem evitar a criação de arquivos que contenham dados da conta até que o registro da conta seja concluído com êxito. Se o aplicativo precisar criar arquivos enquanto estiver offline, ele poderá usar MAMFileProtectionManager.protectForOID para corrigir a identidade associada do arquivo depois que o SDK estiver online.

Proteção de buffer de dados

Aviso

Não é recomendável gravar dados pertencentes a várias contas em um único arquivo. Se possível, organize os arquivos do seu aplicativo por identidade.

O MAMDataProtectionManager do SDK fornece métodos para verificar e alterar a identidade marcada em buffers de dados específicos em um ou byte[]InputStream formato.

MAMDataProtectionManager.protectForOID Permite que um aplicativo associe dados a uma identidade e, se a identidade estiver atualmente direcionada à política de criptografia, criptografe os dados. Esses dados criptografados são adequados para armazenamento em disco em um arquivo.

MAMDataProtectionManager Também permite consultar os dados associados à identidade e descriptografá-los.

Os aplicativos que usam MAMDataProtectionManager devem implementar um receptor para a MANAGEMENT_REMOVED notificação. Consulte Registrar-se para notificações do SDK para obter mais detalhes.

Após a conclusão dessa notificação, os buffers protegidos por essa classe não serão mais legíveis (se a criptografia de arquivo foi habilitada quando os buffers foram protegidos). Um aplicativo pode impedir que esses buffers se tornem ilegíveis chamando MAMDataProtectionManager.unprotect todos os buffers ao lidar com a MANAGEMENT_REMOVED notificação. Também é seguro ligar protectForOID durante essa notificação, se você quiser preservar as informações de identidade. A criptografia é garantida para ser desabilitada durante a notificação e chamar protectForOID o manipulador não criptografará buffers de dados.

Aviso

As operações de criptografia devem ser evitadas no início do processo do aplicativo. O SDK executará a inicialização de criptografia de forma assíncrona o mais cedo possível após a inicialização do aplicativo. No entanto, se um aplicativo fizer uma solicitação de criptografia na inicialização do aplicativo, ela poderá ser bloqueada até que a inicialização da criptografia seja concluída.

Observação

A API de criptografia do SDK do aplicativo do Intune deve ser usada somente para criptografar dados conforme exigido pela política do Intune. Nenhuma proteção será aplicada a contas que não sejam direcionadas com a política de criptografia habilitada, portanto, ela não pode ser usada como biblioteca de criptografia de uso geral.

Provedores de Conteúdo

Um aplicativo de várias identidades também deve proteger os dados compartilhados por meio ContentProviderde s para impedir o compartilhamento inadequado de conteúdo gerenciado.

Seu aplicativo deve chamar o método isProvideContentAllowedForOid(provider, oid)MAMContentProvider estático antes de retornar o conteúdo. Se essa função retornar false, o conteúdo não deverá ser retornado ao chamador.

A chamada isProvideContentAllowedForOid não é necessária se estiver ContentProvider retornando um ParcelFileDescriptordomínio . Os descritores de arquivo retornados por meio de um provedor de conteúdo são tratados automaticamente com base na identidade do arquivo.

Apagamento seletivo

Por padrão, o SDK do aplicativo do Intune manipulará automaticamente apagamentos seletivos, excluindo todos os arquivos associados à identidade gerenciada. Depois, o SDK fechará o aplicativo normalmente, concluindo as atividades e encerrando o processo do aplicativo.

O SDK fornece a capacidade opcional para que seu aplicativo complemente (recomendado) ou substitua o comportamento de apagamento padrão.

O manipulador de apagamento padrão do SDK não lida com buffers de dados protegidos por MAMDataProtectionManager. Se o aplicativo usou esse recurso, ele deverá complementar ou substituir o manipulador de apagamento padrão para remover esses dados.

Observação

Complementar e substituir o comportamento de apagamento padrão requer o tratamento de notificações específicas do SDK. Consulte Registrar-se para notificações do SDK para obter mais detalhes sobre como implementar manipuladores de notificação.

Complementando o comportamento de apagamento padrão

Para complementar o comportamento de apagamento padrão do SDK, seu aplicativo pode se registrar para o WIPE_USER_AUXILIARY_DATAMAMNotificationType.

Essa notificação será enviada pelo SDK antes que ele execute o apagamento seletivo padrão. O SDK aguardará a conclusão do manipulador de notificação do aplicativo antes de excluir dados e encerrar o aplicativo. Seu aplicativo deve limpar os dados de forma síncrona e não retornar até que toda a limpeza seja concluída.

Os aplicativos devem considerar fortemente a complementação do comportamento de apagamento padrão com WIPE_USER_AUXILIARY_DATA, pois a limpeza específica do aplicativo é comum para aplicativos de várias identidades.

Substituindo o comportamento de apagamento padrão

Para substituir o comportamento de apagamento padrão do SDK, seu aplicativo pode se registrar para o WIPE_USER_DATAMAMNotificationType.

Aviso

Um aplicativo nunca deve se registrar para ambos e WIPE_USER_DATAWIPE_USER_AUXILIARY_DATA.

Substituir o comportamento de apagamento padrão do SDK coloca um risco considerável em seu aplicativo. Seu aplicativo será totalmente responsável por remover todos os dados associados à identidade gerenciada, incluindo todos os arquivos e buffers de dados que foram marcados para essa identidade.

• Se a identidade gerenciada foi protegida com criptografia e o manipulador de apagamento personalizado do aplicativo não remove totalmente todos os dados gerenciados, todos os arquivos gerenciados restantes permanecerão criptografados. Esses dados ficarão inacessíveis e seu aplicativo pode não lidar com a tentativa de ler dados criptografados normalmente.
• O manipulador de apagamento do aplicativo pode resultar em perda de dados para usuários não gerenciados, se ele remover arquivos que não estão marcados com a identidade gerenciada.

Se o manipulador de apagamento personalizado do aplicativo remover dados gerenciados de um arquivo, mas quiser deixar outros dados no arquivo, ele deverá alterar a identidade do arquivo (via MAMFileProtectionManager.protectForOID) para uma identidade não gerenciada ou cadeia de caracteres vazia.

O manipulador de apagamento substituído deve limpar os dados de forma síncrona e não retornar até que toda a limpeza seja concluída.

Considere fechar seu aplicativo manualmente depois de concluir as etapas do manipulador de apagamento personalizado para impedir que o usuário acesse dados na memória após ocorrer um apagamento.

Critérios de Saída

Planeje dedicar um tempo significativo para validar a integração de várias identidades do seu aplicativo. Antes de começar a testar:

• Criar e atribuir política de proteção de aplicativo a uma conta. Esta será sua conta gerenciada de teste.
• Crie, mas não atribua a política de proteção do aplicativo a outra conta. Esta será sua conta não gerenciada de teste. Como alternativa, se o seu aplicativo der suporte a vários tipos de conta além das contas do Microsoft Entra, você poderá usar uma conta existente que não seja do Entra como a conta de teste não gerenciada.
• Familiarize-se novamente com como a política é imposta dentro do seu aplicativo. O teste de várias identidades exige que você diferencie facilmente quando seu aplicativo está e quando não está operando com a política imposta. A configuração da política de proteção do aplicativo para bloquear capturas de tela é eficaz para testar rapidamente a imposição da política.
• Considere todo o conjunto de interface do usuário que seu aplicativo oferece. Enumerar as telas em que os dados da conta são exibidos. Seu aplicativo apresenta apenas os dados de uma única conta de uma só vez ou pode apresentar dados pertencentes a várias contas ao mesmo tempo?
• Considere todo o conjunto de arquivos que seu aplicativo cria. Enumere quais desses arquivos contêm dados pertencentes a uma conta, em vez de dados no nível do sistema.
  • Determine como você validará a criptografia em cada um desses arquivos.
• Considere todo o conjunto de maneiras pelas quais seu aplicativo pode interagir com outros aplicativos. Enumere todos os pontos de entrada e saída. Que tipos de dados seu aplicativo pode ingerir? Que intenções ele transmite? Quais provedores de conteúdo ele implementa?
  • Determine como você exercitará cada um desses recursos de compartilhamento de dados.
  • Prepare um dispositivo de teste que tenha aplicativos gerenciados e não gerenciados que possam interagir com seu aplicativo.
• Considere como seu aplicativo permite que o usuário final interaja com todas as contas conectadas. O usuário precisa mudar manualmente para uma conta antes que os dados dessa conta sejam exibidos?

Depois de avaliar minuciosamente o comportamento atual do seu aplicativo, valide a integração de várias identidades executando o conjunto de testes a seguir. Observe que esta não é uma lista abrangente e não garante que a implementação de várias identidades do seu aplicativo esteja livre de bugs.

Validando cenários de logon e logoff

Seu aplicativo de várias identidades dá suporte a até 1 conta gerenciada e várias contas não gerenciadas. Esses testes ajudam a garantir que sua integração de várias identidades não altere indevidamente as proteções quando os usuários fizerem logon ou logoff.

Para esses testes, instale seu aplicativo e o Portal da Empresa do Intune; não faça logon antes de iniciar o teste.

Cenário	Etapas
Fazer logon gerenciado primeiro	- Faça login primeiro com uma conta gerenciada e valide se os dados da conta são gerenciados. - Faça login com uma conta não gerenciada e valide se os dados dessa conta não são gerenciados.
Fazer logon não gerenciado primeiro	- Faça logon primeiro com uma conta não gerenciada e valide que os dados dessa conta não são gerenciados. - Faça login com uma conta gerenciada e valide que os dados dessa conta são gerenciados.
Fazer logon em vários grupos gerenciados	- Faça login primeiro com uma conta gerenciada e valide se os dados da conta são gerenciados. - Faça login com uma segunda conta gerenciada e valide se o usuário está impedido de fazer logon sem primeiro remover a conta gerenciada original.
Fazer logoff gerenciado	- Faça login no seu aplicativo com uma conta gerenciada e não gerenciada. - Saia da conta gerenciada. - Confirme se a conta gerenciada foi removida do seu aplicativo e se todos os dados dessa conta foram removidos. - Confirme se a conta não gerenciada ainda está conectada, se nenhum dos dados da conta não gerenciada foi removido e se a política ainda não foi aplicada.
Fazer logoff não gerenciado	- Faça login no seu aplicativo com uma conta gerenciada e não gerenciada. - Saia da conta não gerenciada. - Confirme se a conta não gerenciada foi removida do seu aplicativo e se todos os dados dessa conta foram removidos. - Confirme se a conta gerenciada ainda está conectada, se nenhum dos dados da conta não gerenciada foi removido e se a política ainda está aplicada.

Validando a identidade ativa e o ciclo de vida do aplicativo

Seu aplicativo de várias identidades pode apresentar exibições com os dados de uma única conta e permitir que o usuário altere explicitamente a conta em uso atual. Ele também pode apresentar exibições com dados de várias contas ao mesmo tempo. Esses testes ajudam a garantir que sua integração de várias identidades forneça as proteções certas para a identidade ativa em cada página durante todo o ciclo de vida do aplicativo.

Para esses testes, instale seu aplicativo e o Portal da Empresa do Intune; faça logon com uma conta gerenciada e não gerenciada antes de iniciar o teste.

Cenário	Etapas
Exibição de conta única, gerenciada	- Mude para a conta gerenciada. - Navegue por todas as páginas do seu aplicativo que apresentam os dados de uma única conta. - Confirme se a política é aplicada em todas as páginas.
Exibição de conta única, não gerenciada	- Alterne para a conta não gerenciada. - Navegue por todas as páginas do seu aplicativo que apresentam os dados de uma única conta. - Confirme se a política não é aplicada em nenhuma página.
Exibição de várias contas	- Navegue para todas as páginas do seu aplicativo que apresentam dados de várias contas simultaneamente. - Confirme se a política é aplicada em todas as páginas.
Pausa gerenciada	- Em uma tela com dados gerenciados exibidos e política ativa, pause o aplicativo navegando até a tela inicial do dispositivo ou outro aplicativo. - Retome o aplicativo. - Confirme se a política ainda está aplicada.
Pausa não gerenciada	- Em uma tela com dados não gerenciados exibidos e nenhuma política ativa, pause o aplicativo navegando até a tela inicial do dispositivo ou outro aplicativo. - Retome o aplicativo. - Confirme se a política não foi aplicada.
Eliminação gerenciada	- Em uma tela com dados gerenciados exibidos e política ativa, force o encerramento do aplicativo. - Reinicie o aplicativo. - Confirme se, se o aplicativo for retomado em uma tela com os dados da conta gerenciada (esperado), a política ainda será aplicada. Se o aplicativo for retomado em uma tela com os dados da conta não gerenciada, confirme se a política não foi aplicada.
Encerramento não gerenciado	- Em uma tela com dados não gerenciados exibidos e política ativa, force o encerramento do aplicativo. - Reinicie o aplicativo. - Confirme se, se o aplicativo for retomado em uma tela com os dados da conta não gerenciada (esperado), a política não será aplicada. Se o aplicativo for retomado em uma tela com os dados da conta gerenciada, confirme se a política ainda está aplicada.
Troca de identidade ad hoc	- Experimente alternar entre contas e pausar / retomar / matar / reiniciar o aplicativo. - Confirme se os dados da conta gerenciada estão sempre protegidos e se os dados da conta não gerenciada nunca estão protegidos.

Validando cenários de compartilhamento de dados

Seu aplicativo de várias identidades pode enviar e receber dados de outros aplicativos. As políticas de proteção de aplicativo do Intune têm configurações que determinam esse comportamento. Esses testes ajudam a garantir que sua integração de várias identidades honre essas configurações de compartilhamento de dados.

Para esses testes, instale seu aplicativo e o Portal da Empresa do Intune; faça logon com uma conta gerenciada e não gerenciada antes de iniciar o teste. Além disso:

• Defina a política da conta gerenciada como:
  • "Enviar dados da organização para outros aplicativos" para "Aplicativos gerenciados por política".
  • "Receber dados de outros aplicativos" para "Aplicativos gerenciados por política".
• Instale outros aplicativos no dispositivo de teste:
  • Um aplicativo gerenciado, direcionado com a mesma política que seu aplicativo, que pode enviar e receber dados (como o Microsoft Outlook).
  • Qualquer aplicativo não gerenciado que possa enviar e receber dados.
• Faça logon no outro aplicativo gerenciado com a conta de teste gerenciada. Mesmo que o outro aplicativo gerenciado tenha várias identidades, faça logon somente com a conta gerenciada.

Se seu aplicativo tiver a capacidade de enviar dados para outros aplicativos, como o Microsoft Outlook enviando um anexo de documento para o Microsoft Office:

Cenário	Etapas
Envio de identidade gerenciada para aplicativo não gerenciado	- Mude para a conta gerenciada. - Navegue até onde seu aplicativo pode enviar dados. - Tente enviar dados para um aplicativo não gerenciado. - Você deve ser impedido de enviar dados para o aplicativo não gerenciado.
Envio de identidade gerenciada para aplicativo gerenciado	- Mude para a conta gerenciada. - Navegue até onde seu aplicativo pode enviar dados. - Tente enviar dados para o outro aplicativo gerenciado com a conta gerenciada conectada. - Você deve ter permissão para enviar dados para o aplicativo gerenciado.
Identidade não gerenciada enviada ao aplicativo gerenciado	- Alterne para a conta não gerenciada. - Navegue até onde seu aplicativo pode enviar dados. - Tente enviar dados para o outro aplicativo gerenciado com a conta gerenciada conectada. - Você deve ser impedido de enviar dados para o outro aplicativo gerenciado.
Envio de identidade não gerenciada para aplicativo não gerenciado	- Alterne para a conta não gerenciada. - Navegue até onde seu aplicativo pode enviar dados. - Tente enviar dados para um aplicativo não gerenciado. - Você sempre deve ter permissão para enviar os dados de uma conta não gerenciada para um aplicativo não gerenciado.

Seu aplicativo pode importar ativamente dados de outros aplicativos, como o Microsoft Outlook anexando um arquivo do Microsoft OneDrive. Seu aplicativo também pode receber passivamente dados de outros aplicativos, como o Microsoft Office abrindo um documento de um anexo do Microsoft Outlook. A configuração de política de proteção do aplicativo de recebimento abrange os dois cenários.

Se seu aplicativo tiver a capacidade de importar ativamente dados de outros aplicativos:

Cenário	Etapas
Importação de identidade gerenciada de aplicativo não gerenciado	- Mude para a conta gerenciada. - Navegue até onde seu aplicativo pode importar dados de outros aplicativos. - Tente importar dados de um aplicativo não gerenciado. - Você deve ser impedido de importar dados de aplicativos não gerenciados.
Importação de identidade gerenciada do aplicativo gerenciado	- Mude para a conta gerenciada. - Navegue até onde seu aplicativo pode importar dados de outros aplicativos. - Tente importar dados do outro aplicativo gerenciado com a conta gerenciada conectada. - Você deve ter permissão para importar dados do outro aplicativo gerenciado.
Importação de identidade não gerenciada do aplicativo gerenciado	- Alterne para a conta não gerenciada. - Navegue até onde seu aplicativo pode importar dados de outros aplicativos. - Tente importar dados do outro aplicativo gerenciado com a conta gerenciada conectada. - Você deve ser impedido de importar dados do outro aplicativo gerenciado.
Importação de identidade não gerenciada de aplicativo não gerenciado	- Alterne para a conta não gerenciada. - Navegue até onde seu aplicativo pode importar dados de outros aplicativos. - Tente importar dados de um aplicativo não gerenciado. - Você sempre deve ter permissão para importar dados de um aplicativo não gerenciado para uma conta não gerenciada.

Se o seu aplicativo tiver a capacidade de receber dados passivamente de outros aplicativos:

Cenário	Etapas
Recebimento de identidade gerenciada de aplicativo não gerenciado	- Mude para a conta gerenciada. - Alternar para o aplicativo não gerenciado. - Navegue para onde ele pode enviar dados. - Tente enviar dados do aplicativo não gerenciado para seu aplicativo. - A conta gerenciada do seu aplicativo não deve ser capaz de receber dados do aplicativo não gerenciado.
Recebimento de identidade gerenciada de aplicativo gerenciado	- Mude para a conta gerenciada. - Alterne para o outro aplicativo gerenciado com a conta gerenciada conectada. - Navegue para onde ele pode enviar dados. - Tente enviar dados do aplicativo gerenciado para seu aplicativo. - A conta gerenciada do seu aplicativo deve ter permissão para receber dados do outro aplicativo gerenciado.
Identidade não gerenciada receber de aplicativo gerenciado	- Alterne para a conta não gerenciada. - Alterne para o outro aplicativo gerenciado com a conta gerenciada conectada. - Navegue para onde ele pode enviar dados. - Tente enviar dados do aplicativo gerenciado para seu aplicativo. - A conta não gerenciada do seu aplicativo não deve receber dados do aplicativo gerenciado.
Identidade não gerenciada receber de aplicativo não gerenciado	- Alterne para a conta não gerenciada. - Alternar para o aplicativo não gerenciado. - Navegue para onde ele pode enviar dados. - Tente enviar dados do aplicativo não gerenciado para seu aplicativo. - A conta não gerenciada do seu aplicativo sempre deve ter permissão para receber dados do aplicativo não gerenciado.

Falhas nesses testes podem indicar que seu aplicativo não tem a identidade ativa correta definida ao tentar enviar ou receber dados. Você pode investigar isso aproveitando as APIs de obtenção de identidade do SDK no ponto de envio/recebimento para confirmar se a identidade ativa está definida corretamente.

Validando cenários de apagamento seletivo

Seu aplicativo de várias identidades pode ter complementado ou substituído o comportamento de apagamento padrão do SDK. Esses testes ajudam a garantir que sua integração de várias identidades remova corretamente os dados gerenciados quando os apagamentos são iniciados, sem afetar os dados não gerenciados.

Aviso

Lembrete, se o seu aplicativo aproveitou MAMDataProtectionManager.protectForOID, ele deve implementar um manipulador para ou WIPE_USER_AUXILIARY_DATAWIPE_USER_DATA.

Para esses testes, instale seu aplicativo e o Portal da Empresa do Intune; faça logon com uma conta gerenciada e não gerenciada antes de iniciar o teste. Para ambas as contas, cenários de aplicativos de exercícios que armazenam dados da conta.

Cenário	Condições prévias	Etapas
Manipulador de apagamento complementar	Seu aplicativo implementou um manipulador para WIPE_USER_AUXILIARY_DATA	- Execute um apagamento seletivo no centro de administração do Microsoft Intune. - Confirme (normalmente por meio de registro) se o manipulador de apagamento foi executado com êxito. - Confirme se a conta gerenciada foi removida do seu aplicativo e se todos os dados dessa conta foram removidos. - Confirme se a conta não gerenciada ainda está conectada, se nenhum dos dados da conta não gerenciada foi removido e se a política ainda não foi aplicada.
Manipulador de apagamento substituído	Seu aplicativo implementou um manipulador para WIPE_USER_DATA	- Execute um apagamento seletivo no centro de administração do Microsoft Intune. - Confirme (normalmente por meio de registro) se o manipulador de apagamento foi executado com êxito. - Confirme se a conta gerenciada foi removida do seu aplicativo e se todos os dados dessa conta foram removidos. - Confirme se a conta não gerenciada ainda está conectada, se nenhum dos dados da conta não gerenciada foi removido e se a política ainda não foi aplicada. - Confirme se o aplicativo foi encerrado normalmente ou ainda está em um estado íntegro após a conclusão do manipulador de apagamento.
Proteção manual de arquivos	- Seu aplicativo chama MAMFileProtectionManager.protectForOID - Seu aplicativo implementou um manipulador para WIPE_USER_DATA	- Certifique-se de ter exercitado cenários em que seu aplicativo protegeria manualmente pelo menos um arquivo pertencente à conta gerenciada. - Execute um apagamento seletivo no centro de administração do Microsoft Intune. - Confirme se os arquivos foram removidos.
Proteção manual do buffer de dados	- Seu aplicativo chama MAMDataProtectionManager.protectForOID - Seu aplicativo implementou um manipulador para ou WIPE_USER_AUXILIARY_DATAWIPE_USER_DATA	- Certifique-se de ter exercitado cenários em que seu aplicativo protegeria manualmente pelo menos um buffer de dados pertencente à conta gerenciada. - Execute um apagamento seletivo no centro de administração do Microsoft Intune. - Confirme se os buffers de dados foram removidos de todos os arquivos em que foram armazenados e se seu aplicativo ainda pode ler os dados não gerenciados desses arquivos.

Próximas etapas

Depois de concluir todos os critérios de saída acima, seu aplicativo agora está integrado com êxito como várias identidades e pode impor políticas de proteção de aplicativo por identidade. As seções subsequentes, Estágio 6: Configuração de Aplicativos e Estágio 7: Recursos de Participação no Aplicativo, podem ou não ser necessários, dependendo do suporte desejado da política de proteção do aplicativo do aplicativo. Se você não tiver certeza se alguma dessas seções se aplica ao seu aplicativo, consulte as principais decisões para integração ao SDK.