Intune App SDK voor iOS - Multi-Identity

Opmerking

Deze handleiding is onderverdeeld in verschillende fasen. Bekijk eerst Fase 1: De integratie plannen.

Fase 5: Meerdere identiteiten (optioneel)

Standaard past de SDK een beleid toe op de app als geheel. Meerdere identiteiten is een MAM-functie die u kunt inschakelen om een beleid per identiteit toe te passen. Hiervoor is meer deelname aan apps vereist dan andere MAM-functies.

De app moet de app-SDK informeren wanneer deze van plan is de actieve identiteit te wijzigen. De SDK meldt de app ook wanneer een identiteitswijziging is vereist. Momenteel wordt slechts één beheerde identiteit ondersteund. Nadat de gebruiker het apparaat of de app heeft ingeschreven, gebruikt de SDK deze identiteit en wordt deze beschouwd als de primaire beheerde identiteit. Andere gebruikers in de app worden behandeld als onbeheerd met onbeperkte beleidsinstellingen.

Houd er rekening mee dat een identiteit eenvoudigweg wordt gedefinieerd als een tekenreeks. Identiteiten zijn niet hoofdlettergevoelig. Aanvragen voor de SDK voor een identiteit retourneren mogelijk niet dezelfde casing die oorspronkelijk werd gebruikt toen de identiteit werd ingesteld.

Fase Goals

• Bepaal of uw toepassing ondersteuning voor meerdere identiteiten nodig heeft.
• Inzicht in hoe de Intune App SDK identiteiten ziet.
• Uw toepassing herstructureren voor identiteitsbewustzijn.
• Voeg code toe om de SDK te informeren over actieve en veranderende identiteiten in uw toepassing.
• Test het afdwingen van app-beveiligingsbeleid grondig voor zowel beheerde als onbeheerde identiteiten.

Identiteitsoverzicht

Een identiteit is gewoon de gebruikersnaam van een account (bijvoorbeeld user@contoso.com). Ontwikkelaars kunnen de identiteit van de app instellen op de volgende niveaus:

• Procesidentiteit: stelt de procesbrede identiteit in en wordt voornamelijk gebruikt voor toepassingen met één identiteit. Deze identiteit is van invloed op alle taken, bestanden en gebruikersinterface.

• UI-identiteit: bepaalt welk beleid wordt toegepast op UI-taken in de hoofdthread, zoals knippen/kopiëren/plakken, pincode, verificatie en het delen van gegevens. De ui-identiteit heeft geen invloed op bestandstaken, zoals versleuteling en back-up.

• Thread-identiteit: bepaalt welk beleid wordt toegepast op de huidige thread. Deze identiteit is van invloed op alle taken, bestanden en gebruikersinterface.

De app is verantwoordelijk voor het op de juiste wijze instellen van de identiteiten, ongeacht of de gebruiker wordt beheerd of niet.

Elke thread heeft op elk gewenst moment een effectieve identiteit voor UI-taken en bestandstaken. Dit is de identiteit die wordt gebruikt om te controleren welke beleidsregels, indien van toepassing, moeten worden toegepast. Als de identiteit 'geen identiteit' is of als de gebruiker niet wordt beheerd, wordt er geen beleid toegepast. In de onderstaande diagrammen ziet u hoe de effectieve identiteiten worden bepaald.

Thread-wachtrijen

Apps verzenden vaak asynchrone en synchrone taken naar threadwachtrijen. De SDK onderschept GCD-aanroepen (Grand Central Dispatch) en koppelt de huidige thread-identiteit aan de verzonden taken. Wanneer de taken zijn voltooid, wijzigt de SDK de thread-identiteit tijdelijk in de identiteit die is gekoppeld aan de taken, voltooit de taken en herstelt vervolgens de oorspronkelijke thread-identiteit.

