SDK da Aplicação Intune para Android – Identidade Múltipla

O SDK da Aplicação Microsoft Intune para Android permite-lhe incorporar políticas de proteção de aplicações do Intune (também conhecidas como políticas de APLICAÇÃO ou MAM) na sua aplicação Java/Kotlin Android nativa. Uma aplicação gerida pelo Intune é uma aplicação integrada com o SDK da Aplicação intune. Os administradores do Intune podem facilmente implementar políticas de proteção de aplicações na sua aplicação gerida pelo Intune quando o Intune gere ativamente a aplicação.

Observação

Este guia está dividido em várias fases distintas. Comece por rever a Fase 1: Planear a Integração.

Fase 5: Identidade Múltipla

Objetivos de Fase

• Determine se a sua aplicação precisa de suporte de várias identidades.
• Compreender como o SDK da Aplicação intune percebe as identidades.
• Refatorize a sua aplicação para deteção de identidade.
• Adicione código para informar o SDK de identidades ativas e alteradas em toda a sua aplicação.
• Teste exaustivamente a imposição da política de proteção de aplicações para identidades geridas e não geridas.

Terminologia de identidade

Os termos "utilizador", "conta" e "identidade" são frequentemente utilizados alternadamente. Este guia tenta diferenciar da seguinte forma:

• Utilizador: o ser humano que utiliza o produto de software. Diferenciado ainda mais como utilizador final, o ser humano que utiliza a aplicação Android e / oadministrador / administrador de TIPro, o utilizador administrador deTI / , o ser humano que utiliza o centro de administração do Microsoft Intune.
• Conta: o registo de software pertencente a uma organização que identifica exclusivamente a entidade de um utilizador. Um utilizador humano pode ter várias contas.
• Identidade: o conjunto de dados que o SDK da Aplicação intune utiliza para identificar exclusivamente uma conta.

Histórico

Por predefinição, o SDK da Aplicação intune aplica a política a toda a aplicação. Depois de registar uma conta com a política de proteção de aplicações direcionada, o SDK associa todos os ficheiros e todas as atividades à identidade dessa conta e aplicará universalmente a política de destino dessa conta.

Para muitos programadores, este é o comportamento de proteção de aplicações pretendido para a respetiva aplicação. Estas aplicações são consideradas de identidade única. Ao concluir as fases anteriores, a aplicação foi integrada com êxito como identidade única e pode impor todas as políticas básicas. As aplicações que se destinam a manter a identidade única podem ignorar esta secção e avançar para a Fase 6: Configuração da Aplicação.

Opcionalmente, o SDK da Aplicação Do Intune pode impor a política a um nível por identidade. Se a sua aplicação já suportar várias contas com sessão iniciada em simultâneo e quiser manter este suporte de várias contas com políticas de proteção de aplicações, a sua aplicação é considerada identidade múltipla.

Dica

Se não tiver a certeza se a aplicação deve suportar proteções de identidade única ou de várias identidades, consulte A minha aplicação é de identidade única ou de várias identidades?

Aviso

Suportar várias identidades é significativamente mais complexo do que outras funcionalidades de proteção de aplicações. A integração incorreta de várias identidades pode resultar em fugas de dados e outros problemas de segurança. Reveja cuidadosamente esta secção e planeie tempo suficiente para testes antes de avançar para a fase seguinte.

"Identidade" para o SDK

Quando uma aplicação integrada no SDK regista uma conta com o registerAccountForMAM, o SDK guarda todos os parâmetros fornecidos (upn, aadId, tenantId e autoridade) como a identidade. No entanto, a maioria das APIs de identidade do SDK utiliza apenas a cadeia upn fornecida como abreviatura da identidade. Estas APIs irão devolver apenas a cadeia upn como a identidade e apenas requerem o parâmetro de cadeia upn para a identidade.

As identidades não são sensíveis a maiúsculas e minúsculas. Os pedidos ao SDK para uma identidade podem não devolver a mesma caixa que foi utilizada ao registar ou definir a identidade.

Dica

No futuro, as APIs do SDK podem apresentar uma estrutura de identidade mais holística que inclui todos os campos fornecidos no momento do registo da conta e não apenas upn. Ao integrar o suporte de várias identidades, certifique-se de que a sua aplicação também tem acesso a aadId, tenantId e autoridade ao definir a identidade com as APIs atuais.

Identidades Geridas vs. Não Geridas

Conforme descrito em Registar-se na Política de Proteção de Aplicações, a sua aplicação é responsável por informar o SDK quando um utilizador inicia sessão. No momento do início de sessão, a conta do utilizador pode ou não ser alvo da política de proteção de aplicações. Se a conta for direcionada com a política de proteção de aplicações, o SDK considera-a gerida; caso contrário, não é gerido.

O SDK irá impor a política para identidades que considera geridas. O SDK não impõe a política para identidades que considera não geridas.

Atualmente, o SDK da Aplicação intune só suporta uma única identidade gerida por dispositivo. Assim que qualquer aplicação integrada no SDK registar uma identidade gerida, todas as identidades registadas subsequentemente, mesmo que estejam atualmente direcionadas para políticas de proteção de aplicações, serão tratadas como não geridas.

Se uma identidade gerida já tiver sido registada no dispositivo e a sua aplicação registar outra identidade que também é direcionada para a política de proteção de aplicações, o SDK irá devolver MAMEnrollmentManager.Result.WRONG_USER e pedir ao utilizador final opções para remediar. Veja Registar-se para obter notificações do SDK para obter mais detalhes.

Observação

Uma conta que não seja direcionada com a política de proteção de aplicações no momento do registo será considerada não gerida. Mesmo que a conta não esteja licenciada ou direcionada para a política de proteção de aplicações, o SDK verificará periodicamente se esta conta fica licenciada e direcionada mais tarde. Se nenhuma outra identidade gerida tiver sido registada, o SDK começará a tratar esta identidade como gerida assim que for direcionada para a política. O utilizador não precisa de terminar sessão e voltar a iniciar sessão nesta conta para efetuar esta alteração.

A Identidade Ativa

A aplicação tem de manter sempre o SDK informado sobre a identidade que está em utilização atual, também conhecida como identidade ativa. Se a identidade ativa for gerida, o SDK aplicará proteções. Se a identidade ativa não for gerida, o SDK não aplicará proteções.

Uma vez que o SDK não tem conhecimentos específicos da aplicação, tem de confiar na aplicação para partilhar a identidade ativa correta.

• Se a aplicação indicar incorretamente ao SDK que uma identidade não gerida está ativa quando a identidade gerida está realmente a ser utilizada, o SDK não aplicará proteções. Isto pode causar uma fuga de dados que coloca os dados dos utilizadores em risco.

• Se a aplicação indicar incorretamente ao SDK que a identidade gerida está ativa quando uma identidade não gerida está realmente a ser utilizada, o SDK aplicará proteções de forma inadequada. Não se trata de uma fuga de dados, mas pode restringir desnecessariamente os utilizadores não geridos e colocar os dados dos utilizadores não geridos em risco de eliminação.

