Intune App SDK per Android - Multi-Identity

Microsoft Intune App SDK per Android consente di incorporare i criteri di protezione delle app di Intune (noti anche come criteri APP o MAM) nell'app Java/Kotlin Android nativa. Un'applicazione gestita da Intune è integrata con Intune App SDK. Gli amministratori di Intune possono distribuire facilmente i criteri di protezione delle app nell'app gestita da Intune quando Intune gestisce attivamente l'app.

Nota

Questa guida è suddivisa in diverse fasi distinte. Per iniziare, esaminare la fase 1: Pianificare l'integrazione.

Fase 5: Multi-Identity

Fase Goals

• 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.

Terminologia dell'identità

I termini "utente", "account" e "identità" vengono spesso usati in modo intercambiabile. Questa guida tenta di distinguere come segue:

• Utente: l'essere umano che usa il prodotto software. Ulteriormente differenziato come utente finale, l'utente che usa l'app Android el'utente / / amministratore / amministratoreIT IT Pro, l'utente che usa l'interfaccia di amministrazione Microsoft Intune.
• Account: il record software appartenente a un'organizzazione che identifica in modo univoco l'entità di un utente. Un utente umano può avere più account.
• Identità: set di dati usato da Intune App SDK per identificare in modo univoco un account.

Background

Per impostazione predefinita, Intune App SDK applica i criteri all'intera applicazione. Dopo aver registrato un account con i criteri di protezione delle app di destinazione, l'SDK associa ogni file e ogni attività all'identità dell'account e applicherà i criteri di destinazione dell'account a livello universale.

Per molti sviluppatori, questo è il comportamento di protezione delle app desiderato per l'applicazione. Queste applicazioni sono considerate a identità singola. Completando le fasi precedenti, l'applicazione è stata integrata correttamente come identità singola e può applicare tutti i criteri di base. Le app destinate a rimanere a identità singola possono ignorare questa sezione e passare alla fase 6: Configurazione app.

Intune App SDK può applicare facoltativamente criteri a livello di identità. Se l'applicazione supporta già più account connessi contemporaneamente e si vuole mantenere il supporto per più account con i criteri di protezione delle app, l'applicazione viene considerata multi-identità.

Consiglio

Se non si è chiari se l'applicazione deve supportare protezioni a identità singola o multi-identità, rivedere L'applicazione è a identità singola o multi-identità?

Avviso

Il supporto di più identità è molto più complesso rispetto ad altre funzionalità di protezione delle app. L'integrazione non corretta di più identità può causare perdite di dati e altri problemi di sicurezza. Esaminare attentamente questa sezione e pianificare un ampio periodo di tempo per i test prima di procedere alla fase successiva.

"Identity" per l'SDK

Quando un'applicazione integrata nell'SDK registra un account usando registerAccountForMAM, l'SDK salva tutti i parametri forniti (upn, aadId, tenantId e autorità) come identità. Tuttavia, la maggior parte delle API di identità dell'SDK usa solo la stringa upn fornita come forma abbreviata per l'identità. Queste API restituiscono solo la stringa upn come identità e richiedono solo il parametro della stringa upn per l'identità.

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 durante la registrazione o l'impostazione dell'identità.

Consiglio

In futuro, le API SDK potrebbero presentare una struttura di identità più olistica che include tutti i campi forniti al momento della registrazione dell'account, non solo upn. Quando si integra il supporto per più identità, assicurarsi che l'app abbia anche accesso a aadId, tenantId e autorità quando si imposta l'identità usando le API correnti.

Identità gestite e non gestite

Come descritto in Registrazione per i criteri di protezione delle app, l'applicazione è responsabile di informare l'SDK quando un utente accede. Al momento dell'accesso, l'account dell'utente può essere destinato o meno ai criteri di protezione delle app. Se l'account è destinato ai criteri di protezione delle app, l'SDK lo considera gestito; in caso contrario, non è gestito.

L'SDK applicherà i criteri per le identità considerate gestite. L'SDK non applica i criteri per le identità considerate non gestite.

Attualmente, Intune App SDK supporta solo una singola identità gestita per ogni dispositivo. Non appena un'applicazione integrata nell'SDK registra un'identità gestita, tutte le identità registrate successivamente, anche se sono attualmente destinate ai criteri di protezione delle app, verranno considerate non gestite.

Se un'identità gestita è già stata registrata nel dispositivo e l'app registra un'altra identità destinata anche ai criteri di protezione delle app, l'SDK restituirà MAMEnrollmentManager.Result.WRONG_USER e richiederà all'utente finale le opzioni per la correzione. Per altre informazioni, vedere Registrare le notifiche dall'SDK .

Nota

Un account non destinato ai criteri di protezione delle app in fase di registrazione verrà considerato non gestito. Anche se l'account non è concesso in licenza per o destinato ai criteri di protezione delle app, l'SDK verificherà periodicamente se l'account viene concesso in licenza e destinato in un secondo momento. Se non è stata registrata alcuna altra identità gestita, l'SDK inizierà a considerare questa identità come gestita una volta che è destinata ai criteri. L'utente non deve disconnettersi e accedere nuovamente a questo account per apportare questa modifica.

Identità attiva

L'applicazione deve sempre mantenere l'SDK informato dell'identità in uso, nota anche come identità attiva. Se l'identità attiva è gestita, l'SDK applicherà le protezioni. Se l'identità attiva non è gestita, l'SDK non applica le protezioni.

Poiché l'SDK non dispone di conoscenze specifiche dell'applicazione, deve considerare attendibile l'applicazione per condividere l'identità attiva corretta.

• Se l'applicazione indica erroneamente all'SDK che un'identità non gestita è attiva quando l'identità gestita è effettivamente in uso, l'SDK non applicherà le protezioni. Ciò potrebbe causare una perdita di dati che mette a rischio i dati degli utenti.

• Se l'applicazione indica erroneamente all'SDK che l'identità gestita è attiva quando un'identità non gestita è effettivamente in uso, l'SDK applicherà in modo inappropriato le protezioni. Non si tratta di una perdita di dati, ma può limitare inutilmente gli utenti non gestiti e mettere i dati degli utenti non gestiti a rischio di eliminazione.

Se l'applicazione visualizza i dati di qualsiasi utente, deve visualizzare solo i dati che appartengono all'identità attiva. Se l'applicazione non è attualmente a conoscenza di chi possiede i dati visualizzati, potrebbe essere necessario effettuare il refactoring dell'applicazione per una maggiore consapevolezza dell'identità prima di iniziare a integrare il supporto multi-identità.

Organizzazione dei dati dell'app per identità