Omdat NSOperationQueue is gebouwd op GCD, NSOperations wordt uitgevoerd op de identiteit van de thread op het moment dat de taken worden toegevoegd aan NSOperationQueue. NSOperations of functies die rechtstreeks via GCD worden verzonden, kunnen ook de huidige thread-identiteit wijzigen terwijl ze worden uitgevoerd. Deze identiteit overschrijft de identiteit die is overgenomen van de verzendende thread.

In swift is vanwege een gevolg van de wijze waarop de SDK identiteiten doorgeeft voor DispatchWorkItem, de identiteit die is gekoppeld aan een DispatchWorkItem de identiteit van de thread die het item heeft gemaakt en niet de thread die het verzendt.

Bestandseigenaar

De SDK houdt de identiteiten van lokale bestandseigenaren bij en past het beleid dienovereenkomstig toe. Een bestandseigenaar wordt vastgesteld wanneer een bestand wordt gemaakt of wanneer een bestand wordt geopend in de afkappingsmodus. De eigenaar is ingesteld op de effectieve bestandstaakidentiteit van de thread die de taak uitvoert.

Apps kunnen ook de identiteit van de bestandseigenaar expliciet instellen met behulp van IntuneMAMFilePolicyManager. Apps kunnen worden gebruikt IntuneMAMFilePolicyManager om de eigenaar van het bestand op te halen en de gebruikersinterface-identiteit in te stellen voordat de bestandsinhoud wordt weergegeven.

Gedeelde gegevens

Als de app bestanden maakt die gegevens bevatten van zowel beheerde als niet-beheerde gebruikers, is de app verantwoordelijk voor het versleutelen van de gegevens van de beheerde gebruiker. U kunt gegevens versleutelen met behulp van de protect API's en unprotect in IntuneMAMDataProtectionManager.

De protect methode accepteert een identiteit die een beheerde of onbeheerde gebruiker kan zijn. Als de gebruiker wordt beheerd, worden de gegevens versleuteld. Als de gebruiker niet wordt beheerd, wordt er een header toegevoegd aan de gegevens die de identiteit coderen, maar de gegevens worden niet versleuteld. U kunt de methode gebruiken om de protectionInfo eigenaar van de gegevens op te halen.

Extensies delen

Als de app een share-extensie heeft, kan de eigenaar van het gedeelde item worden opgehaald via de protectionInfoForItemProvider methode in IntuneMAMDataProtectionManager. Als het gedeelde item een bestand is, zorgt de SDK ervoor dat de eigenaar van het bestand wordt ingesteld. Als het gedeelde item gegevens zijn, is de app verantwoordelijk voor het instellen van de eigenaar van het bestand als deze gegevens worden bewaard in een bestand en voor het aanroepen van de setUIPolicyAccountId API voordat deze gegevens in de gebruikersinterface worden weergegeven.

Meerdere identiteiten inschakelen

Apps worden standaard beschouwd als één identiteit. De SDK stelt de procesidentiteit in op de ingeschreven gebruiker. Als u ondersteuning voor meerdere identiteiten wilt inschakelen, voegt u een Booleaanse instelling met de naam MultiIdentity en de waarde JA toe aan de intuneMAMSettings-woordenlijst in het bestand Info.plist van de app.

Opmerking

Wanneer meerdere identiteiten zijn ingeschakeld, worden de procesidentiteit, de gebruikersinterface-identiteit en de thread-identiteiten ingesteld op nil. De app is verantwoordelijk voor het op de juiste manier instellen van deze.

Schakelen tussen identiteiten