Se a sua aplicação apresentar os dados de qualquer utilizador, só tem de apresentar dados que pertençam à identidade ativa. Se a sua aplicação não tiver atualmente conhecimento de quem é o proprietário dos dados que são apresentados, poderá ter de refatorizar a sua aplicação para maior deteção de identidade antes de começar a integrar o suporte de identidades múltiplas.

Organizar Dados da Aplicação por Identidade

Sempre que a sua aplicação escreve um novo ficheiro, o SDK associa (também conhecido como "etiquetas") uma identidade com esse ficheiro com base no thread ativo atual e na identidade do processo. Em alternativa, a sua aplicação pode chamar diretamente o SDK para etiquetar manualmente um ficheiro com uma identidade específica (consulte Escrever Ficheiros Protegidos para obter detalhes). O SDK utiliza esta identidade de ficheiro etiquetada para encriptação de ficheiros e eliminação seletiva.

Se a identidade gerida for direcionada com a política de encriptação, apenas os ficheiros etiquetados com a identidade gerida serão encriptados.

Se a ação de administrador ou a política configurada pedir que os dados geridos sejam apagados, apenas os ficheiros etiquetados com a identidade gerida serão eliminados.

O SDK não consegue associar múltiplas identidades a um único ficheiro. Se a sua aplicação armazenar dados pertencentes a vários utilizadores no mesmo ficheiro, o comportamento predefinido do SDK resultará na sub-proteção ou na proteção excessiva destes dados. É fortemente encorajado a organizar os dados da sua aplicação por identidade.

Se a sua aplicação tiver de armazenar dados pertencentes a identidades diferentes no mesmo ficheiro, o SDK fornece funcionalidades para subconjunto de dados de identificação de identidade num ficheiro. Veja Proteção da Memória Intermédia de Dados para obter detalhes.

Implementar Várias Identidades

Para declarar o suporte de várias identidades para a sua aplicação, comece por colocar os seguintes metadados no AndroidManifest.xml.

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

Definir a Identidade Ativa

A sua aplicação pode definir a identidade ativa nos seguintes níveis na prioridade descendente:

1. Nível de thread
2. Context (geralmente Activity) nível
3. Nível de processo

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

Uma identidade definida num Context só é utilizada em cenários associados adequados. As operações de E/S de ficheiros, por exemplo, não têm um .Context Normalmente, as aplicações irão definir a Context identidade num Activity. Considere definir a Context identidade em Activity.onCreate. Uma aplicação não pode apresentar dados para uma identidade, a menos que a Activity identidade esteja definida para essa mesma identidade.

Em geral, a identidade ao nível do processo só é útil se a aplicação funcionar apenas com uma única identidade de cada vez em todos os threads. Este comportamento não é típico para aplicações que suportam várias contas. É fortemente encorajado a segregar os dados da conta e a definir a identidade ativa no thread ou Context níveis.

Se a sua aplicação utilizar o Application contexto para adquirir serviços do sistema, certifique-se de que o thread ou a identidade do processo foram definidos ou que definiu a identidade da IU no contexto da Application sua aplicação.

Se a sua aplicação utilizar um Service contexto para iniciar intenções, utilizar resoluções de conteúdos ou tirar partido de outros serviços do sistema, certifique-se de que define a identidade no Service contexto. Da mesma forma, se a sua aplicação utilizar um JobService contexto para efetuar estas ações, certifique-se de que define a identidade no JobService contexto ou thread, conforme exigido pela sua JobService implementação. Por exemplo, se os seus JobService processos forem tarefas para uma única identidade, considere definir a identidade no JobService contexto. Se os seus JobService processos forem tarefas para múltiplas identidades, considere definir a identidade ao nível do thread.

Cuidado

As aplicações que utilizam WorkManager devem ter especial cuidado ao definir a identidade. Especificamente, estas aplicações devem evitar definir uma identidade no Context construtor transmitido Worker . Esta Context instância pode ser partilhada entre várias Worker instâncias em simultâneo. Para evitar comportamentos indefinidos, as aplicações devem, em vez disso, definir uma identidade de thread como Worker.doWork() exigido pela Worker implementação.

Observação

Uma vez que o CLIPBOARD_SERVICE é utilizado para operações de IU, o SDK utiliza a identidade de IU da atividade em primeiro plano para ClipboardManager operações.

Os seguintes métodos no MAMPolicyManager podem ser utilizados para definir a identidade ativa e obter os valores de identidade anteriormente definidos.

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

Como conveniência, também pode definir a identidade de uma atividade diretamente através de um método em MAMActivity em vez de chamar MAMPolicyManager.setUIPolicyIdentity. Utilize o seguinte método para o fazer:

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

Observação

Se a sua aplicação não tiver declarado suporte de várias identidades no manifesto, chamar estes métodos para definir a identidade não executará nenhuma ação e, se devolverem uma MAMIdentitySwitchResult, devolverá FAILEDsempre .

Armadilhas comuns do Comutador de Identidade

• Para chamadas para startActivityo , o SDK da Aplicação intune pressupõe que a identidade ativa ao Context nível está associada ao parâmetro fornecido Intent . Recomendamos vivamente que defina a Context identidade de nível com o contexto de um Activitye não com o Applicationcontexto.

• Recomenda-se definir a Context identidade durante o método de onCreate uma Atividade. No entanto, certifique-se de que também abrange outros pontos de entrada, como onNewIntent. Caso contrário, quando a mesma Atividade é reutilizada para apresentar dados para identidades geridas e não geridas, a política pode ser aplicada incorretamente, o que leva a dados empresariais desprotegidos ou dados pessoais indevidamente restritos.

Resultados do Comutador de Identidade

Todos os métodos utilizados para definir os valores de resultado do relatório de identidade através de MAMIdentitySwitchResult. Existem quatro valores que podem ser devolvidos:

Valor de retorno	Cenário
SUCCEEDED	A alteração de identidade foi bem-sucedida.
NOT_ALLOWED	A alteração de identidade não é permitida. Isto ocorre se for efetuada uma tentativa de definir a identidade da IU (Context) quando uma identidade diferente é definida no thread atual.
CANCELLED	Geralmente, o utilizador cancelou a alteração de identidade ao premir o botão anterior num pedido de PIN ou autenticação.
FAILED	A alteração de identidade falhou por um motivo não especificado.

A aplicação deve verificar se MAMIdentitySwitchResult está SUCCEEDED antes de apresentar ou utilizar os dados de uma conta gerida.

A maioria dos métodos para definir a identidade ativa devolve MAMIdentitySwitchResult de forma síncrona. No caso de definir uma Context identidade através de setUIPolicyIdentity, o resultado é comunicado de forma assíncrona. A aplicação pode implementar um MAMSetUIIdentityCallback para receber este resultado ou pode passar nulo para o objeto de chamada de retorno. Se uma chamada for efetuada enquanto setUIPolicyIdentity o resultado de uma chamada anterior para setUIPolicyIdentityno mesmo contexto ainda não tiver sido entregue, a nova chamada de retorno substituirá a antiga e a chamada de retorno original nunca receberá um resultado.

