Intune App SDK per Android - Multi-identità

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

Fase 5: multi-identità

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.

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 utilizza il prodotto software. Ulteriormente differenziati come utente finale, l'utente che utilizza l'app Android e l'utente / amministratore / amministratore IT / Pro, l'umano che utilizza l'interfaccia di amministrazione di 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à: il 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 mirati, l'SDK associa ogni file e ogni attività all'identità di tale account e applicherà universalmente i criteri di destinazione di tale account.

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 si è 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.

La SDK per app Intune può facoltativamente applicare 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à.

"Identità" 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 authority) come identità. Tuttavia, la maggior parte delle API di identità dell'SDK utilizza l'OID fornito (noto anche come Microsoft Entra ID o AAD ID) come identificatore per l'identità. Le API di MAM SDK restituiranno la stringa OID come identità e richiederanno il parametro della stringa OID per l'identità. Alcuni metodi possono anche accettare o restituire una stringa UPN, nel qual caso l'UPN è solo a scopo informativo.

Nei parametri di identità non viene fatta distinzione tra maiuscole e minuscole. Le richieste di identità all'SDK potrebbero non restituire le stesse maiuscole e minuscole usate durante la registrazione o l'impostazione dell'identità.

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 o meno destinato ai criteri di protezione delle app. Se l'account è destinato a criteri di protezione delle app, l'SDK lo considera gestito; in caso contrario, non è gestito.

L'SDK applicherà i criteri per le identità che considera gestite. L'SDK non applicherà i criteri per le identità che considera non gestite.

Attualmente, SDK per app Intune supporta solo una singola identità gestita per dispositivo. Non appena un'applicazione integrata nell'SDK registra un'identità gestita, tutte le identità registrate successivamente, anche se attualmente sono destinate a 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à anch'essa destinata ai criteri di protezione delle app, SDK verrà restituito MAMEnrollmentManager.Result.WRONG_USER e richiederà all'utente finale le opzioni per la correzione. Per maggiori dettagli, consulta Registrazione per le notifiche dall'SDK .

L'identità attiva

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

Poiché l'SDK non ha 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 fuga 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à le protezioni in modo inappropriato. Non si tratta di una fuga 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 un utente, deve visualizzare solo i dati che appartengono all'identità attiva. Se l'applicazione non è attualmente a conoscenza di chi è proprietario dei dati visualizzati, potrebbe essere necessario effettuare il refactoring dell'applicazione per una maggiore consapevolezza dell'identità prima di iniziare a integrare il supporto per più identità.

Organizzazione dei dati dell'app per identità

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

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

Se l'azione dell'amministratore o i criteri configurati richiedono che i dati gestiti vengano 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 comporterà una protezione insufficiente o eccessiva di questi dati. È consigliabile organizzare i dati dell'app in base all'identità.

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

Implementazione di più identità