Ogni volta che l'applicazione scrive un nuovo file, l'SDK associa (noto anche come "tag") un'identità a tale file in base al thread attivo corrente e all'identità del processo. In alternativa, l'app può chiamare direttamente l'SDK per contrassegnare manualmente un file con una determinata identità (per informazioni dettagliate, vedere Scrittura di file protetti ). L'SDK usa questa identità di file con tag sia per la crittografia dei file che per la cancellazione selettiva.

Se l'identità gestita è destinata ai criteri di crittografia, verranno crittografati solo i file contrassegnati con l'identità gestita.

Se l'azione dell'amministratore o le richieste di criteri configurate che i dati gestiti vengono cancellati, verranno eliminati solo i file contrassegnati con l'identità gestita.

L'SDK non può associare più identità a un singolo file. Se l'app archivia dati appartenenti a più utenti nello stesso file, il comportamento predefinito dell'SDK comporta una protezione insufficiente o una protezione eccessiva di questi dati. È consigliabile organizzare i dati dell'app in base all'identità.

Se l'app deve assolutamente archiviare i dati appartenenti a identità diverse nello stesso file, l'SDK fornisce funzionalità per l'assegnazione di tag di identità a subset di dati all'interno di un file. Per informazioni dettagliate, vedere Protezione buffer dati.

Implementazione di più identità

Per dichiarare il supporto multi-identità per l'app, iniziare inserendo i metadati seguenti in AndroidManifest.xml.

  <meta-data
    android:name="com.microsoft.intune.mam.MAMMultiIdentity"
    android:value="true" />

Impostazione dell'identità attiva

L'applicazione può impostare l'identità attiva sui livelli seguenti con priorità decrescente:

1. Livello thread
2. Context (in genere Activity) Livello
3. Livello di processo

Un set di identità a livello di thread sostituisce un set di identità a Context livello, che sostituisce un set di identità a livello di processo.

Un set di identità in un Context oggetto viene usato solo negli scenari associati appropriati. Le operazioni di I/O dei file, ad esempio, non hanno un oggetto associato.Context In genere, le app imposteranno l'identità Context in un oggetto Activity. Provare a impostare l'identità Context in Activity.onCreate. Un'app non deve visualizzare i dati per un'identità a meno che l'identità Activity non sia impostata sulla stessa identità.

In generale, l'identità a livello di processo è utile solo se l'app funziona solo con una singola identità alla volta in tutti i thread. Questo comportamento non è tipico per le app che supportano più account. È consigliabile separare i dati dell'account e impostare l'identità attiva nel thread o Context nei livelli.

Se l'app usa il Application contesto per acquisire i servizi di sistema, assicurarsi che l'identità del thread o del processo sia stata impostata o che l'identità dell'interfaccia utente sia stata impostata nel contesto dell'app Application .

Se l'app usa un Service contesto per avviare finalità, usa resolver di contenuto o usa altri servizi di sistema, assicurati di impostare l'identità nel Service contesto. Analogamente, se l'app usa un JobService contesto per eseguire queste azioni, assicurarsi di impostare l'identità nel contesto o nel JobService thread in base alle esigenze dell'implementazione JobService . Ad esempio, se i processi JobService vengono elaborati per una singola identità, è consigliabile impostare l'identità nel JobService contesto. Se i processi JobService vengono elaborati per più identità, è consigliabile impostare l'identità a livello di thread.

Attenzione

Le app che usano WorkManager devono prestare particolare attenzione quando si imposta l'identità. In particolare, queste app devono evitare di impostare un'identità sul Context passato nel Worker costruttore. Questa Context istanza può essere condivisa tra più Worker istanze contemporaneamente. Per evitare un comportamento non definito, le app devono invece impostare un'identità del thread in come Worker.doWork() richiesto dall'implementazione Worker .

Nota

CLIPBOARD_SERVICE Poiché viene usato per le operazioni dell'interfaccia utente, l'SDK usa l'identità dell'interfaccia utente dell'attività in primo piano per ClipboardManager le operazioni.

I metodi seguenti in MAMPolicyManager possono essere usati per impostare l'identità attiva e recuperare i valori identity impostati in precedenza.

public static void setUIPolicyIdentity(final Context context, final String identity, final MAMSetUIIdentityCallback mamSetUIIdentityCallback,
final EnumSet<IdentitySwitchOption> options);

public static String getUIPolicyIdentity(final Context context);

public static MAMIdentitySwitchResult setProcessIdentity(final String identity);

public static String getProcessIdentity();

public static MAMIdentitySwitchResult setCurrentThreadIdentity(final String identity);

public static String getCurrentThreadIdentity();

/**
 * Get the current app policy. This does NOT take the UI (Context) identity into account.
 * If the current operation has any context (e.g. an Activity) associated with it, use the overload below.
 */
public static AppPolicy getCurrentThreadPolicy();

/**
 * Get the current app policy. This DOES take the UI (Context) identity into account.
 * If the current operation has any context (e.g. an Activity) associated with it, use this function.
 */
public static AppPolicy getPolicy(final Context context);


public static AppPolicy getPolicyForIdentity(final String identity);

public static boolean getIsIdentityManaged(final String identity);

Per praticità, è anche possibile impostare l'identità di un'attività direttamente tramite un metodo in MAMActivity invece di chiamare MAMPolicyManager.setUIPolicyIdentity. A tale scopo, usare il metodo seguente:

     public final void switchMAMIdentity(final String newIdentity, final EnumSet<IdentitySwitchOption> options);

Nota

Se l'app non ha dichiarato il supporto multi-identità nel manifesto, la chiamata di questi metodi per impostare l'identità non eseguirà alcuna azione e, se restituiscono un MAMIdentitySwitchResult, restituirà FAILEDsempre .

Insidie del commutatore di identità comune

• Per le chiamate a startActivity, Intune App SDK presuppone che l'identità attiva a Context livello sia associata al parametro specificato Intent . È consigliabile impostare l'identità Context di livello con il contesto di , Activitynon con il Applicationcontesto di .

• È consigliabile impostare l'identità Context durante il metodo di onCreate un'attività. Assicurarsi tuttavia di coprire anche altri punti di ingresso, ad esempio onNewIntent. In caso contrario, quando la stessa attività viene riutilizzata per visualizzare i dati sia per le identità gestite che per le identità non gestite, i criteri potrebbero essere applicati in modo non corretto, causando dati aziendali non protetti o dati personali con restrizioni non corrette.

Risultati del commutatore di identità

Tutti i metodi usati per impostare i valori dei risultati del report identità tramite MAMIdentitySwitchResult. È possibile restituire quattro valori:

