Dela via

Intune App SDK för Android – flera identiteter

  • Artikel

Med Microsoft Intune App SDK för Android kan du införliva Intune-appskyddsprinciper (även kallade APP- eller MAM-principer ) i din interna Java/Kotlin Android-app. Ett Intune-hanterat program är ett program som är integrerat med Intune App SDK. Intune-administratörer kan enkelt distribuera appskyddsprinciper till din Intune-hanterade app när Intune aktivt hanterar appen.

Obs!

Den här guiden är uppdelad i flera olika steg. Börja med att granska steg 1: Planera integreringen.

Steg 5: Flera identiteter

Etappmål

  • Kontrollera om programmet behöver stöd för flera identiteter.
  • Förstå hur Intune App SDK uppfattar identiteter.
  • Omstrukturera ditt program för identitetsmedvetenhet.
  • Lägg till kod för att informera SDK om aktiva och föränderliga identiteter i hela programmet.
  • Testa appskyddsprincipen noggrant för både hanterade och ohanterade identiteter.

Identitetsterminologi

Termerna "användare", "konto" och "identitet" används ofta synonymt. Den här guiden försöker skilja på följande sätt:

  • Användare: den människa som använder programvaruprodukten. Särskiljas ytterligare som slutanvändare, den människa som använder Android-appen och it-administratörsanvändarens / / IT-administratörs-IT / Pro, den som använder Administrationscenter för Microsoft Intune.
  • Konto: programvaruposten som tillhör en organisation som unikt identifierar en användares entitet. En mänsklig användare kan ha flera konton.
  • Identitet: den uppsättning data som Intune App SDK använder för att unikt identifiera ett konto.

Bakgrund

Som standard tillämpar Intune App SDK principen för hela programmet. När du har registrerat ett konto med en appskyddsprincip associerar SDK:t varje fil och varje aktivitet med kontots identitet och tillämpar kontots målprincip universellt.

För många utvecklare är detta det önskade appskyddsbeteendet för deras program. Dessa program betraktas som en enda identitet. Genom att slutföra de föregående stegen har programmet integrerats som en enda identitet och kan tillämpa alla grundläggande principer. Appar som är avsedda att förbli enkla identiteter kan hoppa över det här avsnittet och gå vidare till steg 6: Appkonfiguration.

Intune App SDK kan eventuellt framtvinga principer på identitetsnivå. Om ditt program redan har stöd för flera konton som loggas in samtidigt och du vill behålla det här stöd för flera konton med appskyddsprinciper betraktas ditt program som flera identiteter.

Tips

Om du är osäker på om programmet ska ha stöd för skydd med en identitet eller flera identiteter kan du gå tillbaka till Är mitt program enstaka identitet eller flera identiteter?

Varning

Stöd för flera identiteter är betydligt mer komplext än andra appskyddsfunktioner. Felaktig integrering av flera identiteter kan resultera i dataläckor och andra säkerhetsproblem. Granska det här avsnittet noggrant och planera en omfattande tid för testning innan du fortsätter till nästa steg.

"Identitet" till SDK

När ett SDK-integrerat program registrerar ett konto med hjälp av registerAccountForMAM sparar SDK:t alla angivna parametrar (upn, aadId, tenantId och auktoritet) som identitet. De flesta av SDK:ernas identitets-API:er använder dock bara den angivna upn-strängen som förkortning för identiteten. Dessa API:er returnerar bara upn-strängen som identitet och kräver bara upn-strängparametern för identiteten.

Identiteter är skiftlägeskänsliga. Begäranden till SDK för en identitet kanske inte returnerar samma hölje som användes vid registrering eller inställning av identiteten.

Tips

I framtiden kan SDK-API:erna presentera en mer holistisk identitetsstruktur som innehåller alla fält som tillhandahålls vid kontoregistreringen, inte bara upn. När du integrerar stöd för flera identiteter ska du se till att din app också har åtkomst till aadId, tenantId och auktoritet när du anger identiteten med hjälp av de aktuella API:erna.

Hanterade eller ohanterade identiteter

Enligt beskrivningen i Registrera för appskyddsprincip ansvarar ditt program för att informera SDK:t när en användare loggar in. Vid tidpunkten för inloggningen kan användarens konto vara riktat mot appskyddsprincipen. Om kontot är mål för appskyddsprincipen anser SDK:et att det är hanterat. Annars är den ohanterad.

SDK:n tillämpar principen för identiteter som den anser vara hanterade. SDK:n framtvingar inte principen för identiteter som den anser vara ohanterade.

För närvarande stöder Intune App SDK endast en enda hanterad identitet per enhet. Så snart ett SDK-integrerat program registrerar en hanterad identitet behandlas alla därefter registrerade identiteter, även om de för närvarande är mål för appskyddsprinciper, som ohanterade.

Om en hanterad identitet redan har registrerats på enheten och din app registrerar en annan identitet som också är riktad mot appskyddsprincipen, returnerar SDK:n och uppmanar MAMEnrollmentManager.Result.WRONG_USER slutanvändaren att åtgärda problemet. Mer information finns i Registrera för meddelanden från SDK .

Obs!

Ett konto som inte är mål för appskyddsprincipen vid registreringen betraktas som ohanterat. Även om kontot inte är licensierat för eller målinriktat med appskyddsprincipen kontrollerar SDK regelbundet om det här kontot licensieras och riktas vid ett senare tillfälle. Om ingen annan hanterad identitet har registrerats börjar SDK:n behandla den här identiteten som hanterad när den är riktad mot principen. Användaren behöver inte logga ut och logga in på det här kontot igen för att göra den här ändringen.

Den aktiva identiteten

Ditt program måste alltid hålla SDK:t informerat om den identitet som används, även kallat den aktiva identiteten. Om den aktiva identiteten hanteras tillämpar SDK:t skydd. Om den aktiva identiteten inte hanteras tillämpar SDK:t inte skydd.

Eftersom SDK:n inte har någon programspecifik kunskap måste den lita på att programmet delar rätt aktiv identitet.

  • Om programmet felaktigt meddelar SDK:t att en ohanterad identitet är aktiv när den hanterade identiteten faktiskt används, kommer SDK:t inte att tillämpa skydd. Detta kan orsaka en dataläcka som utsätter användarnas data för risk.

  • Om programmet felaktigt meddelar SDK:t att den hanterade identiteten är aktiv när en ohanterad identitet faktiskt används, tillämpar SDK:t skydd på ett olämpligt sätt. Det här är inte en dataläcka, men det kan i onödan begränsa ohanterade användare och utsätta ohanterade användares data för risk för borttagning.

Om ditt program visar någon användares data får det bara visa data som tillhör den aktiva identiteten. Om ditt program för närvarande inte är medvetet om vem som äger data som visas kan du behöva omstrukturera ditt program för större identitetsmedvetenhet innan du börjar integrera stöd för flera identiteter.

