Intune App SDK för Android – Multi-Identity

Med Microsoft Intune App SDK för Android kan du införliva Intune appskyddsprinciper (kallas även 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 integrationen.

Steg 5: Multi-Identity

Etappmål

• Avgöra om ditt program 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:n om aktiva och föränderliga identiteter i hela programmet.
• Testa tillämpningen av appskyddsprinciper grundligt för både hanterade och ohanterade identiteter.

Identitetstermer

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

• Användare: den person som använder programvaran. Ytterligare differentierad som slutanvändare, människan som använder Android-appen ochadministratörsadministratörsanvändare / / IT-administratör / IT-proffs, människan som använder Microsoft Intune administrationscenter.
• 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 på hela programmet. När du har registrerat ett konto med en appskyddsprincip associerad associerar SDK:n varje fil och varje aktivitet med kontots identitet och tillämpar kontots riktade princip universellt.

För många utvecklare är detta det appskyddsbeteende som önskas för deras program. Dessa program betraktas som en enda identitet. Genom att slutföra de föregående stegen har ditt program integrerats som en enda identitet och kan framtvinga alla grundläggande principer. Appar som är avsedda att förbli en identitet kan hoppa över det här avsnittet och gå vidare till steg 6: App Configuration.

Intune App SDK kan också framtvinga principer per identitetsnivå. Om ditt program redan har stöd för flera konton som är inloggade samtidigt och du vill behålla det här stödet för flera konton med appskyddsprinciper anses ditt program vara flera identiteter.

Tips

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

Varning

Att stödja flera identiteter är betydligt mer komplext än andra appskyddsfunktioner. Felaktig integrering av flera identiteter kan leda till dataläckor och andra säkerhetsproblem. Läs igenom det här avsnittet noggrant och planera in testtid innan du går vidare till nästa steg.

"Identitet" till SDK

När ett SDK-integrerat program registrerar ett konto med hjälp av registerAccountForMAM sparar SDK:n alla angivna parametrar (upn, aadId, tenantId och authority) som identitet. De flesta av SDK: s identitets-API:er använder dock den angivna OID (kallas även Microsoft Entra ID eller AAD ID) som identifierare för identiteten. MAM SDK-API:erna returnerar OID-strängen som identitet och kräver OID-strängparametern för identiteten. Vissa metoder kan också ta eller returnera en UPN-sträng, i vilket fall UPN endast är i informationssyfte.

Identitetsparametrar är skiftlägesokänsliga. Begäranden till SDK för en identitet kanske inte returnerar samma skiftläge som användes vid registrering eller inställning av identiteten.

Försiktighet

För appar som använder inaktuella metoder som tar eller returnerar en UPN-sträng måste appar se till att identitets-UPN-strängen som skickas till olika API-anrop är konsekvent. Om inkonsekventa UPN-strängar skickas kan det leda till dataläckor.

Hanterade jämfört med ohanterade identiteter

Enligt beskrivningen i Registrering för appskyddsprincip ansvarar ditt program för att informera SDK när en användare loggar in. Vid inloggningen kan användarens konto vara eller inte vara mål för appskyddsprincipen. Om kontot är mål för appskyddsprincipen anser SDK:n att det hanteras. Annars är den ohanterad.

SDK:n framtvingar principen för identiteter som den anser vara hanterade. SDK:n framtvingar inte principer 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 efterföljande 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 mål för appskyddsprincipen returnerar MAMEnrollmentManager.Result.WRONG_USER SDK:n och uppmanar slutanvändaren att åtgärda alternativen. Mer information finns i Registrera dig för meddelanden från SDK .

Obs!

Ett konto som inte är mål för appskyddsprincipen vid registreringstillfället betraktas som ohanterat. Även om kontot inte är licensierat för eller mål med appskyddsprincipen kontrollerar SDK:et regelbundet om det här kontot blir licensierat och riktat 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 igen med det här kontot för att göra den här ändringen.

Den aktiva identiteten

Ditt program måste alltid hålla SDK:n informerad om identiteten som används för närvarande, även kallat den aktiva identiteten. Om den aktiva identiteten hanteras tillämpar SDK:n skydd. Om den aktiva identiteten inte hanteras tillämpar SDK:n 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 berättar för SDK:n att en ohanterad identitet är aktiv när den hanterade identiteten faktiskt används, tillämpar SDK:n inte skydd. Detta kan orsaka en dataläcka som utsätter användarnas data för risk.

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

Om programmet visar användardata 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 programmet skriver en ny fil associerar SDK:n (även kallat "taggar") en identitet med filen baserat på den aktuella aktiva tråden och processidentiteten. Alternativt kan din app anropa SDK direkt för att manuellt tagga en fil med en viss identitet (mer information finns i Skriva skyddade Files). SDK:n använder den här taggade filidentiteten för både filkryptering och selektiv rensning.

Om den hanterade identiteten är riktad mot en krypteringsprincip krypteras endast filer som är taggade med den hanterade identiteten.

Om administratörsåtgärder 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:ets standardbeteende i att dessa data underskyddas eller överskyddas. Vi rekommenderar starkt att du organiserar appens data efter identitet.

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

Implementera multiidentitet

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" />

Ställa in den aktiva identiteten

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

1. Trådnivå
2. Context (Allmänt Activity) nivå
3. Processnivå

En identitetsuppsättning på trådnivå ersätter en identitetsuppsättning på nivån Context , som ersätter en identitetsuppsättning på processnivå.

En identitetsuppsättning på en Context används endast i lämpliga associerade scenarier. Fil-I/O-åtgärder har till exempel ingen associerad Context. Vanligast är att appar anger identiteten Context på en Activity. Överväg att ange identiteten Context i Activity.onCreate. En app får inte visa data för en identitet såvida identiteten Activity inte är inställd på samma identitet.

I allmänhet är identiteten på processnivå bara användbar om appen bara fungerar med en enda identitet i taget på alla trådar. Detta är inte typiskt för appar som har stöd för flera konton. Vi rekommenderar starkt att du separerar kontodata och anger den aktiva identiteten i tråden eller Context nivåerna.

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

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

Försiktighet

Appar som använder WorkManager den bör vara särskilt försiktiga när identiteten anges. 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() enlighet med vad som krävs av implementeringen Worker .

Obs!

Eftersom används CLIPBOARD_SERVICE för användargränssnittsåtgärder använder SDK:n användargränssnittsidentiteten 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 tidigare angetts.

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

public static String getUIPolicyIdentityOID(final Context context);

public static MAMIdentitySwitchResult setProcessIdentityOID(final String oid);

public static String getProcessIdentityOID();

public static MAMIdentitySwitchResult setCurrentThreadIdentityOID(final String oid);

public static String getCurrentThreadIdentityOID();

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

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


public static AppPolicy getPolicyForIdentityOID(final String oid);

public static boolean getIsIdentityOIDManaged(final String oid);

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.setUIPolicyIdentityOID. Det gör du med följande metod:

     public final void switchMAMIdentityOID(final String newIdentityOid, 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 köra någon åtgärd och, om de returnerar en MAMIdentitySwitchResult, kommer alltid att returneras FAILED.

Fallgropar med vanliga identitetsbyten

• 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 Context ställer in nivåidentiteten med kontexten Activitys, inte kontexten Application.

• Vi rekommenderar att du anger Context identiteten under en aktivitets onCreate metod. Se dock 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 är inte tillåten. Detta inträffar om ett försök görs att ange UI-identiteten (Context) när en annan identitet har angetts för den aktuella tråden.
CANCELLED	Användaren avbröt identitetsändringen, vanligtvis genom att trycka på bakåtknappen på en PIN-kod eller uppmaning om autentisering.
FAILED	Identitetsändringen misslyckades av en ospecificerad anledning.

Appen bör verifiera att MAMIdentitySwitchResult är SUCCEEDED innan data för ett hanterat konto visas eller används.

De flesta metoder för att ange den aktiva identiteten returnerar MAMIdentitySwitchResult synkront. Om du anger en Context identitet via setUIPolicyIdentityOID rapporteras resultatet asynkront. Appen kan implementera en MAMSetUIIdentityCallback för att ta emot det här resultatet, eller skicka null för återanropsobjektet. Om ett samtal görs till setUIPolicyIdentityOID medan resultatet från ett tidigare anrop till setUIPolicyIdentityOIDpå samma Context sätt ännu inte har levererats, kommer det nya återanropet att ersätta det gamla och det ursprungliga återanropet kommer aldrig att få något resultat.

Försiktighet

Om den Context angivna uppsättningsUIPolicyIdentityOID :en är en Activityvet SDK:n inte om identitetsändringen lyckades förrän administratörens konfigurerade kontroller för villkorlig start har utförts. Detta kan kräva att användaren anger en PIN-kod eller företagets autentiseringsuppgifter.

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

Identitetsväxlingen för användargränssnittet kan misslyckas på grund av ogiltiga argument, om den skulle vara i konflikt med trådidentiteten eller om användaren avbryter kravet på villkorsstyrd start (till exempel trycker på bakåtknappen på PIN-skärmen).

Standardbeteendet för en misslyckad UI-identitetsväxling för en aktivitet är att slutföra aktiviteten. Om du vill ändra det här beteendet och få meddelanden om försök till identitetsändringar 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 data för ett hanterat konto inte visas efter ett misslyckat identitetsbyte.

Obs!

Om du byter identitet kan aktiviteten behöva återskapas. I det här fallet onSwitchMAMIdentityComplete levereras motringningen till den nya instansen av aktiviteten.

Identitet, avsikter och IdentitySwitchOptions

Förutom att automatiskt tagga nya filer med den aktiva identiteten taggar SDK:n ä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:n vanligtvis (*) en identitetsväxel (se Implicita identitetsändringar nedan för mer information).

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

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

De valfria IdentitySwitchOption-uppräkningarna kan skickas till API:erna setUIPolicyIdentityOID och switchMAMIdentityOID för att ändra SDK:s standardbeteende.

• IGNORE_INTENT: när du begär en identitetsväxling i användargränssnittslagret informerar det här alternativet SDK 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 inte bör blockera identitetsbytet. Till exempel:

  1. Din app är ett dokumentvisningsprogram. Den kan återge dokument som skickats in 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 funktionen för kontobyte navigerar appen till en kontospecifik målsida 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 skydd korrekt tillämpade.
  4. Användaren använder kontoväxlaren för att byta till sitt personliga konto.

  Din app måste ändra UI-identiteten 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ändas IGNORE_INTENT i identitetsväxlingsanropet. På så sätt undviker du att SDK:n misslyckas med det här anropet på ett olämpligt sätt.

• DATA_FROM_INTENT: när du begär en identitetsväxling i användargränssnittslagret informerar det här alternativet SDK:n om att data från den senast lagrade avsiktsidentiteten fortsätter att visas när identitetsbytet har slutförts. Därför utvärderar SDK:n mottagningsprincipen fullständigt mot den tidigare avsiktsidentiteten för att avgöra om den får visas. Till exempel:

  1. Din app är ett dokumentvisningsprogram. Den kan återge dokument som skickats in från andra appar. Den innehåller också en funktion där användare kan byta konto. Till skillnad från 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 funktionen för kontobyte.
  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 skydd korrekt tillämpade.
  4. Användaren använder kontoväxlaren för att byta till sitt personliga konto.

  Din app måste ändra UI-identiteten 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ändas DATA_FROM_INTENT i identitetsväxlingsanropet. Detta informerar SDK om att kontrollera den konfigurerade appskyddsprincipen för att avgöra om det är lämpligt att data fortsätter att visas.

(*) SDK:s standardbeteende omfattar särskilda skiftlägen som hoppar över den här dataingresskontrollen om avsikten till exempel kommer inifrån samma app eller från systemstartprogrammet.

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:n ska tillämpa den hanterade identitetens principer, men du kanske inte har någon uttrycklig identitet att växla till.

Du kan radera den aktiva identiteten genom att anropa någon av de angivna identitetsmetoderna med identitets-OID-parametern inställd på null. Om du rensar identiteten på en nivå kommer SDK:n att söka efter den aktiva identiteten på andra nivåer, baserat på prioritetsordningen.

Alternativt kan du skicka en tom sträng som identitets-OID-parameter, som anger identiteten till ett särskilt tomt värde som behandlas som en ohanterad identitet. Om du anger den aktiva identiteten till en tom sträng anger du att SDK :n inte ska tillämpa någon appskyddsprincip.

Implicita identitetsändringar

I avsnittet ovan beskrivs de olika sätt som din app uttryckligen kan ange den aktiva identiteten på tråd-, kontext- och processnivå. Men den aktiva identiteten i din app kan också ändras utan att din app 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:n ändrar aldrig den aktiva identiteten utan att tillhandahålla dessa implicita meddelanden om identitetsändringar.

Försiktighet

Om din app väljer att inte lyssna efter implicita identitetsändringar bör du vara extra försiktig så att du inte antar den aktiva identiteten. Om du är osäker kan du använda , getCurrentThreadIdentityOIDgetUIPolicyIdentityOIDoch getProcessIdentityOID metoder för att bekräfta den aktiva identiteten.

Källor till implicita identitetsändringar

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

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

    • Till exempel startas en aktivitet för att visa ett Word dokument från en avsikt från Outlook när en användare väljer ett bifogat dokument. Identiteten för aktiviteten i Office-dokumentvisningsprogrammet växlas till identiteten från Outlook.

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

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

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

  • Om en användare avbryter en auktoriseringsfråga resulterar Resume det 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. Programmet kan till exempel kräva flera steg innan ett extra konto kan användas, till exempel en e-postapp som konfigurerar en ny inkorg. När du ser ett identitetsförsök växla till den här ofullständiga kontoidentiteten kan appens hanterare omdirigera användaren till kontokonfigurationsaktiviteten innan identitetsbytet 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 gäller för den här tråden. Implementeringen måste åsidosätta:

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

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

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

Parametern AppIdentitySwitchReason enum beskriver källan till den implicita identitetsväxeln.

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

Med parametern AppIdentitySwitchResultCallback kan utvecklare å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 utom de som görs via en Binder som returneras från MAMService.onMAMBind. Standardimplementeringarna av onMAMIdentitySwitchRequired omedelbart anrop:

• 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 ett identitetsbyte på ett annat sätt, men om en app behöver göra det måste följande punkter beaktas:

• Om en identitetsväxling blockeras är slutanvändarbeteendet detsamma som om SDK:s skyddsinställning för "ta emot data från andra appar" hade förbjudit datainträngning.

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

• För Activity att skapa onMAMIdentitySwitchRequired anropas före onMAMCreate. Om appen måste visa användargränssnittet för att avgöra om identitetsbytet ska tillåtas, måste det 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 så att data som överensstämmer med identitetsväxlingen visas. Om detta inte är möjligt ska appen neka bytet och användaren uppmanas igen att följa principen för att återuppta identiteten (till exempel genom att se skärmen för att ange appens PIN-kod).

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.getIsIdentityOIDManaged 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 identitetsbytet nekas.

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

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

Identitetsbyten och skärmskärmsbegränsningar

Intune App SDK använder flaggan WindowFLAG_SECURE för att framtvinga skärmbildsprincip. Vissa appar kan också anges FLAG_SECURE för sina egna syften. När appskyddsprincipen inte begränsar skärmbilder ändrar FLAG_SECURESDK:n inte.

Vid en identitetsväxling från en identitet vars princip kräver att skärmbilder inaktiveras till en identitet vars princip inte gör det rensas FLAG_SECURESDK:n. Därför bör din app inte förlita sig på att FLAG_SECURE förbli inställd efter ett identitetsbyte.

Bevara identitet i asynkrona åtgärder

Appar skickar ofta bakgrundsaktiviteter från användargränssnittstråden för att hantera åtgärder i andra trådar. En app med flera identiteter måste säkerställa att dessa bakgrundsaktiviteter fungerar med rätt 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. Din app måste antingen använda dessa (eller uttryckligen ange trådidentiteten för aktiviteterna) om dess asynkrona åtgärder kan:

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

MAMAsyncTask

Om du vill använda MAMAsyncTask, ärver du helt enkelt från den istället för AsyncTask och ersätter åsidosättningar av doInBackground och onPreExecute med doInBackgroundMAM och onPreExecuteMAM respektive. 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 antar den aktiva identiteten baserat på normal prioritetsordning.

MAMIdentityExecutors

MAMIdentityExecutorsGör att du kan omsluta en befintlig Executor ELLER-instans ExecutorService som en identitetsbevarandeExecutorService/Executor MED wrapExecutor OCH-metoderwrapExecutorService. Till exempel

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

MAMIdentityExecutors antar den aktiva identiteten baserat på normal prioritetsordning.

Filskydd

Skriva skyddade filer

Som nämnts 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 korrekt kryptering och selektiv rensningsfunktion.

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

Metoden protectForOID kan också användas för att skydda kataloger. Katalogskydd gäller rekursivt för alla filer och underkataloger som finns i katalogen. När en katalog är skyddad får alla nya filer som skapas i katalogen automatiskt samma skydd. Eftersom katalogskydd tillämpas rekursivt kan anropet protectForOID ta lite tid att slutföra för stora kataloger. Därför kanske appar som använder skydd på en katalog som innehåller ett stort antal filer vill köras protectForOID asynkront på en bakgrundstråd.

Om du anropar protectForOID 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 var krypterad. När ett selektivt rensningskommando utfärdas tas filen/katalogen inte bort.

Varning

Det är viktigt att se till att endast filer som tillhör en viss identitet skyddas med den identiteten. Annars kan andra identiteter uppleva dataförlust när den ägande identiteten loggar ut, eftersom filer rensas och åtkomst till krypteringsnycklar går förlorad.

Visa skyddat filinnehåll

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

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

Om getProtectionInfo en identitet som inte är null och inte är tom rapporteras måste appen ange användargränssnittsidentiteten så att den matchar den här identiteten med hjälp av antingen MAMActivity.switchMAMIdentityOID eller MAMPolicyManager.setUIPolicyIdentityOID. Om identitetsbytet 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 getProtectionInfo överbelastningen som tar en) och sedan ange kontext- eller trådidentiteten Uripå rätt sätt. Detta måste du göra 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.

• I det öppna flödet, innan data från disken läses, bekräftar appen identiteten som ska användas för att visa innehållet:

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

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

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

• Appen öppnas och återger filen.

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

Single-Identity till övergång med flera identiteter

Om en app som tidigare släppts med enkel identitet Intune integration senare integrerar flera identiteter, kommer tidigare installerade appar att uppleva en övergång. Den här övergången visas inte för användaren.

Appen behö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.
• Anrop protectForOID 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öretagsportalen appen inte är installerad. Filidentitetstaggning är känsligt i offlineläge:

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

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

• När taggning av filidentitet blir tillgängligt behandlas alla filer som skapats tidigare som personliga/ohanterade (som tillhör identiteten med tom sträng), förutom i fall där appen tidigare installerades som en hanterad app med en enda identitet, enligt beskrivningen i Övergång från en identitet till 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.protectForOID för att korrigera filens associerade identitet när SDK:n är online.

Databuffertskydd

Varning

Du bör inte skriva data som tillhör flera konton i en enda fil. Om möjligt organiserar du appens filer efter identitet.

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

MAMDataProtectionManager.protectForOID Gör det möjligt för en app att associera data med en identitet och, om identiteten för närvarande är mål för en krypteringsprincip, kryptera data. Dessa krypterade data är lämpliga för lagring på disk i en fil.

MAMDataProtectionManager Du kan också fråga efter data som är associerade med identiteten och avkryptera dem.

Appar som använder sig av MAMDataProtectionManager bör implementera en mottagare för aviseringen MANAGEMENT_REMOVED . Mer information finns i Registrera dig 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 var aktiverad när buffertarna skyddades). En app kan förhindra att dessa buffertar blir oläsliga genom att anropa MAMDataProtectionManager.unprotect alla buffertar vid hantering av meddelandet MANAGEMENT_REMOVED . Det är också säkert att ringa protectForOID under denna meddelande, om du vill bevara identitetsinformation. Kryptering inaktiveras garanterat under meddelandet och anrop protectForOID av hanteraren krypterar inte databuffertar.

