App Intune SDK per Android - MAM Integration Essentials

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 4: Elementi essenziali per l'integrazione MAM

Obiettivi della fase

• Abilitare la modalità severa MAM.
• Registrati per le notifiche critiche dall'SDK.
• Implementare e registrare un callback di autenticazione per fornire token Microsoft Entra da MSAL all'SDK.
• Registrare i nuovi account per la gestione di MAM dopo l'autenticazione con MSAL.
• Annulla la registrazione degli account alla disconnessione per rimuovere i dati aziendali.
• (Scelta consigliata) Incorpora l'accesso MAM nella tua app.
• (Scelta consigliata) Informazioni su come usare la finestra di dialogo di diagnostica SDK.

Background

Dopo aver scaricato l'SDK per app di Intune, averlo integrato nella compilazione ed eseguito correttamente le sostituzioni di classi e metodi, è il momento di apportare le modifiche essenziali al codice per iniziare ad applicare le impostazioni dei criteri di protezione delle app per gli account protetti da MAM.

Questa fase spiega come connettersi alla registrazione dell'SDK, richiamare una finestra di dialogo di diagnostica, abilitare la modalità MAM Strict per identificare possibili bug di integrazione, registrarsi per le notifiche dall'SDK e, soprattutto, come registrare un account per Intune MAM per iniziare a ricevere i criteri.

Modalità severa MAM

La modalità MAM Strict è in grado di identificare potenziali bug nell'integrazione dell'applicazione di Intune App SDK. Questi bug di integrazione possono causare errori nell'applicazione corretta dei criteri di protezione delle app e lasciare i dati aziendali non protetti. Di conseguenza, è necessario usare la modalità MAM Strict.

La modalità MAM strict cerca le anomalie nell'utilizzo delle API MAM e delle API della piattaforma con restrizioni MAM da parte dell'applicazione. Modellata in modo approssimativo su StrictMode di Android, la modalità Strict MAM esegue un set predefinito di controlli che generano errori di runtime quando hanno esito negativo. La modalità MAM Strict non deve essere lasciata abilitata nelle build di produzione; Usalo invece nelle build di sviluppo interne, debug e/o dogfood della tua app.

Per abilitare la modalità severa MAM, chiamare il metodo seguente all'inizio dell'inizializzazione dell'applicazione, ad esempio: Application.onCreate

MAMStrictMode.enable();

Quando un controllo della modalità MAM Severa ha esito negativo, prova a determinare se si tratta di un problema reale che può essere risolto nella tua app o di un falso positivo. Se si ritiene che sia un falso positivo o non si è sicuri, informa il team MAM di Intune. In questo modo sarà possibile essere d'accordo con la determinazione del falso positivo e tentare di migliorare il rilevamento per le versioni future. Per eliminare i falsi positivi, disabilitare il controllo non riuscito seguendo le istruzioni riportate di seguito.

Gestione delle violazioni

Quando un controllo ha esito negativo, esegue un MAMStrictViolationHandler. Il gestore predefinito genera un Errorarresto anomalo dell'app. Questo per rendere gli errori il più rumorosi possibile e si adatta all'intenzione che la modalità strict non debba essere abilitata nelle build di produzione.

Se l'app vuole gestire le violazioni in modo diverso, può fornire il proprio gestore chiamando il metodo seguente in cui handler implementa MAMStrictViolationHandler:

MAMStrictMode.global().setHandler(handler);

Eliminazione dei controlli

Se un controllo non riesce in una situazione in cui l'app non esegue operazioni errate, segnalarlo come indicato in precedenza. Nel frattempo, potrebbe essere necessario disabilitare il controllo riscontrando un falso positivo, almeno in attesa di un SDK aggiornato. Il controllo non riuscito verrà visualizzato nell'errore generato dal gestore predefinito o verrà passato a un gestore personalizzato, se impostato.

Anche se le eliminazioni possono essere eseguite a livello globale, è preferibile disabilitare temporaneamente il thread nel sito di chiamata specifico. Gli esempi seguenti mostrano vari modi per disabilitare MAMStrictCheck.IDENTITY_NO_SUCH_FILE (sollevato se viene fatto un tentativo di proteggere un file che non esiste).

Per-Thread Soppressione temporanea

Questo è il meccanismo di soppressione preferito.

try (StrictScopedDisable disable = MAMStrictMode.thread().disableScoped(MAMStrictCheck.IDENTITY_NO_SUCH_FILE)) {
    // Perform the operation which raised a violation here
}
// The check is no longer disabled once the block exits

Per-Thread Soppressione permanente

MAMStrictMode.thread().disable(MAMStrictCheck.IDENTITY_NO_SUCH_FILE);

Eliminazione globale (a livello di processo)

MAMStrictMode.global().disable(MAMStrictCheck.IDENTITY_NO_SUCH_FILE);

Registrati per le notifiche dall'SDK

