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

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 (opcional)

Por predefinição, o SDK aplica uma política à aplicação como um todo. A identidade múltipla é uma funcionalidade de MAM que pode ativar para aplicar uma política a um nível por identidade. Isto requer mais participação da aplicação do que outras funcionalidades de MAM.

A aplicação tem de informar o SDK da aplicação quando pretende alterar a identidade ativa. O SDK também notifica a aplicação quando é necessária uma alteração de identidade. Atualmente, só é suportada uma identidade gerida. Depois de o utilizador inscrever o dispositivo ou a aplicação, o SDK utiliza esta identidade e considera-a a identidade gerida principal. Os outros utilizadores na aplicação serão tratados como não geridos com definições de política sem restrições.

Tenha em atenção que uma identidade é simplesmente definida como uma cadeia. 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 originalmente utilizada quando a identidade foi definida.

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.

Descrição geral da identidade

Uma identidade é simplesmente o nome de utilizador de uma conta (por exemplo, user@contoso.com). Os programadores podem definir a identidade da aplicação nos seguintes níveis:

• Identidade do processo: define a identidade ao nível do processo e é utilizada principalmente para aplicações de identidade única. Esta identidade afeta todas as tarefas, ficheiros e IU.

• Identidade da IU: determina que políticas são aplicadas a tarefas de IU no thread principal, como cortar/copiar/colar, PIN, autenticação e partilha de dados. A identidade da IU não afeta tarefas de ficheiro, como encriptação e cópia de segurança.

• Identidade do thread: afeta as políticas que são aplicadas no thread atual. Esta identidade afeta todas as tarefas, ficheiros e IU.

A aplicação é responsável por definir as identidades adequadamente, quer o utilizador seja ou não gerido.

Em qualquer altura, cada thread tem uma identidade eficaz para tarefas de IU e tarefas de ficheiro. Esta é a identidade utilizada para verificar que políticas, se existirem, devem ser aplicadas. Se a identidade for "sem identidade" ou se o utilizador não for gerido, não serão aplicadas políticas. Os diagramas abaixo mostram como as identidades efetivas são determinadas.

Filas de threads

Muitas vezes, as aplicações distribuem tarefas assíncronas e síncronas para filas de threads. O SDK interceta chamadas do Grand Central Dispatch (GCD) e associa a identidade de thread atual às tarefas enviadas. Quando as tarefas estiverem concluídas, o SDK altera temporariamente a identidade do thread para a identidade associada às tarefas, termina as tarefas e, em seguida, restaura a identidade do thread original.

Uma NSOperationQueue vez que é criado com base no GCD, NSOperations será executado na identidade do thread no momento em que as tarefas são adicionadas ao NSOperationQueue. NSOperations ou as funções enviadas diretamente através do GCD também podem alterar a identidade do thread atual à medida que estão em execução. Esta identidade substituirá a identidade herdada do thread de distribuição.

Rapidamente, devido a uma consequência da forma 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 distribui.

Proprietário do ficheiro

O SDK controla as identidades dos proprietários de ficheiros locais e aplica as políticas em conformidade. Um proprietário de ficheiro é estabelecido quando um ficheiro é criado ou quando um ficheiro é aberto no modo de truncado. O proprietário está definido para a identidade de tarefa de ficheiro efetiva do thread que está a executar a tarefa.

Em alternativa, as aplicações podem definir explicitamente a identidade do proprietário do ficheiro com IntuneMAMFilePolicyManager. As aplicações podem utilizar IntuneMAMFilePolicyManager para obter o proprietário do ficheiro e definir a identidade da IU antes de mostrar o conteúdo do ficheiro.

Dados partilhados

Se a aplicação criar ficheiros com dados de utilizadores geridos e não geridos, a aplicação é responsável por encriptar os dados do utilizador gerido. Pode encriptar dados com as protect APIs e unprotect no IntuneMAMDataProtectionManager.

O protect método aceita uma identidade que pode ser um utilizador gerido ou não gerido. Se o utilizador for gerido, os dados serão encriptados. Se o utilizador não for gerido, será adicionado um cabeçalho aos dados que estão a codificar a identidade, mas os dados não serão encriptados. Pode utilizar o protectionInfo método para obter o proprietário dos dados.

Partilhar extensões

Se a aplicação tiver uma extensão de partilha, o proprietário do item que está a ser partilhado pode ser obtido através do protectionInfoForItemProvider método em IntuneMAMDataProtectionManager. Se o item partilhado for um ficheiro, o SDK processará a definição do proprietário do ficheiro. Se o item partilhado for dados, a aplicação é responsável por definir o proprietário do ficheiro se estes dados persistirem num ficheiro e por chamar a setUIPolicyAccountId API antes de mostrar estes dados na IU.

Ativar várias identidades

Por predefinição, as aplicações são consideradas identidade única. O SDK define a identidade do processo para o utilizador inscrito. Para ativar o suporte de várias identidades, adicione uma definição Booleana com o nome MultiIdentity e um valor de SIM ao dicionário IntuneMAMSettings no ficheiro Info.plist da aplicação.

Observação