• Door de app geïnitieerde identiteitsswitch:

  Bij het starten worden apps met meerdere identiteiten beschouwd als uitgevoerd onder een onbekend, onbeheerd account. De gebruikersinterface voor voorwaardelijk starten wordt niet uitgevoerd en er wordt geen beleid afgedwongen voor de app. De app is verantwoordelijk voor het op de hoogte stellen van de SDK wanneer de identiteit moet worden gewijzigd. Dit gebeurt meestal wanneer de app op het punt staat om gegevens weer te geven voor een specifiek gebruikersaccount.

  Een voorbeeld hiervan is wanneer de gebruiker probeert een document, een postvak of een tabblad in een notitieblok te openen. De app moet de SDK op de hoogte stellen voordat het bestand, postvak of tabblad daadwerkelijk wordt geopend. Dit wordt gedaan via de setUIPolicyAccountId API in IntuneMAMPolicyManager. Deze API moet worden aangeroepen, ongeacht of de gebruiker wordt beheerd. Als de gebruiker wordt beheerd, voert de SDK de controles voor voorwaardelijke start uit, zoals jailbreakdetectie, pincode en verificatie.

  Het resultaat van de identiteitsswitch wordt asynchroon naar de app geretourneerd via een voltooiingshandler. De app moet het openen van het document, postvak of tabblad uitstellen totdat een resultaatcode wordt geretourneerd. Als de identiteitswisseling is mislukt, moet de app de taak annuleren.

  Apps met meerdere identiteiten moeten voorkomen dat ze worden gebruikt setProcessAccountId als een manier om de identiteit in te stellen. Apps die gebruikmaken van UIScenes moeten de setUIPolicyAccountId:forWindow API gebruiken om de identiteit in te stellen.

  Apps kunnen ook de identiteit voor de huidige thread instellen met behulp van setCurrentThreadIdentity: en setCurrentThreadIdentity:forScope:. De app kan bijvoorbeeld een achtergrondthread maken, de identiteit instellen op de beheerde identiteit en vervolgens bestandsbewerkingen uitvoeren op beheerde bestanden. Als de app gebruikmaakt setCurrentThreadAccountId:van , moet de app ook gebruiken getCurrentThreadAccountId , zodat de oorspronkelijke identiteit kan worden hersteld zodra deze is voltooid. Als de app echter gebruikt setCurrentThreadAccountId:forScope: , wordt de oude identiteit automatisch hersteld. Het heeft de voorkeur om te gebruiken setCurrentThreadAccountId:forScope:.

  In swift, vanwege asynchroon/wachten, [IntuneMAMPolicyManager setCurrentThreadAccountId:] en [IntuneMAMPolicyManager setCurrentThreadAccountId:forScope:] niet beschikbaar zijn. Gebruik in plaats hiervan snel om de huidige identiteit IntuneMAMSwiftContextManager.setAccountId(_, forScope:)in te stellen. Er zijn varianten van deze API voor asynchrone, gooi- en asynchrone sluitingen die moeten worden doorgegeven.

• Door SDK geïnitieerde identiteitsswitch:

  Soms moet de SDK de app vragen om over te schakelen naar een specifieke identiteit. Apps met meerdere identiteiten moeten de identitySwitchRequiredForAccountId methode in IntuneMAMPolicyDelegate implementeren om deze aanvraag af te handelen.

  Wanneer deze methode wordt aangeroepen en de app de aanvraag kan verwerken om over te schakelen naar de opgegeven identiteit, moet deze worden doorgegeven IntuneMAMAddIdentityResultSuccess aan de voltooiingshandler. Als het wisselen van identiteit niet kan worden verwerkt, moet de app worden doorgegeven IntuneMAMAddIdentityResultFailed aan de voltooiingshandler.

  De app hoeft niet aan te roepen setUIPolicyAccountId als reactie op deze aanroep. Als de SDK de app moet overschakelen naar een niet-beheerd gebruikersaccount, wordt de lege tekenreeks doorgegeven aan de identitySwitchRequiredForAccountId aanroep.

• Door SDK geïnitieerde automatische inschrijving van identiteiten:

  Wanneer de SDK een gebruiker automatisch moet inschrijven in de app om een actie uit te voeren, moeten apps de addIdentity:completionHandler: methode implementeren in IntuneMAMPolicyDelegate. De toepassing moet vervolgens de voltooiingshandler aanroepen en doorgeven in IntuneMAMAddIdentityResultSuccess als de app de identiteit of IntuneMAMAddIdentityResultFailed anders kan toevoegen.

