SDK do aplicativo do Intune para iOS – Multi-Identity

Observação

Este guia é dividido em vários estágios distintos. Comece examinando a Fase 1: Planeje a Integração.

Estágio 5: Multi-Identidade (opcional)

Por padrão, o SDK aplica uma política ao aplicativo como um todo. A multi-identidade é um recurso MAM que você pode habilitar para aplicar uma política em um nível por identidade. Isso requer mais participação do aplicativo do que outros recursos de MAM.

O aplicativo deve informar o SDK do aplicativo quando pretende alterar a identidade ativa. O SDK também notifica o aplicativo quando uma alteração de identidade é necessária. Atualmente, há suporte para apenas uma identidade gerenciada. Depois que o usuário registra o dispositivo ou o aplicativo, o SDK usa essa identidade e a considera a identidade gerenciada primária. Outros usuários no aplicativo serão tratados como não gerenciados com configurações de política irrestritas.

Observe que uma identidade é simplesmente definida como uma cadeia de caracteres. Identidades são insensíveis a casos. As solicitações ao SDK para uma identidade podem não retornar o mesmo invólucro que foi originalmente usado quando a identidade foi definida.

Goals de estágio

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

Visão geral da identidade

Uma identidade é simplesmente o nome de usuário de uma conta (por exemplo, user@contoso.com). Os desenvolvedores podem definir a identidade do aplicativo nos seguintes níveis:

• Identidade de processo: define a identidade em todo o processo e é usada principalmente para aplicativos de identidade única. Essa identidade afeta todas as tarefas, arquivos e interface do usuário.

• Identidade da interface do usuário: determina quais políticas são aplicadas a tarefas da interface do usuário no thread main, como corte/cópia/colar, PIN, autenticação e compartilhamento de dados. A identidade da interface do usuário não afeta tarefas de arquivo, como criptografia e backup.

• Identidade de thread: afeta quais políticas são aplicadas no thread atual. Essa identidade afeta todas as tarefas, arquivos e interface do usuário.

O aplicativo é responsável por definir as identidades adequadamente, se o usuário é gerenciado ou não.

A qualquer momento, cada thread tem uma identidade eficaz para tarefas de interface do usuário e tarefas de arquivo. Essa é a identidade usada para marcar quais políticas, se houver, devem ser aplicadas. Se a identidade for "nenhuma identidade" ou o usuário não for gerenciado, nenhuma política será aplicada. Os diagramas abaixo mostram como as identidades efetivas são determinadas.

Filas de thread

Os aplicativos geralmente despacham tarefas assíncronas e síncronas para filas de thread. O SDK intercepta chamadas do Grand Central Dispatch (GCD) e associa a identidade de thread atual às tarefas expedidas. Quando as tarefas são concluídas, o SDK altera temporariamente a identidade do thread para a identidade associada às tarefas, conclui as tarefas e restaura a identidade de thread original.

Como NSOperationQueue é criado em cima do GCD, NSOperations será executado na identidade do thread no momento em que as tarefas forem adicionadas a NSOperationQueue. NSOperations ou as funções enviadas diretamente por meio do GCD também podem alterar a identidade do thread atual à medida que estão em execução. Essa identidade substituirá a identidade herdada do thread de expedição.

Rapidamente, devido a uma consequência de como o SDK propaga identidades para DispatchWorkItem, a identidade associada a um DispatchWorkItem é a identidade do thread que criou o item e não o thread que o despacha.

Proprietário do arquivo

O SDK rastreia as identidades dos proprietários de arquivos locais e aplica as políticas de acordo. Um proprietário de arquivo é estabelecido quando um arquivo é criado ou quando um arquivo é aberto no modo truncado. O proprietário está definido como a identidade de tarefa de arquivo eficaz do thread que está executando a tarefa.

Como alternativa, os aplicativos podem definir a identidade do proprietário do arquivo explicitamente usando IntuneMAMFilePolicyManager. Os aplicativos podem usar IntuneMAMFilePolicyManager para recuperar o proprietário do arquivo e definir a identidade da interface do usuário antes de mostrar o conteúdo do arquivo.

Dados compartilhados

Se o aplicativo criar arquivos com dados de usuários gerenciados e não gerenciados, o aplicativo será responsável por criptografar os dados do usuário gerenciado. Você pode criptografar dados usando as protect APIs e unprotect no IntuneMAMDataProtectionManager.