Organisera appdata efter identitet

När ditt program skriver en ny fil associerar SDK:n (kallas även "taggar") en identitet med den filen baserat på den aktuella aktiva tråden och processidentiteten. Alternativt kan appen anropa SDK:t direkt för att manuellt tagga en fil med en viss identitet (mer information finns i Skriva skyddade filer ). SDK använder den här taggade filidentiteten för både filkryptering och selektiv rensning.

Om den hanterade identiteten är riktad mot krypteringsprincipen krypteras endast filer som taggats med den hanterade identiteten.

Om administratörsåtgärden eller konfigurerade principbegäranden om att hanterade data rensas tas endast filer som taggats med den hanterade identiteten bort.

SDK:n kan inte associera flera identiteter med en enda fil. Om din app lagrar data som tillhör flera användare i samma fil resulterar SDK:s standardbeteende i att dessa data underskyddas eller överbeskyddas. Du uppmanas starkt att organisera appens data efter identitet.

Om din app absolut måste lagra data som tillhör olika identiteter i samma fil innehåller SDK:n funktioner för identitetstaggning av delmängder av data i en fil. Mer information finns i Dataskydd för databuffert .

Implementera flera identiteter

Om du vill deklarera stöd för flera identiteter för din app börjar du med att placera följande metadata i AndroidManifest.xml.

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

Ange aktiv identitet

Programmet kan ange den aktiva identiteten på följande nivåer i fallande prioritet:

  1. Trådnivå
  2. Context (vanligtvis Activity) nivå
  3. Processnivå

En identitet som anges på trådnivå ersätter en identitet som angetts på Context nivån, vilket ersätter en identitet som angetts på processnivå.

En identitet som angetts för en Context används endast i lämpliga associerade scenarier. Fil-I/O-åtgärder har till exempel inte någon associerad Context. Oftast ställer appar in identiteten på Context en Activity. Överväg att ange identiteten Context i Activity.onCreate. En app får inte visa data för en identitet om inte identiteten Activity är inställd på samma identitet.

I allmänhet är identiteten på processnivå endast användbar om appen bara fungerar med en enda identitet åt gången i alla trådar. Detta är inte typiskt för appar som stöder flera konton. Du uppmanas starkt att separera kontodata och ange den aktiva identiteten på tråden eller Context nivåerna.

Om din app använder kontexten Application för att hämta systemtjänster kontrollerar du att tråden eller processidentiteten har angetts eller att du har angett användargränssnittsidentiteten i appens Application kontext.

Om din app använder en Service kontext för att starta avsikter, använder innehållsmatchare eller använder andra systemtjänster måste du ange identiteten för kontexten Service . På samma sätt, om din app använder en JobService kontext för att utföra dessa åtgärder, måste du ange identiteten för kontexten eller tråden JobService som krävs av implementeringen JobService . Om du JobService till exempel bearbetar jobb för en enda identitet bör du överväga att ange identiteten i kontexten JobService . Om du JobService bearbetar jobb för flera identiteter bör du överväga att ange identiteten på trådnivå.

Försiktighet

Appar som använder WorkManager bör vara särskilt försiktiga när du anger identiteten. Mer specifikt bör dessa appar undvika att ange en identitet för den Context som skickas i Worker konstruktorn. Den här Context instansen kan delas mellan flera Worker instanser samtidigt. För att undvika odefinierat beteende bör appar i stället ange en trådidentitet i Worker.doWork() enligt implementeringen Worker .

Obs!

CLIPBOARD_SERVICE Eftersom används för UI-åtgärder använder SDK UI-identiteten för förgrundsaktiviteten för ClipboardManager åtgärder.

Följande metoder i MAMPolicyManager kan användas för att ange den aktiva identiteten och hämta de identitetsvärden som angetts tidigare.

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);

Som en bekvämlighet kan du också ange identiteten för en aktivitet direkt via en metod i MAMActivity i stället för att anropa MAMPolicyManager.setUIPolicyIdentity. Använd följande metod för att göra det:

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

Obs!

Om din app inte har deklarerat stöd för flera identiteter i manifestet, kommer anrop av dessa metoder för att ange identiteten inte att utföra någon åtgärd, och om de returnerar en MAMIdentitySwitchResultreturneras FAILEDalltid .

Vanliga fallgropar för identitetsväxling

  • För anrop till startActivityförutsätter Intune App SDK att den aktiva identiteten Context på nivån är associerad med den angivna Intent parametern. Vi rekommenderar starkt att du anger nivåidentiteten Context med kontexten Activity's, inte kontexten Application's.

  • Vi rekommenderar att du anger identiteten Context under en aktivitets onCreate metod. Men se till att även täcka andra startpunkter som onNewIntent. Annars, när samma aktivitet återanvänds för att visa data för både hanterade och ohanterade identiteter, kan principen tillämpas felaktigt, vilket leder till antingen oskyddade företagsdata eller felaktigt begränsade personuppgifter.

Resultat för identitetsväxling

Alla metoder som används för att ange resultatvärden för identitetsrapporten via MAMIdentitySwitchResult. Det finns fyra värden som kan returneras:

Returvärde Scenario
SUCCEEDED Identitetsändringen lyckades.
NOT_ALLOWED Identitetsändringen tillåts inte. Detta inträffar om ett försök görs att ange användargränssnittsidentiteten (Context) när en annan identitet anges i den aktuella tråden.
CANCELLED Användaren avbröt identitetsändringen, vanligtvis genom att trycka på bakåtknappen i en PIN-kod eller autentiseringsprompt.
FAILED Identitetsändringen misslyckades av en ospecificerad orsak.

Appen bör kontrollera att MAMIdentitySwitchResult visas SUCCEEDED innan du visar eller använder ett hanterat kontos data.

De flesta metoder för att ange den aktiva identiteten returnerar MAMIdentitySwitchResult synkront. Om du anger en Context identitet via setUIPolicyIdentity rapporteras resultatet asynkront. Appen kan implementera en MAMSetUIIdentityCallback för att få det här resultatet eller skicka null för motringningsobjektet. Om ett anrop görs till setUIPolicyIdentity medan resultatet från ett tidigare anrop till setUIPolicyIdentityi samma kontext ännu inte har levererats ersätter det nya återanropet det gamla och det ursprungliga återanropet får aldrig något resultat.

Försiktighet

Om den Context angivna setUIPolicyIdentity är en Activity, vet SDK:t inte om identitetsändringen lyckades förrän efter att administratören har konfigurerat kontroller för villkorlig start. Detta kan kräva att användaren anger en PIN-kod eller företagets autentiseringsuppgifter.