Varning

Krypteringsåtgärder bör undvikas tidigt i appprocessen. SDK:n utför krypteringsinitiering asynkront så tidigt som möjligt efter appstart. Men om en app gör en krypteringsbegäran i appstarten kan den blockeras tills krypteringsinitieringen är klar.

Obs!

Intune App SDK-krypterings-API:et bör endast användas för att kryptera data enligt Intune princip. Inget skydd tillämpas på konton som inte är mål med krypteringsprincipen aktiverad, så det kan inte användas som bibliotek för generell kryptering.

Innehållsleverantörer

En app med flera identiteter måste också skydda data som delas via ContentProviders för att förhindra olämplig delning av hanterat innehåll.

Appen måste anropa den statiska MAMContentProvider-metodenisProvideContentAllowedForOid(provider, oid) innan innehåll returneras. Om funktionen returnerar false får innehållet inte returneras till anroparen.

Du behöver inte ringa isProvideContentAllowedForOid om du ContentProvider returnerar en ParcelFileDescriptor. Filbeskrivningar som returneras av en innehållsleverantör 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:n appen på ett smidigt sätt, slutför aktiviteter och avslutar appprocessen.

SDK ger appen möjlighet att antingen komplettera (rekommenderas) eller åsidosätta standardinställningen för rensning.

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

