Intune App SDK per iOS - Multi-Identity

Fase 5: Multi-Identity (facoltativo)

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

L'app deve informare l'SDK dell'app quando intende modificare l'identità attiva. L'SDK notifica anche 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 nell'app verranno considerati non gestiti con impostazioni dei criteri senza restrizioni.

Si noti che un'identità è semplicemente definita come stringa. Le identità non fanno distinzione tra maiuscole e minuscole. Le richieste all'SDK per un'identità potrebbero non restituire la stessa combinazione di maiuscole e minuscole usata in origine quando è stata impostata l'identità.

Obiettivi di fase

• Determinare se l'applicazione necessita di supporto multi-identità.
• Informazioni su come Intune App SDK percepisce le identità.
• Effettuare il refactoring dell'applicazione per la consapevolezza dell'identità.
• Aggiungere codice per informare l'SDK delle identità attive e mutevoli in tutta l'applicazione.
• Testare accuratamente l'imposizione dei criteri di protezione delle app sia per le identità gestite che per le identità non gestite.

Panoramica dell'identità

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

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

• Identità dell'interfaccia utente: determina quali criteri vengono 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à dei file, ad esempio la crittografia e il backup.

• Identità del thread: influisce sui criteri applicati al 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à efficace per le attività dell'interfaccia utente e le attività dei file. Si tratta dell'identità usata per controllare quali criteri, se presenti, devono essere applicati. Se l'identità è "nessuna identità" o l'utente non è gestito, non verranno applicati criteri. I diagrammi seguenti illustrano come vengono determinate le identità valide.

Code di thread

Le app spesso inviano attività asincrone e sincrone alle code dei thread. L'SDK intercetta le chiamate GCD (Grand Central Dispatch) e associa l'identità del thread corrente alle attività inviate. Al termine delle attività, l'SDK modifica temporaneamente l'identità del thread nell'identità associata alle attività, termina le attività e quindi 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 o le funzioni inviate direttamente tramite GCD possono anche modificare l'identità del thread corrente durante l'esecuzione. Questa identità eseguirà l'override dell'identità ereditata dal thread di invio.

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

Proprietario del file

L'SDK tiene traccia delle identità dei proprietari di file locali e applica i criteri di conseguenza. Un proprietario di file viene stabilito quando viene creato un file o quando un file viene aperto in modalità di troncamento. 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 usare 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'app crea file con dati sia da utenti gestiti che da utenti non gestiti, l'app è responsabile della crittografia dei dati dell'utente gestito. È possibile crittografare i dati usando le protect API e 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, verrà aggiunta un'intestazione ai dati che codificano l'identità, ma i dati non verranno crittografati. È possibile utilizzare il protectionInfo metodo per recuperare il proprietario dei dati.

Condividere le estensioni

Se l'app ha 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 salvati in modo permanente in un file e della chiamata all'API setUIPolicyAccountId prima di visualizzare questi dati nell'interfaccia utente.

Attivare più identità

Per impostazione predefinita, le app vengono considerate una singola identità. 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.

Cambiare identità

• Opzione di identità avviata dall'app:

  All'avvio, le app multi-identità vengono 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, ciò 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 notebook. L'app deve inviare una notifica all'SDK prima che il file, la cassetta postale o la scheda venga effettivamente aperto. 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, ad esempio il rilevamento jailbreak, il PIN e l'autenticazione.

  Il risultato dell'opzione identity 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 fino a quando non viene restituito un codice di risultato positivo. Se l'opzione identity non è riuscita, l'app deve annullare l'attività.

  Le app multi-identità devono evitare di usare setProcessAccountId come modo 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 deve usare getCurrentThreadAccountId anche in modo che possa ripristinare l'identità originale una volta eseguita. Tuttavia, se l'app usa setCurrentThreadAccountId:forScope: , il ripristino dell'identità precedente viene eseguito automaticamente. È preferibile usare setCurrentThreadAccountId:forScope:.

  In swift, a causa di async/await e [IntuneMAMPolicyManager setCurrentThreadAccountId:][IntuneMAMPolicyManager setCurrentThreadAccountId:forScope:] non sono disponibili. Al contrario, in swift per impostare l'identità corrente usare IntuneMAMSwiftContextManager.setAccountId(_, forScope:). Esistono varianti di questa API per le chiusure asincrone, generate e asincrone da passare.