Cuidado

Se o Context fornecido para setUIPolicyIdentity for um Activity, o SDK não sabe se a alteração de identidade teve êxito até que execute as verificações de início condicional configuradas pelo administrador. Isto pode exigir que o utilizador introduza um PIN ou credenciais empresariais.

Atualmente, os comutadores de identidade de processos e threads terão sempre êxito para uma aplicação com várias identidades ativada. O SDK reserva-se o direito de adicionar condições de falha no futuro.

O comutador de identidade da IU pode falhar para argumentos inválidos, se entrar em conflito com a identidade do thread ou se o utilizador cancelar os requisitos de início condicional (por exemplo, premir o botão anterior no ecrã pin).

O comportamento predefinido de um comutador de identidade de IU com falha numa atividade é concluir a atividade. Para alterar este comportamento e receber notificações sobre tentativas de alteração de identidade para uma atividade, pode substituir um método no MAMActivity.

    public void onSwitchMAMIdentityComplete(final MAMIdentitySwitchResult result);

Se substituir onSwitchMAMIdentityComplete (ou chamar o super método), tem de se certificar de que os dados de uma conta gerida não são apresentados após uma mudança de identidade falhada.

Observação

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

Identity, Intents e IdentitySwitchOptions

Além de etiquetar automaticamente novos ficheiros com a identidade ativa, o SDK também identifica as intenções com a identidade ativa. Por predefinição, o SDK irá verificar a identidade numa intenção de entrada e compará-la com a identidade ativa. Se estas identidades não corresponderem, o SDK normalmente(*) solicita um comutador de identidade (veja Alterações implícitas de identidade abaixo para obter mais detalhes).

O SDK também armazena esta identidade de intenção de entrada para utilização posterior. Quando a aplicação altera explicitamente a identidade da IU, o SDK compara a identidade para a qual a aplicação está a tentar mudar face à identidade de intenção de entrada mais recente. Se estas identidades não corresponderem, o SDK irá normalmente (*) falhar a mudança de identidade.

O SDK efetua esta verificação porque pressupõe que a aplicação ainda está a apresentar conteúdo da intenção que pertence à identidade etiquetada na intenção. Esta suposição protege contra a aplicação desativar involuntariamente as proteções ao apresentar dados geridos; no entanto, esta suposição pode não estar correta para o comportamento real da aplicação.

As enumerações de IdentitySwitchOption opcionais podem ser transmitidas para as APIs setUIPolicyIdentity e switchMAMIdentity para modificar o comportamento predefinido do SDK.

• IGNORE_INTENT: ao pedir um comutador de identidade na camada de IU, esta opção informa o SDK para ignorar a comparação do parâmetro de identidade pedido com a identidade de intenção armazenada mais recentemente. Isto é útil quando a sua aplicação já não apresenta conteúdos pertencentes a essa identidade e o SDK não deve bloquear esta mudança de identidade. Por exemplo:

  1. A sua aplicação é um visualizador de documentos. Pode compor documentos transmitidos a partir de outras aplicações. Também contém uma funcionalidade em que os utilizadores podem mudar de contas. Sempre que o utilizador utilizar esta funcionalidade de comutador de conta, a aplicação navega para uma página de destino específica da conta com os documentos recentes dessa conta.
  2. A sua aplicação recebe a intenção de apresentar um documento. Esta intenção está marcada com a identidade gerida.
  3. A sua aplicação é mudada para a identidade gerida e apresenta este documento, com proteções aplicadas corretamente.
  4. O utilizador utiliza o comutador de conta para mudar para a respetiva conta pessoal.

  A sua aplicação tem de alterar a identidade da IU no passo 4. Neste caso, uma vez que o comportamento da aplicação é navegar para fora dos dados da conta gerida (o documento na intenção), deve utilizar IGNORE_INTENT na chamada do comutador de identidade. Isto evita que o SDK falhe inadequadamente nesta chamada.

• DATA_FROM_INTENT: ao pedir um comutador de identidade na camada de IU, esta opção informa o SDK de que os dados da identidade de intenção armazenada mais recentemente continuarão a ser apresentados após o comutador de identidade ser bem-sucedido. Como resultado, o SDK avaliará totalmente a política de receção em relação à identidade de intenção anterior para determinar se é permitido apresentá-la. Por exemplo:

  1. A sua aplicação é um visualizador de documentos. Pode compor documentos transmitidos a partir de outras aplicações. Também contém uma funcionalidade em que os utilizadores podem mudar de contas. Ao contrário do exemplo anterior, sempre que o utilizador utiliza esta funcionalidade de mudança de conta, a aplicação navega para uma página partilhada que mostra documentos recentes para todas as contas".
  2. A sua aplicação recebe a intenção de apresentar um documento. Esta intenção está marcada com a identidade gerida.
  3. A sua aplicação é mudada para a identidade gerida e apresenta este documento, com proteções aplicadas corretamente.
  4. O utilizador utiliza o comutador de conta para mudar para a respetiva conta pessoal.

  A sua aplicação tem de alterar a identidade da IU no passo 4. Neste caso, uma vez que o comportamento da aplicação é continuar a apresentar os dados da identidade gerida (uma pré-visualização do documento na intenção), deve utilizá-lo DATA_FROM_INTENT na chamada do comutador de identidade. Isto informa o SDK para verificar a política de proteção de aplicações configurada para determinar se é apropriado que os dados continuem a ser apresentados.

(*) O comportamento predefinido do SDK inclui maiúsculas/vulas especiais que ignoram esta verificação de entrada de dados se, por exemplo, a intenção for proveniente da mesma aplicação ou do iniciador do sistema.

Limpar a Identidade Ativa

A sua aplicação pode ter cenários que são agnósticos em conta. A sua aplicação também pode ter cenários para cenários não geridos locais que não requerem qualquer início de sessão. Em ambos os casos, a sua aplicação pode não querer que o SDK imponha as políticas da identidade gerida, mas pode não ter uma identidade explícita para a qual mudar.

Pode limpar a identidade ativa ao chamar qualquer um dos métodos de identidade definidos com o parâmetro de identidade definido como null. Limpar a identidade num nível fará com que o SDK procure a identidade ativa noutros níveis, com base na ordem de precedência.

Em alternativa, pode transmitir a cadeia vazia como o parâmetro de identidade, que define a identidade para um valor vazio especial que é tratado como uma identidade não gerida. Definir a identidade ativa como uma cadeia vazia indica ao SDK para não impor nenhuma política de proteção de aplicações.

Alterações de Identidade Implícitas

A secção acima descreve as diferentes formas como a sua aplicação pode definir explicitamente a identidade ativa nos níveis de thread, contexto e processo. No entanto, a identidade ativa na sua aplicação também pode ser alterada sem que a sua aplicação chame qualquer um destes métodos. Esta secção descreve como a sua aplicação pode escutar e responder a estas alterações implícitas de identidade.

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

