Intune App SDK för iOS – flera identiteter

Obs!

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

Steg 5: Flera identiteter (valfritt)

Som standard tillämpar SDK:t en princip på appen som helhet. Flera identiteter är en MAM-funktion som du kan aktivera för att tillämpa en princip på en nivå per identitet. Detta kräver mer app deltagande än andra MAM-funktioner.

Appen måste informera app-SDK när den avser att ändra den aktiva identiteten. SDK meddelar även appen när en identitetsändring krävs. För närvarande stöds endast en hanterad identitet. När användaren har registrerat enheten eller appen använder SDK:n den här identiteten och betraktar den som den primära hanterade identiteten. Andra användare i appen behandlas som ohanterade med obegränsade principinställningar.

Observera att en identitet helt enkelt definieras som en sträng. Identiteter är skiftlägeskänsliga. Begäranden till SDK för en identitet kanske inte returnerar samma hölje som ursprungligen användes när identiteten angavs.

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.

Identitetsöversikt

En identitet är bara användarnamnet för ett konto (till exempel user@contoso.com). Utvecklare kan ange appens identitet på följande nivåer:

• Processidentitet: Anger den processomfattande identiteten och används främst för program med en enda identitet. Den här identiteten påverkar alla uppgifter, filer och användargränssnitt.

• Användargränssnittsidentitet: Avgör vilka principer som tillämpas på gränssnittsuppgifter i huvudtråden, till exempel klipp ut/kopiera/klistra in, PIN-kod, autentisering och datadelning. Användargränssnittsidentiteten påverkar inte filuppgifter som kryptering och säkerhetskopiering.

• Trådidentitet: Påverkar vilka principer som tillämpas på den aktuella tråden. Den här identiteten påverkar alla uppgifter, filer och användargränssnitt.

Appen ansvarar för att ange identiteterna på rätt sätt, oavsett om användaren hanteras eller inte.

Varje tråd har när som helst en effektiv identitet för användargränssnittsuppgifter och filuppgifter. Det här är den identitet som används för att kontrollera vilka principer som ska tillämpas. Om identiteten är "ingen identitet" eller om användaren inte hanteras tillämpas inga principer. Diagrammen nedan visar hur de effektiva identiteterna bestäms.

Trådköer

Appar skickar ofta asynkrona och synkrona uppgifter till trådköer. SDK fångar upp GCD-anrop (Grand Central Dispatch) och associerar den aktuella trådidentiteten med de skickade uppgifterna. När uppgifterna är klara ändrar SDK:t tillfälligt trådidentiteten till den identitet som är associerad med aktiviteterna, slutför uppgifterna och återställer sedan den ursprungliga trådidentiteten.

Eftersom NSOperationQueue är byggt ovanpå GCD NSOperations körs på trådens identitet när aktiviteterna läggs till NSOperationQueuei . NSOperations eller funktioner som skickas direkt via GCD kan också ändra den aktuella trådidentiteten när de körs. Den här identiteten åsidosätter identiteten som ärvts från sändningstråden.

På grund av en konsekvens av hur SDK:n sprider identiteter för är identiteten som är associerad med en DispatchWorkItem identiteten för DispatchWorkItemden tråd som skapade objektet, inte den tråd som skickar det.

Filägare

SDK spårar identiteterna för lokala filägare och tillämpar principer i enlighet med detta. En filägare upprättas när en fil skapas eller när en fil öppnas i trunkeringsläge. Ägaren är inställd på den effektiva filuppgiftsidentiteten för den tråd som utför uppgiften.

Alternativt kan appar uttryckligen ange filägaridentiteten med hjälp IntuneMAMFilePolicyManagerav . Appar kan använda IntuneMAMFilePolicyManager för att hämta filägaren och ange användargränssnittets identitet innan filinnehållet visas.

Delade data

Om appen skapar filer som har data från både hanterade och ohanterade användare ansvarar appen för att kryptera den hanterade användarens data. Du kan kryptera data med api:erna protect och unprotect i IntuneMAMDataProtectionManager.

Metoden protect accepterar en identitet som kan vara en hanterad eller ohanterad användare. Om användaren hanteras krypteras data. Om användaren är ohanterad läggs en rubrik till i de data som kodar identiteten, men data krypteras inte. Du kan använda protectionInfo metoden för att hämta dataägaren.

Dela tillägg

Om appen har ett resurstillägg kan ägaren av objektet som delas hämtas via protectionInfoForItemProvider metoden i IntuneMAMDataProtectionManager. Om det delade objektet är en fil hanterar SDK:et inställningen för filägaren. Om det delade objektet är data ansvarar appen för att ange filägaren om dessa data sparas i en fil och för att anropa API:et setUIPolicyAccountId innan dessa data visas i användargränssnittet.

Aktivera flera identiteter

Som standard betraktas appar som en enda identitet. SDK anger processidentiteten till den registrerade användaren. Om du vill aktivera stöd för flera identiteter lägger du till en boolesk inställning med namnet MultiIdentity och värdet YES i ordlistan IntuneMAMSettings i appens Info.plist-fil.