Obs!

Komplettering och åsidosättning av standardbeteendet för rensning kräver hantering av specifika SDK-meddelanden. Se Registrera dig för meddelanden från SDK:n för mer information om hur du implementerar meddelandehanterare.

Komplettera standardrensningsbeteendet

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

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

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

Åsidosätta standardinställningen för rensning

Om du vill åsidosätta standardbeteendet för SDK-rensning kan din app 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 standard-SDK-rensningsbeteendet utgör det en stor risk för din app. Din app ansvarar helt 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 alla återstående hanterade filer krypterade. Dessa data blir otillgängliga och din app kanske inte hanterar försök att läsa krypterade data på ett smidigt sätt.
• Din apps rensningshanterare kan resultera i 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 filens identitet (via MAMFileProtectionManager.protectForOID) till antingen en ohanterad identitet eller en tom sträng.

Den åsidosatta rensningshanteraren ska rensa data synkront och inte återgå förrän rensningen är klar.

Överväg att stänga appen manuellt när du har slutfört den anpassade rensningshanteringsstegen för att förhindra att användaren kommer åt minnesinterna data efter att en rensning utförts.

Villkor för att avsluta

Planera att avsätta mycket tid för att verifiera appens integrering av flera identiteter. Innan du börjar testa:

• Skapa och tilldela en appskyddsprincip till ett konto. Det här blir ditt testhanterade konto.
• Skapa, men tilldela inte en appskyddsprincip till, ett annat konto. Det här kommer att vara ditt ohanterade testkonto. Alternativt, om din app stöder flera kontotyper utöver Microsoft Entra konton, kan du använda ett befintligt icke-Entra konto som ohanterat test konto.
• Bekanta dig med hur principer tillämpas i din app. Testning av flera identiteter kräver att du enkelt urskiljer när din app fungerar och inte fungerar med principen framtvingad. Appskyddsprincipinställningen för att blockera skärmbilder är effektiv när det gäller att snabbt testa principtillämpningen.
• Tänk på hela uppsättningen användargränssnitt som din app erbjuder. Räkna upp skärmarna där kontodata visas. Visar appen bara ett kontos data samtidigt eller kan den presentera data som tillhör flera konton samtidigt?
• Tänk på hela uppsättningen filer som appen skapar. Räkna upp vilka av dessa filer som innehåller data som tillhör ett konto, i motsats till data på systemnivå.
  • Bestäm hur du ska verifiera kryptering på var och en av dessa filer.