Cuidado

Se a sua aplicação optar por não escutar alterações implícitas de identidade, tenha muito cuidado para não assumir a identidade ativa. Em caso de dúvida, utilize os getCurrentThreadIdentitymétodos , getUIPolicyIdentitye getProcessIdentity para confirmar a identidade ativa.

Origens de Alterações de Identidade Implícitas

• A entrada de dados de outras aplicações geridas pelo Intune pode alterar a identidade ativa no nível de thread e contexto.

  • Se uma atividade for iniciada a partir de uma Intent aplicação enviada por outra Aplicação MAM, a identidade da atividade será definida com base na identidade ativa na outra aplicação no momento em que foi Intent enviada.

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

  • Para os serviços, a identidade do thread será definida de forma semelhante durante uma onStart chamada ou onBind . Binder As chamadas a partir das onBind devolvidas também definirão temporariamente a identidade do thread.

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

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

  • Um utilizador que cancele um pedido de autorização durante Resume o resultará numa mudança implícita para uma identidade vazia.

Processar Alterações de Identidade Implícitas

Opcionalmente, a aplicação pode escutar e reagir a estas alterações de identidade implícitas. Por exemplo, a sua aplicação pode exigir vários passos antes de ser possível utilizar uma conta adicionada, como uma aplicação de e-mail que configura uma nova caixa de entrada. Após ver uma tentativa de mudança de identidade para a identidade desta conta incompleta, o processador da sua aplicação pode redirecionar o utilizador para a atividade de configuração da conta antes de aceitar a mudança de identidade. Em alternativa, o processador da aplicação pode apresentar uma caixa de diálogo de erro e bloquear o comutador de identidade.

A sua aplicação pode implementar a interface MAMIdentityRequirementListener numa Service ou ContextProvider para alterações de identidade aplicadas a este thread. A implementação tem de substituir:

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

A sua aplicação pode implementar a interface MAMActivityIdentityRequirementListener numa Activity para alterações de identidade aplicadas a esta atividade. A implementação tem de substituir:

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

O AppIdentitySwitchReason parâmetro de enumeração descreve a origem do comutador de identidade implícito.

Valor de enumeração	Comportamento predefinido do SDK	Descrição
CREATE	Permitir a mudança de identidade.	O comutador de identidade está a ocorrer devido à criação de uma atividade.
NEW_INTENT	Permitir a mudança de identidade.	O comutador de identidade está a ocorrer porque está a ser atribuída uma nova intenção a uma atividade.
RESUME_CANCELLED	Bloquear o comutador de identidade.	O comutador de identidade está a ocorrer porque foi cancelado um currículo. Isto é mais comum quando o utilizador final prime o botão anterior no PIN, na autenticação ou na IU de conformidade.

O parâmetro AppIdentitySwitchResultCallback permite que os programadores substituam o comportamento predefinido do comutador 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 implícitas de identidade, exceto as efetuadas através de um Binder devolvido de MAMService.onMAMBind. As implementações predefinidas da onMAMIdentitySwitchRequired chamada imediata:

• callback.reportIdentitySwitchResult(FAILURE) quando o motivo é RESUME_CANCELLED.

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

Não é esperado que a maioria das aplicações tenha de bloquear ou atrasar uma mudança de identidade de uma forma diferente, mas se uma aplicação precisar de o fazer, os seguintes pontos têm de ser considerados:

• Se um comutador de identidade for bloqueado, o comportamento do utilizador final é o mesmo que se a definição de proteção da aplicação "receber dados de outras aplicações" do SDK tivesse proibido a entrada de dados.

• Se um Serviço estiver em execução no thread principal, reportIdentitySwitchResulttem de ser chamado de forma síncrona ou o thread da IU deixa de responder.

• Para Activity a criação, onMAMIdentitySwitchRequired será chamado antes onMAMCreatede . Se a aplicação tiver de mostrar a IU para determinar se pretende permitir a mudança de identidade, essa IU tem de ser apresentada com uma atividade diferente .

• Num Activity, quando é pedida uma mudança para a identidade vazia com o motivo como RESUME_CANCELLED, a aplicação tem de modificar a atividade retomada para apresentar dados consistentes com essa mudança de identidade. Se tal não for possível, a aplicação deverá recusar a mudança e ser-lhe-á pedido novamente que cumpra a política para a identidade retomada (por exemplo, ao ser apresentado o ecrã de entrada do PIN da aplicação).

Cuidado

Uma aplicação de várias identidades pode receber dados recebidos de aplicações geridas e não geridas. É da responsabilidade da aplicação tratar os dados de identidades geridas de forma gerida.

Se for gerida uma identidade pedida (utilize MAMPolicyManager.getIsIdentityManaged para verificar), mas a aplicação não conseguir utilizar essa conta (por exemplo, porque as contas, como as contas de e-mail, têm de ser configuradas primeiro na aplicação), o comutador de identidade deve ser recusado.

O comportamento predefinido para MAMActivity.onMAMIdentitySwitchRequired pode ser acedido ao chamar o método MAMActivity.defaultOnMAMIdentitySwitchRequired(activity, identity, reason, callback)estático .

Da mesma forma, se precisar de substituir MAMActivity.onSwitchMAMIdentityComplete, poderá implementar MAMActivityIdentitySwitchListener sem herdar explicitamente de MAMActivity.

Comutadores de Identidade e Restrições de Captura de Ecrã

O SDK da Aplicação intune utiliza o Window sinalizador FLAG_SECURE para impor a política de captura de ecrã. Algumas aplicações também podem ser definidas FLAG_SECURE para os seus próprios fins. Quando a política de proteção de aplicações não restringe as capturas de ecrã, o SDK não modifica .FLAG_SECURE

Numa identidade, mude de uma identidade cuja política requer a desativação de capturas de ecrã para uma identidade cuja política não o faça, o SDK irá limpar FLAG_SECURE. Como resultado, a sua aplicação não deve depender FLAG_SECURE do conjunto restante após uma mudança de identidade.

Preservar a Identidade nas Operações Assíncronas

Muitas vezes, as aplicações enviam tarefas em segundo plano do thread de IU para processar operações noutros threads. Uma aplicação de várias identidades tem de garantir que estas tarefas em segundo plano funcionam com a identidade adequada, que é frequentemente a mesma identidade utilizada pela atividade que as distribuiu.

O SDK da Aplicação intune fornece MAMAsyncTask e MAMIdentityExecutors como uma conveniência para ajudar a preservar a identidade em operações assíncronas. A sua aplicação tem de utilizar estes (ou definir explicitamente a identidade do thread nas tarefas) se as respetivas operações assíncronas puderem:

• Escrever dados pertencentes a uma identidade gerida num ficheiro
• Comunicar com outras aplicações

MAMAsyncTask

Para utilizar MAMAsyncTask, basta herdar do mesmo em vez de AsyncTask e substituir substituições de doInBackground e onPreExecute por doInBackgroundMAM e onPreExecuteMAM , respetivamente. O MAMAsyncTask construtor assume 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-lhe encapsular uma instância ou existente como uma preservação ExecutorExecutorService/de identidade com wrapExecutor métodos e.wrapExecutorServiceExecutorExecutorService 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 Ficheiros

