Compartilhar via


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.

Fase Goals

  • Determine se a sua aplicação precisa de suporte de várias identidades.
  • Compreenda 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 às tarefas de IU no thread de main, 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 marcar 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.

SDK da Aplicação Intune para iOS: processo de determinação de identidade

Filas de threads

Muitas vezes, as aplicações distribuem tarefas assíncronas e síncronas para filas de threads. O SDK interceta as chamadas do Grand Central Dispatch (MDC) 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 sobre MDC, NSOperations será executado na identidade do thread no momento em que as tarefas são adicionadas a NSOperationQueue. NSOperationsou as funções enviadas diretamente através de MDC 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 Microsoft Entra contas, 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.