L'SDK dell'app Intune emette molti tipi diversi di notifiche per informare le applicazioni delle operazioni di gestione sensibili al tempo. L'applicazione può registrarsi e intervenire quando riceve una qualsiasi di queste notifiche.

Ad esempio, ogni volta che un amministratore IT esegue un comando di cancellazione selettiva per un dispositivo, il servizio Intune invia una notifica all'SDK, che viene passata all'applicazione come WIPE_USER_DATA. L'applicazione può ascoltare questa notifica e controllare quali dati vengono cancellati; oppure può basarsi sul comportamento di cancellazione predefinito dell'SDK.

Molte notifiche sono facoltative. A seconda delle funzionalità SDK usate dall'applicazione, potrebbero essere necessarie alcune notifiche. Per informazioni dettagliate su come eseguire la registrazione alle notifiche, quali notifiche vengono recapitate dall'SDK e su come gestire tipi di notifica specifici, vedere Registrazione per le notifiche dall'SDK nella fase 7: Funzionalità di partecipazione all'app

Registrazione per i criteri di protezione delle app

Quando gli amministratori creano criteri di protezione delle app, li indirizzano ad account specifici nell'organizzazione. Nel client, l'SDK deve sapere quale account sta utilizzando l'applicazione in modo da poter recuperare i criteri di tale account e applicare le impostazioni in modo appropriato. L'app è responsabile di fornire all'SDK queste informazioni sull'account. Questo processo è chiamato registrazione.

Ogni volta che l'app aggiunge un nuovo account, deve registrare l'account nell'SDK, anche se altri account sono già registrati. L'app può registrare più account. Tuttavia, attualmente è possibile registrare un solo account o applicare criteri di protezione delle app. In Android, questa limitazione dell'account gestito singolo è a livello di dispositivo.

Registrazione vs Iscrizione

La registrazione è il processo con il quale l'app informa l'SDK che è in uso un nuovo account. L'SDK contiene le funzioni che l'app deve chiamare per registrare e annullare la registrazione degli account.

La registrazione è il processo in cui l'SDK registra l'account registrato con il servizio Intune in modo da poter applicare i criteri dell'account. L'app non deve chiamare alcuna funzione per la registrazione. L'SDK gestisce completamente la registrazione dopo la registrazione di un account.

Se un account è già registrato per l'applicazione, quando registra un altro account, anche se tale account è destinato ai criteri di protezione delle app, il secondo account non verrà registrato e i criteri non verranno applicati.

Implementazione della registrazione

Per registrare correttamente un account, l'app deve apportare tre modifiche al codice:

1. L'app deve implementare e registrare un'istanza dell'interfaccia MAMServiceAuthenticationCallback o MAMServiceAuthenticationCallbackExtended . L'istanza onCreate() di callback deve essere registrata nel metodo (o onMAMCreate()) della sottoclasse Application.

2. Quando viene creato un account e l'utente esegue correttamente l'accesso con MSAL, l'app deve chiamare registerAccountForMAM.

3. Quando un account viene rimosso, l'app deve chiamare unregisterAccountForMAM per rimuovere l'account dalla gestione di Intune.

   Attenzione

   La chiamata potrebbe avviare una cancellazione per rimuovere completamente i dati aziendali per l'account.

Tutte le API di autenticazione e registrazione necessarie sono disponibili nell'interfaccia MAMEnrollmentManager . Un riferimento al MAMEnrollmentManager può essere ottenuto come segue:

MAMEnrollmentManager mgr = MAMComponents.get(MAMEnrollmentManager.class);

// make use of mgr

L'istanza MAMEnrollmentManager restituita non è Null. I metodi API si dividono in due categorie: autenticazione e registrazione dell'account.

MAMEnrollmentManager e autenticazione

L'SDK comunica spesso con il servizio Intune: per registrare gli account registrati, per ottenere gli aggiornamenti delle impostazioni dei criteri di protezione delle app e per ottenere azioni amministrative in sospeso, come la cancellazione selettiva dei dati protetti all'interno dell'app. Per comunicare correttamente con il servizio Intune, l'SDK richiede nuovi token di accesso dalle app con MSAL integrato.

Se l'SDK non è in grado di recuperare un nuovo token, non sarà in grado di comunicare con il servizio Intune, il che può ritardare il recupero e l'applicazione di nuove impostazioni dei criteri o azioni di amministrazione. È fondamentale che l'app completi questi passaggi per garantire un'applicazione uniforme dei criteri.

Nella fase 2 è stato integrato MSAL nell'applicazione per l'autenticazione e l'acquisizione di token di accesso. In questo caso, si implementa un callback di autenticazione per consentire all'SDK di richiedere i token necessari.

MAMEnrollmentManager dispone dei seguenti metodi di autenticazione:

interface MAMServiceAuthenticationCallback {
    String acquireToken(String upn, String aadId, String resourceId);
}
interface MAMServiceAuthenticationCallbackExtended extends MAMServiceAuthenticationCallback {
    String acquireToken(String upn, String aadId, String tenantId, String authority, String resourceId);
}
void registerAuthenticationCallback(MAMServiceAuthenticationCallback callback);
void updateToken(String upn, String aadId, String resourceId, String token);

1. L'app deve implementare l'interfaccia MAMServiceAuthenticationCallback o l'interfaccia MAMServiceAuthenticationCallbackExtended per consentire all'SDK di richiedere un token Microsoft Entra per l'account e l'ID risorsa specificati. L'istanza di callback deve essere fornita al chiamando il MAMEnrollmentManager metodo registerAuthenticationCallback . Un token potrebbe essere necessario all'inizio del ciclo di vita dell'app per i tentativi di registrazione o per le onCreate() archiviazioni di aggiornamento dei criteri di protezione delle app, quindi il callback deve essere registrato nel metodo (Or onMAMCreate()) della sottoclasse dell'app Application .

2. Il acquireToken metodo deve acquisire il token di accesso per l'ID risorsa richiesto per l'account specificato. Se non riesce ad acquisire il token richiesto, deve restituire null.

   Consiglio

   Assicurarsi che l'app utilizzi i resourceId parametri e passati aadId a acquireToken() in modo che venga acquisito il token corretto. Il upn parametro ha solo scopo informativo; non deve essere utilizzato per identificare un account senza considerare anche il parametro aadId. Devono resourceId essere utilizzati per generare gli ambiti appropriati e devono aadId essere utilizzati per passare l'account corretto. Se i token vengono restituiti per l'account e/o la risorsa errati, potrebbero causare ritardi o errori nella registrazione dell'app e nel recupero dei criteri. Se l'app richiede l'autorità Microsoft Entra per acquisire correttamente il token, implementare l'interfacciaMAMServiceAuthenticationCallbackExtended.

   class MAMAuthCallback implements MAMServiceAuthenticationCallbackExtended {
       public String acquireToken(String upn, String aadId,
                   String tenantId, String authority, String resourceId) {
           final String[] scopes = {resourceId + "/.default"};
   
           final IAccount account = getAccount(aadId);
           if (account == null) {
               // Log error or warning here about: "no account found for " + aadId
               return null;
           }
   
           AcquireTokenSilentParameters params =
               new AcquireTokenSilentParameters.Builder()
                       .forAccount(account)
                       .fromAuthority(account.getAuthority())
                       .withScopes(Arrays.asList(scopes))
                       .withCallback(callback)
                       .build();
   
           return mMsalClientApplication.acquireTokenSilent(params);
       }
   
       private static IAccount getAccount(String aadId) throws InterruptedException, MsalException {
         IAccount account = null;
   
         if (mMsalClientApplication instanceof IMultipleAccountPublicClientApplication) {
             IMultipleAccountPublicClientApplication multiAccountPCA =
                     (IMultipleAccountPublicClientApplication) mMsalClientApplication;
   
             account = multiAccountPCA.getAccount(aadId);
         } else {
             ISingleAccountPublicClientApplication singleAccountPCA =
                     (ISingleAccountPublicClientApplication) mMsalClientApplication;
   
             ICurrentAccountResult accountResult = singleAccountPCA.getCurrentAccount();
             if (accountResult != null) {
                 account = accountResult.getCurrentAccount();
                 // make sure this is the correct user
                 if (account != null && !account.getId().equals(aadId))
                     account = null;
             }
         }
         return account;
     }
   }
   

3. Nel caso in cui l'app non sia in grado di fornire un token quando l'SDK chiama acquireToken() , ad esempio se l'autenticazione invisibile all'utente non riesce ed è un momento scomodo per mostrare un'interfaccia utente, l'app può fornire un token in un secondo momento chiamando il metodo updateToken . Lo stesso UPN, Microsoft Entra ID e ID risorsa richiesti dalla chiamata precedente a devono essere passati a , insieme al acquireToken()updateToken()token che è stato infine acquisito. Il upn parametro ha solo scopo informativo e viene generalmente ignorato dall'SDK MAM. L'app deve chiamare questo metodo il prima possibile dopo aver restituito Null dal callback fornito.

   Avviso

   Non chiamare updateToken() dall'interno dell'implementazione di acquireToken(). updateToken() deve essere usato nel caso in cui acquireToken() non sia possibile acquisire un token.

   Nota

   L'SDK chiamerà acquireToken() periodicamente per ottenere il token, quindi la chiamata updateToken() non è strettamente necessaria. Tuttavia, è fortemente consigliato in quanto può aiutare a completare le registrazioni e le archiviazioni dei criteri di protezione delle app in modo tempestivo.

Note sull'implementazione dell'autenticazione

