Intune App SDK per iOS - Multi-identità

Nota

Questa guida è suddivisa in diverse fasi distinte. Inizia esaminando la fase 1: pianifica l'integrazione.

Fase 5: identità multipla (facoltativo)

Per impostazione predefinita, l'SDK applica un criterio all'app nel suo complesso. Multi-identità è una funzionalità di MAM che è possibile abilitare per applicare un criterio a livello di identità. Ciò richiede una maggiore partecipazione all'app rispetto ad altre funzionalità di MAM.

L'app deve informare l'SDK dell'app quando intende modificare l'identità attiva. L'SDK notifica inoltre all'app quando è necessaria una modifica dell'identità. Attualmente è supportata una sola identità gestita. Dopo che l'utente ha registrato il dispositivo o l'app, l'SDK usa questa identità e la considera l'identità gestita primaria. Gli altri utenti dell'app verranno considerati non gestiti con impostazioni di criteri senza restrizioni.

Si noti che un'identità è semplicemente definita come una stringa. Le identità non fanno distinzione tra maiuscole e minuscole. Le richieste di un'identità all'SDK potrebbero non restituire le stesse maiuscole e minuscole originariamente utilizzate quando l'identità è stata impostata.

Obiettivi della fase

• Determinare se l'applicazione necessita del supporto per più identità.
• Informazioni su come Intune App SDK percepisce le identità.
• Effettuare il refactoring dell'applicazione per rilevare l'identità.
• Aggiungi codice per informare l'SDK delle identità attive e mutevoli in tutta l'applicazione.
• Testare accuratamente l'applicazione dei criteri di protezione delle app per le identità gestite e non gestite.

Panoramica delle identità

Un'identità è semplicemente il nome utente di un account (ad esempio, user@contoso.com). Gli sviluppatori possono impostare l'identità dell'app nei livelli seguenti:

• Identità processo: imposta l'identità a livello di processo e viene usato principalmente per applicazioni a identità singola. Questa identità influisce su tutte le attività, i file e l'interfaccia utente.

• Identità dell'interfaccia utente: determina i criteri applicati alle attività dell'interfaccia utente nel thread principale, ad esempio taglia/copia/incolla, PIN, autenticazione e condivisione dei dati. L'identità dell'interfaccia utente non influisce sulle attività relative ai file, ad esempio la crittografia e il backup.

• Identità del thread: influisce sui criteri applicati nel thread corrente. Questa identità influisce su tutte le attività, i file e l'interfaccia utente.

L'app è responsabile dell'impostazione appropriata delle identità, indipendentemente dal fatto che l'utente sia gestito o meno.

In qualsiasi momento, ogni thread ha un'identità effettiva per le attività dell'interfaccia utente e le attività dei file. Questa è l'identità usata per controllare quali criteri, se presenti, devono essere applicati. Se l'identità è "senza identità" o se l'utente non è gestito, non verranno applicati criteri. I diagrammi seguenti mostrano come vengono determinate le identità effettive.

Code di thread

Le app spesso inviano attività asincrone e sincrone alle code di thread. L'SDK intercetta le chiamate Grand Central Dispatch (GCD) e associa l'identità del thread corrente alle attività inviate. Al termine delle attività, l'SDK modifica temporaneamente l'identità del thread in quella associata alle attività, termina le attività e ripristina l'identità del thread originale.

Poiché NSOperationQueue è basato su GCD, NSOperations verrà eseguito sull'identità del thread al momento dell'aggiunta delle attività a NSOperationQueue. NSOperations Le funzioni inviate direttamente tramite GCD possono modificare l'identità del thread corrente durante l'esecuzione. Questa identità sostituirà l'identità ereditata dal thread di invio.

In swift, a causa di una conseguenza del modo in cui l'SDK propaga le identità per DispatchWorkItem, l'identità associata a DispatchWorkItem è l'identità del thread che ha creato l'elemento, non il thread che lo invia.

Proprietario del file