O protect método aceita uma identidade que pode ser um usuário gerenciado ou não gerenciado. Se o usuário for gerenciado, os dados serão criptografados. Se o usuário não for gerenciado, um cabeçalho será adicionado aos dados que estão codificando a identidade, mas os dados não serão criptografados. Você pode usar o protectionInfo método para recuperar o proprietário dos dados.

Compartilhar extensões

Se o aplicativo tiver uma extensão de compartilhamento, o proprietário do item que está sendo compartilhado poderá ser recuperado por meio do protectionInfoForItemProvider método em IntuneMAMDataProtectionManager. Se o item compartilhado for um arquivo, o SDK tratará a configuração do proprietário do arquivo. Se o item compartilhado for dados, o aplicativo será responsável por definir o proprietário do arquivo se esses dados forem mantidos em um arquivo e por chamar a setUIPolicyIdentity API antes de mostrar esses dados na interface do usuário.

Ativar várias identidades

Por padrão, os aplicativos são considerados identidade única. O SDK define a identidade do processo para o usuário registrado. Para habilitar o suporte a várias identidades, adicione uma configuração booliana com o nome MultiIdentity e um valor DE SIM ao dicionário IntuneMAMSettings no arquivo Info.plist do aplicativo.

Observação

Quando várias identidades estão habilitadas, a identidade do processo, a identidade da interface do usuário e as identidades de thread são definidas como zero. O aplicativo é responsável por defini-los adequadamente.

Alternar identidades

• Opção de identidade iniciada pelo aplicativo:

  No início, os aplicativos de várias identidades são considerados em execução em uma conta desconhecida e não gerenciada. A interface do usuário de inicialização condicional não será executada e nenhuma política será imposta no aplicativo. O aplicativo é responsável por notificar o SDK sempre que a identidade deve ser alterada. Normalmente, isso acontecerá sempre que o aplicativo estiver prestes a mostrar dados para uma conta de usuário específica.

  Um exemplo é quando o usuário tenta abrir um documento, uma caixa de correio ou uma guia em um notebook. O aplicativo precisa notificar o SDK antes que o arquivo, a caixa de correio ou a guia seja realmente aberto. Isso é feito por meio da setUIPolicyIdentity API em IntuneMAMPolicyManager. Essa API deve ser chamada se o usuário é gerenciado ou não. Se o usuário for gerenciado, o SDK executará as verificações de inicialização condicionais, como detecção de jailbreak, PIN e autenticação.

  O resultado da opção de identidade é retornado ao aplicativo de forma assíncrona por meio de um manipulador de conclusão. O aplicativo deve adiar a abertura do documento, caixa de correio ou guia até que um código de resultado de êxito seja retornado. Se a opção de identidade falhar, o aplicativo deverá cancelar a tarefa.

  Aplicativos de várias identidades devem evitar o uso setProcessIdentity como uma forma de definir a identidade. Os aplicativos que usam UIScenes devem usar a setUIPolicyIdentity:forWindow API para definir a identidade.

  Os aplicativos também podem definir a identidade do thread atual usando setCurrentThreadIdentity: e setCurrentThreadIdentity:forScope:. Por exemplo, o aplicativo pode gerar um thread em segundo plano, definir a identidade como a identidade gerenciada e, em seguida, executar operações de arquivo em arquivos gerenciados. Se o aplicativo usar setCurrentThreadIdentity:, o aplicativo também deverá ser usado getCurrentThreadIdentity para que ele possa restaurar a identidade original depois de concluído. No entanto, se o aplicativo usar setCurrentThreadIdentity:forScope: , a restauração da identidade antiga ocorrerá automaticamente. É preferível usar setCurrentThreadIdentity:forScope:.

  Rapidamente, devido a assíncrona/aguardada, [IntuneMAMPolicyManager setCurrentThreadIdentity:] e [IntuneMAMPolicyManager setCurrentThreadIdentity:forScope:] não estão disponíveis. Em vez disso, rapidamente para definir o uso IntuneMAMSwiftContextManager.setIdentity(_, forScope:)atual da identidade . Há variantes dessa API para fechamentos assíncronos, de lançamento e de lançamento assíncronos a serem passados.

