SDK do Aplicativo do Intune para iOS - Várias Identidades

Etapa 5: Identidade múltipla (opcional)

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

O aplicativo deve informar ao 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 principal. 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. As identidades não diferenciam maiúsculas de minúsculas. As solicitações para o SDK para uma identidade podem não retornar o mesmo uso de maiúsculas e minúsculas que foi originalmente usado quando a identidade foi definida.

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.

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 do 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 às tarefas da interface do usuário no thread principal, como cortar/copiar/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 do 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, independentemente de o usuário ser gerenciado ou não.

A qualquer momento, cada thread tem uma identidade efetiva 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 "sem identidade" ou se o usuário não for gerenciado, nenhuma política será aplicada. Os diagramas a seguir mostram como as identidades efetivas são determinadas.

Filas de threads

Os aplicativos geralmente despacham tarefas assíncronas e síncronas para filas de thread. O SDK intercepta chamadas do GCD (Grand Central Dispatch) e associa a identidade do 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 original do thread.

Como NSOperationQueue é criado sobre o GCD, NSOperations será executado na identidade do thread no momento em que as tarefas são adicionadas ao NSOperationQueue. NSOperations ou expedidas diretamente por meio do GCD também podem alterar a identidade do thread atual enquanto estão em execução. Essa identidade substituirá a identidade herdada do thread de expedição.

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

Proprietário do arquivo

O SDK rastreia as identidades dos proprietários de arquivos locais e aplica políticas de acordo. O proprietário de um arquivo é estabelecido quando um arquivo é criado ou quando é aberto no modo truncado. O proprietário é definido como a identidade efetiva da tarefa de arquivo 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 que tenham dados de usuários gerenciados e não gerenciados, ele 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.

Extensões de compartilhamento

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 cuidará da 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 persistirem em um arquivo e por chamar a setUIPolicyAccountId API antes de mostrar esses dados na interface do usuário.

Ativar várias identidades

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

Alternar identidades

• Opção de identidade iniciada pelo aplicativo:

  No lançamento, 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 de 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 bloco de anotações. 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 setUIPolicyAccountId API no IntuneMAMPolicyManager. Essa API deve ser chamada independentemente de o usuário ser gerenciado ou não. Se o usuário for gerenciado, o SDK executará as verificações de inicialização condicional, como detecção de jailbreak, PIN e autenticação.

  O resultado da troca 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 sucesso seja retornado. Se a troca de identidade falhar, o aplicativo deverá cancelar a tarefa.

  Os aplicativos de identidade múltipla devem evitar o uso setProcessAccountId como uma maneira de definir a identidade. Os aplicativos que usam UIScenes devem usar a setUIPolicyAccountId:forWindow API para definir a identidade.

  Os aplicativos também podem definir a identidade para o 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 setCurrentThreadAccountId:, o aplicativo também deverá usar getCurrentThreadAccountId para que possa restaurar a identidade original depois de concluído. No entanto, se o aplicativo usar setCurrentThreadAccountId:forScope: , a restauração da identidade antiga ocorrerá automaticamente. É preferível usar setCurrentThreadAccountId:forScope:.

  Em swift, devido a async/await [IntuneMAMPolicyManager setCurrentThreadAccountId:] e [IntuneMAMPolicyManager setCurrentThreadAccountId:forScope:] não estão disponíveis. Em vez disso, em swift para definir o uso IntuneMAMSwiftContextManager.setAccountId(_, forScope:)de identidade atual. Há variantes dessa API para fechamentos assíncronos, de lançamento e de lançamento assíncrono 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. Os aplicativos de várias identidades devem implementar o identitySwitchRequiredForAccountId método para IntuneMAMPolicyDelegate lidar com essa solicitação.

  Quando esse método for chamado, se o aplicativo puder lidar com 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 mudança da identidade, o aplicativo deverá passar IntuneMAMAddIdentityResultFailed para o manipulador de conclusão.

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

• Registro automático de identidade iniciada 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 deverá 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 wipeDataForAccountId método em IntuneMAMPolicyDelegate. O aplicativo é responsável por remover a conta do usuário especificado e todos os dados associados a ela. O SDK é capaz de remover todos os arquivos pertencentes ao usuário e fará isso se o aplicativo retornar FALSE da wipeDataForAccountId 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 tenham sido removidos (com exceção de arquivos, se o aplicativo retornar FALSE).

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 não AAD existente 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 em um dispositivo de teste; Não faça login antes de iniciar o teste.

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 em um dispositivo de teste; Faça login com uma conta gerenciada e não gerenciada antes de iniciar o teste.

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 em um dispositivo de teste; Faça login 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:

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:

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

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.

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: suporte de acesso condicional de proteção de aplicativo e Estágio 7: recursos de exibição da Web, podem ou não ser necessários, dependendo do suporte à política de proteção de aplicativo desejado do aplicativo.