För närvarande kommer process- och trådidentitetsväxlar alltid att lyckas för en app med flera identiteter. SDK förbehåller sig rätten att lägga till felvillkor i framtiden.

UI-identitetsväxlingen kan misslyckas för ogiltiga argument, om den skulle vara i konflikt med trådidentiteten eller om användaren avbryter kraven för villkorlig start (till exempel trycker på bakåtknappen på PIN-skärmen).

Standardbeteendet för en misslyckad UI-identitetsväxling på en aktivitet är att slutföra aktiviteten. Om du vill ändra det här beteendet och få meddelanden om identitetsändringsförsök för en aktivitet kan du åsidosätta en metod i MAMActivity.

    public void onSwitchMAMIdentityComplete(final MAMIdentitySwitchResult result);

Om du åsidosätter onSwitchMAMIdentityComplete (eller anropar super metoden ) måste du se till att ett hanterat kontos data inte visas efter en misslyckad identitetsväxling.

Obs!

Att byta identitet kan kräva att aktiviteten återskapas. I det här fallet levereras återanropet onSwitchMAMIdentityComplete till den nya instansen av aktiviteten.

Identitet, avsikter och IdentitySwitchOptions

Förutom att automatiskt tagga nya filer med den aktiva identiteten taggar SDK även avsikter med den aktiva identiteten. Som standard kontrollerar SDK:n identiteten för en inkommande avsikt och jämför den med den aktiva identiteten. Om dessa identiteter inte matchar begär SDK vanligtvis(*) en identitetsväxling (se Implicita identitetsändringar nedan för mer information).

SDK:t lagrar även den här inkommande avsiktsidentiteten för senare användning. När appen uttryckligen ändrar användargränssnittsidentiteten jämför SDK den identitet som appen försöker växla till mot den senaste inkommande avsiktsidentiteten. Om dessa identiteter inte matchar kommer SDK vanligtvis(*) att misslyckas med identitetsväxlingen.

SDK utför den här kontrollen eftersom den förutsätter att appen fortfarande visar innehåll från avsikten som tillhör den identitet som taggats för avsikten. Det här antagandet skyddar mot att appen oavsiktligt inaktiverar skydd när hanterade data visas. Men det här antagandet kanske inte stämmer med appens faktiska beteende.

Valfria IdentitySwitchOption-uppräkningar kan skickas till API:erna setUIPolicyIdentity och switchMAMIdentity för att ändra SDK:ts standardbeteende.

  • IGNORE_INTENT: När du begär en identitetsväxling på UI-lagret informerar det här alternativet SDK:t om att hoppa över att jämföra den begärda identitetsparametern med den senast lagrade avsiktsidentiteten. Detta är användbart när din app inte längre visar innehåll som tillhör den identiteten och SDK:n inte ska blockera den här identitetsväxlingen. Till exempel:

    1. Din app är ett dokumentvisningsprogram. Den kan rendera dokument som skickas från andra appar. Den innehåller också en funktion där användare kan byta konto. När användaren använder den här kontoväxlingsfunktionen navigerar appen till en kontospecifik landningssida med det kontots senaste dokument.
    2. Appen får en avsikt att visa ett dokument. Den här avsikten är taggad med den hanterade identiteten.
    3. Din app växlas till den hanterade identiteten och visar det här dokumentet med rätt skydd.
    4. Användaren använder kontoväxlaren för att ändra till sitt personliga konto.

    Din app måste ändra användargränssnittets identitet i steg 4. I det här fallet, eftersom appens beteende är att navigera bort från det hanterade kontots data (dokumentet i avsikten), bör den använda IGNORE_INTENT i identitetsväxlingsanropet. På så sätt undviker du att SDK:et misslyckas på ett olämpligt sätt med det här anropet.

  • DATA_FROM_INTENT: När du begär en identitetsväxling på UI-lagret informerar det här alternativet SDK:t om att data från den senast lagrade avsiktsidentiteten fortsätter att visas när identitetsväxlingen lyckas. Därför utvärderar SDK:t fullständigt mottagningsprincipen mot den tidigare avsiktsidentiteten för att avgöra om den tillåts visas. Till exempel:

    1. Din app är ett dokumentvisningsprogram. Den kan rendera dokument som skickas från andra appar. Den innehåller också en funktion där användare kan byta konto. Till skillnad från i det tidigare exemplet navigerar appen till en delad sida som visar de senaste dokumenten för alla konton när användaren använder den här kontoväxlingsfunktionen.
    2. Appen får en avsikt att visa ett dokument. Den här avsikten är taggad med den hanterade identiteten.
    3. Din app växlas till den hanterade identiteten och visar det här dokumentet med rätt skydd.
    4. Användaren använder kontoväxlaren för att ändra till sitt personliga konto.

    Din app måste ändra användargränssnittets identitet i steg 4. I det här fallet, eftersom appens beteende är att fortsätta visa den hanterade identitetens data (en förhandsgranskning av dokumentet i avsikten), bör den använda DATA_FROM_INTENT i identitetsväxlingsanropet. Detta informerar SDK för att kontrollera den konfigurerade appskyddsprincipen för att avgöra om det är lämpligt att data fortsätter att visas.

(*) SDK:ts standardbeteende omfattar särskilt hölje som hoppar över den här dataingresskontrollen om till exempel avsikten kommer inifrån samma app eller från systemstartaren.

Rensa den aktiva identiteten

Ditt program kan ha scenarier som är kontoagnostiska. Ditt program kan också ha scenarier för lokala ohanterade scenarier som inte kräver någon inloggning. I båda dessa fall kanske din app inte vill att SDK:t ska framtvinga den hanterade identitetens principer, men du kanske inte har någon explicit identitet att växla till.

Du kan rensa den aktiva identiteten genom att anropa någon av de angivna identitetsmetoderna med identitetsparametern inställd på null. Genom att rensa identiteten på en nivå kommer SDK:t att söka efter den aktiva identiteten på andra nivåer, baserat på prioritetsordningen.

Alternativt kan du skicka en tom sträng som identitetsparameter, som anger identiteten till ett särskilt tomt värde som behandlas som en ohanterad identitet. Om du ställer in den aktiva identiteten på en tom sträng uppmanas SDK:t att inte tillämpa någon appskyddsprincip.

Implicita identitetsändringar

I avsnittet ovan beskrivs de olika sätt som appen uttryckligen kan ange den aktiva identiteten på tråd-, kontext- och processnivå. Den aktiva identiteten i din app kan dock också ändras utan att appen anropar någon av dessa metoder. I det här avsnittet beskrivs hur din app kan lyssna efter och svara på dessa implicita identitetsändringar.

Det är valfritt att lyssna efter dessa implicita identitetsändringar, men rekommenderas. SDK:t ändrar aldrig den aktiva identiteten utan att tillhandahålla dessa implicita meddelanden om identitetsändring.