L'SDK tiene traccia delle identità dei proprietari dei file locali e applica i criteri di conseguenza. Il proprietario del file viene stabilito quando viene creato un file o quando un file viene aperto in modalità troncata. Il proprietario è impostato sull'identità effettiva dell'attività file del thread che esegue l'attività.

In alternativa, le app possono impostare l'identità del proprietario del file in modo esplicito usando IntuneMAMFilePolicyManager. Le app possono essere usate IntuneMAMFilePolicyManager per recuperare il proprietario del file e impostare l'identità dell'interfaccia utente prima di visualizzare il contenuto del file.

Dati condivisi

Se l'applicazione crea file che contengono dati di utenti gestiti e non gestiti, è responsabile della crittografia dei dati dell'utente gestito. È possibile crittografare i dati usando le protect API and unprotect in IntuneMAMDataProtectionManager.

Il protect metodo accetta un'identità che può essere un utente gestito o non gestito. Se l'utente è gestito, i dati verranno crittografati. Se l'utente non è gestito, ai dati che codifica l'identità verrà aggiunta un'intestazione, ma i dati non saranno crittografati. È possibile utilizzare il protectionInfo metodo per recuperare il proprietario dei dati.

Condividere le estensioni

Se l'app dispone di un'estensione di condivisione, il proprietario dell'elemento condiviso può essere recuperato tramite il protectionInfoForItemProvider metodo in IntuneMAMDataProtectionManager. Se l'elemento condiviso è un file, l'SDK gestirà l'impostazione del proprietario del file. Se l'elemento condiviso è costituito da dati, l'app è responsabile dell'impostazione del proprietario del file se questi dati vengono mantenuti in un file e della chiamata all'API setUIPolicyAccountId prima di visualizzare questi dati nell'interfaccia utente.

Attiva multi-identità

Per impostazione predefinita, le app sono considerate a identità singola. L'SDK imposta l'identità del processo sull'utente registrato. Per abilitare il supporto per più identità, aggiungere un'impostazione booleana con il nome MultiIdentity e il valore YES al dizionario IntuneMAMSettings nel file Info.plist dell'app.

Nota

Quando è abilitata l'identità multipla, l'identità del processo, l'identità dell'interfaccia utente e le identità del thread sono impostate su nil. L'app è responsabile dell'impostazione appropriata.

Cambiare identità

Importante

L'SDK non è in grado di rilevare in modo indipendente le modifiche di identità. Si affida interamente all'app per segnalarli. Se l'app non notifica correttamente all'SDK un cambio di identità:

• I criteri di protezione di app potrebbero non essere applicati per l'utente attivo, lasciando la protezione dei dati gestiti.
• I dati non gestiti potrebbero essere limitati in modo non corretto.

L'app deve chiamare le API di cambio di identità appropriate, ad esempio setUIPolicyAccountId) ogni volta che l'utente attivo cambia, anche all'avvio dell'app, al cambio di account e durante la visualizzazione dei dati per un altro utente.