• Selectief wissen:

  Wanneer de app selectief wordt gewist, roept de SDK de wipeDataForAccountId methode aan in IntuneMAMPolicyDelegate. De app is verantwoordelijk voor het verwijderen van het account van de opgegeven gebruiker en alle bijbehorende gegevens. De SDK kan alle bestanden verwijderen die eigendom zijn van de gebruiker en doet dit als de app FALSE retourneert vanuit de wipeDataForAccountId aanroep.

  Houd er rekening mee dat deze methode wordt aangeroepen vanuit een achtergrondthread. De app mag pas een waarde retourneren als alle gegevens voor de gebruiker zijn verwijderd (met uitzondering van bestanden als de app ONWAAR retourneert).

Afsluitcriteria

Plan om veel tijd te besteden aan het valideren van de integratie van meerdere identiteiten van uw app. Voordat u begint met testen:

• Creatie en wijs app-beveiligingsbeleid toe aan een account. Dit wordt uw door test beheerde account.
• Creatie, maar wijs geen app-beveiligingsbeleid toe aan een ander account. Dit is uw niet-beheerde testaccount. Als uw app meerdere accounttypen ondersteunt buiten Microsoft Entra accounts, kunt u een bestaand niet-AAD-account gebruiken als het niet-beheerde testaccount.
• Houd uzelf vertrouwd met de wijze waarop beleid wordt afgedwongen in uw app. Testen met meerdere identiteiten vereist dat u eenvoudig kunt onderscheiden wanneer uw app wel en niet werkt met afgedwongen beleid. De instelling voor app-beveiligingsbeleid om schermopnamen te blokkeren, is effectief bij het snel testen van beleidshandhaving.
• Houd rekening met de volledige set gebruikersinterfaces die uw app biedt. Inventariseer de schermen waarop accountgegevens worden weergegeven. Worden in uw app de gegevens van één account in één keer weergegeven of kunnen gegevens van meerdere accounts tegelijk worden weergegeven?
• Houd rekening met de volledige set bestanden die uw app maakt. Inventariseer welke van deze bestanden gegevens bevatten die behoren tot een account, in tegenstelling tot gegevens op systeemniveau.
  • Bepaal hoe u de versleuteling voor elk van deze bestanden gaat valideren.
• Houd rekening met de volledige set manieren waarop uw app kan communiceren met andere apps. Inventariseer alle inkomende en uitgaande punten. Welke typen gegevens kan uw app opnemen? Welke intenties worden er uitgezonden? Welke inhoudsproviders implementeert het?
  • Bepaal hoe u elk van deze functies voor het delen van gegevens gaat gebruiken.
  • Bereid een testapparaat voor met zowel beheerde als onbeheerde apps die kunnen communiceren met uw app.
• Bedenk hoe de eindgebruiker met uw app kan communiceren met alle aangemelde accounts. Moet de gebruiker handmatig overschakelen naar een account voordat de gegevens van dat account worden weergegeven?

Zodra u het huidige gedrag van uw app grondig hebt geëvalueerd, valideert u de integratie met meerdere identiteiten door de volgende set tests uit te voeren. Opmerking: dit is geen uitgebreide lijst en garandeert niet dat de implementatie van uw app met meerdere identiteiten foutloos is.

Aanmeldings- en afmeldingsscenario's valideren

Uw app met meerdere identiteiten ondersteunt maximaal 1 beheerd account en meerdere niet-beheerde accounts. Deze tests helpen ervoor te zorgen dat uw integratie met meerdere identiteiten de beveiliging niet onjuist wijzigt wanneer gebruikers zich aanmelden of afmelden.

Voor deze tests installeert u uw app op een testapparaat; meld u niet aan voordat u de test start.