Valore restituito	Scenario
SUCCEEDED	La modifica dell'identità ha avuto esito positivo.
NOT_ALLOWED	La modifica dell'identità non è consentita. Ciò si verifica se viene effettuato un tentativo di impostare l'identità dell'interfaccia utente (Context) quando viene impostata un'identità diversa nel thread corrente.
CANCELLED	L'utente ha annullato la modifica dell'identità, in genere premendo il pulsante Indietro su un PIN o una richiesta di autenticazione.
FAILED	La modifica dell'identità non è riuscita per un motivo non specificato.

L'app deve verificare che MAMIdentitySwitchResult sia SUCCEEDED prima di visualizzare o usare i dati di un account gestito.

La maggior parte dei metodi per l'impostazione dell'identità attiva restituisce MAMIdentitySwitchResult in modo sincrono. Nel caso di impostazione di un'identità Context tramite setUIPolicyIdentity, il risultato viene segnalato in modo asincrono. L'app può implementare un MAMSetUIIdentityCallback per ricevere questo risultato o passare null per l'oggetto callback. Se viene effettuata una chiamata a setUIPolicyIdentity mentre il risultato di una chiamata precedente a setUIPolicyIdentitynello stesso contesto non è ancora stato recapitato, il nuovo callback sostituirà quello precedente e il callback originale non riceverà mai un risultato.

Attenzione

Se l'oggetto Context specificato per setUIPolicyIdentity è , Activityl'SDK non sa se la modifica dell'identità è riuscita fino a quando non esegue i controlli di avvio condizionale configurati dall'amministratore. Ciò potrebbe richiedere all'utente di immettere un PIN o credenziali aziendali.

Attualmente, i commutatori di identità dei processi e dei thread avranno sempre esito positivo per un'app abilitata per più identità. L'SDK si riserva il diritto di aggiungere condizioni di errore in futuro.

L'opzione di identità dell'interfaccia utente potrebbe non riuscire per gli argomenti non validi, se sarebbe in conflitto con l'identità del thread o se l'utente annulla i requisiti di avvio condizionale (ad esempio, preme il pulsante Indietro nella schermata PIN).

Il comportamento predefinito per un'opzione di identità dell'interfaccia utente non riuscita in un'attività consiste nel completare l'attività. Per modificare questo comportamento e ricevere notifiche sui tentativi di modifica dell'identità per un'attività, è possibile eseguire l'override di un metodo in MAMActivity.

    public void onSwitchMAMIdentityComplete(final MAMIdentitySwitchResult result);

Se si esegue l'override onSwitchMAMIdentityComplete (o si chiama il super metodo ), è necessario assicurarsi che i dati di un account gestito non vengano visualizzati dopo un'opzione di identità non riuscita.

Nota

Il cambio di identità può richiedere la ricreazione dell'attività. In questo caso, il onSwitchMAMIdentityComplete callback verrà recapitato alla nuova istanza dell'attività.

Identity, Intents e IdentitySwitchOptions

Oltre a contrassegnare automaticamente i nuovi file con l'identità attiva, l'SDK contrassegna anche le finalità con l'identità attiva. Per impostazione predefinita, l'SDK controllerà l'identità in una finalità in ingresso e la confronterà con l'identità attiva. Se queste identità non corrispondono, l'SDK in genere(*) richiede un'opzione identity (vedere Modifiche implicite all'identità di seguito per altri dettagli).

L'SDK archivia anche questa identità di finalità in ingresso per un uso successivo. Quando l'app modifica in modo esplicito l'identità dell'interfaccia utente, l'SDK confronta l'identità a cui l'app sta tentando di passare rispetto all'identità della finalità in ingresso più recente. Se queste identità non corrispondono, l'SDK in genere non riuscirà l'opzione identity.

L'SDK esegue questo controllo perché presuppone che l'app visualizzi ancora il contenuto della finalità che appartiene all'identità contrassegnata nella finalità. Questo presupposto protegge dall'app disattivando involontariamente le protezioni quando si visualizzano dati gestiti; tuttavia questo presupposto potrebbe non essere corretto per il comportamento effettivo dell'app.

Le enumere IdentitySwitchOption facoltative possono essere passate alle API setUIPolicyIdentity e switchMAMIdentity per modificare il comportamento predefinito dell'SDK.

• IGNORE_INTENT: quando si richiede un'opzione identity a livello di interfaccia utente, questa opzione informa l'SDK di ignorare il confronto tra il parametro identity richiesto e l'identità finalità archiviata più di recente. Ciò è utile quando l'app non visualizza più contenuto appartenente a tale identità e l'SDK non deve bloccare questo commutatore di identità. Ad esempio:

  1. L'app è un visualizzatore di documenti. Può eseguire il rendering dei documenti passati da altre app. Contiene anche una funzionalità in cui gli utenti possono cambiare account. Ogni volta che l'utente usa questa funzionalità di cambio account, l'app passa a una pagina di destinazione specifica dell'account con i documenti recenti dell'account.
  2. L'app riceve una finalità per visualizzare un documento. Questa finalità viene contrassegnata con l'identità gestita.
  3. L'app viene passata all'identità gestita e visualizza questo documento, con protezioni applicate correttamente.
  4. L'utente usa il commutatore di account per passare al proprio account personale.

  L'app deve modificare l'identità dell'interfaccia utente nel passaggio 4. In questo caso, poiché il comportamento dell'app consiste nell'allontanarsi dai dati dell'account gestito (il documento nella finalità), deve essere usato IGNORE_INTENT nella chiamata al commutatore di identità. In questo modo, l'SDK non riesce in modo inappropriato a questa chiamata.

• DATA_FROM_INTENT: quando si richiede un'opzione identity a livello di interfaccia utente, questa opzione informa l'SDK che i dati dell'identità finalità archiviata più di recente continueranno a essere visualizzati dopo il completamento dell'opzione identity. Di conseguenza, l'SDK valuterà completamente i criteri di ricezione rispetto all'identità della finalità precedente per determinare se è consentito visualizzarli. Ad esempio:

  1. L'app è un visualizzatore di documenti. Può eseguire il rendering dei documenti passati da altre app. Contiene anche una funzionalità in cui gli utenti possono cambiare account. A differenza dell'esempio precedente, ogni volta che l'utente usa questa funzionalità di cambio account, l'app passa a una pagina condivisa che mostra i documenti recenti per tutti gli account.
  2. L'app riceve una finalità per visualizzare un documento. Questa finalità viene contrassegnata con l'identità gestita.
  3. L'app viene passata all'identità gestita e visualizza questo documento, con protezioni applicate correttamente.
  4. L'utente usa il commutatore di account per passare al proprio account personale.

  L'app deve modificare l'identità dell'interfaccia utente nel passaggio 4. In questo caso, poiché il comportamento dell'app consiste nel continuare a visualizzare i dati dell'identità gestita (un'anteprima del documento nella finalità), deve essere usato DATA_FROM_INTENT nella chiamata al commutatore di identità. Questo informa l'SDK di controllare i criteri di protezione delle app configurati per determinare se è appropriato che i dati continuino a essere visualizzati.