• Cambio di identità avviato dall'app:

  Al momento dell'avvio, le app con più identità sono considerate in esecuzione con un account sconosciuto non gestito. L'interfaccia utente di avvio condizionale non verrà eseguita e non verranno applicati criteri all'app. L'app è responsabile della notifica all'SDK ogni volta che l'identità deve essere modificata. In genere, questo problema si verifica ogni volta che l'app sta per visualizzare i dati per un account utente specifico.

  Un esempio è quando l'utente tenta di aprire un documento, una cassetta postale o una scheda in un blocco appunti. L'app deve inviare una notifica all'SDK prima dell'apertura effettiva del file, della cassetta postale o della scheda. Questa operazione viene eseguita tramite l'API setUIPolicyAccountId in IntuneMAMPolicyManager. Questa API deve essere chiamata indipendentemente dal fatto che l'utente sia gestito o meno. Se l'utente è gestito, l'SDK eseguirà i controlli di avvio condizionale, come il rilevamento del jailbreak, il PIN e l'autenticazione.

  Il risultato del cambio di identità viene restituito all'app in modo asincrono tramite un gestore di completamento. L'app deve posticipare l'apertura del documento, della cassetta postale o della scheda finché non viene restituito un codice di risultato di esito positivo. Se il cambio di identità non è riuscito, l'app deve annullare l'attività.

  Le app con più identità devono evitare di usarle setProcessAccountId come metodo per impostare l'identità. Le app che usano UIScenes devono usare l'API setUIPolicyAccountId:forWindow per impostare l'identità.

  Le app possono anche impostare l'identità per il thread corrente usando setCurrentThreadIdentity: e setCurrentThreadIdentity:forScope:. Ad esempio, l'app può generare un thread in background, impostare l'identità sull'identità gestita e quindi eseguire operazioni sui file gestiti. Se l'app usa setCurrentThreadAccountId:, l'app dovrebbe usare anche getCurrentThreadAccountId l'app in modo che possa ripristinare l'identità originale una volta terminato. Tuttavia, se l'app utilizza setCurrentThreadAccountId:forScope: , il ripristino dell'identità precedente viene eseguito automaticamente. È preferibile usare .setCurrentThreadAccountId:forScope:

  In swift, a causa di asincrono/await, [IntuneMAMPolicyManager setCurrentThreadAccountId:] e [IntuneMAMPolicyManager setCurrentThreadAccountId:forScope:] non sono disponibili. Invece in swift per impostare l'uso IntuneMAMSwiftContextManager.setAccountId(_, forScope:)dell'identità corrente . Esistono varianti di questa API per chiusure asincrone, di generazione e di generazione asincrona da passare.

• Cambio di identità avviato dall'SDK:

  A volte, l'SDK deve chiedere all'app di passare a un'identità specifica. Le app con più identità devono implementare il identitySwitchRequiredForAccountId metodo in IntuneMAMPolicyDelegate per gestire questa richiesta.

  Quando questo metodo viene chiamato, se l'app è in grado di gestire la richiesta per passare all'identità specificata, deve passare IntuneMAMAddIdentityResultSuccess al gestore di completamento. Se non è in grado di gestire il cambio di identità, l'app deve passare IntuneMAMAddIdentityResultFailed al gestore di completamento.

  L'app non deve chiamare setUIPolicyAccountId in risposta a questa chiamata. Se l'SDK richiede che l'app passi a un account utente non gestito, la stringa vuota verrà passata nella identitySwitchRequiredForAccountId chiamata.

• Registrazione automatica dell'identità avviata dall'SDK:

  Quando l'SDK deve registrare automaticamente un utente nell'app per eseguire un'azione, le app devono implementare il addIdentity:completionHandler: metodo in IntuneMAMPolicyDelegate. L'applicazione deve quindi chiamare il gestore di completamento e passare IntuneMAMAddIdentityResultSuccess se l'app è in grado di aggiungere l'identità o IntuneMAMAddIdentityResultFailed in caso contrario.