• Fundera över hur din app kan interagera med andra appar. Räkna upp alla ingående och utgående punkter. Vilka typer av data kan appen mata in? Vilka avsikter sänds den? Vilka innehållsleverantörer implementeras?
  • Bestäm hur du ska använda var och en av dessa datadelningsfunktioner.
  • 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 noggrant har utvärderat appens aktuella beteende verifierar du integreringen av flera identiteter genom att köra följande uppsättning tester. Observera att det här inte är en fullständig lista och garanterar inte att appens implementering av flera identiteter är felfri.

Verifiera inloggnings- och utloggningsscenarier

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

För dessa tester installerar du din app och Intune-företagsportal; logga inte in innan du startar testet.

Scenario	Steg
Logga in hanterad först	- Logga först in med ett hanterat konto och kontrollera att kontots data hanteras. - Logga in med ett ohanterat konto och kontrollera att kontots data inte hanteras.
Logga in ohanterad först	- Logga först in med ett ohanterat konto och kontrollera att kontots data inte hanteras. - Logga in med ett hanterat konto och kontrollera att kontots data hanteras.
Logga in flera hanterade	- Logga först in med ett hanterat konto och kontrollera att kontots data hanteras. - Logga in med ett andra hanterat konto och verifiera 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 appen och att alla kontodata har tagits bort. - Bekräfta att det ohanterade kontot fortfarande är inloggat, att inga data för det ohanterade kontot har tagits bort och att principen fortfarande inte tillämpas.
Logga ut ohanterad	- 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 appen och att alla kontodata har tagits bort. - Bekräfta att det hanterade kontot fortfarande är inloggat, att inga av det ohanterade kontots data har tagits bort och att principen fortfarande tillämpas.