• Le app sono incoraggiate ad acquisire i token Microsoft Entra prima di chiamare registerAccountForMAM. Dopo aver registrato un account, le app riceveranno un callback al metodo registrato MAMServiceAuthenticationCallbacksu acquireToken() un thread diverso. Fornire un token valido in tale callback consente alla registrazione di procedere. L'app ottiene il risultato della registrazione tramite notifica.

• Se l'app non restituisce un token Microsoft Entra valido, il risultato finale del tentativo di registrazione saràAUTHORIZATION_NEEDED. Se l'app riceve questo risultato tramite notifica, è consigliabile accelerare il processo di registrazione acquisendo il token per l'account e la risorsa precedentemente richiesti ad acquireToken e chiamando il metodo updateToken per avviare nuovamente il processo di registrazione.

• Il server registrato MAMServiceAuthenticationCallback dell'app sarà anche chiamato ad acquisire un token per le archiviazioni periodiche dei criteri di protezione delle app. Se l'app non è in grado di fornire un token quando richiesto, non riceverà una notifica, ma dovrebbe tentare di acquisire un token e chiamare updateToken() al momento opportuno per accelerare il processo di archiviazione. Se non viene fornito un token, il callback potrebbe comunque essere chiamato al successivo tentativo di archiviazione.

• Il supporto per i cloud sovrani richiede di fornire l'autorità.

• Se MAMServiceAuthenticationCallbackExtended l'interfaccia è implementata, non è necessario implementare il metodo ereditato acquireToken() da MAMServiceAuthenticationCallback , poiché l'interfaccia fornisce un'implementazione MAMServiceAuthenticationCallbackExtended predefinita.

MAMEnrollmentManager e registrazione

Ogni volta che l'app aggiunge un account, deve registrarlo nell'SDK. Analogamente, ogni volta che l'app rimuove un account, dovrebbe annullare la registrazione dell'account per indicare che l'app non deve più applicare i criteri per quell'account. Se l'account è stato registrato nel servizio MAM, la registrazione dell'account viene annullata e l'app verrà cancellata.

MAMEnrollmentManager dispone dei seguenti metodi di registrazione dell'account:

void registerAccountForMAM(String upn, String aadId, String tenantId);
void registerAccountForMAM(String upn, String aadId, String tenantId, String authority);
void unregisterAccountForMAM(String upn, String aadId);
Result getRegisteredAccountStatus(String upn, String aadId);

1. Per registrare un account per la gestione, l'app deve chiamare registerAccountForMAM(). Un account è identificato dal nome UPN e dall'ID utente di Microsoft Entra. L'ID tenant è necessario anche per associare i dati di registrazione al tenant di Microsoft Entra dell'account. L'autorità dell'account può anche essere fornita per consentire la registrazione su specifici cloud sovrani; Per ulteriori informazioni, consulta Registrazione di Sovereign Cloud. L'SDK può tentare di registrare l'app per l'account specificato nel servizio MAM; Se la registrazione non riesce, ritenterà periodicamente la registrazione finché la registrazione non avrà esito positivo o l'account non verrà annullato. Il periodo di ripetizione dei tentativi è in genere di 12-24 ore. L'SDK fornisce lo stato dei tentativi di registrazione in modo asincrono tramite notifiche.

2. Il momento migliore per chiamare registerAccountForMAM è dopo che l'utente ha eseguito l'accesso all'app e si è autenticato con MSAL. L'ID utente di Microsoft Entra, l'ID tenant e l'autorità dell'account vengono restituiti dalla chiamata di autenticazione MSAL come parte della IAccount relazione a IAuthenticationResult.

   • L'account proviene dal metodo e contiene le informazioni relative all'account IAuthenticationResult.getAccount() .
   • L'ID AAD (noto anche come Microsoft Entra ID o OID) deriva dal IAccount.getId() metodo.
   • L'ID IAccount.getTenantId() tenant proviene dal metodo.
   • L'autorità IAccount.getAuthority() deriva dal metodo.

3. Per annullare la registrazione di un account dalla gestione di Intune, l'app deve chiamare unregisterAccountForMAM(). Se l'account è stato registrato correttamente ed è gestito, l'SDK annulla la registrazione dell'account e cancella i dati. I tentativi di registrazione periodica per l'account verranno interrotti. L'SDK fornisce lo stato delle richieste di annullamento della registrazione in modo asincrono tramite notifica.

Note sull'implementazione della registrazione

• I metodi di registrazione sono idempotenti. Ad esempio, registerAccountForMAM registrerà un account e tenterà di registrare l'app solo se l'account non è già registrato e unregisterAccountForMAM annullerà la registrazione di un account solo se è attualmente registrato. Le chiamate successive non sono operative, quindi non c'è nulla di male nel chiamare questi metodi più di una volta.