Scenario	Stappen
Eerst aanmelden bij beheerd	- Meld u eerst aan met een beheerd account en controleer of de gegevens van het account worden beheerd. - Meld u aan met een niet-beheerd account en controleer of de gegevens van het account niet worden beheerd.
Eerst onbeheerd aanmelden	- Meld u eerst aan met een niet-beheerd account en controleer of de gegevens van het account niet worden beheerd. - Meld u aan met een beheerd account en controleer of de gegevens van het account worden beheerd.
Aanmelden bij meerdere beheerde	- Meld u eerst aan met een beheerd account en controleer of de gegevens van het account worden beheerd. - Meld u aan met een tweede beheerd account en controleer of de gebruiker zich niet kan aanmelden zonder eerst het oorspronkelijke beheerde account te verwijderen.
Beheerde afmelding	- Meld u aan bij uw app met een beheerd onbeheerd account. - Meld u af bij het beheerde account. - Controleer of het beheerde account is verwijderd uit uw app en dat alle gegevens van dat account zijn verwijderd. - Bevestig dat het niet-beheerde account nog steeds is aangemeld, dat er geen gegevens van het niet-beheerde account zijn verwijderd en dat het beleid nog steeds niet wordt toegepast.
Niet-beheerd afmelden	- Meld u aan bij uw app met een beheerd onbeheerd account. - Meld u af bij het niet-beheerde account. - Controleer of het niet-beheerde account is verwijderd uit uw app en dat alle gegevens van dat account zijn verwijderd. - Controleer of het beheerde account nog steeds is aangemeld, dat er geen gegevens van het niet-beheerde account zijn verwijderd en dat het beleid nog steeds wordt toegepast.

Actieve identiteit en levenscyclus van apps valideren

Uw app met meerdere identiteiten kan weergaven weergeven met de gegevens van één account en de gebruiker in staat stellen om het huidige in gebruik-account expliciet te wijzigen. Het kan ook weergaven met gegevens van meerdere accounts tegelijk weergeven. Deze tests helpen ervoor te zorgen dat uw integratie met meerdere identiteiten de juiste beveiliging biedt voor de actieve identiteit op elke pagina gedurende de hele levenscyclus van de app.

Voor deze tests installeert u uw app op een testapparaat; meld u aan met een beheerd en onbeheerd account voordat u de test start.

Scenario	Stappen
Weergave van één account, beheerd	- Overschakelen naar het beheerde account. - Navigeer naar alle pagina's in uw app waarop de gegevens van één account worden weergegeven. - Controleer of het beleid wordt toegepast op elke pagina.
Weergave van één account, niet-beheerd	- Schakel over naar het niet-beheerde account. - Navigeer naar alle pagina's in uw app waarop de gegevens van één account worden weergegeven. - Controleer of het beleid op geen enkele pagina wordt toegepast.
Weergave voor meerdere accounts	- Navigeer naar alle pagina's in uw app waarop de gegevens van meerdere accounts tegelijk worden weergegeven. - Controleer of het beleid wordt toegepast op elke pagina.
Beheerde pauze	- Op een scherm met beheerde gegevens weergegeven en beleid actief, pauzeert u de app door naar het startscherm van het apparaat of een andere app te navigeren. - De app hervatten. - Controleer of het beleid nog steeds wordt toegepast.
Onbeheerde onderbreking	- Op een scherm waarop onbeheerde gegevens worden weergegeven en geen beleid actief is, pauzeert u de app door naar het startscherm van het apparaat of een andere app te navigeren. - De app hervatten. - Controleer of het beleid niet wordt toegepast.
Beheerde kill	- Op een scherm waarop beheerde gegevens worden weergegeven en het beleid actief is, kunt u de app afdwingen. - Start de app opnieuw. - Bevestig dat als de app wordt hervat op een scherm met de gegevens van het beheerde account (verwacht), het beleid nog steeds wordt toegepast. Als de app wordt hervat op een scherm met de gegevens van het onbeheerde account, controleert u of het beleid niet wordt toegepast.
Onbeheerde kill	- Op een scherm waarop onbeheerde gegevens worden weergegeven en het beleid actief is, forceert u de app. - Start de app opnieuw. - Bevestig dat als de app wordt hervat op een scherm met de gegevens van het onbeheerde account (verwacht), het beleid niet wordt toegepast. Als de app wordt hervat op een scherm met de gegevens van het beheerde account, controleert u of het beleid nog steeds wordt toegepast.
Ad hoc identiteitsswitch	- Experimenteer met schakelen tussen accounts en het onderbreken/hervatten/doden/opnieuw opstarten van de app. - Controleer of de gegevens van het beheerde account altijd zijn beveiligd en dat de gegevens van het niet-beheerde account nooit zijn beveiligd.