Validera aktiv identitet och appens livscykel

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

För dessa tester installerar du din app och Intune-företagsportalen; loggar in med både ett hanterat och ohanterat konto innan du startar testet.

Scenario	Steg
Vy för ett enskilt konto, hanterad	- Växla till det hanterade kontot. - Navigera till alla sidor i din app som visar data för ett enda konto. - Kontrollera att principen tillämpas på varje sida.
Vy med ett enda konto, ohanterad	- Växla till det ohanterade kontot. - Navigera till alla sidor i din app som visar data för ett enda konto. - Bekräfta att policyn inte tillämpas på någon sida.
Vy för flera konton	- Navigera till alla sidor i din app som visar flera kontons data samtidigt. - Kontrollera att principen tillämpas på varje sida.
Hanterad paus	- På en skärm där hanterade data visas och principen är aktiv pausar du appen genom att navigera 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 policy är aktiv, pausar du appen genom att navigera till enhetens startskärm eller en annan app. - Återuppta appen. - Bekräfta att principen inte tillämpas.
Hanterat dödande	- På en skärm med hanterade data som visas och principen är aktiv, tvingar du att avsluta appen. - Starta om appen. - Bekräfta att policyn 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 data för det ohanterade kontot bekräftar du att principen inte används.
Okontrollerat avslut	- Tvångsavsluta appen på en skärm där ohanterade data visas och principen är aktiv. - 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 data för det hanterade kontot bekräftar du att principen fortfarande används.
Ad hoc-identitetsväxling	- Experimentera med att växla mellan konton och pausa/återuppta/döda/starta om appen. - Bekräfta att det hanterade kontots data alltid är skyddade och att det ohanterade kontots data aldrig är skyddade.