• Non c'è alcuna garanzia che ogni chiamata di registrazione/annullamento della registrazione abbia una notifica dei risultati corrispondente. Ad esempio, se registerAccountForMAM() viene chiamata per un account già registrato, la notifica potrebbe non essere inviata di nuovo per tale identità. In alternativa, l'SDK può inviare notifiche anche quando l'app non ha chiamato questi metodi, poiché l'SDK può tentare periodicamente le registrazioni in background e le disregistrazioni possono essere attivate dalle richieste di cancellazione ricevute dal servizio Intune.

• I metodi di registrazione possono essere chiamati per un numero qualsiasi di account diversi, ma attualmente solo un account può essere registrato correttamente. Se più account concessi in licenza per Intune e destinati con criteri di protezione delle app vengono registrati contemporaneamente o quasi, non c'è alcuna garanzia su quale vincerà la gara.

• È possibile interrogare MAMEnrollmentManager per verificare se un particolare account è registrato e per ottenere il suo stato corrente utilizzando il metodo getRegisteredAccountStatus . Se l'account fornito non viene registrato, questo metodo restituisce Null. Se l'account è registrato, questo metodo restituisce lo stato dell'account come uno dei membri dell'enumerazione MAMEnrollmentManager.Result .

Registrazione Sovereign Cloud

Azure supporta più cloud fisicamente isolati, noti come cloud sovrani o nazionali. Se l'applicazione è compatibile con il cloud sovrano, deve fornire il authority parametro a registerAccountForMAM().

Indicazioni MSAL

Per MSAL, impostato multiple_clouds_supported su true nel file di configurazione MSAL.

{
  "multiple_clouds_supported": true,
}

Codici di risultato e di stato della registrazione

Quando un account viene registrato per la PENDING prima volta, inizia nello stato, indicando che il tentativo iniziale di registrazione del servizio MAM è incompleto. Al termine del tentativo di registrazione, verrà inviata una notifica con uno dei codici di risultato riportati nella tabella seguente. Inoltre, il metodo getRegisteredAccountStatus restituisce lo stato dell'account in modo che l'app possa sempre determinare se sono stati applicati criteri di protezione dell'app. Se il tentativo di registrazione non riesce, lo stato dell'account potrebbe cambiare nel tempo quando l'SDK ritenta la registrazione in background.

(Scelta consigliata) Registrazione

La registrazione deve essere inizializzata in anticipo per ottenere il massimo valore dai dati registrati. Application.onMAMCreate() è in genere il posto migliore per inizializzare la registrazione.

Per ricevere i log MAM nell'app, creare un gestore Java e aggiungerlo a MAMLogHandlerWrapper. Richiama il gestore applicazioni per ogni messaggio di publish() log.

/**
 * Global log handler that enables fine grained PII filtering within MAM logs.
 * To start using this you should build your own log handler and add it via
 * MAMComponents.get(MAMLogHandlerWrapper.class).addHandler(myHandler, false);
 * You may also remove the handler entirely via
 * MAMComponents.get(MAMLogHandlerWrapper.class).removeHandler(myHandler);
 */
public interface MAMLogHandlerWrapper {
    /**
     * Add a handler, PII can be toggled.
     * @param handler handler to add.
     * @param wantsPII if PII is desired in the logs.
     */
    void addHandler(final Handler handler, final boolean wantsPII);

    /**
     * Remove a handler.
     * @param handler handler to remove.
     */
    void removeHandler(final Handler handler);
}

(Scelta consigliata) Informazioni di diagnostica

L'app Portale aziendale Intune offre diverse opzioni per la raccolta di informazioni diagnostiche. Il Portale aziendale include un'interfaccia utente che:

• Consente agli utenti finali di raccogliere i log del Portale aziendale.
• Visualizza i metadati del dispositivo e dell'account.
• Include informazioni per app sui criteri MAM correnti.

Intune

Per una spiegazione dettagliata dei dati inclusi nei log del Portale aziendale e nell'interfaccia utente di diagnostica, vedere Informazioni sui log del Portale aziendalenell'appendice.

Le app possono avviare questa interfaccia utente di diagnostica richiamando MAMPolicyManager.showDiagnostics(context). Gli utenti finali possono anche avviare la console di diagnostica del Portale aziendale tramite Microsoft Edge, immettendo about:intunehelp la barra degli indirizzi. Questa è una funzionalità facoltativa che può essere utile per il debug.

Queste informazioni di diagnostica sono disponibili solo quando il Portale aziendale è installato nel dispositivo. Viene visualizzata una finestra di dialogo di avviso ogni volta showDiagnostics che viene chiamata senza che sia installato il Portale aziendale.

Criteri di chiusura

A questo punto dell'integrazione, l'app può ora ricevere e applicare i criteri di protezione delle app. Eseguire i test seguenti per convalidare l'integrazione.

Test dell'applicazione primo criterio

Eseguire prima di tutto il test seguente per acquisire familiarità con l'esperienza utente finale completa dell'applicazione dei criteri all'interno dell'app:

1. Creare un criterio di protezione delle app Android nell'interfaccia di amministrazione di Microsoft Intune. Per informazioni dettagliate, vedere Creazione di un criterio di protezione delle app Android di test nella fase 1. Per questo test, configurare i criteri:
   • Alla voce Protezione dei dati, imposta "Acquisizione schermo e Assistente Google" su "Blocca".
   • In Requisiti di accesso lasciare le impostazioni predefinite. In particolare, "PIN per l'accesso" deve essere "Richiedi".
2. Assicurarsi che i criteri di protezione delle app siano destinati all'applicazione. Probabilmente sarà necessario aggiungere manualmente il nome del pacchetto nella procedura guidata di creazione dei criteri.
3. Assegnare i criteri di protezione delle app a un gruppo di utenti contenente l'account di test.
4. In un dispositivo Android di test disinstalla altre app integrate nell'SDK, come Microsoft Outlook, Teams, OneDrive e Office. Disinstallare anche l'app Portale aziendale Intune e l'app Microsoft Authenticator.

   • Consiglio

     La disinstallazione di altre app integrate nell'SDK garantisce che tu stia testando esclusivamente l'integrazione della tua app.

5. Installare l'applicazione.
6. Accedere all'applicazione con l'account di test destinato ai criteri di protezione delle app.
7. Verificare che venga chiesto di installare il Portale aziendale Intune da Google Play.

   • Nota

     Se il dispositivo di test non ha l'app Google Play Store, verificare che venga chiesto di installare il Portale aziendale Intune da un altro app store o da un sito Web Microsoft.

8. Installare il Portale aziendale. Non è necessario avviare il Portale aziendale o accedere al Portale aziendale.
9. Torna all'app e accedi di nuovo, se necessario.
10. Conferma che ti viene richiesta una schermata Ottieni accesso. Ciò indica che l'SDK ha recuperato correttamente i criteri per questo account.
11. Verrà richiesto di impostare un PIN dell'app. Creare un PIN.
12. Spostarsi all'interno dell'applicazione e provare a acquisire screenshot. Dato che l'SDK ha dei criteri, questo dovrebbe essere bloccato in modo coerente su qualsiasi schermata.
13. Disconnettere l'account gestito dall'applicazione.
14. Se possibile senza eseguire l'accesso, spostarsi all'interno dell'applicazione e provare a acquisire screenshot. Ora che l'account è stato rimosso, non dovrebbe essere bloccato.

Si tratta di un test minimo indispensabile per verificare che l'app abbia registrato correttamente l'account, registrato il callback di autenticazione e annullato la registrazione dell'account. Eseguire i test seguenti per convalidare in modo più approfondito il modo in cui altre impostazioni dei criteri di protezione delle app modificano il comportamento dell'applicazione.

Test di protezione dei dati

I test seguenti illustrano le impostazioni specifiche di protezione dei dati configurate all'interno dei criteri di protezione delle app. Quando si modificano le impostazioni dei criteri di protezione delle app nell'interfaccia di amministrazione di Microsoft Intune, il client non verrà aggiornato immediatamente. Per suggerimenti su come velocizzare i test, vedere Test rapidi con la modifica dei criteri .

Per questi test:

1. Installare l'app.
2. Installare il Portale aziendale Intune.
3. Installare un'altra app gestita, destinata con gli stessi criteri dell'app, in grado di copiare e incollare i dati, ad esempio Microsoft Office.
4. Installare (o riutilizzare) qualsiasi app non gestita in grado di copiare e incollare dati.
5. Accedere all'app con l'account gestito di test.
6. Accedere all'altra app gestita con l'account di test gestito.

Test di trasferimento dati

Le impostazioni di trasferimento dei dati sono un sottoinsieme delle funzionalità di protezione dei dati dei criteri di protezione delle app che controllano i dati in entrata e in uscita dalle app gestite. La maggior parte delle app che supportano l'invio o la ricezione di dati da altre app ha anche la possibilità di salvare e aprire dati dall'archiviazione locale o nel cloud. Se l'app include queste funzionalità, dovrai implementare un supporto aggiuntivo. Per informazioni dettagliate, vedi Criteri per limitare il trasferimento dei dati tra app e dispositivi o posizioni di archiviazione nel cloud .

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 "Ricevi dati da altre app" copre entrambi gli scenari.

Per questi test:

1. Installare l'app.
2. Installare il Portale aziendale Intune.
3. Installare un'altra app gestita, destinata con gli stessi criteri dell'app, in grado di inviare e ricevere dati, ad esempio Microsoft Outlook.
4. Installare (o riutilizzare) qualsiasi app non gestita in grado di inviare e ricevere dati.
5. Accedere all'app con l'account gestito di test.
6. Accedere all'altra app gestita con l'account di test gestito.