(*) Il comportamento predefinito dell'SDK include maiuscole e minuscole speciali che ignorano questo controllo in ingresso dei dati, ad esempio se la finalità proviene dall'interno della stessa app o dall'utilità di avvio del sistema.

Cancellazione dell'identità attiva

L'applicazione può avere scenari indipendenti dall'account. L'applicazione può anche avere scenari per scenari non gestiti locali che non richiedono alcun accesso. In entrambi questi casi, l'app potrebbe non volere che l'SDK applichi i criteri dell'identità gestita, ma potrebbe non essere disponibile un'identità esplicita a cui passare.

È possibile cancellare l'identità attiva chiamando uno dei metodi di identità set con il parametro identity impostato su null. Se si cancella l'identità a un livello, l'SDK cercherà l'identità attiva ad altri livelli, in base all'ordine di precedenza.

In alternativa, è possibile passare una stringa vuota come parametro identity, che imposta l'identità su un valore vuoto speciale che viene considerato come un'identità non gestita. L'impostazione dell'identità attiva su stringa vuota indica all'SDK di non applicare alcun criterio di protezione delle app.

Modifiche implicite all'identità

La sezione precedente descrive i diversi modi in cui l'app può impostare in modo esplicito l'identità attiva a livello di thread, contesto e processo. Tuttavia, l'identità attiva nell'app può anche cambiare senza che l'app chiami uno di questi metodi. Questa sezione descrive come l'app può restare in ascolto e rispondere a queste modifiche implicite dell'identità.

L'ascolto di queste modifiche implicite all'identità è facoltativo, ma consigliato. L'SDK non modificherà mai l'identità attiva senza fornire queste notifiche implicite di modifica dell'identità.

Attenzione

Se l'app sceglie di non restare in ascolto delle modifiche implicite all'identità, prestare particolare attenzione a non assumere l'identità attiva. In caso di dubbi, usare i getCurrentThreadIdentitymetodi , getUIPolicyIdentitye getProcessIdentity per confermare l'identità attiva.

Origini delle modifiche implicite all'identità

• L'ingresso dati da altre app gestite da Intune può modificare l'identità attiva a livello di thread e contesto.

  • Se un'attività viene avviata da un'altra Intent app MAM, l'identità dell'attività verrà impostata in base all'identità attiva nell'altra app al momento dell'invio Intent .

    • Ad esempio, un'attività per visualizzare un documento Word viene avviata da una finalità da Microsoft Outlook quando un utente seleziona un allegato del documento. L'identità dell'attività del visualizzatore di documenti di Office viene passata all'identità da Outlook.

  • Per i servizi, l'identità del thread verrà impostata in modo analogo per la durata di una onStart chiamata o onBind . Le chiamate all'oggetto Binder restituito da onBind imposteranno temporaneamente anche l'identità del thread.

  • Le chiamate in un ContentProvider oggetto imposteranno in modo analogo l'identità del thread per la durata.

• L'interazione dell'utente con un'attività può modificare l'identità attiva a livello di contesto. Ad esempio:

  • Un utente che annulla una richiesta di autorizzazione durante Resume comporterà un passaggio implicito a un'identità vuota.

Gestione delle modifiche implicite all'identità

Facoltativamente, l'app può restare in ascolto e reagire a queste modifiche implicite dell'identità. Ad esempio, l'applicazione potrebbe richiedere più passaggi prima che un account aggiunto sia utilizzabile, ad esempio un'app di posta elettronica che configura una nuova posta in arrivo. Quando viene visualizzato un tentativo di passaggio all'identità dell'account incompleto, il gestore dell'app potrebbe reindirizzare l'utente all'attività di configurazione dell'account prima di accettare l'opzione identity. In alternativa, il gestore dell'app potrebbe visualizzare una finestra di dialogo di errore e bloccare l'opzione identity.

L'app può implementare l'interfaccia MAMIdentityRequirementListener in un Service oggetto o ContextProvider per le modifiche all'identità applicate a questo thread. L'implementazione deve eseguire l'override di:

public abstract void onMAMIdentitySwitchRequired(String identity,
        AppIdentitySwitchResultCallback callback);

L'app può implementare l'interfaccia MAMActivityIdentityRequirementListener in un oggetto per le modifiche all'identità Activity applicate a questa attività. L'implementazione deve eseguire l'override di:

public abstract void onMAMIdentitySwitchRequired(String identity,
        AppIdentitySwitchReason reason,
        AppIdentitySwitchResultCallback callback);

Il AppIdentitySwitchReason parametro enum descrive l'origine dell'opzione di identità implicita.

Valore enumerazione	Comportamento predefinito dell'SDK	Descrizione
CREATE	Consentire l'opzione identity.	L'opzione identity si verifica a causa della creazione di un'attività.
NEW_INTENT	Consentire l'opzione identity.	L'opzione identity si verifica perché a un'attività viene assegnata una nuova finalità.
RESUME_CANCELLED	Bloccare l'opzione identity.	L'opzione identity si verifica perché un curriculum è stato annullato. Questa operazione è più comune quando l'utente finale preme il pulsante Indietro nell'interfaccia utente pin, autenticazione o conformità.

Il parametro AppIdentitySwitchResultCallback consente agli sviluppatori di eseguire l'override del comportamento predefinito per l'opzione identity:

public interface AppIdentitySwitchResultCallback {
  /**
    * @param result
    *            whether the identity switch can proceed.
    */
  void reportIdentitySwitchResult(AppIdentitySwitchResult result);
}
// Where [AppIdentitySwitchResult] is either `SUCCESS` or `FAILURE`.

onMAMIdentitySwitchRequired viene chiamato per tutte le modifiche implicite all'identità, ad eccezione di quelle apportate tramite un binder restituito da MAMService.onMAMBind. Le implementazioni predefinite di onMAMIdentitySwitchRequired chiamano immediatamente:

• callback.reportIdentitySwitchResult(FAILURE) quando il motivo è RESUME_CANCELLED.

• callback.reportIdentitySwitchResult(SUCCESS) in tutti gli altri casi.