Försiktighet

Om din app väljer att inte lyssna efter implicita identitetsändringar bör du vara extra noga med att inte anta den aktiva identiteten. När du är osäker använder du getCurrentThreadIdentitymetoderna , getUIPolicyIdentityoch getProcessIdentity för att bekräfta den aktiva identiteten.

Källor till implicita identitetsändringar

  • Dataingress från andra Intune-hanterade appar kan ändra den aktiva identiteten på tråd- och kontextnivå.

    • Om en aktivitet startas från en som skickas av en Intent annan MAM-app anges aktivitetens identitet baserat på den aktiva identiteten i den andra appen vid den tidpunkt då den Intent skickades.

      • En aktivitet för att visa ett Word-dokument startas till exempel från en avsikt från Microsoft Outlook när en användare väljer en dokumentbilaga. Office-dokumentvisningsaktivitetens identitet växlas till identiteten från Outlook.

    • För tjänster anges trådidentiteten på samma sätt för varaktigheten för ett eller onBind ett onStart anrop. Anrop till den Binder som returneras från onBind anger även tillfälligt trådidentiteten.

    • Anrop till en ContentProvider anger på samma sätt trådidentiteten för deras varaktighet.

  • Användarinteraktion med en aktivitet kan ändra den aktiva identiteten på kontextnivå. Till exempel:

    • En användare som avbryter en auktoriseringsprompt under Resume resulterar i en implicit växling till en tom identitet.

Hantera implicita identitetsändringar

Din app kan också lyssna efter och reagera på dessa implicita identitetsändringar. Ditt program kan till exempel kräva flera steg innan ett tillagt konto kan användas, till exempel en e-postapp som konfigurerar en ny inkorg. När en identitetsförsök växlas till det ofullständiga kontots identitet kan appens hanterare omdirigera användaren till kontokonfigurationsaktiviteten innan identitetsväxlingen godkänns. Alternativt kan appens hanterare visa en feldialogruta och blockera identitetsväxlingen.

Din app kan implementera MAMIdentityRequirementListener-gränssnittet på en Service eller ContextProvider för identitetsändringar som tillämpas på den här tråden. Implementeringen måste åsidosättas:

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

Din app kan implementera MAMActivityIdentityRequirementListener-gränssnittet på en Activity för identitetsändringar som gäller för den här aktiviteten. Implementeringen måste åsidosättas:

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

Uppräkningsparametern AppIdentitySwitchReason beskriver källan till den implicita identitetsväxlingen.

Uppräkningsvärde Standardbeteende för SDK Beskrivning
CREATE Tillåt identitetsväxlingen. Identitetsväxlingen sker på grund av att en aktivitet har skapats.
NEW_INTENT Tillåt identitetsväxlingen. Identitetsväxlingen sker eftersom en ny avsikt tilldelas till en aktivitet.
RESUME_CANCELLED Blockera identitetsväxlingen. Identitetsväxlingen sker eftersom ett CV avbröts. Detta är vanligast när slutanvändaren trycker på bakåtknappen i användargränssnittet för PIN-kod, autentisering eller efterlevnad.

Parametern AppIdentitySwitchResultCallback gör att utvecklare kan åsidosätta standardbeteendet för identitetsväxlingen:

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

onMAMIdentitySwitchRequired anropas för alla implicita identitetsändringar förutom de som görs via en Binder som returneras från MAMService.onMAMBind. Standardimplementeringarna för onMAMIdentitySwitchRequired anrop omedelbart:

  • callback.reportIdentitySwitchResult(FAILURE) när orsaken är RESUME_CANCELLED.

  • callback.reportIdentitySwitchResult(SUCCESS) i alla andra fall.

Det förväntas inte att de flesta appar behöver blockera eller fördröja en identitetsväxling på ett annat sätt, men om en app behöver göra det måste följande punkter övervägas:

  • Om en identitetsväxling blockeras är slutanvändarnas beteende detsamma som om SDK:ts appskyddsinställning "ta emot data från andra appar" hade förbjudit inkommande data.

  • Om en tjänst körs på huvudtråden reportIdentitySwitchResultmåste anropas synkront, annars slutar användargränssnittstråden att svara.

  • För Activity att skapa anropas onMAMIdentitySwitchRequired före onMAMCreate. Om appen måste visa användargränssnittet för att avgöra om identitetsväxlingen ska tillåtas måste användargränssnittet visas med en annan aktivitet.

  • I en Activity, när en växling till den tomma identiteten begärs med orsaken som RESUME_CANCELLED, måste appen ändra den återupptagna aktiviteten för att visa data som överensstämmer med den identitetsväxlingen. Om detta inte är möjligt bör appen neka växeln och användaren uppmanas att följa principen för den återupptande identiteten (till exempel genom att visas med appens PIN-startskärm).

Försiktighet

En app med flera identiteter kan ta emot inkommande data från både hanterade och ohanterade appar. Det är appens ansvar att behandla data från hanterade identiteter på ett hanterat sätt.

Om en begärd identitet hanteras (använd MAMPolicyManager.getIsIdentityManaged för att kontrollera), men appen inte kan använda det kontot (till exempel eftersom konton, till exempel e-postkonton, måste konfigureras i appen först) ska identitetsväxlingen nekas.

Standardbeteendet för MAMActivity.onMAMIdentitySwitchRequired kan nås genom att anropa den statiska metoden MAMActivity.defaultOnMAMIdentitySwitchRequired(activity, identity, reason, callback).

Om du behöver åsidosätta MAMActivity.onSwitchMAMIdentityCompletekan du implementera MAMActivityIdentitySwitchListener utan att uttryckligen ärva från MAMActivity.

Identitetsväxlar och skärmbildsbegränsningar

Intune App SDK använder Window flaggan FLAG_SECURE för att framtvinga en skärmbildsprincip. Vissa appar kan också ställas in FLAG_SECURE för sina egna syften. När appskyddsprincipen inte begränsar skärmbilder kommer SDK:t inte att ändra FLAG_SECURE.

På en identitetsväxling från en identitet vars princip kräver inaktivering av skärmbilder till en identitet vars princip inte gör det rensar SDK FLAG_SECURE:t . Därför bör din app inte förlita sig på FLAG_SECURE återstående uppsättning efter en identitetsväxling.

Bevara identitet i asynkrona åtgärder

Appar skickar ofta bakgrundsaktiviteter från användargränssnittstråden för att hantera åtgärder på andra trådar. En app med flera identiteter måste se till att dessa bakgrundsaktiviteter fungerar med lämplig identitet, vilket ofta är samma identitet som används av aktiviteten som skickade dem.