Escrever Ficheiros Protegidos

Conforme mencionado em Organizar Dados da Aplicação por Identidade acima, o SDK da Aplicação intune associa a identidade ativa (a partir do nível de thread/processo) aos ficheiros à medida que são escritos. É fundamental ter a identidade correta definida no momento da criação do ficheiro para garantir a encriptação adequada e a funcionalidade de eliminação seletiva.

A sua aplicação pode consultar ou alterar a identidade de um ficheiro através da classe MAMFileProtectionManager , especificamente MAMFileProtectionManager.getProtectionInfo para consultar e MAMFileProtectionManager.protect alterar.

O protect método também pode ser utilizado para proteger diretórios. A proteção de diretórios aplica-se recursivamente a todos os ficheiros e subdiretórios contidos no diretório. Quando um diretório está protegido, todos os novos ficheiros criados no diretório terão automaticamente a mesma proteção aplicada. Uma vez que a proteção de diretórios é aplicada recursivamente, a protect chamada pode demorar algum tempo a ser concluída para diretórios grandes. Por esse motivo, as aplicações que aplicam proteção a um diretório que contém um grande número de ficheiros podem querer ser executadas protect de forma assíncrona num thread em segundo plano.

Chamar protect com uma cadeia vazia para o parâmetro de identidade irá etiquetar o ficheiro/diretório com a identidade não gerida. Esta operação removerá a encriptação do ficheiro/diretório se tiver sido encriptada anteriormente. Quando um comando de eliminação seletiva é emitido, o ficheiro/diretório não será eliminado.

Apresentar Conteúdo de Ficheiro Protegido

É igualmente fundamental ter a identidade correta definida quando o conteúdo do ficheiro está a ser apresentado para impedir que utilizadores não autorizados vejam dados geridos. O SDK não consegue inferir automaticamente uma relação entre os ficheiros que estão a ser lidos e os dados apresentados num Activity. As aplicações têm de definir a identidade da IU adequadamente antes de apresentar quaisquer dados geridos. Isto inclui dados lidos a partir de ficheiros.

Se um ficheiro for proveniente de fora da aplicação (de uma ContentProvider localização gravável ou lida a partir de uma localização publicamente gravável), a aplicação tem de tentar determinar a identidade do ficheiro (utilizando a sobrecarga MAMFileProtectionManager.getProtectionInfo correta para a origem de dados) antes de apresentar as informações lidas a partir do ficheiro.

Se getProtectionInfo comunicar uma identidade não nula e não vazia, a aplicação tem de definir a identidade da IU para corresponder a esta identidade através de MAMActivity.switchMAMIdentity ou MAMPolicyManager.setUIPolicyIdentity. Se o comutador de identidade falhar, os dados do ficheiro não podem ser apresentados.

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

Um fluxo de exemplo pode ter um aspeto semelhante ao seguinte:

• O utilizador seleciona um documento para abrir na aplicação.

• Durante o fluxo aberto, antes de ler dados do disco, a aplicação confirma a identidade que deve ser utilizada para apresentar o conteúdo:

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

• A aplicação aguarda até que um resultado seja comunicado à chamada de retorno.

• Se o resultado comunicado for uma falha, a aplicação não apresenta o documento.

• A aplicação é aberta e compõe o ficheiro.

Se uma aplicação utilizar o Android DownloadManager para transferir ficheiros, o SDK tentará proteger estes ficheiros automaticamente utilizando a prioridade de identidade descrita anteriormente. O contexto utilizado para obter o DownloadManager será utilizado se a identidade do thread não for apresentada. Se os ficheiros transferidos contiverem dados empresariais, é da responsabilidade da aplicação chamar a proteção se os ficheiros forem movidos ou recriados após a transferência.

Single-Identity para a Transição de Várias Identidades

Se uma aplicação lançada anteriormente com a integração de identidade única do Intune integrar mais tarde várias identidades, as aplicações instaladas anteriormente irão sofrer uma transição. Esta transição não é visível para o utilizador.

A aplicação não é necessária para processar esta transição. Todos os ficheiros criados antes da transição continuarão a ser considerados geridos (para que permaneçam encriptados se a política de encriptação estiver ativada).

Se não quiser que todos os dados da aplicação anteriores sejam associados à identidade gerida, pode detetar esta transição e remover explicitamente a proteção.

• Detete a atualização ao comparar a versão da aplicação com uma versão conhecida onde foi adicionado suporte de várias identidades.
• Chame protect com uma cadeia vazia para o parâmetro de identidade em ficheiros ou diretórios que não pretende que estejam associados à identidade gerida.

Cenários Offline

O SDK da Aplicação Intune é executado no modo "offline" quando a aplicação Portal da Empresa não está instalada. A identificação da identidade de ficheiro é sensível ao modo offline:

• Se o Portal da Empresa não estiver instalado, os ficheiros não podem ser etiquetados com identidade. Chamar MAMFileProtectionManager.protect no modo offline é seguro, mas não terá qualquer efeito.

• Se o Portal da Empresa estiver instalado, mas a aplicação não tiver a Política de Proteção de Aplicações, os ficheiros não podem ser etiquetados de identidade de forma fiável.

• Quando a identificação de identidade de ficheiro fica disponível, todos os ficheiros criados anteriormente são tratados como pessoais/não geridos (pertencentes à identidade de cadeia vazia), exceto nos casos em que a aplicação foi instalada anteriormente como uma aplicação gerida de identidade única, conforme descrito em Transição de Identidade Única para Identidade Múltipla.

Para evitar estes casos, as aplicações devem evitar criar ficheiros que contenham dados de conta até que o registo da conta seja concluído com êxito. Se a sua aplicação tiver de criar ficheiros enquanto estiver offline, pode utilizar MAMFileProtectionManager.protect para corrigir a identidade associada do ficheiro assim que o SDK estiver online.

Proteção da Memória Intermédia de Dados

Aviso

Não é recomendado escrever dados pertencentes a várias contas num único ficheiro. Se possível, organize os ficheiros da sua aplicação por identidade.

O MAMDataProtectionManager do SDK fornece métodos para verificar e alterar a identidade etiquetada em memórias intermédias de dados específicas no formato ou InputStream no byte[] formato.

MAMDataProtectionManager.protect permite que uma aplicação associe dados a uma identidade e, se a identidade estiver atualmente direcionada para a política de encriptação, encripte os dados. Estes dados encriptados são adequados para armazenamento em disco num ficheiro.

MAMDataProtectionManager também lhe permite consultar os dados associados à identidade e desencriptá-la.

As aplicações que utilizam MAMDataProtectionManager devem implementar um recetor para a MANAGEMENT_REMOVED notificação. Veja Registar-se para obter notificações do SDK para obter mais detalhes.