• Opção de identidade iniciada pelo SDK:

  Às vezes, o SDK precisa pedir ao aplicativo para mudar para uma identidade específica. Aplicativos de várias identidades devem implementar o identitySwitchRequired método IntuneMAMPolicyDelegate para lidar com essa solicitação.

  Quando esse método for chamado, se o aplicativo puder manipular a solicitação para alternar para a identidade especificada, ele deverá passar IntuneMAMAddIdentityResultSuccess para o manipulador de conclusão. Se ele não puder lidar com a comutação da identidade, o aplicativo deverá passar IntuneMAMAddIdentityResultFailed para o manipulador de conclusão.

  O aplicativo não precisa chamar setUIPolicyIdentity em resposta a essa chamada. Se o SDK precisar que o aplicativo mude para uma conta de usuário não gerenciada, a cadeia de caracteres vazia será passada para a identitySwitchRequired chamada.

• Registro automático de identidade iniciado pelo SDK:

  Quando o SDK precisa registrar automaticamente um usuário no aplicativo para executar uma ação, os aplicativos devem implementar o addIdentity:completionHandler: método no IntuneMAMPolicyDelegate. Em seguida, o aplicativo deve chamar o manipulador de conclusão e passar intuneMAMAddIdentityResultSuccess se o aplicativo for capaz de adicionar a identidade ou IntuneMAMAddIdentityResultFailed caso contrário.

• Apagamento seletivo:

  Quando o aplicativo for apagado seletivamente, o SDK chamará o wipeDataForAccount método em IntuneMAMPolicyDelegate. O aplicativo é responsável por remover a conta do usuário especificada e todos os dados associados a ele. O SDK é capaz de remover todos os arquivos pertencentes ao usuário e o fará se o aplicativo retornar FALSE da wipeDataForAccount chamada.

  Observe que esse método é chamado de um thread em segundo plano. O aplicativo não deve retornar um valor até que todos os dados do usuário sejam removidos (com exceção dos arquivos, se o aplicativo retornar FALSE).

Critérios de saída

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

• Crie e atribua a política de proteção de aplicativo a uma conta. Essa será sua conta gerenciada por teste.
• Crie, mas não atribua a política de proteção de aplicativo a outra conta. Essa será sua conta não gerenciada de teste. Como alternativa, se o aplicativo der suporte a vários tipos de conta além de contas Microsoft Entra, você poderá usar uma conta não AAD existente como a conta de teste não gerenciada.
• Refamiliarize-se com a forma como a política é imposta dentro de seu aplicativo. O teste de várias identidades exige que você distingue facilmente quando seu aplicativo está e não está operando com a política imposta. A configuração da política de proteção de aplicativo para bloquear capturas de tela é eficaz em testar rapidamente a aplicação da política.
• Considere todo o conjunto de ofertas de interface do usuário do aplicativo. Enumera as telas em que os dados da conta são exibidos. Seu aplicativo 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 arquivos que seu aplicativo cria. Enumera 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. Enumera todos os pontos de entrada e saída. Quais tipos de dados seu aplicativo pode ingerir? Que intenções ele transmite? Quais provedores de conteúdo ele implementa?
  • Determine como você exercerá 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 registradas. O usuário precisa alternar manualmente para uma conta antes que os dados dessa conta sejam exibidos?

Depois de avaliar completamente o comportamento atual do aplicativo, valide a integração de várias identidades executando o seguinte conjunto de testes. Observe que essa não é uma lista abrangente e não garante que a implementação de várias identidades do aplicativo seja livre de bugs.

Validando cenários de logon e logon

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 a integração de várias identidades não altere incorretamente as proteções quando os usuários fazem logon ou logon.

Para esses testes, instale seu aplicativo em um dispositivo de teste; não faça logon antes de iniciar o teste.

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

Validando a identidade ativa e o ciclo de vida do aplicativo

Seu aplicativo de várias identidades pode apresentar exibições com 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 com várias identidades forneça as proteções corretas para a identidade ativa em cada página durante todo o ciclo de vida do aplicativo.