Intune App SDK tillhandahåller MAMAsyncTask och MAMIdentityExecutors som en bekvämlighet för att bevara identiteten i asynkrona åtgärder. Appen måste antingen använda dessa (eller uttryckligen ange trådidentiteten för aktiviteterna) om dess asynkrona åtgärder kan:

  • Skriva data som hör till en hanterad identitet till en fil
  • Kommunicera med andra appar

MAMAsyncTask

Om du vill använda MAMAsyncTaskärver du helt enkelt från den i stället för AsyncTask och ersätter åsidosättningar av doInBackground respektive onPreExecute med doInBackgroundMAMonPreExecuteMAM . Konstruktorn MAMAsyncTask tar en aktivitetskontext. Till exempel:

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 förutsätter den aktiva identiteten baserat på normal prioritetsordning.

MAMIdentityExecutors

MAMIdentityExecutorsgör att du kan omsluta en befintlig Executor instans eller ExecutorService instans som en identitetsbevarandeExecutorService/Executor med wrapExecutor metoderna och wrapExecutorService . Till exempel

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

MAMIdentityExecutors förutsätter den aktiva identiteten baserat på normal prioritetsordning.

Filskydd

Skriva skyddade filer

Som vi nämnde i Organisera appdata efter identitet ovan associerar Intune App SDK den aktiva identiteten (från tråd-/processnivå) med filer när de skrivs. Det är viktigt att ha rätt identitet angiven när filen skapas för att säkerställa rätt krypterings- och selektiv rensningsfunktion.

Din app kan fråga eller ändra en fils identitet med hjälp av klassen MAMFileProtectionManager , särskilt MAMFileProtectionManager.getProtectionInfo för frågor och MAMFileProtectionManager.protect ändringar.

Metoden protect kan också användas för att skydda kataloger. Katalogskyddet tillämpas rekursivt på alla filer och underkataloger som finns i katalogen. När en katalog skyddas tillämpas automatiskt samma skydd för alla nya filer som skapats i katalogen. Eftersom katalogskyddet tillämpas rekursivt kan anropet protect ta lite tid att slutföra för stora kataloger. Därför kan appar som tillämpar skydd på en katalog som innehåller ett stort antal filer vilja köra protect asynkront på en bakgrundstråd.

Om du anropar protect med en tom sträng för identitetsparametern taggas filen/katalogen med den ohanterade identiteten. Den här åtgärden tar bort kryptering från filen/katalogen om den tidigare har krypterats. När ett selektivt rensningskommando utfärdas tas inte filen/katalogen bort.

Visa skyddat filinnehåll

Det är lika viktigt att ha rätt identitet angiven när filinnehåll visas för att förhindra obehöriga användare från att visa hanterade data. SDK:t kan inte automatiskt härleda en relation mellan filer som läs- och data som visas i en Activity. Appar måste ange användargränssnittets identitet på rätt sätt innan hanterade data visas. Detta inkluderar data som lästs från filer.

Om en fil kommer utanför appen (antingen från en eller från en ContentProvider offentligt skrivbar plats ) måste appen försöka fastställa filidentiteten (med rätt MAMFileProtectionManager.getProtectionInfo-överlagring för datakällan) innan information som läses från filen visas.

Om getProtectionInfo rapporterar en icke-null, icke-tom identitet måste appen ange UI-identiteten så att den matchar den här identiteten med antingen MAMActivity.switchMAMIdentity eller MAMPolicyManager.setUIPolicyIdentity. Om identitetsväxlingen misslyckas får data från filen inte visas.

När du läser från en innehålls-URI kan det vara nödvändigt att först läsa identiteten (via överlagringen getProtectionInfo tar en Uri) och sedan ange kontexten eller trådidentiteten på rätt sätt. Detta måste göras innan du öppnar en filbeskrivning eller indataström på ContentResolver, annars kan åtgärden misslyckas.

Ett exempelflöde kan se ut ungefär så här:

  • Användaren väljer ett dokument som ska öppnas i appen.

  • Under det öppna flödet, innan du läser data från disken, bekräftar appen den identitet som ska användas för att visa innehållet:

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

  • Appen väntar tills ett resultat rapporteras till återanrop.

  • Om det rapporterade resultatet är ett fel visas inte dokumentet i appen.

  • Appen öppnas och renderar filen.

Om en app använder Android DownloadManager för att ladda ned filer försöker SDK:t skydda dessa filer automatiskt med hjälp av identitetsprioriteten som beskrivs tidigare. Kontexten som används för att hämta DownloadManager används om trådidentiteten inte har angetts. Om de nedladdade filerna innehåller företagsdata är det appens ansvar att anropa skydda om filerna flyttas eller återskapas efter nedladdningen.

Single-Identity till övergång till flera identiteter

Om en app som tidigare släpptes med Intune-integrering med en enda identitet senare integrerar flera identiteter, kommer tidigare installerade appar att uppleva en övergång. Den här övergången är inte synlig för användaren.

Appen krävs inte för att hantera den här övergången. Alla filer som skapats före övergången fortsätter att betraktas som hanterade (så de förblir krypterade om krypteringsprincipen är aktiverad).

Om du inte vill att alla tidigare appdata ska associeras med den hanterade identiteten kan du identifiera den här övergången och uttryckligen ta bort skyddet.

  • Identifiera uppgraderingen genom att jämföra appens version med en känd version där stöd för flera identiteter har lagts till.
  • Anropa protect med en tom sträng för identitetsparametern för filer eller kataloger som du inte vill associera med den hanterade identiteten.

Offlinescenarier

Intune App SDK körs i offlineläge när företagsportalappen inte är installerad. Filidentitetstaggning är känsligt för offlineläge:

  • Om företagsportalen inte är installerad kan filer inte vara identitetstaggade. Det är säkert att anropa MAMFileProtectionManager.protect i offlineläge, men det har ingen effekt.

  • Om företagsportalen är installerad, men appen inte har någon appskyddsprincip, kan filer inte vara identitetstaggade på ett tillförlitligt sätt.

  • När filidentitetstaggning blir tillgänglig behandlas alla tidigare skapade filer som personliga/ohanterade (som tillhör den tomma strängidentiteten), förutom i fall där appen tidigare installerades som en hanterad app med en identitet, enligt beskrivningen i Övergång mellan en identitet och flera identiteter.

För att undvika dessa fall bör appar undvika att skapa filer som innehåller kontodata tills kontoregistreringen har slutförts. Om din app absolut måste skapa filer offline kan den använda MAMFileProtectionManager.protect för att korrigera filens associerade identitet när SDK:t är online.

Skydd av databuffert

Varning

Det rekommenderas inte att du skriver data som hör till flera konton i en enda fil. Organisera om möjligt appens filer efter identitet.