Altre impostazioni di protezione dei dati

Le impostazioni di protezione dei dati seguenti non verranno applicate fino a quando l'app non apporterà ulteriori modifiche. Non è necessario testare queste impostazioni in questa fase. Vedi Fase 7: Funzionalità di partecipazione all'app per maggiori dettagli.

Test di avvio condizionale

Le impostazioni di avvio condizionale sono un sottoinsieme delle funzionalità dei criteri di protezione delle app che limitano l'accesso all'app in base a criteri configurabili a livello di dispositivo o specifici dell'app. Queste impostazioni includono sia le condizioni (ad esempio "la versione minima del sistema operativo") che le azioni (ad esempio "blocca accesso"). Le azioni di avvio condizionale possono essere le seguenti:

• Avviso: l'utente finale visualizza una finestra di dialogo di avviso quando il dispositivo o l'app non soddisfa i criteri. Avranno comunque accesso a tutti i dati dell'app.
• Blocca accesso: l'utente finale visualizza una finestra di dialogo di avviso quando il dispositivo o l'app non soddisfa i criteri. Non potranno entrare nell'app e accedere ai dati dell'app finché non soddisfano i criteri o rimuovono l'account gestito dall'app.
• Cancella dati: tutti i dati aziendali associati all'account gestito verranno cancellati quando il dispositivo o l'app non soddisfa i criteri. L'utente non avrà l'opportunità di soddisfare i criteri prima che i dati vengano rimossi.

Alcune impostazioni di avvio condizionale possono essere configurate con più valori e azioni. Ad esempio:

• Versione minima del sistema operativo, valore "10.0", azione impostata su "Warn".
• Versione minima del sistema operativo, valore "9.0", azione impostata su "Blocca accesso"
• Versione minima del sistema operativo, valore "8.0", azione impostata su "Cancella dati".

Completando i passaggi di integrazione in questa fase, l'app supporta ora tutte le funzionalità di avvio condizionale. Acquisire familiarità con la funzionalità di avvio condizionale modificando gli elementi dei criteri in modo che il dispositivo di test:

• Supera tutte le impostazioni di avvio condizionale configurate.
• Non riesce un'impostazione di avvio condizionale configurata impostata sull'azione "Avvisa".
• Non riesce a configurare un'impostazione di avvio condizionale impostata sull'azione "Blocca accesso".
• Non riesce a configurare un'impostazione di avvio condizionale impostata sull'azione "Cancella dati".

Risoluzione dei problemi

Primo criterio Risoluzione dei problemi dei test dell'applicazione

Seguendo i passaggi precedenti del test dell'applicazione del primo criterio , è possibile che si verifichino i seguenti comportamenti imprevisti:

Dopo aver eseguito l'accesso con un account gestito, non viene chiesto di installare il Portale aziendale (passaggio 7)

Visita prima di tutto l'interfaccia di amministrazione di Intune e verifica che i criteri di protezione dell'app siano destinati all'account di test.

Verificare quindi che il codice sorgente non effettui registerAccountForMAM chiamate e implementazioni di MAMServiceAuthenticationCallback. Se il primo non viene chiamato al momento giusto e/o il secondo non ha fornito correttamente un token valido, non verrà visualizzato il prompt del Portale aziendale.

Infine, cercare nei log (o nel debug) il codice di risultato della registrazione oppure chiamare getRegisteredAccountStatus esplicitamente l'account. Codici come NOT_LICENSED possono indicare problemi di configurazione con l'account di test.

La schermata Ottieni accesso non è stata visualizzata dopo l'accesso (passaggio 10)

Se il Portale aziendale non è stato installato in precedenza, potrebbe essere necessario riprendere o riavviare completamente l'applicazione per visualizzare la schermata Ottieni accesso e applicare correttamente i criteri. Si tratta di un risultato previsto in base al modo in cui le app integrate nell'SDK sfruttano il codice all'interno dell'app Portale aziendale.

Se la schermata Ottieni accesso non viene ancora visualizzata, anche dopo aver riavviato l'app e aver eseguito di nuovo l'accesso, è possibile che l'SDK non riesca a registrare l'account o a recuperare i criteri per l'account. Ricontrollare l'implementazione del codice sorgente di MAMServiceAuthenticationCallback.

Non ho visualizzato la schermata per impostare o immettere un PIN dell'app dopo l'accesso (passaggio 11)

Ci sono altre applicazioni integrate nell'SDK sul tuo dispositivo di test? Il PIN dell'app è condiviso tra tutte le app gestite e l'SDK ha un timer globale per evitare che agli utenti finali venga richiesto il PIN a ogni avvio o ripresa dell'app gestita.

In caso contrario, visitare l'interfaccia di amministrazione di Intune e verificare che il criterio di protezione dell'app abbia il PIN dell'app abilitato e sia destinato all'account di test.

