Intune App SDK för iOS – Multi-Identity

Obs!

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

Steg 5: Flera identiteter (valfritt)

Som standard tillämpar SDK:n en princip på appen som helhet. Multi-identity är en MAM-funktion som du kan aktivera för att tillämpa en princip på identitetsnivå. Detta kräver mer appdeltagande än andra MAM-funktioner.

Appen måste informera appens SDK när den har för avsikt att ändra den aktiva identiteten. SDK:n meddelar också 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ägesokänsliga. Begäranden till SDK för en identitet kanske inte returnerar samma skiftläge som ursprungligen användes när identiteten angavs.

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.

Översikt över identitet

En identitet är helt enkelt användarnamnet på 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 enskilda identitetsprogram. Den här identiteten påverkar alla aktiviteter, filer och användargränssnitt.

  • Användargränssnittsidentitet: Avgör vilka principer som tillämpas på användargränssnittsuppgifter på huvudtråden, till exempel klippa ut/kopiera/klistra in, PIN-kod, autentisering och datadelning. Användargränssnittets identitet påverkar inte filåtgärder 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 aktiviteter, 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 alltid en effektiv identitet för gränssnittsuppgifter och filuppgifter. Det här är den identitet som används för att kontrollera vilka principer, om några, som ska tillämpas. Om identiteten är "ingen identitet" eller om användaren inte hanteras kommer inga principer att tillämpas. Diagrammen nedan visar hur de effektiva identiteterna fastställs.

Intune App SDK iOS: Process för identitetsbestämning

Trådköer

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

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

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

Filägare

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

Appar kan också ange filägarens identitet explicit med hjälp IntuneMAMFilePolicyManagerav . Appar kan använda IntuneMAMFilePolicyManager för att hämta filägaren och ange användargränssnittsidentiteten innan innehållet i filen visas.

Delade data

Om appen skapar filer som innehåller data från både hanterade och ohanterade användare, är appen ansvarig för att kryptera den hanterade användarens data. Du kan kryptera data med hjälp av 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 ett huvud till i de data som kodar identiteten, men data krypteras inte. Du kan använda metoden protectionInfo för att hämta dataägaren.

Dela tillägg

Om appen har ett delningstillägg kan ägaren till det objekt som delas hämtas med protectionInfoForItemProvider hjälp av metoden i IntuneMAMDataProtectionManager. Om det delade objektet är en fil hanterar SDK:et inställningen av filägaren. Om det delade objektet är data ansvarar programmet för att ange filägaren om dessa data finns kvar i en fil, och för att anropa API:t setUIPolicyAccountId innan dessa data visas i användargränssnittet.

Aktivera multiidentitet

Som standard betraktas appar som en enda identitet. SDK:n 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 JA i ordlistan IntuneMAMSettings i appens Info.plist-fil.

Obs!

När multiidentitet är aktiverat anges processidentiteten, UI-identiteten och trådidentiteterna till noll. Appen ansvarar för att ställa in dem på rätt sätt.

Byt identitet

Viktigt

SDK:n kan inte identifiera identitetsändringar oberoende av varandra. Den förlitar sig helt på appen för att rapportera dem. Om appen inte meddelar SDK:n korrekt om en identitetsväxling:

  • Principer för appskydd kanske inte tillämpas för den aktiva användaren och lämnar hanterade data oskyddade.
  • Ohanterade data kan begränsas felaktigt.

Appen måste anropa lämpliga API:er för identitetsväxling (till exempel setUIPolicyAccountId) när den aktiva användaren ändras, inklusive vid appstart, kontobyte och när data för en annan användare visas.

  • Appinitierad identitetsväxling:

    Vid start anses appar med flera identiteter köras under ett okänt, ohanterat konto. Användargränssnittet för villkorsstyrd start körs inte och inga principer tillämpas på appen. Appen ansvarar för att meddela SDK när identiteten ska ändras. Vanligtvis inträffar detta när appen ska visa data för ett visst användarkonto.

    Ett exempel är när användaren försöker öppna ett dokument, en postlåda eller en flik i en anteckningsbok. 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 oavsett om användaren hanteras eller inte. Om användaren hanteras utför SDK:n kontrollerna för villkorlig start, till exempel identifiering av jailbreak, PIN-kod och autentisering.

    Resultatet av identitetsbytet 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 identitetsbytet misslyckades bör appen avbryta aktiviteten.

    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:ska appen också användas getCurrentThreadAccountId så att den kan återställa den ursprungliga identiteten när den är klar. Men om appen använder setCurrentThreadAccountId:forScope: återställs den gamla identiteten automatiskt. Det är att föredra 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 identitetsanvändningen IntuneMAMSwiftContextManager.setAccountId(_, forScope:). Det finns varianter av det här API:et för asynkrona, kastande och asynkrona stängningar som ska skickas in.

  • SDK-initierad identitetsväxling:

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

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

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

  • SDK-initierad automatisk identitetsregistrering:

    När SDK:n automatiskt behöver registrera en användare 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 IntuneMAMAddIdentityResultSuccess om appen kan lägga till identiteten eller IntuneMAMAddIdentityResultFailed annars.

  • Selektiv rensning:

    När appen rensas selektivt anropar SDK:n wipeDataForAccountId metoden i IntuneMAMPolicyDelegate. Appen ansvarar för att ta bort den angivna användarens konto och alla data som är kopplade till det. SDK:n 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 ska 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 FALSKT).

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-AAD-konto som det ohanterade testkontot.
  • 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 appen på en testenhet. 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 appen på en testenhet. Logga 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 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, 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.

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: Stöd för villkorsstyrd åtkomst för appskydd och steg 7: Webbvisningsfunktioner, kan vara nödvändiga eller inte, beroende på appens önskade stöd för appskyddsprinciper.

  • Last updated on