Non è previsto che la maggior parte delle app debba bloccare o ritardare un cambio di identità in modo diverso, ma se un'app deve farlo, è necessario considerare i punti seguenti:

• Se un commutatore di identità è bloccato, il comportamento dell'utente finale è identico a quello in cui l'impostazione di protezione delle app "ricezione dati da altre app" dell'SDK ha vietato l'ingresso dei dati.

• Se un servizio è in esecuzione nel thread principale, reportIdentitySwitchResultdeve essere chiamato in modo sincrono o il thread dell'interfaccia utente smette di rispondere.

• Per Activity la creazione, onMAMIdentitySwitchRequired verrà chiamato prima onMAMCreatedi . Se l'app deve mostrare l'interfaccia utente per determinare se consentire l'opzione identity, l'interfaccia utente deve essere visualizzata usando un'attività diversa .

• In , Activityquando viene richiesta un'opzione all'identità vuota con il motivo come RESUME_CANCELLED, l'app deve modificare l'attività ripresa per visualizzare i dati coerenti con tale opzione di identità. Se questo non è possibile, l'app deve rifiutare l'opzione e all'utente verrà chiesto di rispettare nuovamente i criteri per la ripresa dell'identità (ad esempio, se viene visualizzata la schermata di immissione del PIN dell'app).

Attenzione

Un'app multi-identità può ricevere dati in ingresso da app gestite e non gestite. È responsabilità dell'app trattare i dati delle identità gestite in modo gestito.

Se un'identità richiesta viene gestita (usare MAMPolicyManager.getIsIdentityManaged per controllare), ma l'app non è in grado di usare tale account (ad esempio, perché gli account, ad esempio gli account di posta elettronica, devono essere configurati prima nell'app), l'opzione identity deve essere rifiutata.

È possibile accedere al comportamento predefinito per MAMActivity.onMAMIdentitySwitchRequired chiamando il metodo MAMActivity.defaultOnMAMIdentitySwitchRequired(activity, identity, reason, callback)statico .

Analogamente, se è necessario eseguire l'override MAMActivity.onSwitchMAMIdentityCompletedi , è possibile implementare MAMActivityIdentitySwitchListener senza ereditare in modo esplicito da MAMActivity.

Opzioni di identità e restrizioni dello screenshot

Intune App SDK usa il flag FLAG_SECURE per applicare i Window criteri di screenshot. Alcune app possono anche essere impostate FLAG_SECURE per scopi specifici. Quando i criteri di protezione delle app non limitano gli screenshot, l'SDK non modifica FLAG_SECURE.

In un cambio di identità da un'identità i cui criteri richiedono la disabilitazione degli screenshot a un'identità i cui criteri non lo fanno, l'SDK cancella FLAG_SECURE. Di conseguenza, l'app non deve basarsi sul FLAG_SECURE set rimanente dopo un'opzione di identità.

Mantenimento dell'identità nelle operazioni asincrone

Le app spesso inviano attività in background dal thread dell'interfaccia utente per gestire le operazioni su altri thread. Un'app multi-identità deve assicurarsi che queste attività in background funzionino con l'identità appropriata, che è spesso la stessa identità usata dall'attività che le ha inviate.

Intune App SDK offre MAMAsyncTask e MAMIdentityExecutors come comodità per preservare l'identità nelle operazioni asincrone. L'app deve usare questi valori (o impostare in modo esplicito l'identità del thread nelle attività) se le operazioni asincrone possono:

• Scrivere dati appartenenti a un'identità gestita in un file
• Comunicare con altre app

MAMAsyncTask

Per usare MAMAsyncTask, è sufficiente ereditare da esso anziché AsyncTask e sostituire gli override di doInBackground e onPreExecute rispettivamente con doInBackgroundMAM e onPreExecuteMAM . Il MAMAsyncTask costruttore accetta un contesto di attività. Ad esempio:

AsyncTask<Object, Object, Object> task = new MAMAsyncTask<Object, Object, Object>(thisActivity) {

    @Override
    protected Object doInBackgroundMAM(final Object[] params) {
        // Do operations.
    }

    @Override
    protected void onPreExecuteMAM() {
        // Do setup.
    };
}

MAMAsyncTask assumerà l'identità attiva in base all'ordine di precedenza normale.

MAMIdentityExecutors

MAMIdentityExecutorsconsente di eseguire il wrapping di un'istanza o esistente Executor come metodo di conservazione dell'identità ExecutorExecutorService/con wrapExecutor e .wrapExecutorServiceExecutorService Ad esempio

Executor wrappedExecutor = MAMIdentityExecutors.wrapExecutor(originalExecutor, activity);
ExecutorService wrappedService = MAMIdentityExecutors.wrapExecutorService(originalExecutorService, activity);

MAMIdentityExecutors assumerà l'identità attiva in base all'ordine di precedenza normale.

Protezione file

Scrittura di file protetti

Come indicato in Organizzazione dei dati dell'app in base all'identità precedente, Intune App SDK associa l'identità attiva (a livello di thread/processo) ai file durante la scrittura. È fondamentale impostare l'identità corretta al momento della creazione del file per garantire la corretta crittografia e la funzionalità di cancellazione selettiva.

L'app può eseguire query o modificare l'identità di un file usando la classe MAMFileProtectionManager , in particolare MAMFileProtectionManager.getProtectionInfo per l'esecuzione di query e MAMFileProtectionManager.protect per la modifica.

Il protect metodo può essere utilizzato anche per proteggere le directory. La protezione della directory si applica in modo ricorsivo a tutti i file e le sottodirectory contenute nella directory. Quando una directory è protetta, tutti i nuovi file creati all'interno della directory avranno automaticamente la stessa protezione applicata. Poiché la protezione della directory viene applicata in modo ricorsivo, il completamento della protect chiamata può richiedere del tempo per le directory di grandi dimensioni. Per questo motivo, le app che applicano la protezione a una directory che contiene un numero elevato di file potrebbero voler essere eseguite protect in modo asincrono in un thread in background.

La chiamata protect con stringa vuota per il parametro identity contrassegnerà il file/directory con l'identità non gestita. Questa operazione rimuoverà la crittografia dal file/directory se è stata crittografata in precedenza. Quando viene eseguito un comando di cancellazione selettiva, il file/directory non verrà eliminato.

Visualizzazione di contenuto file protetto

È altrettanto importante avere l'identità corretta impostata quando viene visualizzato il contenuto del file per impedire agli utenti non autorizzati di visualizzare i dati gestiti. L'SDK non può dedurre automaticamente una relazione tra i file letti e i dati visualizzati in un oggetto Activity. Le app devono impostare l'identità dell'interfaccia utente in modo appropriato prima di visualizzare i dati gestiti. Sono inclusi i dati letti dai file.

Se un file proviene dall'esterno dell'app (da o ContentProvider letto da un percorso scrivibile pubblicamente), l'app deve tentare di determinare l'identità del file (usando l'overload MAMFileProtectionManager.getProtectionInfo corretto per l'origine dati) prima di visualizzare le informazioni lette dal file.

Se getProtectionInfo segnala un'identità non Null e non vuota, l'app deve impostare l'identità dell'interfaccia utente in modo che corrisponda a questa identità usando MAMActivity.switchMAMIdentity o MAMPolicyManager.setUIPolicyIdentity. Se l'opzione identity ha esito negativo, i dati del file non devono essere visualizzati.

Durante la lettura da un URI di contenuto, potrebbe essere necessario prima leggere l'identità (tramite l'overload getProtectionInfo accettando un Uri), quindi impostare il contesto o l'identità del thread in modo appropriato. Questa operazione deve essere eseguita prima di aprire un descrittore di file o un flusso di input in ContentResolveroppure l'operazione potrebbe non riuscire.

Un flusso di esempio potrebbe avere un aspetto simile al seguente:

• L'utente seleziona un documento da aprire nell'app.

• Durante il flusso aperto, prima di leggere i dati dal disco, l'app conferma l'identità che deve essere usata per visualizzare il contenuto:

  MAMFileProtectionInfo info = MAMFileProtectionManager.getProtectionInfo(docPath)
  if (info != null)
      MAMPolicyManager.setUIPolicyIdentity(activity, info.getIdentity(), callback, EnumSet.noneOf<IdentitySwitchOption.class>)
  

• L'app attende fino a quando un risultato non viene segnalato al callback.

• Se il risultato segnalato è un errore, l'app non visualizza il documento.

• L'app si apre ed esegue il rendering del file.

Se un'app usa Android DownloadManager per scaricare i file, l'SDK tenterà di proteggere automaticamente questi file usando la priorità di identità descritta in precedenza. Il contesto usato per recuperare l'oggetto DownloadManager verrà usato se l'identità del thread non è impostata. Se i file scaricati contengono dati aziendali, è responsabilità dell'app chiamare protect se i file vengono spostati o ricreati dopo il download.

transizione da Single-Identity a multi-identità

Se un'app rilasciata in precedenza con l'integrazione di Intune con identità singola in un secondo momento integra più identità, le app installate in precedenza sperimenteranno una transizione. Questa transizione non è visibile all'utente.

L'app non è necessaria per gestire questa transizione. Tutti i file creati prima della transizione continueranno a essere considerati gestiti, quindi rimarranno crittografati se i criteri di crittografia sono attivati.

Se non si vuole associare tutti i dati dell'app precedenti all'identità gestita, è possibile rilevare questa transizione e rimuovere in modo esplicito la protezione.

• Rilevare l'aggiornamento confrontando la versione dell'app con una versione nota in cui è stato aggiunto il supporto multi-identità.
• Chiamare protect con una stringa vuota per il parametro identity in file o directory che non si desidera associare all'identità gestita.

Scenari offline

Intune App SDK viene eseguito in modalità "offline" quando l'app Portale aziendale non è installata. L'assegnazione di tag di identità dei file è sensibile alla modalità offline:

• Se il Portale aziendale non è installato, i file non possono essere contrassegnati con tag identity. La chiamata a MAMFileProtectionManager.protect in modalità offline è sicura, ma non avrà alcun effetto.

• Se il Portale aziendale è installato, ma l'app non dispone di criteri di protezione delle app, i file non possono essere contrassegnati in modo affidabile con tag identity.

• Quando il tag identity dei file diventa disponibile, tutti i file creati in precedenza vengono considerati come personali/non gestiti (appartenenti all'identità di stringa vuota), tranne nei casi in cui l'app è stata installata in precedenza come app gestita con identità singola, come descritto in Transizione da identità singola a più identità.

Per evitare questi casi, le app devono evitare di creare file contenenti dati dell'account fino al completamento della registrazione dell'account. Se l'app deve assolutamente creare file offline, può usare MAMFileProtectionManager.protect per correggere l'identità associata del file quando l'SDK è online.

Protezione buffer dati

Avviso

Non è consigliabile scrivere dati appartenenti a più account in un singolo file. Se possibile, organizzare i file dell'app in base all'identità.

MAMDataProtectionManager dell'SDK fornisce metodi per controllare e modificare l'identità con tag in buffer di dati specifici in formato byte[] o InputStream .

MAMDataProtectionManager.protect consente a un'app di associare i dati a un'identità e, se l'identità è attualmente destinata ai criteri di crittografia, crittografa i dati. Questi dati crittografati sono adatti per l'archiviazione su disco in un file.

MAMDataProtectionManager consente inoltre di eseguire query sui dati associati all'identità e di annullarne la crittografia.

Le app che usano MAMDataProtectionManager devono implementare un ricevitore per la MANAGEMENT_REMOVED notifica. Per altre informazioni, vedere Registrare le notifiche dall'SDK .

Al termine della notifica, i buffer protetti tramite questa classe non saranno più leggibili (se la crittografia dei file è stata abilitata quando i buffer sono stati protetti). Un'app può impedire che questi buffer diventino illeggibili chiamando MAMDataProtectionManager.unprotect su tutti i buffer durante la gestione della MANAGEMENT_REMOVED notifica. È anche sicuro chiamare protect durante questa notifica, se si desidera mantenere le informazioni di identità. La crittografia viene sicuramente disabilitata durante la notifica e la chiamata protect nel gestore non crittografa i buffer di dati.

Provider di contenuto

Un'app multi-identità deve anche proteggere i dati condivisi tramite ContentProviders per impedire la condivisione inappropriata del contenuto gestito.

L'app deve chiamare il metodo isProvideContentAllowed(provider, contentIdentity)MAMContentProvider statico prima di restituire il contenuto. Se questa funzione restituisce false, il contenuto non deve essere restituito al chiamante.

La chiamata isProvideContentAllowed non è necessaria se restituisce ContentProvider un ParcelFileDescriptoroggetto . I descrittori di file restituiti tramite un provider di contenuto vengono gestiti automaticamente in base all'identità del file.

Cancellazione selettiva

Per impostazione predefinita, Intune App SDK gestirà automaticamente le cancellazioni selettive, eliminando tutti i file associati all'identità gestita. Successivamente, l'SDK chiuderà l'app in modo normale, completando le attività e uccidendo il processo dell'app.

L'SDK offre all'app la possibilità facoltativa di integrare (scelta consigliata) o sostituire il comportamento di cancellazione predefinito.

Il gestore di cancellazione predefinito dell'SDK non gestisce i buffer di dati protetti da MAMDataProtectionManager. Se l'app usa questa funzionalità, deve integrare o sostituire il gestore di cancellazione predefinito per rimuovere tali dati.

Nota

L'integrazione e l'override del comportamento di cancellazione predefinito richiedono la gestione di notifiche SDK specifiche. Per altre informazioni sull'implementazione dei gestori di notifica, vedere Registrare le notifiche dall'SDK .

Integrazione del comportamento di cancellazione predefinito

Per integrare il comportamento di cancellazione dell'SDK predefinito, l'app può registrarsi per WIPE_USER_AUXILIARY_DATAMAMNotificationType.

Questa notifica verrà inviata dall'SDK prima di eseguire la cancellazione selettiva predefinita. L'SDK attenderà il completamento del gestore di notifica dell'app prima di eliminare i dati e terminare l'app. L'app deve cancellare i dati in modo sincrono e non restituire fino al completamento della pulizia.

Le app devono prendere in considerazione l'integrazione del comportamento di cancellazione predefinito con WIPE_USER_AUXILIARY_DATA, in quanto la pulizia specifica dell'app è comune per le app con più identità.

Override del comportamento di cancellazione predefinito

Per ignorare il comportamento di cancellazione predefinito dell'SDK, l'app può eseguire la WIPE_USER_DATA registrazione per MAMNotificationType.

Avviso

Un'app non deve mai registrarsi per WIPE_USER_DATA e WIPE_USER_AUXILIARY_DATA.

L'override del comportamento di cancellazione dell'SDK predefinito comporta un rischio considerevole per l'app. L'app sarà completamente responsabile della rimozione di tutti i dati associati all'identità gestita, inclusi tutti i file e i buffer di dati contrassegnati per tale identità.

• Se l'identità gestita è stata protetta con la crittografia e il gestore di cancellazione personalizzato dell'app non rimuove completamente tutti i dati gestiti, tutti i file gestiti rimanenti rimarranno crittografati. Questi dati diventeranno inaccessibili e l'app potrebbe non gestire correttamente il tentativo di lettura dei dati crittografati.
• Il gestore di cancellazione dell'app può comportare la perdita di dati per gli utenti non gestiti, se rimuove i file non contrassegnati con l'identità gestita.

Se il gestore di cancellazione personalizzato dell'app rimuove i dati gestiti da un file ma vuole lasciare altri dati nel file, deve modificare l'identità del file (tramite MAMFileProtectionManager.protect) in un'identità non gestita o in una stringa vuota.

Il gestore di cancellazione sottoposto a override deve cancellare i dati in modo sincrono e non restituire fino al completamento di tutte le operazioni di pulizia.

È consigliabile chiudere manualmente l'app dopo aver completato i passaggi del gestore di cancellazione personalizzato per impedire all'utente di accedere ai dati in memoria dopo che si verifica una cancellazione.

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 Microsoft Entra account, è 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 e il Portale aziendale Intune. Non accedere prima di avviare il test.

Scenario	Procedura
Accedere prima gestito	- Accedere prima con un account gestito e verificare che i dati dell'account siano gestiti. - Accedere con un account non gestito e verificare che i dati dell'account non siano gestiti.
Eseguire prima l'accesso non gestito	- Accedere prima con un account non gestito e verificare che i dati dell'account non siano gestiti. - Accedere con un account gestito e verificare che i dati dell'account siano gestiti.
Accedere a più utenti gestiti	- Accedere prima con un account gestito e verificare che i dati dell'account siano gestiti. - Accedere con un secondo account gestito e verificare che all'utente sia impedito l'accesso senza prima rimuovere l'account gestito originale.
Disconnettersi gestito	- Accedere all'app con un account non gestito gestito. - Disconnettersi dall'account gestito. - Verificare che l'account gestito sia stato rimosso dall'app e che tutti i dati dell'account siano stati rimossi. - Verificare che l'account non gestito sia ancora connesso, che nessuno dei dati dell'account non gestito sia stato rimosso e che i criteri non siano ancora applicati.
Disconnettersi non gestito	- Accedere all'app con un account non gestito gestito. - Disconnettersi dall'account non gestito. - Verificare che l'account non gestito sia stato rimosso dall'app e che tutti i dati dell'account siano stati rimossi. - Verificare che l'account gestito sia ancora connesso, che nessuno dei dati dell'account non gestito sia stato rimosso e che i criteri siano ancora applicati.

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 e il Portale aziendale Intune; accedere con un account gestito e non gestito prima di avviare 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. - Verificare che i criteri siano applicati in 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. - Verificare che i criteri non siano applicati in alcuna pagina.
Visualizzazione con più account	- Passare a tutte le pagine dell'app che presentano contemporaneamente i dati di più account. - Verificare che i criteri siano applicati in ogni pagina.
Pausa gestita	- In una schermata con i dati gestiti visualizzati e i criteri attivi, sospendere l'app passando alla schermata iniziale del dispositivo o a un'altra app. - Riprendere l'app. - Verificare che il criterio sia ancora applicato.
Pausa non gestita	- In una schermata con i dati non gestiti visualizzati e nessun criterio attivo, sospendere l'app passando alla schermata iniziale del dispositivo o a un'altra app. - Riprendere l'app. - Verificare che il criterio non sia applicato.
Uccisione gestita	- In una schermata con i dati gestiti visualizzati e i criteri attivi forzare l'eliminazione dell'app. - Riavviare l'app. - Verificare che, se l'app riprende su una schermata con i dati dell'account gestito (previsto), i criteri vengono ancora applicati. Se l'app riprende su una schermata con i dati dell'account non gestito, verificare che i criteri non siano applicati.
Kill non gestito	- In una schermata con i dati non gestiti visualizzati e i criteri attivi forzare l'eliminazione dell'app. - Riavviare l'app. - Verificare che, se l'app riprende su una schermata con i dati dell'account non gestito (previsto), i criteri non vengono applicati. Se l'app riprende su una schermata con i dati dell'account gestito, verificare che i criteri siano ancora applicati.
Commutatore di identità ad hoc	- Sperimentare il passaggio da un account all'altro e sospendere/riprendere/uccidere/riavviare l'app. - Verificare che i dati dell'account gestito siano sempre protetti e che i dati dell'account non gestito non siano mai protetti.

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 e il Portale aziendale Intune; 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:

Scenario	Procedura
Invio dell'identità gestita all'app non gestita	- Passare all'account gestito. - Passare alla posizione in cui l'app può inviare dati. - Tentativo di inviare dati a un'app non gestita. - È consigliabile impedire l'invio di dati all'app non gestita.
Invio dell'identità gestita all'app gestita	- Passare all'account gestito. - Passare alla posizione in cui l'app può inviare dati. - Tentativo di inviare dati all'altra app gestita con l'account gestito connesso. - Dovrebbe essere consentito inviare dati all'app gestita.
Invio di identità non gestite all'app gestita	- Passare all'account non gestito. - Passare alla posizione in cui l'app può inviare dati. - Tentativo di inviare dati all'altra app gestita con l'account gestito connesso. - È consigliabile impedire l'invio di dati all'altra app gestita.
Invio di identità non gestite a un'app non gestita	- Passare all'account non gestito. - Passare alla posizione in cui l'app può inviare dati. - Tentativo di inviare dati a un'app non gestita. - È sempre possibile 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, 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:

Scenario	Procedura
Importazione di identità gestite da un'app non gestita	- Passare all'account gestito. - Passare alla posizione in cui l'app può importare dati da altre app. - Tentativo di importare dati da un'app non gestita. - È consigliabile impedire l'importazione di dati da app non gestite.
Importazione di identità gestite dall'app gestita	- Passare all'account gestito. - Passare alla posizione in cui l'app può importare dati da altre app. - Tentativo di importare dati dall'altra app gestita con l'account gestito connesso. - È necessario poter importare dati dall'altra app gestita.
Importazione di identità non gestita dall'app gestita	- Passare all'account non gestito. - Passare alla posizione in cui l'app può importare dati da altre app. - Tentativo di importare dati dall'altra app gestita con l'account gestito connesso. - È consigliabile impedire l'importazione di dati dall'altra app gestita.
Importazione di identità non gestite da un'app non gestita	- Passare all'account non gestito. - Passare alla posizione in cui l'app può importare dati da altre app. - Tentativo di importare dati da un'app non gestita. - È sempre possibile importare dati da un'app non gestita per un account non gestito.

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

Scenario	Procedura
L'identità gestita viene ricevuta da un'app non gestita	- Passare all'account gestito. - Passare all'app non gestita. - Passare alla posizione in cui può inviare i dati. - Prova a 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 dell'identità gestita dall'app gestita	- Passare all'account gestito. - Passare all'altra app gestita con l'account gestito connesso. - Passare alla posizione in cui può inviare i dati. - Prova a inviare dati dall'app gestita all'app. - L'account gestito dell'app deve essere autorizzato a ricevere dati dall'altra app gestita.
L'identità non gestita viene ricevuta dall'app gestita	- Passare all'account non gestito. - Passare all'altra app gestita con l'account gestito connesso. - Passare alla posizione in cui può inviare i dati. - Prova a inviare dati dall'app gestita all'app. - L'account non gestito dell'app non deve essere in grado di ricevere dati dall'app gestita.
L'identità non gestita viene ricevuta da un'app non gestita	- Passare all'account non gestito. - Passare all'app non gestita. - Passare alla posizione in cui può inviare i dati. - Prova a 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 analizzare questo aspetto sfruttando le API get identity dell'SDK nel punto di invio/ricezione per verificare che l'identità attiva sia impostata correttamente.

Convalida degli scenari di cancellazione selettiva

L'app multi-identità potrebbe aver completato o sostituito il comportamento di cancellazione predefinito dell'SDK. Questi test consentono di garantire che l'integrazione con più identità rimuova correttamente i dati gestiti quando vengono avviate le cancellazioni, senza influire sui dati non gestiti.

Avviso

Promemoria: se l'app usa MAMDataProtectionManager.protect, deve implementare un gestore per WIPE_USER_AUXILIARY_DATA o WIPE_USER_DATA.

Per questi test, installare l'app e il Portale aziendale Intune; accedere con un account gestito e non gestito prima di avviare il test. Per entrambi gli account, eseguire l'esercizio di scenari di app in cui vengono archiviati i dati dell'account.

Scenario	Condizioni	Procedura
Gestore di cancellazione supplementare	L'app ha implementato un gestore per WIPE_USER_AUXILIARY_DATA	- Eseguire una cancellazione selettiva dall'interfaccia di amministrazione Microsoft Intune. - Verificare (in genere tramite la registrazione) che il gestore di cancellazione sia stato eseguito correttamente. - Verificare che l'account gestito sia stato rimosso dall'app e che tutti i dati dell'account siano stati rimossi. - Verificare che l'account non gestito sia ancora connesso, che nessuno dei dati dell'account non gestito sia stato rimosso e che i criteri non siano ancora applicati.
Gestore di cancellazione sottoposto a override	L'app ha implementato un gestore per WIPE_USER_DATA	- Eseguire una cancellazione selettiva dall'interfaccia di amministrazione Microsoft Intune. - Verificare (in genere tramite la registrazione) che il gestore di cancellazione sia stato eseguito correttamente. - Verificare che l'account gestito sia stato rimosso dall'app e che tutti i dati dell'account siano stati rimossi. - Verificare che l'account non gestito sia ancora connesso, che nessuno dei dati dell'account non gestito sia stato rimosso e che i criteri non siano ancora applicati. - Verificare che l'app sia uscita normalmente o che sia ancora in uno stato integro al termine del gestore di cancellazione.
Protezione manuale dei file	- L'app chiama MAMFileProtectionManager.protect - L'app ha implementato un gestore per WIPE_USER_DATA	- Assicurarsi di aver eseguito scenari in cui l'app proteggerebbe manualmente almeno un file appartenente all'account gestito. - Eseguire una cancellazione selettiva dall'interfaccia di amministrazione Microsoft Intune. - Verificare che i file siano stati rimossi.
Protezione manuale del buffer dei dati	- L'app chiama MAMDataProtectionManager.protect - L'app ha implementato un gestore per WIPE_USER_AUXILIARY_DATA o WIPE_USER_DATA	- Assicurarsi di aver eseguito scenari in cui l'app proteggerebbe manualmente almeno un buffer di dati appartenente all'account gestito. - Eseguire una cancellazione selettiva dall'interfaccia di amministrazione Microsoft Intune. - Verificare che i buffer di dati vengano rimossi dai file in cui sono stati archiviati e che l'app possa comunque leggere i dati non gestiti da tali file.

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: Configurazione app e Fase 7: Funzionalità di partecipazione alle app, potrebbero essere necessarie o meno, a seconda del supporto dei criteri di protezione delle app desiderato per l'app. Se non si è certi che una di queste sezioni si applichi all'app, rivedere le decisioni chiave per l'integrazione dell'SDK.