Após a conclusão desta notificação, as memórias intermédias que foram protegidas através desta classe deixarão de ser legíveis (se a encriptação de ficheiros tiver sido ativada quando as memórias intermédias estiverem protegidas). Uma aplicação pode impedir que estas memórias intermédias fiquem ilegíveis ao chamar MAMDataProtectionManager.unprotect todas as memórias intermédias ao processar a MANAGEMENT_REMOVED notificação. Também é seguro chamar protect durante esta notificação, se quiser preservar as informações de identidade. É garantido que a encriptação está desativada durante a notificação e a chamada protect no processador não encripta as memórias intermédias de dados.

Fornecedores de Conteúdo

Uma aplicação de várias identidades também tem de proteger os dados partilhados através ContentProviderde s para impedir a partilha inadequada de conteúdos geridos.

A aplicação tem de chamar o método isProvideContentAllowed(provider, contentIdentity)MAMContentProvider estático antes de devolver o conteúdo. Se esta função devolver false, o conteúdo não pode ser devolvido ao autor da chamada.

As chamadas isProvideContentAllowed não são necessárias se estiver ContentProvider a devolver um ParcelFileDescriptor. Os descritores de ficheiros devolvidos através de um fornecedor de conteúdos são processados automaticamente com base na identidade do ficheiro.

Eliminação Seletiva

Por predefinição, o SDK da Aplicação Intune processará automaticamente eliminações seletivas, eliminando todos os ficheiros que tenham sido associados à identidade gerida. Posteriormente, o SDK fechará a aplicação corretamente, terminando as atividades e eliminando o processo da aplicação.

O SDK fornece a capacidade opcional para a sua aplicação complementar (recomendado) ou substituir o comportamento de eliminação predefinido.

O processador de eliminação predefinido do SDK não processa memórias intermédias de dados protegidas por MAMDataProtectionManager. Se a sua aplicação utilizou esta funcionalidade, tem de complementar ou substituir o processador de eliminação predefinido para remover esses dados.

Observação

Complementar e substituir o comportamento de eliminação predefinido requer o processamento de notificações específicas do SDK. Veja Registar-se para obter notificações do SDK para obter mais detalhes sobre a implementação de processadores de notificação.

Suplementar Comportamento de Eliminação Predefinido

Para complementar o comportamento de eliminação do SDK predefinido, a aplicação pode registar-se no WIPE_USER_AUXILIARY_DATAMAMNotificationType.

Esta notificação será enviada pelo SDK antes de efetuar a eliminação seletiva predefinida. O SDK aguardará que o processador de notificações da sua aplicação seja concluído antes de eliminar os dados e terminar a aplicação. A sua aplicação deve limpar os dados de forma síncrona e não devolver até que toda a limpeza esteja concluída.

As aplicações devem considerar vivamente complementar o comportamento de eliminação predefinido com WIPE_USER_AUXILIARY_DATA, uma vez que a limpeza específica da aplicação é comum para aplicações de várias identidades.

Substituir Comportamento de Eliminação Predefinida

Para substituir o comportamento de eliminação do SDK predefinido, a aplicação pode registar-se no WIPE_USER_DATAMAMNotificationType.

Aviso

Uma aplicação nunca deve registar-se para e WIPE_USER_DATAWIPE_USER_AUXILIARY_DATA.

Substituir o comportamento de eliminação predefinida do SDK coloca um risco considerável na sua aplicação. A sua aplicação será totalmente responsável por remover todos os dados associados à identidade gerida, incluindo todos os ficheiros e memórias intermédias de dados que foram etiquetados para essa identidade.

• Se a identidade gerida tiver sido protegida com encriptação e o processador de eliminação personalizada da sua aplicação não remover totalmente todos os dados geridos, todos os ficheiros geridos restantes permanecerão encriptados. Estes dados ficarão inacessíveis e a sua aplicação poderá não processar a tentativa de leitura de dados encriptados corretamente.
• O processador de eliminação da aplicação pode resultar na perda de dados para utilizadores não geridos, se remover ficheiros que não estão etiquetados com a identidade gerida.

Se o processador de eliminação personalizada da sua aplicação remover dados geridos de um ficheiro, mas quiser deixar outros dados no ficheiro, tem de alterar a identidade do ficheiro (através de MAMFileProtectionManager.protect) para uma identidade não gerida ou uma cadeia vazia.

O processador de eliminação substituído deve limpar os dados de forma síncrona e não devolver até que toda a limpeza esteja concluída.

Considere fechar a aplicação manualmente depois de concluir os passos do processador de eliminação personalizada para impedir que o utilizador aceda aos dados na memória depois de ocorrer uma eliminação.

Critérios de Saída

Planeie dedicar um tempo significativo para validar a integração da sua aplicação em várias identidades. Antes de começar a testar:

• Criar e atribuir uma política de proteção de aplicações a uma conta. Esta será a sua conta gerida de teste.
• Crie, mas não atribua uma política de proteção de aplicações a outra conta. Esta será a sua conta de teste não gerida. Em alternativa, se a sua aplicação suportar vários tipos de conta para além das contas do Microsoft Entra, pode utilizar uma conta não AAD existente como a conta de teste não gerida.
• Reamiliar-se com a forma como a política é imposta dentro da sua aplicação. Os testes de várias identidades requerem que faça uma distinção fácil quando a sua aplicação está e não está a funcionar com a política imposta. A definição de política de proteção de aplicações para bloquear capturas de ecrã é eficaz para testar rapidamente a aplicação da política.
• Considere todo o conjunto de IU que a sua aplicação oferece. Enumerar os ecrãs onde os dados da conta são apresentados. A sua aplicação só apresenta dados de uma única conta ao mesmo tempo ou pode apresentar dados pertencentes a várias contas ao mesmo tempo?
• Considere todo o conjunto de ficheiros que a sua aplicação cria. Enumerar quais destes ficheiros contêm dados pertencentes a uma conta, em oposição aos dados ao nível do sistema.
  • Determine como validará a encriptação em cada um destes ficheiros.
• Considere todo o conjunto de formas como a sua aplicação pode interagir com outras aplicações. Enumerar todos os pontos de entrada e saída. Que tipos de dados a sua aplicação pode ingerir? Que intenções transmite? Que fornecedores de conteúdos implementa?
  • Determine como irá exercer cada uma destas funcionalidades de partilha de dados.
  • Prepare um dispositivo de teste que tenha aplicações geridas e não geridas que possam interagir com a sua aplicação.
• Considere como a sua aplicação permite que o utilizador final interaja com todas as contas com sessão iniciada. O utilizador tem de mudar manualmente para uma conta antes de os dados dessa conta serem apresentados?

Depois de avaliar exaustivamente o comportamento atual da sua aplicação, valide a integração de várias identidades ao executar o seguinte conjunto de testes. Tenha em atenção que esta não é uma lista abrangente e não garante que a implementação de várias identidades da sua aplicação seja isenta de erros.

Validar cenários de início de sessão e fim de sessão