• Cancellazione selettiva:

  Quando l'app viene cancellata selettivamente, l'SDK chiamerà il wipeDataForAccountId metodo in IntuneMAMPolicyDelegate. L'app è responsabile della rimozione dell'account dell'utente specificato e di tutti i dati associati. L'SDK è in grado di rimuovere tutti i file di proprietà dell'utente e lo farà se l'app restituisce FALSE dalla wipeDataForAccountId chiamata.

  Si noti che questo metodo viene chiamato da un thread in background. L'app non dovrebbe restituire un valore fino a quando tutti i dati per l'utente non sono stati rimossi (ad eccezione dei file se l'app restituisce FALSE).

Criteri di chiusura

Pianificare di dedicare molto tempo alla convalida dell'integrazione di più identità dell'app. Prima di iniziare il test:

• Creare e assegnare criteri di protezione delle app a un account. Questo sarà l'account gestito di test.
• Creare un altro account, ma non assegnarvi i criteri di protezione delle app. Questo sarà l'account non gestito di test. In alternativa, se l'app supporta più tipi di account oltre agli account Microsoft Entra, è possibile usare un account non AAD esistente come account di test non gestito.
• Acquisire familiarità con il modo in cui i criteri vengono applicati all'interno dell'app. I test multi-identità richiedono di distinguere facilmente quando l'app funziona e quando non funziona con i criteri applicati. L'impostazione dei criteri di protezione delle app per bloccare gli screenshot è efficace per testare rapidamente l'applicazione dei criteri.
• Considera l'intero set di interfaccia utente offerto dalla tua app. Enumerare le schermate in cui vengono visualizzati i dati dell'account. L'app presenta sempre e solo i dati di un singolo account alla volta o può presentare contemporaneamente i dati appartenenti a più account?
• Considerare l'intero set di file creati dall'app. Enumera quali di questi file contengono dati appartenenti a un account, anziché dati a livello di sistema.
  • Determina come convaliderai la crittografia su ognuno di questi file.
• Considerare l'intero set di modi in cui l'app può interagire con altre app. Enumerare tutti i punti di ingresso e di uscita. Quali tipi di dati può essere acquisito dall'app? Quali finalità trasmette? Quali provider di contenuti implementa?
  • Determina come eserciterai ognuna di queste funzionalità di condivisione dei dati.
  • Prepara un dispositivo di test con app gestite e non gestite in grado di interagire con l'app.
• Considerare in che modo l'app consente all'utente finale di interagire con tutti gli account connessi. L'utente deve passare manualmente a un account prima che i dati di tale account vengano visualizzati?

Dopo aver valutato a fondo il comportamento corrente dell'app, convalida l'integrazione multi-identità eseguendo il seguente set di test. Nota: questo non è un elenco completo e non garantisce che l'implementazione multi-identità dell'app sia priva di bug.

Convalida degli scenari di accesso e disconnessione

L'app per più identità supporta fino a 1 account gestito e più account non gestiti. Questi test consentono di garantire che l'integrazione di più identità non modifichi in modo errato le protezioni quando gli utenti eseguono l'accesso o la disconnessione.

Per questi test, installare l'app in un dispositivo di test. Non accedere prima di aver avviato il test.

Scenario	Procedura
Accesso gestito prima	- Accedi prima con un account gestito e verifica che i dati dell'account siano gestiti. - Accedi con un account non gestito e verifica che i dati dell'account non siano gestiti.
Accedere prima non gestito	- Accedi prima con un account non gestito e verifica che i dati dell'account non siano gestiti. - Accedi con un account gestito e verifica che i dati dell'account siano gestiti.
Accesso con più dati gestiti	- Accedi prima con un account gestito e verifica che i dati dell'account siano gestiti. - Accedere con un secondo account gestito e verificare che all'utente sia stato impedito l'accesso senza prima rimuovere l'account gestito originale.
Disconnessione gestita	- Accedi all'app sia con un account gestito che con un account non gestito. - Esci dall'account gestito. - Conferma che l'account gestito è stato rimosso dalla tua app e tutti i dati di quell'account sono stati rimossi. - Verifica che l'account non gestito sia ancora connesso, che nessuno dei dati dell'account non gestito sia stato rimosso e che il criterio non sia ancora applicato.
Disconnettersi non gestito	- Accedi all'app sia con un account gestito che con un account non gestito. - Esci dall'account non gestito. - Conferma che l'account non gestito è stato rimosso dalla tua app e tutti i dati di quell'account sono stati rimossi. - Verificare che l'account gestito sia ancora connesso, che nessuno dei dati dell'account non gestito sia stato rimosso e che il criterio sia ancora applicato.

Convalida dell'identità attiva e del ciclo di vita delle app

L'app con più identità può presentare visualizzazioni con i dati di un singolo account e consentire all'utente di modificare in modo esplicito l'account attualmente in uso. Può anche presentare visualizzazioni con i dati di più account contemporaneamente. Questi test consentono di garantire che l'integrazione di più identità fornisca le giuste protezioni per l'identità attiva in ogni pagina durante l'intero ciclo di vita dell'app.

Per questi test, installare l'app in un dispositivo di test. Accedi sia con un account gestito che con un account non gestito prima di iniziare il test.

Scenario	Procedura
Visualizzazione account singolo, gestita	- Passare all'account gestito. - Passare a tutte le pagine dell'app che presentano i dati di un singolo account. - Conferma che il criterio venga applicato su ogni pagina.
Visualizzazione account singolo, non gestita	- Passare all'account non gestito. - Passare a tutte le pagine dell'app che presentano i dati di un singolo account. - Conferma che la politica non viene applicata in nessuna pagina.
Visualizzazione multi-account	- Passare a tutte le pagine dell'app che presentano contemporaneamente i dati di più account. - Conferma che il criterio venga applicato su ogni pagina.
Sospensione gestita	- In una schermata con i dati gestiti visualizzati e i criteri attivi, sospendi l'app passando alla schermata iniziale del dispositivo o a un'altra app. - Riprendi l'app. - Conferma che il criterio sia ancora applicato.
Pausa non gestita	- In una schermata con dati non gestiti visualizzati e nessun criterio attivo, sospendi l'app passando alla schermata iniziale del dispositivo o a un'altra app. - Riprendi l'app. - Conferma che il criterio non è applicato.
Kill gestito	- In una schermata con i dati gestiti visualizzati e i criteri attivi, forza l'interruzione dell'app. - Riavvia l'app. - Verificare che, se l'app riprende su una schermata con i dati dell'account gestito (previsto), il criterio è ancora applicato. Se l'app riprende su una schermata con i dati dell'account non gestito, verificare che il criterio non sia applicato.
Uccisione non gestita	- In una schermata con dati non gestiti visualizzati e criteri attivi, forza l'interruzione dell'app. - Riavvia l'app. - Verifica che, se l'app riprende su una schermata con i dati dell'account non gestito (previsto), il criterio non viene applicato. Se l'app riprende in una schermata con i dati dell'account gestito, verificare che il criterio sia ancora applicato.
Cambio di identità ad hoc	- Prova a passare da un account all'altro e a mettere in pausa / riprendere / uccidere / riavviare l'app. - Conferma che i dati dell'account gestito sono sempre protetti e che i dati dell'account non gestito non sono mai protetti.

Convalida degli scenari di condivisione dei dati

L'app con più identità può inviare e ricevere dati da altre app. I criteri di protezione delle app di Intune includono impostazioni che determinano questo comportamento. Questi test consentono di garantire che l'integrazione multi-identità rispetti queste impostazioni di condivisione dei dati.

Per questi test, installare l'app in un dispositivo di test. Accedi sia con un account gestito che con un account non gestito prima di iniziare il test. Inoltre:

• Impostare il criterio dell'account gestito su:
  • "Invia dati dell'organizzazione ad altre app" in "App gestite da criteri".
  • Da "Ricevi dati da altre app" ad "App gestite da criteri".
• Installa altre app nel dispositivo di test:
  • App gestita, destinata agli stessi criteri dell'app, in grado di inviare e ricevere dati, ad esempio Microsoft Outlook.
  • Qualsiasi app non gestita in grado di inviare e ricevere dati.
• Accedere all'altra app gestita con l'account di test gestito. Anche se l'altra app gestita è multi-identità, accedere solo con l'account gestito.

Se l'app ha la capacità di inviare dati ad altre app, ad esempio Microsoft Outlook che invia un documento allegato a Microsoft Office:

Scenario	Procedura
Identità gestita Invia ad app non gestite	- Passare all'account gestito. - Passa alla posizione in cui l'app può inviare dati. - Tentativo di inviare dati a un'app non gestita. - Dovresti essere bloccato dall'invio di dati all'app non gestita.
Invio identità gestita all'app gestita	- Passare all'account gestito. - Passa alla posizione in cui l'app può inviare dati. - Tentativo di inviare dati all'altra app gestita con l'account gestito connesso. - Dovresti essere autorizzato a inviare dati all'app gestita.
Invio identità non gestito all'app gestita	- Passare all'account non gestito. - Passa alla posizione in cui l'app può inviare dati. - Tentativo di inviare dati all'altra app gestita con l'account gestito connesso. - Dovresti essere bloccato dall'invio di dati all'altra app gestita.
Identità non gestita Invia ad app non gestite	- Passare all'account non gestito. - Passa alla posizione in cui l'app può inviare dati. - Tentativo di inviare dati a un'app non gestita. - Dovresti sempre essere autorizzato a inviare i dati di un account non gestito a un'app non gestita.

L'app può importare attivamente dati da altre app, ad esempio Microsoft Outlook allegando un file da Microsoft OneDrive. L'app può anche ricevere passivamente dati da altre app, come Microsoft Office che apre un documento da un allegato di Microsoft Outlook. L'impostazione dei criteri di ricezione della protezione delle app copre entrambi gli scenari.

Se l'app ha la possibilità di importare attivamente dati da altre app:

Scenario	Procedura
Importazione dell'identità gestita da un'app non gestita	- Passare all'account gestito. - Passa al punto in cui la tua app può importare dati da altre app. - Tentativo di importare dati da un'app non gestita. - Dovrebbe essere bloccato l'importazione di dati da app non gestite.
Importazione dell'identità gestita dall'app gestita	- Passare all'account gestito. - Passa al punto in cui la tua app può importare dati da altre app. - Tenta di importare dati dall'altra app gestita con l'account gestito connesso. - Dovresti essere autorizzato a importare dati dall'altra app gestita.
Importazione di identità non gestite da un'app gestita	- Passare all'account non gestito. - Passa al punto in cui la tua app può importare dati da altre app. - Tenta di importare dati dall'altra app gestita con l'account gestito connesso. - Dovresti essere bloccato dall'importazione di dati dall'altra app gestita.
Importazione di identità non gestite da un'app non gestita	- Passare all'account non gestito. - Passa al punto in cui la tua app può importare dati da altre app. - Tentativo di importare dati da un'app non gestita. - Dovresti sempre essere autorizzato a importare dati da app non gestite per un account non gestito.

Se l'app è in grado di ricevere passivamente dati da altre app:

Scenario	Procedura
Ricezione di identità gestita da app non gestite	- Passare all'account gestito. - Passare all'app non gestita. - Passa alla posizione in cui può inviare dati. - Tentativo di inviare dati dall'app non gestita all'app. - L'account gestito dell'app non deve essere in grado di ricevere dati dall'app non gestita.
Ricezione di identità gestita da app gestite	- Passare all'account gestito. - Passare all'altra app gestita con l'account gestito connesso. - Passa alla posizione in cui può inviare dati. - Tentativo di inviare dati dall'app gestita all'app. - L'account gestito dell'app deve essere autorizzato a ricevere dati dall'altra app gestita.
Ricezione di identità non gestita da app gestite	- Passare all'account non gestito. - Passare all'altra app gestita con l'account gestito connesso. - Passa alla posizione in cui può inviare dati. - Tentativo di inviare dati dall'app gestita all'app. - L'account non gestito dell'app non deve essere in grado di ricevere dati dall'app gestita.
Ricezione di identità non gestita da app non gestite	- Passare all'account non gestito. - Passare all'app non gestita. - Passa alla posizione in cui può inviare dati. - Tentativo di inviare dati dall'app non gestita all'app. - L'account non gestito dell'app deve essere sempre autorizzato a ricevere dati dall'app non gestita.

Gli errori in questi test possono indicare che l'app non ha l'identità attiva corretta impostata quando tenta di inviare o ricevere dati. È possibile indagare su questo aspetto sfruttando le API get identity dell'SDK al momento dell'invio o della ricezione per verificare che l'identità attiva sia impostata correttamente.

Operazioni successive

Dopo aver completato tutti i criteri di uscita precedenti, l'app è ora integrata correttamente come multi-identità e può applicare i criteri di protezione delle app in base all'identità. Le sezioni successive, Fase 6: Supporto per l'accesso condizionale per la protezione delle app e Fase 7: Le funzionalità di visualizzazione Web, possono essere necessarie o meno, a seconda del supporto dei criteri di protezione delle app desiderato dall'app.