Scenario's voor het delen van gegevens valideren

Uw app met meerdere identiteiten kan gegevens verzenden naar en ontvangen van andere apps. het app-beveiligingsbeleid van Intune heeft instellingen die dit gedrag dicteren. Deze tests helpen ervoor te zorgen dat uw integratie met meerdere identiteiten deze instellingen voor het delen van gegevens respecteert.

Voor deze tests installeert u uw app op een testapparaat; meld u aan met een beheerd en onbeheerd account voordat u de test start. Bijkomend:

• Stel het beleid van het beheerde account in als:
  • 'Organisatiegegevens verzenden naar andere apps' naar 'Door beleid beheerde apps'.
  • 'Gegevens ontvangen van andere apps' naar 'Door beleid beheerde apps'.
• Installeer andere apps op het testapparaat:
  • Een beheerde app, gericht op hetzelfde beleid als uw app, die gegevens kan verzenden en ontvangen (zoals Microsoft Outlook).
  • Elke niet-beheerde app die gegevens kan verzenden en ontvangen.
• Meld u aan bij de andere beheerde app met het beheerde testaccount. Zelfs als de andere beheerde app meerdere identiteiten heeft, meldt u zich alleen aan met het beheerde account.

Als uw app de mogelijkheid heeft om gegevens te verzenden naar andere apps, zoals Microsoft Outlook die een documentbijlage naar Microsoft Office verzendt:

Scenario	Stappen
Beheerde identiteit verzenden naar niet-beheerde app	- Overschakelen naar het beheerde account. - Navigeer naar de locatie waar uw app gegevens kan verzenden. - Probeer gegevens te verzenden naar een onbeheerde app. - Het verzenden van gegevens naar de niet-beheerde app moet worden geblokkeerd.
Beheerde identiteit verzenden naar beheerde app	- Overschakelen naar het beheerde account. - Navigeer naar de locatie waar uw app gegevens kan verzenden. - Probeer gegevens te verzenden naar de andere beheerde app met het beheerde account dat is aangemeld. - U mag gegevens verzenden naar de beheerde app.
Onbeheerde identiteit wordt verzonden naar beheerde app	- Schakel over naar het niet-beheerde account. - Navigeer naar de locatie waar uw app gegevens kan verzenden. - Probeer gegevens te verzenden naar de andere beheerde app met het beheerde account dat is aangemeld. - Het verzenden van gegevens naar de andere beheerde app moet worden geblokkeerd.
Onbeheerde identiteit verzenden naar onbeheerde app	- Schakel over naar het niet-beheerde account. - Navigeer naar de locatie waar uw app gegevens kan verzenden. - Probeer gegevens te verzenden naar een onbeheerde app. - Het moet altijd zijn toegestaan om de gegevens van een onbeheerd account te verzenden naar een onbeheerde app.

Uw app kan actief gegevens importeren uit andere apps, zoals Microsoft Outlook die een bestand bijvoegt vanuit Microsoft OneDrive. Uw app kan ook passief gegevens ontvangen van andere apps, zoals Microsoft Office die een document opent vanuit een Microsoft Outlook-bijlage. De instelling voor het beveiligingsbeleid voor apps voor ontvangen heeft betrekking op beide scenario's.

Als uw app de mogelijkheid heeft om actief gegevens te importeren uit andere apps:

Scenario	Stappen
Beheerde identiteit importeren uit onbeheerde app	- Overschakelen naar het beheerde account. - Navigeer naar de locatie waar uw app gegevens uit andere apps kan importeren. - Probeer gegevens te importeren uit een onbeheerde app. - U wordt geblokkeerd voor het importeren van gegevens uit onbeheerde apps.
Beheerde identiteit importeren uit beheerde app	- Overschakelen naar het beheerde account. - Navigeer naar de locatie waar uw app gegevens uit andere apps kan importeren. - Probeer gegevens te importeren uit de andere beheerde app waarbij het beheerde account is aangemeld. - U moet gegevens mogen importeren uit de andere beheerde app.
Niet-beheerde identiteit importeren uit beheerde app	- Schakel over naar het niet-beheerde account. - Navigeer naar de locatie waar uw app gegevens uit andere apps kan importeren. - Probeer gegevens te importeren uit de andere beheerde app waarbij het beheerde account is aangemeld. - Het importeren van gegevens uit de andere beheerde app moet worden geblokkeerd.
Niet-beheerde identiteit importeren uit onbeheerde app	- Schakel over naar het niet-beheerde account. - Navigeer naar de locatie waar uw app gegevens uit andere apps kan importeren. - Probeer gegevens te importeren uit een onbeheerde app. - U moet altijd gegevens mogen importeren uit een onbeheerde app voor een onbeheerd account.

Als uw app de mogelijkheid heeft om passief gegevens te ontvangen van andere apps:

Scenario	Stappen
Beheerde identiteit ontvangen van onbeheerde app	- Overschakelen naar het beheerde account. - Overschakelen naar de onbeheerde app. - Navigeer naar de locatie waar gegevens kunnen worden verzonden. - Probeer gegevens van de niet-beheerde app naar uw app te verzenden. - Het beheerde account van uw app mag geen gegevens ontvangen van de onbeheerde app.
Beheerde identiteit ontvangen van beheerde app	- Overschakelen naar het beheerde account. - Schakel over naar de andere beheerde app met het beheerde account aangemeld. - Navigeer naar de locatie waar gegevens kunnen worden verzonden. - Probeer gegevens van de beheerde app naar uw app te verzenden. - Het beheerde account van uw app mag gegevens ontvangen van de andere beheerde app.
Niet-beheerde identiteit ontvangen van beheerde app	- Schakel over naar het niet-beheerde account. - Schakel over naar de andere beheerde app met het beheerde account aangemeld. - Navigeer naar de locatie waar gegevens kunnen worden verzonden. - Probeer gegevens van de beheerde app naar uw app te verzenden. - Het niet-beheerde account van uw app mag geen gegevens van de beheerde app kunnen ontvangen.
Onbeheerde identiteit ontvangen van onbeheerde app	- Schakel over naar het niet-beheerde account. - Overschakelen naar de onbeheerde app. - Navigeer naar de locatie waar gegevens kunnen worden verzonden. - Probeer gegevens van de niet-beheerde app naar uw app te verzenden. - Het niet-beheerde account van uw app mag altijd gegevens ontvangen van de onbeheerde app.

Fouten in deze tests kunnen erop wijzen dat uw app niet de juiste actieve identiteit heeft ingesteld wanneer wordt geprobeerd gegevens te verzenden of te ontvangen. U kunt dit onderzoeken door gebruik te maken van de API's voor ophalen van identiteiten van de SDK op het moment van verzenden/ontvangen om te controleren of de actieve identiteit juist is ingesteld.

Volgende stappen

Nadat u alle bovenstaande afsluitcriteria hebt voltooid, is uw app nu geïntegreerd als meerdere identiteiten en kan app-beveiligingsbeleid per identiteit worden afgedwongen. De volgende secties, Fase 6: Ondersteuning voor voorwaardelijke toegang voor app-beveiliging en Fase 7: functies voor webweergave, kunnen al dan niet vereist zijn, afhankelijk van de gewenste ondersteuning van het app-beveiligingsbeleid van uw app.