A sua aplicação de várias identidades suporta até uma conta gerida e várias contas não geridas. Estes testes ajudam a garantir que a integração de várias identidades não altera incorretamente as proteções quando os utilizadores iniciam sessão ou iniciam sessão.

Para estes testes, instale a sua aplicação e o Portal da Empresa do Intune; não inicie sessão antes de iniciar o teste.

Cenário	Etapas
Iniciar sessão gerido primeiro	- Inicie sessão primeiro com uma conta gerida e valide se os dados da conta são geridos. - Inicie sessão com uma conta não gerida e confirme que os dados da conta não são geridos.
Iniciar sessão sem gestão primeiro	- Inicie sessão primeiro com uma conta não gerida e confirme que os dados da conta não são geridos. - Inicie sessão com uma conta gerida e valide se os dados da conta são geridos.
Iniciar sessão em vários geridos	- Inicie sessão primeiro com uma conta gerida e valide se os dados da conta são geridos. - Inicie sessão com uma segunda conta gerida e confirme que o utilizador está impedido de iniciar sessão sem primeiro remover a conta gerida original.
Terminar sessão gerido	- Inicie sessão na sua aplicação com uma conta gerida não gerida. - Termine sessão na conta gerida. - Confirme que a conta gerida foi removida da sua aplicação e que todos os dados dessa conta foram removidos. - Confirme que a conta não gerida ainda tem sessão iniciada, que nenhum dos dados da conta não gerida foi removido e que a política ainda não foi aplicada.
Terminar sessão sem gestão	- Inicie sessão na sua aplicação com uma conta gerida não gerida. - Termine sessão na conta não gerida. - Confirme que a conta não gerida foi removida da sua aplicação e que todos os dados dessa conta foram removidos. - Confirme que a conta gerida ainda tem sessão iniciada, que nenhum dos dados da conta não gerida foi removido e que a política ainda é aplicada.

Validar a identidade ativa e o ciclo de vida das aplicações

A sua aplicação de várias identidades pode apresentar vistas com os dados de uma única conta e permitir que o utilizador altere explicitamente a conta atual em utilização. Também pode apresentar vistas com dados de várias contas ao mesmo tempo. Estes testes ajudam a garantir que a integração de várias identidades fornece as proteções adequadas para a identidade ativa em todas as páginas ao longo de todo o ciclo de vida da aplicação.

Para estes testes, instale a sua aplicação e o Portal da Empresa do Intune; inicie sessão com uma conta gerida e não gerida antes de iniciar o teste.

Cenário	Etapas
Vista de conta única, gerida	- Mudar para a conta gerida. - Navegue para todas as páginas na sua aplicação que apresentam os dados de uma única conta. - Confirme que a política é aplicada em todas as páginas.
Vista de conta única, não gerida	- Mudar para a conta não gerida. - Navegue para todas as páginas na sua aplicação que apresentam os dados de uma única conta. - Confirme que a política não é aplicada em nenhuma página.
Vista de várias contas	- Navegue para todas as páginas na sua aplicação que apresentam os dados de várias contas em simultâneo. - Confirme que a política é aplicada em todas as páginas.
Pausa gerida	- Num ecrã com dados geridos apresentados e a política ativa, coloque a aplicação em pausa ao navegar para o ecrã principal do dispositivo ou para outra aplicação. - Retomar a aplicação. - Confirme que a política ainda está aplicada.
Pausa não gerida	- Num ecrã com dados não geridos apresentados e sem política ativa, coloque a aplicação em pausa ao navegar para o ecrã principal do dispositivo ou para outra aplicação. - Retomar a aplicação. - Confirme que a política não foi aplicada.
Eliminação gerida	- Num ecrã com dados geridos apresentados e a política ativa, force a eliminação da aplicação. - Reinicie a aplicação. - Confirme que, se a aplicação for retomada num ecrã com os dados da conta gerida (esperado), a política continuará a ser aplicada. Se a aplicação for retomada num ecrã com os dados da conta não gerida, confirme que a política não foi aplicada.
Eliminação não gerida	- Num ecrã com dados não geridos apresentados e a política ativa, force a eliminação da aplicação. - Reinicie a aplicação. - Confirme que, se a aplicação for retomada num ecrã com os dados da conta não gerida (esperado), a política não será aplicada. Se a aplicação for retomada num ecrã com os dados da conta gerida, confirme que a política ainda está aplicada.
Comutador de identidade ad hoc	- Experimente alternar entre contas e colocar em pausa/retomar/eliminar/reiniciar a aplicação. - Confirme que os dados da conta gerida estão sempre protegidos e que os dados da conta não gerida nunca são protegidos.

Validar cenários de partilha de dados

A sua aplicação de várias identidades pode enviar dados para e receber dados de outras aplicações. As políticas de proteção de aplicações do Intune têm definições que ditam este comportamento. Estes testes ajudam a garantir que a sua integração de identidades múltiplas honra estas definições de partilha de dados.

Para estes testes, instale a sua aplicação e o Portal da Empresa do Intune; inicie sessão com uma conta gerida e não gerida antes de iniciar o teste. Além disso:

• Defina a política da conta gerida como:
  • "Enviar dados da organização para outras aplicações" para "Aplicações geridas por políticas".
  • "Receber dados de outras aplicações" para "Aplicações geridas por políticas".
• Instale outras aplicações no dispositivo de teste:
  • Uma aplicação gerida, direcionada com a mesma política que a sua aplicação, que pode enviar e receber dados (como o Microsoft Outlook).
  • Qualquer aplicação não gerida que possa enviar e receber dados.
• Inicie sessão na outra aplicação gerida com a conta de teste gerida. Mesmo que a outra aplicação gerida seja de várias identidades, inicie sessão apenas com a conta gerida.

Se a sua aplicação tiver a capacidade de enviar dados para outras aplicações, como o Microsoft Outlook enviar um anexo de documento para o Microsoft Office:

Cenário	Etapas
A identidade gerida é enviada para uma aplicação não gerida	- Mudar para a conta gerida. - Navegue para onde a sua aplicação pode enviar dados. - Tentar enviar dados para uma aplicação não gerida. - Deve ser impedido de enviar dados para a aplicação não gerida.
Envio de identidade gerida para a aplicação gerida	- Mudar para a conta gerida. - Navegue para onde a sua aplicação pode enviar dados. - Tente enviar dados para a outra aplicação gerida com a conta gerida com sessão iniciada. - Deve ter permissão para enviar dados para a aplicação gerida.
Envio de identidade não gerida para a aplicação gerida	- Mudar para a conta não gerida. - Navegue para onde a sua aplicação pode enviar dados. - Tente enviar dados para a outra aplicação gerida com a conta gerida com sessão iniciada. - Deve ser impedido de enviar dados para a outra aplicação gerida.
Envio de identidade não gerida para a aplicação não gerida	- Mudar para a conta não gerida. - Navegue para onde a sua aplicação pode enviar dados. - Tentar enviar dados para uma aplicação não gerida. - Deve ter sempre permissão para enviar dados de uma conta não gerida para uma aplicação não gerida.