Para esses testes, instale seu aplicativo em um dispositivo de teste; 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	- Alternar para a conta gerenciada. – Navegue até todas as páginas do aplicativo que apresentam os dados de uma única conta. - Confirme se a política é aplicada em cada página.
Exibição de conta única, não gerenciada	- Alterne para a conta não gerenciada. – Navegue até todas as páginas do 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 até todas as páginas do aplicativo que apresentam dados de várias contas simultaneamente. - Confirme se a política é aplicada em cada página.
Pausa gerenciada	- Em uma tela com dados gerenciados exibidos e política ativa, pausa 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 sem política ativa, pausa o aplicativo navegando até a tela inicial do dispositivo ou outro aplicativo. – Retome o aplicativo. - Confirme se a política não está aplicada.
Morte gerenciada	- Em uma tela com dados gerenciados exibidos e política ativa, force a morte do aplicativo. – Reinicie o aplicativo. - Confirme se, se o aplicativo for retomado em uma tela com os dados da conta gerenciada (esperados), a política ainda será aplicada. Se o aplicativo for retomado em uma tela com os dados da conta não gerenciada, confirme se essa política não é aplicada.
Morte não gerenciada	- Em uma tela com dados não gerenciados exibidos e política ativa, force a morte do aplicativo. – Reinicie o aplicativo. - Confirme se, se o aplicativo for retomado em uma tela com os dados da conta não gerenciada (esperados), 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 será aplicada.
Ad hoc do comutador de identidade	– Experimente alternar entre contas e pausar/retomar/matar/reiniciar o aplicativo. - Confirme se os dados da conta gerenciada estão sempre protegidos e que os dados da conta não gerenciada nunca são protegidos.

Validando cenários de compartilhamento de dados

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

Para esses testes, instale seu aplicativo em um dispositivo de teste; 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íticas".
  • "Receber dados de outros aplicativos" para "Aplicativos gerenciados por políticas".
• 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 seja de várias identidades, faça logon apenas 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	- Alternar 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	- Alternar para a conta gerenciada. – Navegue até onde seu aplicativo pode enviar dados. – Tente enviar dados para o outro aplicativo gerenciado com a conta gerenciada inserida. - Você deve ter permissão para enviar dados para o aplicativo gerenciado.
Envio de identidade não gerenciada para o 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 inserida. - Você deve ser impedido de enviar dados para o outro aplicativo gerenciado.
Identidade não gerenciada enviada 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 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 da política de proteção de aplicativo de recebimento abrange ambos os 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	- Alternar 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	- Alternar 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 inserida. - 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 inserida. - 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 seu aplicativo tiver a capacidade de receber passivamente dados de outros aplicativos:

Cenário	Etapas
A identidade gerenciada recebe do aplicativo não gerenciado	- Alternar para a conta gerenciada. - Alternar para o aplicativo não gerenciado. – Navegue até onde pode enviar dados. – Tente enviar dados do aplicativo não gerenciado para seu aplicativo. - A conta gerenciada do aplicativo não deve ser capaz de receber dados do aplicativo não gerenciado.
A identidade gerenciada recebe do aplicativo gerenciado	- Alternar para a conta gerenciada. - Alternar para o outro aplicativo gerenciado com a conta gerenciada insirada. – Navegue até onde pode enviar dados. – Tente enviar dados do aplicativo gerenciado para seu aplicativo. – A conta gerenciada do seu aplicativo deve ser autorizada a receber dados do outro aplicativo gerenciado.
Identidade não gerenciada recebe do aplicativo gerenciado	- Alterne para a conta não gerenciada. - Alternar para o outro aplicativo gerenciado com a conta gerenciada insirada. – Navegue até onde pode enviar dados. – Tente enviar dados do aplicativo gerenciado para seu aplicativo. - A conta não gerenciada do aplicativo não deve ser capaz de receber dados do aplicativo gerenciado.
Identidade não gerenciada recebe de aplicativo não gerenciado	- Alterne para a conta não gerenciada. - Alternar para o aplicativo não gerenciado. – Navegue até onde pode enviar dados. – Tente enviar dados do aplicativo não gerenciado para seu aplicativo. - A conta não gerenciada do aplicativo deve sempre ser autorizada a receber dados do aplicativo não gerenciado.

Falhas nesses testes podem indicar que seu aplicativo não tem o conjunto de identidade ativo certo quando tenta enviar ou receber dados. Você pode investigar isso aproveitando as APIs de identidade get do SDK no ponto de envio/recebimento para confirmar se a identidade ativa está definida corretamente.

Próximas etapas

Depois de concluir todos os Critérios de Saída acima, seu aplicativo agora é integrado com êxito como multi-identidade e pode impor políticas de proteção de aplicativo por identidade. As seções subsequentes, Estágio 6: Suporte ao Acesso Condicional da Proteção de Aplicativo e Estágio 7: recursos de exibição da Web podem ou não ser necessários, dependendo do suporte desejado da política de proteção de aplicativo do aplicativo.