Validera scenarier för datadelning

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

För dessa tester installerar du din app och Intune-företagsportalen; loggar 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, riktad mot samma princip som din app, som kan skicka och ta emot data (t.ex. Outlook).
  • Alla ohanterade appar som kan skicka och ta emot data.
• Logga in med det andra hanterade testkontot i den andra hanterade appen. Även om den andra hanterade appen har flera identiteter behöver du bara logga in med det hanterade kontot.

Om din app kan skicka data till andra appar, till exempel Outlook som skickar en bifogad dokumentfil till Microsoft Office:

Scenario	Steg
Hanterad identitet skickas till ohanterad app	- Växla till det hanterade kontot. - Navigera till den plats där din app kan skicka data. - Försök skicka data till en ohanterad app. – Du bör blockeras från att skicka data till den ohanterade appen.
Skicka hanterad identitet till hanterad app	- Växla till det hanterade kontot. - Navigera till den plats där din app kan skicka data. - Försök skicka data till den andra hanterade appen med det hanterade kontot inloggat. – Du bör kunna skicka data till den hanterade appen.
Ohanterad identitet Skicka till hanterad app	- Växla till det ohanterade kontot. - Navigera till den plats där din app kan skicka data. - Försök skicka data till den andra hanterade appen med det hanterade kontot inloggat. – 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 den plats där din app kan skicka data. - Försök skicka data till en ohanterad app. - Du bör alltid ha tillåtelse att skicka data för ett ohanterat konto till en ohanterad app.

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