A sua aplicação pode importar ativamente dados de outras aplicações, como o Microsoft Outlook anexar um ficheiro do Microsoft OneDrive. A sua aplicação também pode receber dados passivos de outras aplicações, como o Microsoft Office abrir um documento a partir de um anexo do Microsoft Outlook. A definição da política de proteção de aplicações de receção abrange ambos os cenários.

Se a sua aplicação tiver a capacidade de importar ativamente dados de outras aplicações:

Cenário	Etapas
Importação de identidade gerida a partir de uma aplicação não gerida	- Mudar para a conta gerida. - Navegue para onde a sua aplicação pode importar dados de outras aplicações. - Tentar importar dados de uma aplicação não gerida. - Deve ser impedido de importar dados de aplicações não geridas.
Importação de identidade gerida da aplicação gerida	- Mudar para a conta gerida. - Navegue para onde a sua aplicação pode importar dados de outras aplicações. - Tente importar dados da outra aplicação gerida com a conta gerida com sessão iniciada. - Deve ter permissão para importar dados da outra aplicação gerida.
Importação de identidade não gerida da aplicação gerida	- Mudar para a conta não gerida. - Navegue para onde a sua aplicação pode importar dados de outras aplicações. - Tente importar dados da outra aplicação gerida com a conta gerida com sessão iniciada. - Deve ser impedido de importar dados da outra aplicação gerida.
Importação de identidade não gerida da aplicação não gerida	- Mudar para a conta não gerida. - Navegue para onde a sua aplicação pode importar dados de outras aplicações. - Tentar importar dados de uma aplicação não gerida. - Deve ter sempre permissão para importar dados de uma aplicação não gerida para uma conta não gerida.

Se a sua aplicação tiver a capacidade de receber dados passivamente de outras aplicações:

Cenário	Etapas
A identidade gerida recebe de uma aplicação não gerida	- Mudar para a conta gerida. - Mudar para a aplicação não gerida. - Navegue para onde pode enviar dados. - Tente enviar dados da aplicação não gerida para a sua aplicação. - A conta gerida da sua aplicação não deve conseguir receber dados da aplicação não gerida.
A identidade gerida recebe da aplicação gerida	- Mudar para a conta gerida. - Mude para a outra aplicação gerida com a conta gerida com sessão iniciada. - Navegue para onde pode enviar dados. - Tente enviar dados da aplicação gerida para a sua aplicação. - A conta gerida da sua aplicação deve ter permissão para receber dados da outra aplicação gerida.
A identidade não gerida recebe da aplicação gerida	- Mudar para a conta não gerida. - Mude para a outra aplicação gerida com a conta gerida com sessão iniciada. - Navegue para onde pode enviar dados. - Tente enviar dados da aplicação gerida para a sua aplicação. - A conta não gerida da sua aplicação não deve conseguir receber dados da aplicação gerida.
A identidade não gerida recebe da aplicação não gerida	- Mudar para a conta não gerida. - Mudar para a aplicação não gerida. - Navegue para onde pode enviar dados. - Tente enviar dados da aplicação não gerida para a sua aplicação. - A conta não gerida da sua aplicação deve ter sempre permissão para receber dados da aplicação não gerida.

As falhas nestes testes podem indicar que a sua aplicação não tem a identidade ativa correta definida quando tenta enviar ou receber dados. Pode investigar esta situação ao tirar partido das APIs de identidade de obtenção do SDK no ponto de envio/receção para confirmar que a identidade ativa está definida corretamente.

Validar cenários de eliminação seletiva

A sua aplicação de várias identidades pode ter complementado ou substituído o comportamento de eliminação predefinido do SDK. Estes testes ajudam a garantir que a integração de várias identidades remove corretamente os dados geridos quando as eliminações são iniciadas, sem afetar os dados não geridos.

Aviso

Lembrete: se a aplicação tiver aproveitado MAMDataProtectionManager.protect, tem de implementar um processador para ou WIPE_USER_AUXILIARY_DATAWIPE_USER_DATA.

Para estes testes, instale a sua aplicação e o Portal da Empresa do Intune; inicie sessão com uma conta gerida e não gerida antes de iniciar o teste. Para ambas as contas, cenários de aplicações de exercício que armazenam dados de conta.

Cenário	Pré-condições	Etapas
Processador de eliminação suplementar	A sua aplicação implementou um processador para WIPE_USER_AUXILIARY_DATA	- Emita uma eliminação seletiva do centro de administração do Microsoft Intune. - Confirme (normalmente através do registo) que o processador de eliminação foi executado com êxito. - Confirme que a conta gerida foi removida da sua aplicação e que todos os dados dessa conta foram removidos. - Confirme que a conta não gerida ainda tem sessão iniciada, que nenhum dos dados da conta não gerida foi removido e que a política ainda não foi aplicada.
Substituir processador de eliminação	A sua aplicação implementou um processador para WIPE_USER_DATA	- Emita uma eliminação seletiva do centro de administração do Microsoft Intune. - Confirme (normalmente através do registo) que o processador de eliminação foi executado com êxito. - Confirme que a conta gerida foi removida da sua aplicação e que todos os dados dessa conta foram removidos. - Confirme que a conta não gerida ainda tem sessão iniciada, que nenhum dos dados da conta não gerida foi removido e que a política ainda não foi aplicada. - Confirme que a sua aplicação saiu corretamente ou ainda está em bom estado de funcionamento após a conclusão do processador de eliminação.
Proteção manual de ficheiros	- As chamadas à sua aplicação MAMFileProtectionManager.protect - A sua aplicação implementou um processador para WIPE_USER_DATA	- Certifique-se de que exerceu cenários em que a sua aplicação protegeria manualmente, pelo menos, um ficheiro pertencente à conta gerida. - Emita uma eliminação seletiva do centro de administração do Microsoft Intune. - Confirme que os ficheiros foram removidos.
Proteção manual da memória intermédia de dados	- As chamadas à sua aplicação MAMDataProtectionManager.protect - A sua aplicação implementou um processador para ou WIPE_USER_AUXILIARY_DATAWIPE_USER_DATA	- Certifique-se de que tem cenários exercidos em que a sua aplicação protegeria manualmente, pelo menos, uma memória intermédia de dados pertencente à conta gerida. - Emita uma eliminação seletiva do centro de administração do Microsoft Intune. - Confirme que as memórias intermédias de dados são removidas dos ficheiros em que foram armazenadas e que a sua aplicação ainda pode ler os dados não geridos desses ficheiros.

Próximas etapas

Depois de concluir todos os Critérios de Saída acima, a sua aplicação é agora integrada com êxito como várias identidades e pode impor políticas de proteção de aplicações por identidade. As secções subsequentes, Fase 6: Configuração da Aplicação e Fase 7: Funcionalidades de Participação da Aplicação, podem ou não ser necessárias, dependendo do suporte de política de proteção de aplicações pretendido da sua aplicação. Se não tiver a certeza se alguma destas secções se aplica à sua aplicação, reveja As Decisões-Chave para a integração do SDK.