Per dichiarare il supporto per più 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 di thread
2. Context (in generale 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'identità impostata su a Context viene utilizzata solo negli scenari associati appropriati. Le operazioni di I/O dei file, ad esempio, non hanno un file .Context Più comunemente, le app impostano l'identità Context su un file .Activity È consigliabile 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 su quella stessa identità.

In generale, l'identità a livello di processo è utile solo se l'app funziona con una sola 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 contesto per acquisire i servizi di sistema, assicurati che l'identità del thread o del Application processo sia stata impostata o che tu abbia impostato l'identità dell'interfaccia utente nel contesto dell'app Application .

Se l'app usa un Service contesto per avviare intenti, risolutori di contenuto o sfrutta altri servizi di sistema, assicurarsi di impostare l'identità Service nel contesto. Analogamente, se l'app usa un JobService contesto per eseguire queste azioni, assicurati di impostare l'identità nel contesto o nel thread come richiesto dall'implementazione JobServiceJobService . Ad esempio, se si JobService elaborano processi per una singola identità, è consigliabile impostare l'identità JobService nel contesto. Se i JobService processi elaborano per più identità, è consigliabile impostare l'identità a livello di thread.

I seguenti metodi in MAMPolicyManager possono essere utilizzati per impostare l'identità attiva e recuperare i valori di identità precedentemente impostati.

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

public static String getUIPolicyIdentityOID(final Context context);

public static MAMIdentitySwitchResult setProcessIdentityOID(final String oid);

public static String getProcessIdentityOID();

public static MAMIdentitySwitchResult setCurrentThreadIdentityOID(final String oid);

public static String getCurrentThreadIdentityOID();

/**
 * 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 getPolicyForIdentityOID(final String oid);

public static boolean getIsIdentityOIDManaged(final String oid);

Per comodità, puoi anche impostare l'identità di un'attività direttamente tramite un metodo in MAMActivity invece di chiamare MAMPolicyManager.setUIPolicyIdentityOID. A tale scopo, usare il metodo seguente:

     public final void switchMAMIdentityOID(final String newIdentityOid, final EnumSet<IdentitySwitchOption> options);

Insidie comuni del cambio di identità

• Per le chiamate a startActivity, l'SDK dell'app Intune presuppone che l'identità attiva a livello Context sia associata al parametro fornitoIntent. È consigliabile impostare l'identità del Context livello con un Activitycontesto 's, non con il Applicationcontesto 's).

• Si consiglia di impostare l'identità durante il Context metodo di onCreate un'attività. Tuttavia, assicurati di coprire anche altri punti di ingresso come onNewIntent. In caso contrario, quando la stessa attività viene riutilizzata per visualizzare dati per identità gestite e non gestite, i criteri potrebbero essere applicati in modo non corretto, causando la creazione di dati aziendali non protetti o di dati personali con restrizioni non appropriate.

Risultati del cambio di identità

Tutti i metodi usati per impostare i valori dei risultati del report di identità tramite MAMIdentitySwitchResult. Sono quattro i valori che possono essere restituiti:

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 impostare l'identità attiva restituisce MAMIdentitySwitchResult in modo sincrono. Nel caso dell'impostazione di un'identità Context tramite setUIPolicyIdentityOID, il risultato viene segnalato in modo asincrono. L'app può implementare un MAMSetUIIdentityCallback per ricevere questo risultato o può passare null per l'oggetto di callback. Se viene effettuata una chiamata mentre setUIPolicyIdentityOID il risultato di una chiamata precedente sullo setUIPolicyIdentityOIDstesso Context non è ancora stato recapitato, il nuovo callback sostituirà quello precedente e il callback originale non riceverà mai un risultato.

Attualmente, le opzioni di identità di processo e 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.

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

Il comportamento predefinito per un'attivazione dell'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 cambio di identità non riuscito.

Identity, Intents e IdentitySwitchOptions

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

L'SDK archivia anche questa identità di finalità in ingresso per un uso successivo. Quando l'app modifica esplicitamente l'identità dell'interfaccia utente, l'SDK confronta l'identità a cui l'app sta tentando di passare con l'identità della finalità in ingresso più recente. Se queste identità non corrispondono, l'SDK in genere(*) non riuscirà a eseguire il cambio di identità.

L'SDK esegue questo controllo perché presuppone che l'app stia ancora visualizzando il contenuto della finalità che appartiene all'identità contrassegnata sulla finalità. Questo presupposto protegge dall'app che disattiva involontariamente le protezioni durante la visualizzazione dei dati gestiti. Tuttavia, questa ipotesi potrebbe non essere corretta per il comportamento effettivo dell'app.

Le enumerazioni IdentitySwitchOption facoltative possono essere passate alle API setUIPolicyIdentityOID e switchMAMIdentityOID per modificare il comportamento predefinito dell'SDK.

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

  1. L'app è un visualizzatore di documenti. Può eseguire il rendering di 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 di tale account.
  2. L'app riceve l'intento di visualizzare un documento. Questa finalità è contrassegnata con l'identità gestita.
  3. L'app passa all'identità gestita e visualizza questo documento, con le protezioni applicate correttamente.
  4. L'utente usa l'opzione per cambiare account per passare al proprio account personale.

  L'identità dell'interfaccia utente deve essere modificata dall'app nel passaggio 4. In questo caso, poiché il comportamento dell'app consiste nell'allontanarsi dai dati dell'account gestito (il documento nell'intento), deve essere utilizzato IGNORE_INTENT nella chiamata Identity Switch. In questo modo si evita che l'SDK non riesca in modo inappropriato questa chiamata.

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

  1. L'app è un visualizzatore di documenti. Può eseguire il rendering di 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 utilizza questa funzione di cambio account, l'app accede a una pagina condivisa che mostra i documenti recenti per tutti gli account.
  2. L'app riceve l'intento di visualizzare un documento. Questa finalità è contrassegnata con l'identità gestita.
  3. L'app passa all'identità gestita e visualizza questo documento, con le protezioni applicate correttamente.
  4. L'utente usa l'opzione per cambiare account per passare al proprio account personale.

  L'identità dell'interfaccia utente deve essere modificata dall'app nel passaggio 4. In questo caso, poiché il comportamento dell'app è quello di continuare a visualizzare i dati dell'identità gestita (un'anteprima del documento nella finalità), è necessario usarla DATA_FROM_INTENT nella chiamata Identity Switch. In questo modo l'SDK deve 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 una combinazione speciale di maiuscole e minuscole che ignora il controllo dell'ingresso di dati se, ad esempio, la finalità proviene dall'interno della stessa app o dall'icona di avvio del sistema.

Cancellazione dell'identità attiva

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

È possibile cancellare l'identità attiva chiamando uno qualsiasi dei metodi di identità impostati con il parametro identity OID 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 OID di identità, che imposta l'identità su un valore vuoto speciale che viene considerato come un'identità non gestita. L'impostazione dell'identità attiva su una stringa vuota indica all'SDK di non applicare alcun criterio di protezione delle app.

Modifiche implicite dell'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ò ascoltare e rispondere a queste modifiche di identità implicite.

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

Fonti di modifiche implicite dell'identità

• L'ingresso di 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 Intent dell'invio.

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

  • Per i servizi, l'identità del thread verrà impostata in modo analogo per la durata di una onStart chiamata OR onBind . Anche le chiamate nel Binder valore restituito da onBind imposteranno temporaneamente l'identità del thread.

  • Le chiamate in un ContentProvider imposteranno in modo analogo l'identità del thread per la loro 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 di identità implicite

L'app può facoltativamente ascoltare e reagire a queste modifiche implicite dell'identità. Ad esempio, l'applicazione potrebbe richiedere diversi passaggi prima che un account aggiunto sia utilizzabile, come un'app di posta elettronica che configura una nuova cartella Posta in arrivo. Quando viene visualizzato un tentativo di passaggio di identità all'identità di questo account incompleto, il gestore dell'app potrebbe reindirizzare l'utente all'attività di configurazione dell'account prima di accettare il cambio di identità. In alternativa, il gestore dell'app potrebbe visualizzare una finestra di dialogo di errore e bloccare il cambio di identità.

L'app può implementare l'interfaccia MAMIdentityRequirementListener in un Service OR ContextProvider per le modifiche di identità che si applicano a questo thread. L'implementazione deve avere la precedenza:

public abstract void onMAMIdentitySwitchRequired(String upn, String oid,
        AppIdentitySwitchResultCallback callback);

L'app può implementare l'interfaccia MAMActivityIdentityRequirementListener per Activity le modifiche di identità che si applicano a questa attività. L'implementazione deve avere la precedenza:

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

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

Il parametro AppIdentitySwitchResultCallback consente agli sviluppatori di eseguire l'override del comportamento predefinito per il parametro di identità:

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 di identità implicite, ad eccezione di quelle apportate tramite un Binder restituito da MAMService.onMAMBind. Le implementazioni predefinite di onMAMIdentitySwitchRequired immediatamente chiamano:

• 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'opzione di identità è bloccata, il comportamento dell'utente finale è uguale a quello che si avrebbe se l'impostazione di protezione dell'app "Ricevi dati da altre app" dell'SDK avesse impedito l'ingresso dei dati.

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

• Per Activity la creazione, onMAMIdentitySwitchRequired verrà chiamato prima di onMAMCreate. Se l'app deve mostrare l'interfaccia utente per determinare se consentire il cambio di identità, l'interfaccia utente deve essere visualizzata usando un'attività diversa .

• In un , Activityquando viene richiesto un passaggio all'identità vuota con il motivo , RESUME_CANCELLEDl'app deve modificare l'attività ripresa per visualizzare i dati coerenti con tale opzione di identità. Se ciò non è possibile, l'app deve rifiutare il passaggio e all'utente verrà chiesto di nuovo di conformarsi ai criteri per la ripresa dell'identità (ad esempio, presentando la schermata di immissione del PIN dell'app).

Se un'identità richiesta viene gestita (usare MAMPolicyManager.getIsIdentityOIDManaged 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 prima configurati nell'app), il cambio di identità deve essere rifiutato.

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

Allo stesso modo, se è necessario eseguire l'override MAMActivity.onSwitchMAMIdentityComplete, è possibile implementare MAMActivityIdentitySwitchListener senza ereditare esplicitamente da MAMActivity.

Interruttori di identità e restrizioni degli 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 propri. Quando i criteri di protezione delle app non limitano gli screenshot, l'SDK non modificherà FLAG_SECURE.

Quando un'identità passa da un'identità il cui criterio richiede la disabilitazione degli screenshot a un'identità il cui criterio non lo richiede, l'SDK verrà cancellato FLAG_SECURE. Di conseguenza, l'app non deve rimanere FLAG_SECURE impostata dopo un cambio 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 con più identità deve garantire 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 fornisce MAMAsyncTask e MAMIdentityExecutors come praticità per aiutare a mantenere l'identità nelle operazioni asincrone. L'app deve usarli (o impostare in modo esplicito l'identità del thread nelle attività) se le sue operazioni asincrone possono:

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

MAMAsyncTask

Per utilizzare MAMAsyncTask, è sufficiente ereditare da esso anziché AsyncTask sostituire le sostituzioni di doInBackground e onPreExecute con doInBackgroundMAM e onPreExecuteMAM e rispettivamente. 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 al normale ordine di precedenza.

MAMIdentityExecutors

MAMIdentityExecutorsConsente di eseguire il wrapping di un'istanza OR esistente Executor come metodo AND wrapExecutorwrapExecutorService di mantenimento dell'identitàExecutorServiceExecutor/.ExecutorService Ad esempio

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

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

Protezione file

Scrittura di Files protetti

Come indicato nella sezione Organizzazione dei dati delle app in base all'identità, Intune App SDK associa l'identità attiva (dal livello di thread/processo) ai file durante la loro scrittura. È fondamentale impostare l'identità corretta al momento della creazione del file per garantire la corretta funzionalità di crittografia e 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.protectForOID la modifica.

Il protectForOID 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 contenuti nella directory. Quando una directory è protetta, a tutti i nuovi file creati all'interno della directory verrà automaticamente applicata la stessa protezione. Poiché la protezione delle directory viene applicata in modo ricorsivo, il completamento della chiamata può richiedere del tempo per le protectForOID 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 protectForOID in modo asincrono in un thread in background.

La chiamata protectForOID 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 è stato crittografato in precedenza. Quando viene eseguito un comando di cancellazione selettiva, il file/directory non verrà eliminato.

Visualizzazione del contenuto del file protetto

È altrettanto fondamentale impostare l'identità corretta quando viene visualizzato il contenuto del file per impedire a utenti non autorizzati di visualizzare i dati gestiti. L'SDK non è in grado di dedurre automaticamente una relazione tra i file in lettura e i dati visualizzati in un Activityfile . 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 una ContentProvider posizione scrivibile o letta 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.switchMAMIdentityOID o MAMPolicyManager.setUIPolicyIdentityOID. Se l'opzione di identità non riesce, i dati del file non devono essere visualizzati.

Quando si legge da un URI di contenuto, potrebbe essere necessario prima leggere l'identità (tramite l'overload getProtectionInfo che prende a 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 , ContentResolveraltrimenti 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.setUIPolicyIdentityOID(activity, info.getIdentityOID(), callback, EnumSet.noneOf<IdentitySwitchOption.class>)
  

• L'app attende finché 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 questi file automaticamente usando la priorità di identità descritta in precedenza. Il contesto utilizzato per recuperare verrà DownloadManager utilizzato se l'identità del thread non è impostata. Se i file scaricati contengono dati aziendali, è responsabilità dell'app chiamare protectForOID se i file vengono spostati o ricreati dopo il download.

Single-Identity alla transizione con più identità

Se un'app rilasciata in precedenza con l'integrazione di Intune a identità singola integra in seguito 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, pertanto rimarranno crittografati se i criteri di crittografia sono attivi.

Se non si desidera che tutti i dati dell'app precedenti siano associati all'identità gestita, è possibile rilevare questa transizione e rimuovere esplicitamente la protezione.

• Rilevare l'aggiornamento confrontando la versione dell'app con una versione nota in cui è stato aggiunto il supporto per più identità.
• Chiamata protectForOID con stringa vuota per il parametro identity nei file o nelle directory che non si desidera associare all'identità gestita.

Scenari offline

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

• Se il Portale aziendale non è installato, i file non possono essere contrassegnati con identità. Chiamare MAMFileProtectionManager.protectForOID in modalità offline è sicuro, 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 in base all'identità.

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

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 mentre è offline, può usare MAMFileProtectionManager.protectForOID per correggere l'identità associata al file una volta che l'SDK è online.

Protezione del buffer dei dati

MAMDataProtectionManager dell'SDK fornisce metodi per controllare e modificare l'identità contrassegnata in specifici buffer di dati in un byte[] formato ORInputStream.

MAMDataProtectionManager.protectForOID Consente a un'app di associare i dati a un'identità e, se l'identità è attualmente destinata a criteri di crittografia, crittografare 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 decrittografarli.

Le app che usano devono MAMDataProtectionManager implementare un ricevitore per la MANAGEMENT_REMOVED notifica. Per maggiori dettagli, consulta Registrazione per le notifiche dall'SDK .

Al termine di questa notifica, i buffer protetti tramite questa classe non saranno più leggibili (se la crittografia dei file è stata abilitata quando i buffer erano protetti). Un'app può impedire che questi buffer diventino illeggibili chiamando MAMDataProtectionManager.unprotect tutti i buffer durante la gestione della MANAGEMENT_REMOVED notifica. È anche sicuro chiamare protectForOID durante questa notifica, se si desidera preservare le informazioni sull'identità. La crittografia è garantita per essere disabilitata durante la notifica e la chiamata protectForOID al gestore non crittograferà i buffer dei dati.

Provider di contenuti

Un'app con più identità deve anche proteggere i dati condivisi tramite ContentProviders per evitare la condivisione inappropriata del contenuto gestito.

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

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

Cancellazione selettiva

Per impostazione predefinita, la Intune App SDK gestirà automaticamente le cancellazioni selettive, eliminando tutti i file associati all'identità gestita. In seguito, l'SDK chiuderà l'app normalmente, terminando le attività e terminando il processo dell'app.

L'SDK offre all'app la possibilità facoltativa di integrare (scelta consigliata) o di ignorare 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.

Integrazione del comportamento di cancellazione predefinito

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

Questa notifica verrà inviata dall'SDK prima che esegua 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 dovrebbe cancellare i dati in modo sincrono e non tornare finché non sono state completate tutte le operazioni di pulizia.

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

Annullamento del comportamento di cancellazione predefinito

Per eseguire l'override del comportamento di cancellazione SDK predefinito, l'app può eseguire la registrazione per MAMNotificationTypeWIPE_USER_DATA.

L'override del comportamento di cancellazione SDK predefinito comporta rischi considerevoli 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 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 il tentativo di leggere i dati crittografati normalmente.
• Il gestore di cancellazione dell'app può causare la perdita di dati per gli utenti non gestiti, se rimuove i file che non sono 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.protectForOID) in un'identità non gestita o in una stringa vuota.

Il gestore di cancellazione ignorato dovrebbe cancellare i dati in modo sincrono e non tornare 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 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 Entra 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 e il Portale aziendale Intune; non accedere prima di iniziare il test.

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 e il Portale aziendale Intune; accedere con un account gestito e non gestito prima di iniziare il test.

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 e il Portale aziendale Intune; accedere con un account gestito e 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:

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:

Se l'app è in grado 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 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.

Convalida degli scenari di cancellazione selettiva

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

Per questi test, installare l'app e il Portale aziendale Intune; accedere con un account gestito e non gestito prima di iniziare il test. Per entrambi gli account, scenari di app di esercitazione in cui sono memorizzati i dati dell'account.

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: Configurazione app e Fase 7: Funzionalità di partecipazione all'app, possono essere necessarie o meno, a seconda del supporto dei criteri di protezione dell'app desiderato. Se non sei sicuro che una di queste sezioni sia applicabile alla tua app, rivedi Decisioni chiave per l'integrazione dell'SDK.