SDK:ts MAMDataProtectionManager innehåller metoder för att kontrollera och ändra den taggade identiteten på specifika databuffertar i antingen byte[] eller InputStream format.

MAMDataProtectionManager.protect tillåter att en app associerar data med en identitet och krypterar data om identiteten för närvarande är riktad mot krypteringsprincipen. Dessa krypterade data är lämpliga för lagring till disk i en fil.

MAMDataProtectionManager gör också att du kan köra frågor mot de data som är associerade med identiteten och okryptera dem.

Appar som använder MAMDataProtectionManager ska implementera en mottagare för meddelandet MANAGEMENT_REMOVED . Mer information finns i Registrera för meddelanden från SDK .

När det här meddelandet har slutförts går det inte längre att läsa buffertar som skyddades via den här klassen (om filkryptering aktiverades när buffertarna skyddades). En app kan förhindra att dessa buffertar blir olästa genom att anropa MAMDataProtectionManager.unprotect på alla buffertar när du hanterar meddelandet MANAGEMENT_REMOVED . Det är också säkert att anropa protect under det här meddelandet om du vill bevara identitetsinformationen. Krypteringen kommer garanterat att inaktiveras under meddelandet och anrop protect i hanteraren krypterar inte databuffertar.

Innehållsleverantörer

En app med flera identiteter måste också skydda data som delas via ContentProviders för att förhindra att hanterat innehåll delas på ett olämpligt sätt.

Appen måste anropa den statiska MAMContentProvider-metodenisProvideContentAllowed(provider, contentIdentity) innan innehållet returneras. Om den här funktionen returnerar false får innehållet inte returneras till anroparen.

Det krävs inte att du isProvideContentAllowed anropar om du ContentProvider returnerar en ParcelFileDescriptor. Filbeskrivningar som returneras via en innehållsprovider hanteras automatiskt baserat på filidentiteten.

Selektiv rensning

Som standard hanterar Intune App SDK automatiskt selektiva rensningar och tar bort alla filer som har associerats med den hanterade identiteten. Därefter stänger SDK:et appen på ett smidigt sätt, avslutar aktiviteter och avslutar appprocessen.

SDK:t ger den valfria möjligheten för din app att antingen komplettera (rekommenderas) eller åsidosätta standardrensningsbeteendet.

SDK:ts standardrensningshanterare hanterar inte databuffertar som skyddas av MAMDataProtectionManager. Om din app använde den här funktionen måste den komplettera eller åsidosätta standardrensningshanteraren för att ta bort dessa data.

Obs!

Om du vill komplettera och åsidosätta standardrensningsbeteendet måste du hantera specifika SDK-meddelanden. Mer information om hur du implementerar meddelandehanterare finns i Registrera för meddelanden från SDK .

Komplettera standardrensningsbeteendet

För att komplettera standardbeteendet för SDK-rensning kan appen registrera sig för WIPE_USER_AUXILIARY_DATAMAMNotificationType.

Det här meddelandet skickas av SDK innan den utför den selektiva standardrensningen. SDK väntar tills appens meddelandehanterare har slutförts innan data tas bort och appen avslutas. Appen bör rensa data synkront och inte returnera förrän all rensning har slutförts.

Appar bör starkt överväga att komplettera standardrensningsbeteendet med WIPE_USER_AUXILIARY_DATA, eftersom appspecifik rensning är vanligt för appar med flera identiteter.

Åsidosätta standardrensningsbeteende

Om du vill åsidosätta standardbeteendet för SDK-rensning kan appen registrera sig för WIPE_USER_DATAMAMNotificationType.

Varning

En app får aldrig registreras för både WIPE_USER_DATA och WIPE_USER_AUXILIARY_DATA.

Om du åsidosätter standardbeteendet för SDK-rensning innebär det stora risker för din app. Din app ansvarar fullt ut för att ta bort alla data som är associerade med den hanterade identiteten, inklusive alla filer och databuffertar som har taggats för den identiteten.

  • Om den hanterade identiteten skyddades med kryptering och appens anpassade rensningshanterare inte helt tar bort alla hanterade data, förblir eventuella återstående hanterade filer krypterade. Dessa data blir otillgängliga och din app kanske inte hanterar försök att läsa krypterade data korrekt.
  • Appens rensningshanterare kan leda till dataförlust för ohanterade användare om den tar bort filer som inte är taggade med den hanterade identiteten.

Om appens anpassade rensningshanterare tar bort hanterade data från en fil men vill lämna andra data i filen måste den ändra identiteten för filen (via MAMFileProtectionManager.protect) till antingen en ohanterad identitet eller en tom sträng.

Din åsidosatta rensningshanterare bör rensa data synkront och inte returnera förrän all rensning har slutförts.

Överväg att stänga appen manuellt när du har slutfört stegen för anpassad rensningshanterare för att förhindra att användaren kommer åt minnesinterna data efter att en rensning har inträffat.

Avslutsvillkor

Planera att ägna betydande tid åt att verifiera appens integrering av flera identiteter. Innan du börjar testa:

  • Skapa och tilldela en appskyddsprincip till ett konto. Det här är ditt testhanterade konto.
  • Skapa, men tilldela inte appskyddsprincip till, ett annat konto. Det här är ditt ohanterade testkonto. Om din app har stöd för flera kontotyper utöver Microsoft Entra-konton kan du också använda ett befintligt icke-AAD-konto som det ohanterade testkontot.
  • Förfina dig själv med hur principen tillämpas i din app. Testning med flera identiteter kräver att du enkelt kan urskilja när din app är och inte fungerar med principen framtvingad. Inställningen för appskyddsprincip för att blockera skärmbilder är effektiv vid snabb testning av principtillämpning.
  • Överväg hela uppsättningen användargränssnitt som appen erbjuder. Räkna upp skärmarna där kontodata visas. Visar din app bara data för ett enda konto samtidigt, eller kan den presentera data som hör till flera konton samtidigt?
  • Överväg hela uppsättningen filer som din app skapar. Räkna upp vilka av dessa filer som innehåller data som tillhör ett konto, till skillnad från data på systemnivå.
    • Fastställ hur du ska validera kryptering för var och en av dessa filer.
  • Överväg hela uppsättningen med sätt som din app kan interagera med andra appar. Räkna upp alla ingress- och utgående punkter. Vilka typer av data kan appen mata in? Vilka avsikter sänder den? Vilka innehållsleverantörer implementerar det?
    • Bestäm hur du ska använda var och en av dessa funktioner för datadelning.
    • Förbered en testenhet som har både hanterade och ohanterade appar som kan interagera med din app.
  • Överväg hur din app gör det möjligt för slutanvändaren att interagera med alla inloggade konton. Måste användaren manuellt växla till ett konto innan kontots data visas?