Come ultima risorsa, il riavvio del dispositivo reimposterà il timer del PIN. Se la schermata del PIN non viene visualizzata dopo il riavvio del dispositivo, è probabile che non sia configurato correttamente nel criterio.

Viene visualizzata la schermata Ottieni accesso, ma gli screenshot sono ancora consentiti (passaggio 12)

Durante il recupero del criterio, è stato applicato il criterio errato. Visita prima di tutto l'interfaccia di amministrazione di Intune e verifica che i criteri di protezione dell'app disabilitino gli screenshot e siano destinati all'account di test. Usa quindi la console di diagnostica (descritta sopra) per controllare i criteri che sono stati estratti per la tua app. Se entrambe le politiche confermano che gli screenshot devono essere bloccati, controllare la configurazione del plug-in di compilazione Gradle per assicurarsi che vengano apportate sostituzioni MAM.

L'app sembrava bloccarsi o arrestarsi dopo la disconnessione (passaggio 13)

Quando annulli la registrazione di un account registrato in precedenza e i cui criteri sono stati applicati, i dati associati a tale account verranno cancellati dall'SDK. È prevista la chiusura del processo dell'app.

Gli screenshot sono ancora bloccati anche dopo che mi sono disconnesso (passaggio 14)

Controllare il codice sorgente per le chiamate a unregisterAccountForMAM(). Se il criterio viene ancora applicato dopo la disconnessione, è probabile che l'account non sia stato correttamente annullato e registrato.

Risoluzione dei problemi del test di protezione dei dati

Seguendo la procedura precedente dei test di protezione dei dati , è possibile che si verifichino i seguenti comportamenti imprevisti:

L'app non riceve o non applica alcun criterio

Verificare prima di tutto che i criteri di protezione dell'app siano destinati a un gruppo contenente l'account di test. Per informazioni dettagliate, vedere Come convalidare la configurazione dei criteri di protezione delle app in Microsoft Intune.

Controllare quindi le informazioni di diagnostica del client per verificare che l'SDK abbia ricevuto il criterio configurato. In caso contrario, controlla l'implementazione dell'app MAMServiceAuthenticationCallback e chiama .registerAccountForMAM Controllare anche i log o eseguire il debug per verificare il MAMEnrollmentManager.Resultfile .

L'app può condividere dati con un'app non gestita

Verificare che "Invia dati dell'organizzazione ad altre app" sia impostato su "App gestite da criteri". Controllare l'interfaccia di amministrazione di Microsoft Intune per verificare che il criterio sia configurato e destinato correttamente. Controllare le informazioni di diagnostica del client per verificare che l'SDK abbia ricevuto il criterio configurato.

Se quindi il criterio viene configurato e recuperato correttamente, verificare se alcuni criteri vengono applicati: L'app non riceve o applica alcun criterio.

L'app non può condividere dati con un'altra app gestita

Confermare le impostazioni dei criteri di protezione delle app destinate sia all'app che all'altra app gestita. È consigliabile fare in modo che lo stesso criterio sia destinato a entrambe le app. Il criterio destinato all'app deve avere "Invia dati dell'organizzazione ad altre app" impostato su "App gestite da criteri". Controllare i criteri destinati all'altra app. se "Ricevi dati da altre app" è impostato su "Nessuno", questo comportamento è previsto.

L'app può ricevere dati da un'app non gestita

Verificare che "Ricevi dati da altre app" sia impostato su "App gestite da criteri". Controllare l'interfaccia di amministrazione di Microsoft Intune per verificare che il criterio sia configurato e destinato correttamente. Controllare le informazioni di diagnostica del client per verificare che l'SDK abbia ricevuto il criterio configurato.

Se quindi il criterio viene configurato e recuperato correttamente, verificare se alcuni criteri vengono applicati: L'app non riceve o applica alcun criterio.

L'app non può ricevere dati da un'altra app gestita

Confermare le impostazioni dei criteri di protezione delle app destinate sia all'app che all'altra app gestita. È consigliabile fare in modo che lo stesso criterio sia destinato a entrambe le app. Il criterio di destinazione dell'app deve avere "Ricevi dati da altre app" impostato su "App gestite da criteri". Controllare i criteri destinati all'altra app. se l'opzione "Invia dati dell'organizzazione ad altre app" è impostata su "Nessuna", questo comportamento è previsto.

Operazioni successive

Dopo aver completato tutti i criteri di uscita precedenti, l'app è ora integrata correttamente come identità singola e può applicare tutti i criteri di protezione delle app di base. Le sezioni successive, Fase 5: Multi-identità, Fase 6: Configurazione app e Fase 7: Partecipazione alle app Le funzionalità possono essere necessarie o meno, a seconda del supporto dei criteri di protezione delle app desiderato dall'app. Se non sei sicuro che una di queste sezioni sia applicabile alla tua app, rivedi Decisioni chiave per l'integrazione dell'SDK.