Om din app kan aktivt importera data från andra appar:

Scenario	Steg
Import av 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 importera data från en ohanterad app. – Du bör blockeras från att importera data från ohanterade appar.
Import av 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 importera data från den andra hanterade appen med det hanterade kontot inloggat. – Du bör kunna importera data från den andra hanterade appen.
Import av ohanterade identiteter 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 importera data från den andra hanterade appen med det hanterade kontot inloggat. – Du bör blockeras från att importera data från den andra hanterade appen.
Import av ohanterade identiteter 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 importera data från en ohanterad app. – Du bör alltid ha tillåtelse att importera data från ohanterade appar för ett ohanterat konto.

Om din app kan passivt ta emot data från andra appar:

Scenario	Steg
Ta emot hanterad identitet från ohanterad app	- Växla till det hanterade kontot. - Byt till den ohanterade appen. - Navigera till den plats där den kan skicka data. - Försök skicka data från den ohanterade appen till din app. - Appens hanterade konto ska inte kunna ta emot data från den ohanterade appen.
Ta emot hanterad identitet från hanterad app	- Växla till det hanterade kontot. - Växla till den andra hanterade appen med det hanterade kontot inloggat. - Navigera till den plats där den kan skicka data. - Försök 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 tas emot från hanterad app	- Växla till det ohanterade kontot. - Växla till den andra hanterade appen med det hanterade kontot inloggat. - Navigera till den plats där den kan skicka data. - Försök 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 tas emot från ohanterad app	- Växla till det ohanterade kontot. - Byt till den ohanterade appen. - Navigera till den plats där den kan skicka data. - Försök skicka data från den ohanterade appen till din app. - Din apps ohanterade konto ska alltid tillåtas 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:s API:er för att hämta identitet när de skickas/tas 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:s standardrensningsbeteende. De här testerna hjälper till att säkerställa att integreringen av flera identiteter tar bort hanterade data på rätt sätt när rensningar initieras, utan att ohanterade data påverkas.