När du har utvärderat appens aktuella beteende noggrant validerar du integreringen med flera identiteter genom att köra följande uppsättning tester. Observera att det här inte är en omfattande lista och garanterar inte att appens implementering av flera identiteter är buggfri.

Validera inloggnings- och utloggningsscenarier

Din app för flera identiteter stöder upp till 1 hanterat konto och flera ohanterade konton. De här testerna hjälper till att säkerställa att integreringen av flera identiteter inte ändrar skyddet på ett felaktigt sätt när användarna loggar in eller loggar ut.

Installera appen och Intune-företagsportalen för de här testerna. logga inte in innan du startar testet.

Scenario Steg
Logga in hanterad först – Logga in först med ett hanterat konto och verifiera att kontots data hanteras.
– Logga in med ett ohanterat konto och verifiera att kontots data inte hanteras.
Logga in ohanterad först – Logga in först med ett ohanterat konto och verifiera att kontots data inte hanteras.
– Logga in med ett hanterat konto och verifiera att kontots data hanteras.
Logga in på flera hanterade – Logga in först med ett hanterat konto och verifiera att kontots data hanteras.
– Logga in med ett andra hanterat konto och kontrollera att användaren är blockerad från att logga in utan att först ta bort det ursprungliga hanterade kontot.
Logga ut hanterad – Logga in på din app med både ett hanterat och ohanterat konto.
– Logga ut från det hanterade kontot.
– Bekräfta att det hanterade kontot har tagits bort från din app och att alla data för kontot har tagits bort.
– Bekräfta att det ohanterade kontot fortfarande är inloggad, att ingen av det ohanterade kontots data har tagits bort och att principen fortfarande inte tillämpas.
Logga ut ohanterat – Logga in på din app med både ett hanterat och ohanterat konto.
– Logga ut från det ohanterade kontot.
– Bekräfta att det ohanterade kontot har tagits bort från din app och att alla kontots data har tagits bort.
– Bekräfta att det hanterade kontot fortfarande är inloggad, att ingen av det ohanterade kontots data har tagits bort och att principen fortfarande tillämpas.

Verifiera aktiv identitet och applivscykel

Din app för flera identiteter kan visa vyer med ett enda kontos data och tillåta att användaren uttryckligen ändrar det aktuella kontot som används. Den kan också visa vyer med flera kontons data samtidigt. De här testerna säkerställer att integreringen av flera identiteter ger rätt skydd för den aktiva identiteten på varje sida under hela appens livscykel.

Installera appen och Intune-företagsportalen för de här testerna. logga in med både ett hanterat och ohanterat konto innan du startar testet.

Scenario Steg
Vy för enskilt konto, hanterad – Växla till det hanterade kontot.
– Gå till alla sidor i din app som visar ett enda kontos data.
– Bekräfta att principen tillämpas på varje sida.
Enkel kontovy, ohanterad – Växla till det ohanterade kontot.
– Gå till alla sidor i din app som visar ett enda kontos data.
– Bekräfta att principen inte tillämpas på någon sida.
Vy över flera konton – Gå till alla sidor i din app som presenterar flera kontons data samtidigt.
– Bekräfta att principen tillämpas på varje sida.
Hanterad paus – På en skärm med hanterade data som visas och principen är aktiv pausar du appen genom att gå till enhetens startskärm eller en annan app.
– Återuppta appen.
– Bekräfta att principen fortfarande tillämpas.
Ohanterad paus – På en skärm där ohanterade data visas och ingen princip är aktiv pausar du appen genom att gå till enhetens startskärm eller en annan app.
– Återuppta appen.
– Bekräfta att principen inte tillämpas.
Hanterad avlivning – På en skärm med hanterade data som visas och principen är aktiv tvingar du appen att avslutas.
– Starta om appen.
– Bekräfta att principen fortfarande tillämpas om appen återupptas på en skärm med det hanterade kontots data (förväntat). Om appen återupptas på en skärm med det ohanterade kontots data kontrollerar du att principen inte tillämpas.
Ohanterad död – På en skärm med ohanterade data som visas och principen är aktiv tvingar du appen att avslutas.
– Starta om appen.
– Bekräfta att principen inte tillämpas om appen återupptas på en skärm med det ohanterade kontots data (förväntat). Om appen återupptas på en skärm med det hanterade kontots data bekräftar du att principen fortfarande tillämpas.
Ad hoc för identitetsväxling – Experimentera med att växla mellan konton och pausa/återuppta/avliva/starta om appen.
– Bekräfta att det hanterade kontots data alltid är skyddade och att det ohanterade kontots data aldrig skyddas.

Validera scenarier för datadelning

Din app för flera identiteter kan skicka data till och ta emot data från andra appar. Intunes appskyddsprinciper har inställningar som styr det här beteendet. De här testerna hjälper till att säkerställa att integreringen av flera identiteter respekterar dessa inställningar för datadelning.

Installera appen och Intune-företagsportalen för de här testerna. logga in med både ett hanterat och ohanterat konto innan du startar testet. Dessutom:

  • Ange principen för det hanterade kontot som:
    • "Skicka organisationsdata till andra appar" till "Principhanterade appar".
    • "Ta emot data från andra appar" till "Principhanterade appar".
  • Installera andra appar på testenheten:
    • En hanterad app som är riktad mot samma princip som din app och som kan skicka och ta emot data (t.ex. Microsoft Outlook).
    • Alla ohanterade appar som kan skicka och ta emot data.
  • Logga in på den andra hanterade appen med det hanterade testkontot. Även om den andra hanterade appen är flera identiteter loggar du bara in med det hanterade kontot.

Om din app har möjlighet att skicka data till andra appar, som att Microsoft Outlook skickar en bifogad dokumentbilaga till Microsoft Office:

Scenario Steg
Hanterad identitet skickas till ohanterad app – Växla till det hanterade kontot.
– Navigera till platsen där din app kan skicka data.
– Försök att skicka data till en ohanterad app.
– Du bör blockeras från att skicka data till den ohanterade appen.
Hanterad identitet skickas till hanterad app – Växla till det hanterade kontot.
– Navigera till platsen där din app kan skicka data.
– Försök att skicka data till den andra hanterade appen med det hanterade kontot loggat in.
– Du bör kunna skicka data till den hanterade appen.
Ohanterad identitet skickas till hanterad app – Växla till det ohanterade kontot.
– Navigera till platsen där din app kan skicka data.
– Försök att skicka data till den andra hanterade appen med det hanterade kontot loggat in.
– Du bör blockeras från att skicka data till den andra hanterade appen.
Ohanterad identitet skickas till ohanterad app – Växla till det ohanterade kontot.
– Navigera till platsen där din app kan skicka data.
– Försök att skicka data till en ohanterad app.
– Du bör alltid ha behörighet att skicka ohanterade kontodata till en ohanterad app.