Quando a identidade múltipla está ativada, a identidade do processo, a identidade da IU e as identidades de thread são definidas como nulas. A aplicação é responsável por defini-las adequadamente.

Mudar de identidade

• Comutador de identidade iniciado pela aplicação:

  No início, as aplicações de várias identidades são consideradas como estando em execução numa conta desconhecida e não gerida. A IU de início condicional não será executada e não serão impostas políticas na aplicação. A aplicação é responsável por notificar o SDK sempre que a identidade deve ser alterada. Normalmente, isto acontece sempre que a aplicação está prestes a mostrar dados para uma conta de utilizador específica.

  Um exemplo é quando o utilizador tenta abrir um documento, uma caixa de correio ou um separador num bloco de notas. A aplicação tem de notificar o SDK antes de o ficheiro, a caixa de correio ou o separador serem realmente abertos. Isto é feito através da setUIPolicyAccountId API no IntuneMAMPolicyManager. Esta API deve ser chamada quer o utilizador seja ou não gerido. Se o utilizador for gerido, o SDK efetuará as verificações de iniciação condicional, como a deteção de jailbreak, o PIN e a autenticação.

  O resultado do comutador de identidade é devolvido à aplicação de forma assíncrona através de um processador de conclusão. A aplicação deve adiar a abertura do documento, da caixa de correio ou do separador até que seja devolvido um código de resultado de êxito. Se o comutador de identidade tiver falhado, a aplicação deverá cancelar a tarefa.

  As aplicações de várias identidades devem evitar utilizar setProcessAccountId como forma de definir a identidade. As aplicações que utilizam UIScenes devem utilizar a setUIPolicyAccountId:forWindow API para definir a identidade.

  As aplicações também podem definir a identidade para o thread atual com setCurrentThreadIdentity: e setCurrentThreadIdentity:forScope:. Por exemplo, a aplicação pode gerar um thread em segundo plano, definir a identidade para a identidade gerida e, em seguida, realizar operações de ficheiros em ficheiros geridos. Se a aplicação utilizar setCurrentThreadAccountId:, a aplicação também deve utilizar getCurrentThreadAccountId para que possa restaurar a identidade original assim que estiver concluída. No entanto, se a aplicação utilizar setCurrentThreadAccountId:forScope: , o restauro da identidade antiga ocorrerá automaticamente. É preferível utilizar setCurrentThreadAccountId:forScope:.

  Rapidamente, devido a assíncrona/espera, [IntuneMAMPolicyManager setCurrentThreadAccountId:] e [IntuneMAMPolicyManager setCurrentThreadAccountId:forScope:] não estão disponíveis. Em vez disso, defina rapidamente a utilização IntuneMAMSwiftContextManager.setAccountId(_, forScope:)da identidade atual. Existem variantes desta API para assíncrona, lançamento e fechos assíncronas para serem transmitidos.

• Comutador de identidade iniciado pelo SDK:

  Por vezes, o SDK tem de pedir à aplicação para mudar para uma identidade específica. As aplicações de várias identidades têm de implementar o identitySwitchRequiredForAccountId método no IntuneMAMPolicyDelegate para processar este pedido.

  Quando este método é chamado, se a aplicação conseguir processar o pedido para mudar para a identidade especificada, deve passar IntuneMAMAddIdentityResultSuccess para o processador de conclusão. Se não conseguir processar a mudança de identidade, a aplicação deverá passar IntuneMAMAddIdentityResultFailed para o processador de conclusão.

  A aplicação não tem de chamar setUIPolicyAccountId em resposta a esta chamada. Se o SDK precisar que a aplicação mude para uma conta de utilizador não gerida, a cadeia vazia será transmitida para a identitySwitchRequiredForAccountId chamada.

• Inscrição automática de identidade iniciada pelo SDK:

  Quando o SDK precisa de inscrever automaticamente um utilizador na aplicação para efetuar uma ação, as aplicações têm de implementar o addIdentity:completionHandler: método no IntuneMAMPolicyDelegate. Em seguida, a aplicação tem de chamar o processador de conclusão e transmitir in IntuneMAMAddIdentityResultSuccess se a aplicação conseguir adicionar a identidade ou IntuneMAMAddIdentityResultFailed de outra forma.

• Eliminação seletiva:

  Quando a aplicação é eliminada seletivamente, o SDK chamará o wipeDataForAccountId método em IntuneMAMPolicyDelegate. A aplicação é responsável por remover a conta do utilizador especificado e quaisquer dados associados à mesma. O SDK é capaz de remover todos os ficheiros pertencentes ao utilizador e irá fazê-lo se a aplicação devolver FALSE da wipeDataForAccountId chamada.

  Tenha em atenção que este método é chamado a partir de um thread de fundo. A aplicação não deve devolver um valor até que todos os dados do utilizador sejam removidos (com exceção dos ficheiros se a aplicação devolver FALSE).

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 num dispositivo de teste; 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 num dispositivo de teste; 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 num dispositivo de teste; 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.

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: Suporte de Acesso Condicional da Proteção de Aplicações e Fase 7: funcionalidades de vista Web, podem ou não ser necessárias, dependendo do suporte de política de proteção de aplicações pretendido da sua aplicação.