• Opzione di identità avviata dall'SDK:

  In alcuni casi, l'SDK deve chiedere all'app di passare a un'identità specifica. Le app multi-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 di 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 in modo selettivo, l'SDK chiamerà il wipeDataForAccountId metodo in IntuneMAMPolicyDelegate. L'app è responsabile della rimozione dell'account utente specificato e degli eventuali 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 deve 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 uscita

Pianifica di dedicare tempo significativo alla convalida dell'integrazione dell'app con più identità. Prima di iniziare il test:

• Creare e assegnare criteri di protezione delle app a un account. Si tratta dell'account gestito di test.
• Creare, ma non assegnare criteri di protezione delle app a un altro account. Si tratta dell'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. Il test multi-identità richiede di distinguere facilmente quando l'app è e non funziona con i criteri applicati. L'impostazione dei criteri di protezione delle app per bloccare gli screenshot è efficace per testare rapidamente l'imposizione dei criteri.
• Si consideri l'intero set di interfacce utente offerte dall'app. Enumerare le schermate in cui vengono visualizzati i dati dell'account. L'app presenta contemporaneamente solo i dati di un singolo account o può presentare contemporaneamente dati appartenenti a più account?
• Si consideri l'intero set di file creati dall'app. Enumerare quali di questi file contengono dati appartenenti a un account, anziché dati a livello di sistema.
  • Determinare come si convalida la crittografia in ognuno di questi file.
• Considera l'intero set di modi in cui l'app può interagire con altre app. Enumerare tutti i punti in ingresso e in uscita. Quali tipi di dati possono essere inseriti dall'app? Quali finalità trasmette? Quali provider di contenuti implementa?
  • Determinare la modalità di esercizio di ognuna di queste funzionalità di condivisione dei dati.
  • Preparare un dispositivo di test con app gestite e non gestite che possono interagire con l'app.
• Si consideri il modo in cui l'app consente all'utente finale di interagire con tutti gli account connessi. L'utente deve passare manualmente a un account prima che vengano visualizzati i dati dell'account?

Dopo aver valutato accuratamente il comportamento corrente dell'app, convalidare l'integrazione con più identità eseguendo il set di test seguente. 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 multi-identità supporta fino a 1 account gestito e più account non gestiti. Questi test consentono di garantire che l'integrazione con più identità non modifichi in modo errato le protezioni quando gli utenti accedono o disconnetteno.

Per questi test, installare l'app in un dispositivo di test; non accedere prima di avviare il test.

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

L'app multi-identità può presentare visualizzazioni con i dati di un singolo account e consentire all'utente di modificare in modo esplicito l'account in uso corrente. Può anche presentare visualizzazioni con dati di più account contemporaneamente. Questi test consentono di garantire che l'integrazione con più identità fornisca le protezioni appropriate 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; Accedere con un account gestito e non gestito prima di avviare il test.

Convalida degli scenari di condivisione dei dati

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

Per questi test, installare l'app in un dispositivo di test; Accedere con un account gestito e non gestito prima di avviare il test. Inoltre:

• Impostare i criteri dell'account gestito come:
  • "Invia dati dell'organizzazione ad altre app" a "App gestite da criteri".
  • "Ricevere dati da altre app" a "App gestite da criteri".
• Installare altre app nel dispositivo di test:
  • Un'app gestita, destinata agli stessi criteri dell'app, che può 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 possibilità di inviare dati ad altre app, ad esempio Microsoft Outlook che invia un allegato di documento a Microsoft Office:

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, ad esempio Microsoft Office che apre un documento da un allegato di Microsoft Outlook. L'impostazione dei criteri di protezione delle app di ricezione copre entrambi gli scenari.

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

Se l'app ha la possibilità di ricevere passivamente dati da altre app:

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 analizzare questo aspetto sfruttando le API get identity dell'SDK nel punto di invio/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 alle singole identità. Le sezioni successive , Fase 6: Supporto dell'accesso condizionale per la protezione delle app e Fase 7: Funzionalità di visualizzazione Web, potrebbero essere necessarie o meno, a seconda del supporto dei criteri di protezione delle app desiderato per l'app.