Din app kan aktivt importera data från andra appar, till exempel Microsoft Outlook som kopplar en fil från Microsoft OneDrive. Din app kan också passivt ta emot data från andra appar, som att Microsoft Office öppnar ett dokument från en Microsoft Outlook-bifogad fil. Inställningen för att ta emot appskyddsprinciper omfattar båda scenarierna.

Om din app har möjlighet att aktivt importera data från andra appar:

Scenario Steg
Importera hanterad identitet från ohanterad app – Växla till det hanterade kontot.
– Navigera till den plats där din app kan importera data från andra appar.
– Försök att importera data från en ohanterad app.
– Du bör blockeras från att importera data från ohanterade appar.
Importera hanterad identitet från hanterad app – Växla till det hanterade kontot.
– Navigera till den plats där din app kan importera data från andra appar.
– Försök att importera data från den andra hanterade appen med det hanterade kontot loggat in.
– Du bör kunna importera data från den andra hanterade appen.
Ohanterad identitetsimport från hanterad app – Växla till det ohanterade kontot.
– Navigera till den plats där din app kan importera data från andra appar.
– Försök att importera data från den andra hanterade appen med det hanterade kontot loggat in.
– Du bör blockeras från att importera data från den andra hanterade appen.
Ohanterad identitetsimport från ohanterad app – Växla till det ohanterade kontot.
– Navigera till den plats där din app kan importera data från andra appar.
– Försök att importera data från en ohanterad app.
– Du bör alltid tillåtas att importera data från ohanterade appar för ett ohanterat konto.

Om din app har möjlighet att passivt ta emot data från andra appar:

Scenario Steg
Hanterad identitet tar emot från ohanterad app – Växla till det hanterade kontot.
– Växla till den ohanterade appen.
– Navigera till platsen där data kan skickas.
– Försök att skicka data från den ohanterade appen till din app.
– Appens hanterade konto ska inte kunna ta emot data från den ohanterade appen.
Hanterad identitet tar emot från hanterad app – Växla till det hanterade kontot.
– Växla till den andra hanterade appen med det hanterade kontot inloggad.
– Navigera till platsen där data kan skickas.
– Försök att skicka data från den hanterade appen till din app.
– Appens hanterade konto ska kunna ta emot data från den andra hanterade appen.
Ohanterad identitet tar emot från hanterad app – Växla till det ohanterade kontot.
– Växla till den andra hanterade appen med det hanterade kontot inloggad.
– Navigera till platsen där data kan skickas.
– Försök att skicka data från den hanterade appen till din app.
– Appens ohanterade konto ska inte kunna ta emot data från den hanterade appen.
Ohanterad identitet tar emot från ohanterad app – Växla till det ohanterade kontot.
– Växla till den ohanterade appen.
– Navigera till platsen där data kan skickas.
– Försök att skicka data från den ohanterade appen till din app.
– Appens ohanterade konto bör alltid tillåtas att ta emot data från den ohanterade appen.

Fel i dessa tester kan tyda på att din app inte har rätt aktiv identitet inställd när den försöker skicka eller ta emot data. Du kan undersöka detta genom att använda SDK:ets API:er för att hämta identiteter vid tidpunkten för att skicka/ta emot för att bekräfta att den aktiva identiteten har angetts korrekt.

Validera scenarier för selektiv rensning

Din app för flera identiteter kan ha kompletterat eller åsidosatt SDK:ts standardrensningsbeteende. De här testerna hjälper till att säkerställa att integreringen av flera identiteter tar bort hanterade data korrekt när rensningar initieras, utan att påverka ohanterade data.

Varning

Påminnelse om att om din app använder MAMDataProtectionManager.protectmåste den implementera en hanterare för antingen WIPE_USER_AUXILIARY_DATA eller WIPE_USER_DATA.

Installera appen och Intune-företagsportalen för de här testerna. logga in med både ett hanterat och ohanterat konto innan du startar testet. För båda kontona använder du scenarier med övningsappar som lagrar kontodata.

Scenario Förutsättningar Steg
Kompletterande rensningshanterare Din app har implementerat en hanterare för WIPE_USER_AUXILIARY_DATA - Utfärda en selektiv rensning från administrationscentret för Microsoft Intune.
– Bekräfta (vanligtvis via loggning) att rensningshanteraren har körts korrekt.
– Bekräfta att det hanterade kontot har tagits bort från din app och att alla data för kontot har tagits bort.
– Bekräfta att det ohanterade kontot fortfarande är inloggad, att ingen av det ohanterade kontots data har tagits bort och att principen fortfarande inte tillämpas.
Åsidosatt rensningshanterare Din app har implementerat en hanterare för WIPE_USER_DATA - Utfärda en selektiv rensning från administrationscentret för Microsoft Intune.
– Bekräfta (vanligtvis via loggning) att rensningshanteraren har körts korrekt.
– Bekräfta att det hanterade kontot har tagits bort från din app och att alla data för kontot har tagits bort.
– Bekräfta att det ohanterade kontot fortfarande är inloggad, att ingen av det ohanterade kontots data har tagits bort och att principen fortfarande inte tillämpas.
– Bekräfta att appen antingen har avslutats korrekt eller fortfarande är i ett felfritt tillstånd när rensningshanteraren har slutförts.
Manuellt filskydd – Appen anropar MAMFileProtectionManager.protect
– Din app har implementerat en hanterare för WIPE_USER_DATA		 – Se till att du har övningsscenarier där din app manuellt skulle skydda minst en fil som tillhör det hanterade kontot.
- Utfärda en selektiv rensning från administrationscentret för Microsoft Intune.
– Bekräfta att filerna har tagits bort.
Manuellt skydd mot databuffert – Appen anropar MAMDataProtectionManager.protect
– Din app har implementerat en hanterare för antingen WIPE_USER_AUXILIARY_DATA eller WIPE_USER_DATA		 – Se till att du har övningsscenarier där din app manuellt skulle skydda minst en databuffert som tillhör det hanterade kontot.
- Utfärda en selektiv rensning från administrationscentret för Microsoft Intune.
– Bekräfta att databuffertarna tas bort från de filer som de har lagrats i och att din app fortfarande kan läsa ohanterade data från dessa filer.

Nästa steg

När du har slutfört alla avslutsvillkor ovan har appen nu integrerats som flera identiteter och kan tillämpa appskyddsprinciper per identitet. Följande avsnitt, steg 6: Appkonfiguration och steg 7: Funktioner för app deltagande, kan behövas eller inte, beroende på appens önskade stöd för appskyddsprinciper. Om du är osäker på om något av de här avsnitten gäller för din app kan du gå tillbaka till Viktiga beslut för SDK-integrering.