Varning

Påminnelse, om din app utnyttjade MAMDataProtectionManager.protectForOIDmåste den implementera en hanterare för antingen WIPE_USER_AUXILIARY_DATA eller WIPE_USER_DATA.

För dessa tester installerar du din app och Intune-företagsportalen; loggar in med både ett hanterat och ohanterat konto innan du startar testet. För båda kontona kan du träna appscenarier som lagrar kontodata.

Scenario	Förutsättningar	Steg
Extra hanterare för rensning	Din app har implementerat en hanterare för WIPE_USER_AUXILIARY_DATA	- Utfärda en selektiv rensning från Microsoft Intune administrationscenter. - Bekräfta (vanligtvis via loggning) att rensningshanteraren har körts. - Bekräfta att det hanterade kontot har tagits bort från appen och att alla kontodata har tagits bort. - Bekräfta att det ohanterade kontot fortfarande är inloggat, att inga data för det ohanterade kontot 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 Microsoft Intune administrationscenter. - Bekräfta (vanligtvis via loggning) att rensningshanteraren har körts. - Bekräfta att det hanterade kontot har tagits bort från appen och att alla kontodata har tagits bort. - Bekräfta att det ohanterade kontot fortfarande är inloggat, att inga data för det ohanterade kontot 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 är klar.
Manuellt filskydd	- Din app ringer MAMFileProtectionManager.protectForOID - Din app har implementerat en hanterare för WIPE_USER_DATA	- Se till att du har utövat scenarier där din app manuellt skulle skydda minst en fil som tillhör det hanterade kontot. - Utfärda en selektiv rensning från Microsoft Intune administrationscenter. - Bekräfta att filerna är borttagna.
Manuellt databuffertskydd	- Din app ringer MAMDataProtectionManager.protectForOID - Din app har implementerat en hanterare för antingen WIPE_USER_AUXILIARY_DATA eller WIPE_USER_DATA	- Se till att du har utövat scenarier där din app manuellt skulle skydda minst en databuffert som tillhör det hanterade kontot. - Utfärda en selektiv rensning från Microsoft Intune administrationscenter. - Bekräfta att databuffertarna har tagits bort från de filer som de lagrades i och att din app fortfarande kan läsa ohanterade data från dessa filer.

Nästa steg

När du har uppfyllt alla avslutsvillkor ovan är din app nu integrerad som flera identiteter och kan tillämpa appskyddsprinciper per identitet. De efterföljande avsnitten, steg 6: App Configuration och steg 7: Funktioner för appdeltagande, kan vara nödvändiga eller inte, beroende på vilket stöd du vill att appskyddsprincipen ska ha. Om du är osäker på om något av dessa avsnitt gäller för din app går du till viktiga beslut för SDK-integrering.