Obs!

När flera identiteter är aktiverade anges processidentiteten, användargränssnittsidentiteten och trådidentiteterna till noll. Appen ansvarar för att ställa in dem på rätt sätt.

Växla identiteter

• Appinitierad identitetsväxling:

  Vid start anses appar med flera identiteter köras under ett okänt, ohanterat konto. Användargränssnittet för villkorlig start körs inte och inga principer tillämpas på appen. Appen ansvarar för att meddela SDK:t när identiteten ska ändras. Detta sker vanligtvis när appen är på väg att visa data för ett specifikt användarkonto.

  Ett exempel är när användaren försöker öppna ett dokument, en postlåda eller en flik i en notebook-fil. Appen måste meddela SDK innan filen, postlådan eller fliken faktiskt öppnas. Detta görs via API:et setUIPolicyAccountId i IntuneMAMPolicyManager. Det här API:et ska anropas om användaren hanteras eller inte. Om användaren hanteras utför SDK:t de villkorliga startkontrollerna, till exempel upplåsningsidentifiering, PIN-kod och autentisering.

  Resultatet av identitetsväxlingen returneras till appen asynkront via en slutförandehanterare. Appen bör skjuta upp öppnandet av dokumentet, postlådan eller fliken tills en resultatkod returneras. Om identitetsväxlingen misslyckades bör appen avbryta uppgiften.

  Appar med flera identiteter bör undvika att använda setProcessAccountId som ett sätt att ange identiteten. Appar som använder UIScenes bör använda API:et setUIPolicyAccountId:forWindow för att ange identiteten.

  Appar kan också ange identiteten för den aktuella tråden med hjälp av setCurrentThreadIdentity: och setCurrentThreadIdentity:forScope:. Appen kan till exempel skapa en bakgrundstråd, ange identiteten till den hanterade identiteten och sedan utföra filåtgärder på hanterade filer. Om appen använder setCurrentThreadAccountId:bör appen också använda getCurrentThreadAccountId så att den kan återställa den ursprungliga identiteten när den är klar. Men om appen använder setCurrentThreadAccountId:forScope: så sker återställningen av den gamla identiteten automatiskt. Vi föredrar att använda setCurrentThreadAccountId:forScope:.

  I Swift, på grund av async/await, [IntuneMAMPolicyManager setCurrentThreadAccountId:] och [IntuneMAMPolicyManager setCurrentThreadAccountId:forScope:] är inte tillgängliga. I stället i Swift för att ange den aktuella identiteten använder du IntuneMAMSwiftContextManager.setAccountId(_, forScope:). Det finns varianter av det här API:et för att asynkrona, kasta och asynkrona stängningar ska skickas in.

• SDK-initierad identitetsväxling:

  Ibland måste SDK:t be appen att växla till en specifik identitet. Appar med flera identiteter måste implementera identitySwitchRequiredForAccountId metoden i IntuneMAMPolicyDelegate för att hantera den här begäran.

  När den här metoden anropas, om appen kan hantera begäran om att växla till den angivna identiteten, bör den skickas IntuneMAMAddIdentityResultSuccess till slutförandehanteraren. Om den inte kan hantera växling av identiteten bör appen skickas IntuneMAMAddIdentityResultFailed till slutförandehanteraren.

  Appen behöver inte anropa setUIPolicyAccountId som svar på det här anropet. Om SDK:et behöver appen för att växla till ett ohanterat användarkonto skickas den tomma strängen till anropet identitySwitchRequiredForAccountId .

• SDK-initierad identitet registreras automatiskt:

  När SDK:et behöver registrera en användare automatiskt i appen för att utföra en åtgärd måste appar implementera addIdentity:completionHandler: metoden i IntuneMAMPolicyDelegate. Programmet måste sedan anropa slutförandehanteraren och skicka in IntuneMAMAddIdentityResultSuccess om appen kan lägga till identiteten eller IntuneMAMAddIdentityResultFailed på annat sätt.

• Selektiv rensning:

  När appen rensas selektivt anropar wipeDataForAccountId SDK -metoden i IntuneMAMPolicyDelegate. Appen ansvarar för att ta bort den angivna användarens konto och alla data som är associerade med det. SDK:et kan ta bort alla filer som ägs av användaren och gör det om appen returnerar FALSE från anropet wipeDataForAccountId .

  Observera att den här metoden anropas från en bakgrundstråd. Appen bör inte returnera ett värde förrän alla data för användaren har tagits bort (med undantag för filer om appen returnerar FALSE).

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.

För dessa tester installerar du appen på en testenhet. 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.

För dessa tester installerar du appen på en testenhet. 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.

För dessa tester installerar du appen på en testenhet. 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.

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: Stöd för villkorsstyrd åtkomst för appskydd och steg 7: Webbvisningsfunktioner kan eller kanske inte krävs, beroende på appens önskade stöd för appskyddsprincipen.