Intune App SDK voor Android - Multi-Identity

Met de Microsoft Intune App SDK voor Android kunt u Intune-beleid voor app-beveiliging (ook wel APP- of MAM-beleid genoemd) opnemen in uw systeemeigen Java/Kotlin Android-app. Een door Intune beheerde toepassing is een toepassing die is geïntegreerd met de Intune App SDK. Intune-beheerders kunnen eenvoudig app-beveiligingsbeleid implementeren in uw door Intune beheerde app wanneer Intune de app actief beheert.

Opmerking

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

Fase 5: Meerdere identiteiten

Fase Goals

• Bepaal of uw toepassing ondersteuning voor meerdere identiteiten nodig heeft.
• Inzicht in hoe identiteiten worden waargenomen in de Intune App SDK.
• 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.

Identiteitsterminologie

De termen 'gebruiker', 'account' en 'identiteit' worden vaak door elkaar gebruikt. In deze handleiding wordt als volgt geprobeerd onderscheid te maken:

• Gebruiker: de mens die het softwareproduct gebruikt. Verder gedifferentieerd als eindgebruiker, de mens die de Android-app gebruikt en beheerder / gebruiker / IT-beheerder / IT Pro, de mens die het Microsoft Intune beheercentrum gebruikt.
• Account: de softwarerecord van een organisatie die de entiteit van een gebruiker uniek identificeert. Een menselijke gebruiker kan meerdere accounts hebben.
• Identiteit: de set gegevens die de Intune App SDK gebruikt om een account uniek te identificeren.

Achtergrond

Standaard past de Intune App SDK beleid toe op uw hele toepassing. Nadat u een account hebt geregistreerd met app-beveiligingsbeleid, koppelt de SDK elk bestand en elke activiteit aan de identiteit van dat account en past het beoogde beleid van dat account universeel toe.

Voor veel ontwikkelaars is dit het gewenste gedrag voor app-beveiliging voor hun toepassing. Deze toepassingen worden beschouwd als één identiteit. Door de vorige fasen te voltooien, is uw toepassing geïntegreerd als één identiteit en kan alle basisbeleidsregels worden afgedwongen. Apps die zijn bedoeld om één identiteit te behouden, kunnen deze sectie overslaan en doorgaan naar fase 6: App Configuration.

De Intune App SDK kan optioneel beleid afdwingen op het niveau per identiteit. Als uw toepassing al meerdere accounts ondersteunt die tegelijkertijd zijn aangemeld en u deze ondersteuning voor meerdere accounts wilt behouden met app-beveiligingsbeleid, wordt uw toepassing beschouwd als meerdere identiteiten.

Tip

Als u niet zeker weet of de toepassing ondersteuning moet bieden voor beveiliging met één identiteit of meerdere identiteiten, gaat u opnieuw naar Is mijn toepassing één identiteit of meerdere identiteiten?

Waarschuwing

Het ondersteunen van meerdere identiteiten is aanzienlijk complexer dan andere functies voor app-beveiliging. Het onjuist integreren van meerdere identiteiten kan leiden tot gegevenslekken en andere beveiligingsproblemen. Bekijk deze sectie zorgvuldig en plan voldoende tijd voor het testen voordat u doorgaat naar de volgende fase.

'Identiteit' naar de SDK

Wanneer een met sdk geïntegreerde toepassing een account registreert met behulp van de registerAccountForMAM, slaat de SDK alle opgegeven parameters (upn, aadId, tenantId en instantie) op als de identiteit. De meeste identiteits-API's van de SDK gebruiken echter alleen de opgegeven upn-tekenreeks als afkorting voor de identiteit. Deze API's retourneren alleen de upn-tekenreeks als de identiteit en vereisen alleen de upn-tekenreeksparameter voor de identiteit.

Identiteiten zijn niet hoofdlettergevoelig. Aanvragen naar de SDK voor een identiteit retourneren mogelijk niet dezelfde casing die is gebruikt bij het registreren of instellen van de identiteit.

Tip

In de toekomst kunnen de SDK-API's een meer holistische identiteitsstructuur hebben die alle velden bevat die tijdens de accountregistratie zijn opgegeven, niet alleen upn. Wanneer u ondersteuning voor meerdere identiteiten integreert, moet u ervoor zorgen dat uw app ook toegang heeft tot aadId, tenantId en instantie bij het instellen van de identiteit met behulp van de huidige API's.

Beheerde versus niet-beheerde identiteiten

Zoals beschreven in Registreren voor app-beveiligingsbeleid, is uw toepassing verantwoordelijk voor het informeren van de SDK wanneer een gebruiker zich aanmeldt. Op het moment van aanmelding kan het account van de gebruiker al dan niet het doelwit zijn van app-beveiligingsbeleid. Als het account is gericht op app-beveiligingsbeleid, beschouwt de SDK het als beheerd; anders is het onbeheerd.

De SDK dwingt beleid af voor identiteiten die als beheerd worden beschouwd. De SDK dwingt geen beleid af voor identiteiten die als onbeheerd worden beschouwd.

Momenteel ondersteunt de Intune App SDK slechts één beheerde identiteit per apparaat. Zodra een met SDK geïntegreerde toepassing een beheerde identiteit registreert, worden alle vervolgens geregistreerde identiteiten, zelfs als ze momenteel zijn gericht op app-beveiligingsbeleid, behandeld als onbeheerd.

Als er al een beheerde identiteit is geregistreerd op het apparaat en uw app een andere identiteit registreert die ook is gericht op het beveiligingsbeleid voor apps, retourneert MAMEnrollmentManager.Result.WRONG_USER de SDK en vraagt de eindgebruiker om opties voor herstel. Zie Registreren voor meldingen van de SDK voor meer informatie.

Opmerking

Een account dat niet is gericht op app-beveiligingsbeleid op het moment van registratie, wordt beschouwd als onbeheerd. Zelfs als het account niet is gelicentieerd voor of gericht is op app-beveiligingsbeleid, controleert de SDK periodiek of dit account op een later tijdstip in licentie wordt gegeven. Als er geen andere beheerde identiteit is geregistreerd, begint de SDK deze identiteit te behandelen als beheerd zodra deze is gericht op beleid. De gebruiker hoeft zich niet af te melden en weer aan te melden bij dit account om deze wijziging aan te brengen.

De actieve identiteit

Uw toepassing moet de SDK altijd op de hoogte houden van de identiteit die momenteel wordt gebruikt, ook wel de actieve identiteit genoemd. Als de actieve identiteit wordt beheerd, past de SDK beveiligingen toe. Als de actieve identiteit niet wordt beheerd, past de SDK geen beveiliging toe.

Omdat de SDK geen toepassingsspecifieke kennis heeft, moet deze de toepassing vertrouwen om de juiste actieve identiteit te delen.

• Als de toepassing de SDK ten onrechte vertelt dat een onbeheerde identiteit actief is wanneer de beheerde identiteit daadwerkelijk wordt gebruikt, past de SDK geen beveiliging toe. Dit kan een gegevenslek veroorzaken waardoor de gegevens van gebruikers risico lopen.

• Als de toepassing de SDK ten onrechte vertelt dat de beheerde identiteit actief is wanneer een onbeheerde identiteit daadwerkelijk wordt gebruikt, wordt de SDK op onjuiste wijze beveiligd. Dit is geen gegevenslek, maar dit kan onnodig onbeheerde gebruikers beperken en de gegevens van onbeheerde gebruikers het risico lopen te worden verwijderd.

Als in uw toepassing gebruikersgegevens worden weergegeven, moeten alleen gegevens worden weergegeven die deel uitmaken van de actieve identiteit. Als uw toepassing momenteel niet weet wie eigenaar is van gegevens die worden weergegeven, moet u uw toepassing mogelijk herstructureren voor meer identiteitsbewustzijn voordat u ondersteuning voor meerdere identiteiten gaat integreren.

App-gegevens ordenen op identiteit

Wanneer uw toepassing een nieuw bestand schrijft, koppelt de SDK (ook wel 'tags' genoemd) een identiteit aan dat bestand op basis van de huidige actieve thread en procesidentiteit. Uw app kan ook rechtstreeks de SDK aanroepen om een bestand handmatig te taggen met een bepaalde identiteit (zie Beveiligde bestanden schrijven voor meer informatie). De SDK gebruikt deze gelabelde bestandsidentiteit voor zowel bestandsversleuteling als selectief wissen.

Als de beheerde identiteit is gericht op versleutelingsbeleid, worden alleen bestanden versleuteld die zijn getagd met de beheerde identiteit.

Als een actie van de beheerder of geconfigureerde beleidsregels vraagt dat beheerde gegevens worden gewist, worden alleen bestanden verwijderd die zijn getagd met de beheerde identiteit.

De SDK kan niet meerdere identiteiten aan één bestand koppelen. Als uw app gegevens van meerdere gebruikers in hetzelfde bestand opslaat, leidt het standaardgedrag van de SDK ertoe dat deze gegevens te weinig of te veel worden beveiligd. U wordt sterk aangeraden om de gegevens van uw app te organiseren op identiteit.

Als uw app absoluut gegevens moet opslaan die behoren tot verschillende identiteiten in hetzelfde bestand, biedt de SDK functies voor het taggen van identiteiten van subsets van gegevens in een bestand. Zie Data Buffer Protection voor meer informatie.

Meerdere identiteiten implementeren

Als u ondersteuning voor meerdere identiteiten voor uw app wilt declareren, plaatst u eerst de volgende metagegevens in AndroidManifest.xml.

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

De actieve identiteit instellen

Uw toepassing kan de actieve identiteit instellen op de volgende niveaus in aflopende prioriteit:

1. Threadniveau
2. Context (in het algemeen Activity) Niveau
3. Procesniveau

Een identiteit die is ingesteld op threadniveau vervangt een identiteit die is ingesteld op het Context niveau, die een identiteit vervangt die is ingesteld op procesniveau.

Een identiteit die is ingesteld op een Context wordt alleen gebruikt in de juiste gekoppelde scenario's. Bestands-IO-bewerkingen hebben bijvoorbeeld geen gekoppelde Context. Meestal stellen apps de Context identiteit in op een Activity. Overweeg om de Context identiteit in te stellen in Activity.onCreate. Een app mag geen gegevens voor een identiteit weergeven, tenzij de Activity identiteit is ingesteld op diezelfde identiteit.

Over het algemeen is de identiteit op procesniveau alleen nuttig als de app slechts met één identiteit tegelijk werkt op alle threads. Dit is geen typisch gedrag voor apps die ondersteuning bieden voor meerdere accounts. U wordt sterk aangeraden accountgegevens te scheiden en de actieve identiteit in te stellen op de thread of Context niveaus.

Als uw app de Application context gebruikt om systeemservices te verkrijgen, controleert u of de thread- of procesidentiteit is ingesteld of dat u de ui-identiteit hebt ingesteld op de context van Application uw app.

Als uw app gebruikmaakt van een Service context om intenties te starten, inhoudsoplossingsfunctie gebruikt of andere systeemservices gebruikt, moet u de identiteit instellen voor de Service context. Als uw app een JobService context gebruikt om deze acties uit te voeren, moet u ook de identiteit voor de JobService context of thread instellen zoals vereist voor uw JobService implementatie. Als u JobService bijvoorbeeld taken voor één identiteit verwerkt, kunt u overwegen om de identiteit in te stellen op de JobService context. Als uw JobService taken voor meerdere identiteiten verwerkt, kunt u overwegen om de identiteit in te stellen op threadniveau.

Voorzichtigheid

Apps die gebruikmaken WorkManager van moeten extra voorzichtig zijn bij het instellen van de identiteit. Deze apps moeten met name voorkomen dat een identiteit wordt ingesteld op de Context doorgegeven in de Worker constructor. Dit Context exemplaar kan worden gedeeld tussen meerdere Worker exemplaren tegelijk. Om niet-gedefinieerd gedrag te voorkomen, moeten apps in plaats daarvan een thread-identiteit instellen in Worker.doWork() , zoals vereist door de Worker implementatie.

Opmerking

Omdat de CLIPBOARD_SERVICE wordt gebruikt voor UI-bewerkingen, gebruikt de SDK de UI-identiteit van de voorgrondactiviteit voor ClipboardManager bewerkingen.

De volgende methoden in MAMPolicyManager kunnen worden gebruikt om de actieve identiteit in te stellen en de eerder ingestelde identiteitswaarden op te halen.

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

public static String getUIPolicyIdentity(final Context context);

public static MAMIdentitySwitchResult setProcessIdentity(final String identity);

public static String getProcessIdentity();

public static MAMIdentitySwitchResult setCurrentThreadIdentity(final String identity);

public static String getCurrentThreadIdentity();

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

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


public static AppPolicy getPolicyForIdentity(final String identity);

public static boolean getIsIdentityManaged(final String identity);

Voor het gemak kunt u ook de identiteit van een activiteit rechtstreeks instellen via een methode in MAMActivity in plaats van aan te roepen MAMPolicyManager.setUIPolicyIdentity. Gebruik hiervoor de volgende methode:

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

Opmerking

Als uw app geen ondersteuning voor meerdere identiteiten in het manifest heeft gedeclareerd, wordt er geen actie uitgevoerd als u deze methoden aanroept om de identiteit in te stellen. Als ze een MAMIdentitySwitchResultretourneren, wordt altijd geretourneerd FAILED.

Veelvoorkomende valkuilen voor identiteitsswitch

• Voor aanroepen naar startActivitygaat de Intune App SDK ervan uit dat de actieve identiteit op het Context niveau is gekoppeld aan de opgegeven Intent parameter. We raden u ten zeerste aan om de Context niveauidentiteit in te stellen met een Activitycontext, niet met de Applicationcontext.

• Het instellen van de Context identiteit tijdens de methode van onCreate een activiteit wordt aanbevolen. Zorg er echter ook voor dat u andere toegangspunten behandelt, zoals onNewIntent. Als dezelfde activiteit anders opnieuw wordt gebruikt om gegevens weer te geven voor zowel beheerde als onbeheerde identiteiten, kan het beleid onjuist worden toegepast, wat leidt tot niet-beveiligde bedrijfsgegevens of onjuist beperkte persoonsgegevens.

Resultaten van identiteitsswitch

Alle methoden die worden gebruikt om de identiteit in te stellen, rapporteren resultaatwaarden via MAMIdentitySwitchResult. Er zijn vier waarden die kunnen worden geretourneerd:

Retourwaarde	Scenario
SUCCEEDED	De identiteitswijziging is geslaagd.
NOT_ALLOWED	De identiteitswijziging is niet toegestaan. Dit doet zich voor als er een poging wordt gedaan om de identiteit van de gebruikersinterface (Context) in te stellen wanneer een andere identiteit is ingesteld voor de huidige thread.
CANCELLED	De gebruiker heeft de identiteitswijziging geannuleerd, meestal door op de knop Terug te drukken bij een pincode of verificatieprompt.
FAILED	De identiteitswijziging is om een niet-opgegeven reden mislukt.

De app moet controleren of de MAMIdentitySwitchResult is SUCCEEDED voordat de gegevens van een beheerd account worden weergegeven of gebruikt.

De meeste methoden voor het instellen van de actieve identiteit retourneren MAMIdentitySwitchResult synchroon. In het geval van het instellen van een Context identiteit via setUIPolicyIdentity, wordt het resultaat asynchroon gerapporteerd. De app kan een MAMSetUIIdentityCallback implementeren om dit resultaat te ontvangen, of kan null doorgeven voor het callback-object. Als er een aanroep wordt uitgevoerd terwijl setUIPolicyIdentity het resultaat van een eerdere aanroep naar setUIPolicyIdentityin dezelfde context nog niet is geleverd, wordt de nieuwe callback vervangen door de oude callback en ontvangt de oorspronkelijke callback nooit een resultaat.

Voorzichtigheid

Als de Context opgegeven voor setUIPolicyIdentity een Activityis, weet de SDK pas of de identiteitswijziging is geslaagd nadat de beheerder geconfigureerde controles voor voorwaardelijke start heeft uitgevoerd. Hiervoor moet de gebruiker mogelijk een pincode of bedrijfsreferenties invoeren.

Momenteel slagen proces- en threadidentiteitsswitches altijd voor een app met meerdere identiteiten. De SDK behoudt zich het recht voor om in de toekomst foutvoorwaarden toe te voegen.

De schakeloptie voor ui-identiteit kan mislukken vanwege ongeldige argumenten, als deze conflicteert met de thread-identiteit of als de gebruiker de vereisten voor voorwaardelijk starten annuleert (bijvoorbeeld door op de knop Vorige op het pincodescherm te drukken).

Het standaardgedrag voor een mislukte ui-id-schakeloptie voor een activiteit is het voltooien van de activiteit. Als u dit gedrag wilt wijzigen en meldingen wilt ontvangen over identiteitswijzigingspogingen voor een activiteit, kunt u een methode overschrijven in MAMActivity.

    public void onSwitchMAMIdentityComplete(final MAMIdentitySwitchResult result);

Als u de methode overschrijft onSwitchMAMIdentityComplete (of aanroept super ), moet u ervoor zorgen dat de gegevens van een beheerd account niet worden weergegeven na een mislukte identiteitswisseling.

Opmerking

Als u de identiteit wilt overschakelen, moet u mogelijk de activiteit opnieuw maken. In dit geval wordt de onSwitchMAMIdentityComplete callback geleverd aan het nieuwe exemplaar van de activiteit.

Identiteit, Intenties en IdentitySwitchOptions

Naast het automatisch taggen van nieuwe bestanden met de actieve identiteit, tagt de SDK ook intenties met de actieve identiteit. Standaard controleert de SDK de identiteit op een binnenkomende intentie en vergelijkt deze met de actieve identiteit. Als deze identiteiten niet overeenkomen, vraagt de SDK meestal(*) een identiteitsswitch aan (zie Impliciete identiteitswijzigingen hieronder voor meer informatie).

De SDK slaat deze binnenkomende intentie-identiteit ook op voor later gebruik. Wanneer de app de ui-identiteit expliciet wijzigt, vergelijkt de SDK de identiteit waarop de app probeert over te schakelen met de meest recente binnenkomende intentie-identiteit. Als deze identiteiten niet overeenkomen, mislukt de SDK doorgaans(*) bij de identiteitswisseling.

De SDK voert deze controle uit omdat wordt ervan uitgegaan dat de app nog steeds inhoud weergeeft van de intentie die behoort tot de identiteit die op de intentie is getagd. Deze veronderstelling beschermt tegen het onbedoeld uitschakelen van beveiliging door de app bij het weergeven van beheerde gegevens; deze veronderstelling is echter mogelijk niet juist voor het werkelijke gedrag van de app.

De optionele IdentitySwitchOption-opsommingen kunnen worden doorgegeven aan de API's setUIPolicyIdentity en switchMAMIdentity om het standaardgedrag van de SDK te wijzigen.

• IGNORE_INTENT: wanneer u een identiteitsswitch aanvraagt op de gebruikersinterfacelaag, informeert deze optie de SDK om de vergelijking van de aangevraagde identiteitsparameter met de laatst opgeslagen intentie-identiteit over te slaan. Dit is handig wanneer uw app geen inhoud meer weergeeft die bij die identiteit hoort en de SDK deze identiteitsswitch niet mag blokkeren. Bijvoorbeeld:

  1. Uw app is een documentviewer. Het kan documenten weergeven die zijn doorgegeven vanuit andere apps. Het bevat ook een functie waarmee gebruikers van account kunnen wisselen. Wanneer de gebruiker deze functie voor accountwisseling gebruikt, navigeert de app naar een accountspecifieke landingspagina met de recente documenten van dat account.
  2. Uw app ontvangt een intentie om een document weer te geven. Deze intentie is gelabeld met de beheerde identiteit.
  3. Uw app wordt overgeschakeld naar de beheerde identiteit en dit document wordt weergegeven, waarbij de beveiliging correct is toegepast.
  4. De gebruiker gebruikt de accountwisselaar om over te schakelen naar zijn/haar persoonlijke account.

  Uw app moet de gebruikersinterface-identiteit in stap 4 wijzigen. In dit geval, omdat het gedrag van de app is om weg te navigeren van de gegevens van het beheerde account (het document in de intentie), moet deze worden gebruikt IGNORE_INTENT in de aanroep van de identiteitsswitch. Dit voorkomt dat de SDK deze aanroep mislukt.

• DATA_FROM_INTENT: wanneer u een identiteitsswitch aanvraagt op de gebruikersinterfacelaag, informeert deze optie de SDK dat gegevens van de laatst opgeslagen intentie-identiteit nog steeds worden weergegeven nadat de identiteitsswitch is geslaagd. Als gevolg hiervan evalueert de SDK het ontvangstbeleid volledig op basis van de vorige intentie-identiteit om te bepalen of deze mag worden weergegeven. Bijvoorbeeld:

  1. Uw app is een documentviewer. Het kan documenten weergeven die zijn doorgegeven vanuit andere apps. Het bevat ook een functie waarmee gebruikers van account kunnen wisselen. In tegenstelling tot het vorige voorbeeld navigeert de app naar een gedeelde pagina met recente documenten voor alle accounts wanneer de gebruiker deze functie gebruikt.
  2. Uw app ontvangt een intentie om een document weer te geven. Deze intentie is gelabeld met de beheerde identiteit.
  3. Uw app wordt overgeschakeld naar de beheerde identiteit en dit document wordt weergegeven, waarbij de beveiliging correct is toegepast.
  4. De gebruiker gebruikt de accountwisselaar om over te schakelen naar zijn/haar persoonlijke account.

  Uw app moet de gebruikersinterface-identiteit in stap 4 wijzigen. Omdat in dit geval het gedrag van de app is dat de gegevens van de beheerde identiteit blijven worden weergegeven (een voorbeeld van het document in de intentie), moet deze worden gebruikt DATA_FROM_INTENT in de aanroep van de identiteitsswitch. Hiermee wordt de SDK geïnformeerd om het geconfigureerde app-beveiligingsbeleid te controleren om te bepalen of het geschikt is om de gegevens weer te geven.

(*) Het standaardgedrag van de SDK omvat speciale casing waarmee deze gegevensinkomende controle wordt overgeslagen als de intentie bijvoorbeeld afkomstig is van dezelfde app of van het startprogramma voor het systeem.

De actieve identiteit wissen

Uw toepassing heeft mogelijk scenario's die account-agnostisch zijn. Uw toepassing kan ook scenario's hebben voor lokale onbeheerde scenario's waarvoor u zich niet hoeft aan te melden. In beide gevallen wil uw app mogelijk niet dat de SDK het beleid van de beheerde identiteit afdwingt, maar mogelijk hebt u geen expliciete identiteit om naar over te schakelen.

U kunt de actieve identiteit wissen door een van de ingestelde identiteitsmethoden aan te roepen met de identiteitsparameter ingesteld op null. Als u de identiteit op één niveau wist, zoekt de SDK naar de actieve identiteit op andere niveaus, op basis van de volgorde van prioriteit.

U kunt ook een lege tekenreeks doorgeven als de identiteitsparameter, waarmee de identiteit wordt ingesteld op een speciale lege waarde die wordt behandeld als een onbeheerde identiteit. Als u de actieve identiteit instelt op een lege tekenreeks, wordt door de SDK geen app-beveiligingsbeleid afgedwongen.

Impliciete identiteitswijzigingen

In de bovenstaande sectie worden de verschillende manieren beschreven waarop uw app expliciet de actieve identiteit kan instellen op thread-, context- en procesniveau. De actieve identiteit in uw app kan echter ook worden gewijzigd zonder dat uw app een van deze methoden aanroept. In deze sectie wordt beschreven hoe uw app deze impliciete identiteitswijzigingen kan beluisteren en erop kan reageren.

Luisteren naar deze impliciete identiteitswijzigingen is optioneel, maar wordt aanbevolen. De SDK wijzigt nooit de actieve identiteit zonder deze impliciete meldingen over identiteitswijziging op te geven.

Voorzichtigheid

Als uw app ervoor kiest om niet te luisteren naar impliciete identiteitswijzigingen, moet u extra voorzichtig zijn om niet de actieve identiteit aan te nemen. Als u twijfelt, gebruikt u de getCurrentThreadIdentitymethoden , getUIPolicyIdentityen getProcessIdentity om de actieve identiteit te bevestigen.

Bronnen van impliciete identiteitswijzigingen

• Binnenkomende gegevens van andere door Intune beheerde apps kunnen de actieve identiteit op thread- en contextniveau wijzigen.

  • Als een activiteit wordt gestart vanuit een Intent verzonden door een andere MAM-app, wordt de identiteit van de activiteit ingesteld op basis van de actieve identiteit in de andere app op het moment dat de Intent is verzonden.

    • Een activiteit voor het weergeven van een Word document wordt bijvoorbeeld gestart vanuit een intentie van Microsoft Outlook wanneer een gebruiker een documentbijlage selecteert. De identiteit van de documentvieweractiviteit van Office wordt vanuit Outlook overgezet naar de identiteit.

  • Voor services wordt de thread-identiteit op dezelfde manier ingesteld voor de duur van een onStart of-aanroep onBind . Aanroepen naar de Binder geretourneerde van onBind stellen ook tijdelijk de thread-identiteit in.

  • Aanroepen in een ContentProvider stelt op dezelfde manier de thread-identiteit in voor de duur.

• Gebruikersinteractie met een activiteit kan de actieve identiteit op contextniveau wijzigen. Bijvoorbeeld:

  • Een gebruiker die een autorisatieprompt annuleert tijdens Resume , resulteert in een impliciete overschakeling naar een lege identiteit.

Impliciete identiteitswijzigingen verwerken

Uw app kan optioneel luisteren naar en reageren op deze impliciete identiteitswijzigingen. Uw toepassing kan bijvoorbeeld meerdere stappen vereisen voordat een toegevoegd account bruikbaar is, zoals een e-mail-app die een nieuw Postvak IN instelt. Wanneer u een poging ziet om over te schakelen naar de identiteit van dit onvolledige account, kan de handler van uw app de gebruiker omleiden naar de accountinstallatieactiviteit voordat de identiteitsswitch wordt geaccepteerd. De handler van uw app kan ook een foutdialoogvenster weergeven en de identiteitsswitch blokkeren.

Uw app kan de INTERFACE MAMIdentityRequirementListener implementeren op een Service of ContextProvider voor identiteitswijzigingen die op deze thread worden toegepast. Uw implementatie moet het volgende overschrijven:

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

Uw app kan de interface MAMActivityIdentityRequirementListener implementeren op een Activity voor identiteitswijzigingen die van toepassing zijn op deze activiteit. Uw implementatie moet het volgende overschrijven:

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

De AppIdentitySwitchReason parameter enum beschrijft de bron van de impliciete identiteitsswitch.

Opsommingswaarde	Standaard-SDK-gedrag	Omschrijving
CREATE	De identiteitswisseling toestaan.	De identiteitswijziging vindt plaats vanwege het maken van een activiteit.
NEW_INTENT	De identiteitswisseling toestaan.	De identiteitswijziging vindt plaats omdat er een nieuwe intentie wordt toegewezen aan een activiteit.
RESUME_CANCELLED	De identiteitsswitch blokkeren.	De identiteitswijziging vindt plaats omdat een cv is geannuleerd. Dit komt het meest voor wanneer de eindgebruiker op de knop Vorige drukt op de gebruikersinterface voor pincode, verificatie of naleving.

Met de parameter AppIdentitySwitchResultCallback kunnen ontwikkelaars het standaardgedrag voor de identiteitsswitch overschrijven:

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

onMAMIdentitySwitchRequired wordt aangeroepen voor alle impliciete identiteitswijzigingen, met uitzondering van wijzigingen die zijn aangebracht via een binder die wordt geretourneerd van MAMService.onMAMBind. De standaard implementaties van onMAMIdentitySwitchRequired direct aanroepen:

• callback.reportIdentitySwitchResult(FAILURE) als de reden is RESUME_CANCELLED.

• callback.reportIdentitySwitchResult(SUCCESS) in alle andere gevallen.

Het is niet te verwachten dat de meeste apps een identiteitswijziging op een andere manier moeten blokkeren of vertragen, maar als een app dit moet doen, moet rekening worden gehouden met de volgende punten:

• Als een identiteitsswitch wordt geblokkeerd, is het gedrag van de eindgebruiker hetzelfde als wanneer de app-beveiligingsinstelling 'Gegevens ontvangen van andere apps' van de SDK de toegang tot gegevens had verboden.

• Als een service wordt uitgevoerd op de hoofdthread, reportIdentitySwitchResultmoet deze synchroon worden aangeroepen, anders reageert de UI-thread niet meer.

• Voor Activity het maken wordt onMAMIdentitySwitchRequired aangeroepen voor onMAMCreate. Als de app gebruikersinterface moet weergeven om te bepalen of de identiteitswisseling moet worden toegestaan, moet die gebruikersinterface worden weergegeven met behulp van een andere activiteit.

• Wanneer in een Activityeen overschakeling naar de lege identiteit wordt aangevraagd met de reden als RESUME_CANCELLED, moet de app de hervat activiteit wijzigen om gegevens weer te geven die consistent zijn met die identiteitsswitch. Als dit niet mogelijk is, moet de app de overstap weigeren en wordt de gebruiker opnieuw gevraagd om te voldoen aan het beleid voor het hervatten van de identiteit (bijvoorbeeld door het invoerscherm voor de pincode van de app te zien).

Voorzichtigheid

Een app met meerdere identiteiten kan binnenkomende gegevens ontvangen van zowel beheerde als onbeheerde apps. Het is de verantwoordelijkheid van de app om gegevens van beheerde identiteiten op een beheerde manier te behandelen.

Als een aangevraagde identiteit wordt beheerd (gebruik MAMPolicyManager.getIsIdentityManaged om te controleren), maar de app kan dat account niet gebruiken (bijvoorbeeld omdat accounts, zoals e-mailaccounts, eerst in de app moeten worden ingesteld), moet de identiteitswisseling worden geweigerd.

Het standaardgedrag voor MAMActivity.onMAMIdentitySwitchRequired kan worden geopend door de statische methode MAMActivity.defaultOnMAMIdentitySwitchRequired(activity, identity, reason, callback)aan te roepen.

Als u wilt overschrijven MAMActivity.onSwitchMAMIdentityComplete, kunt MAMActivityIdentitySwitchListener u implementeren zonder expliciet over te nemen van MAMActivity.

Identiteitsswitches en schermopnamebeperkingen

De Intune App SDK gebruikt de Window vlag FLAG_SECURE om beleid voor schermopnamen af te dwingen. Sommige apps kunnen ook voor hun eigen doeleinden worden ingesteld FLAG_SECURE . Wanneer het app-beveiligingsbeleid schermopnamen niet beperkt, wijzigt FLAG_SECUREde SDK niet .

Bij een identiteitswijziging van een identiteit waarvan het beleid het uitschakelen van schermopnamen vereist naar een identiteit waarvan het beleid dit niet doet, wordt de SDK gewist FLAG_SECURE. Als gevolg hiervan moet uw app niet afhankelijk zijn van FLAG_SECURE de resterende set na een identiteitswisseling.

Identiteit behouden in asynchrone bewerkingen

Apps verzenden vaak achtergrondtaken vanuit de UI-thread om bewerkingen op andere threads af te handelen. Een app met meerdere identiteiten moet ervoor zorgen dat deze achtergrondtaken werken met de juiste identiteit, die vaak dezelfde identiteit is die wordt gebruikt door de activiteit die ze heeft verzonden.

De Intune App SDK biedt MAMAsyncTask en MAMIdentityExecutors als hulpmiddel bij het behouden van de identiteit bij asynchrone bewerkingen. Uw app moet deze gebruiken (of expliciet de thread-identiteit voor de taken instellen) als de asynchrone bewerkingen het volgende kunnen doen:

• Gegevens van een beheerde identiteit naar een bestand schrijven
• Communiceren met andere apps

MAMAsyncTask

Als u wilt gebruiken MAMAsyncTask, neemt u er eenvoudigweg van over in plaats van AsyncTask en vervangt u overschrijvingen van doInBackground respectievelijk en onPreExecutedoInBackgroundMAMonPreExecuteMAM . De MAMAsyncTask constructor neemt een activiteitscontext. Bijvoorbeeld:

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 neemt de actieve identiteit aan op basis van de normale volgorde van prioriteit.

MAMIdentityExecutors

MAMIdentityExecutorshiermee kunt u een bestaande Executor of instantie verpakken als een identiteitsbehoud ExecutorExecutorService/met wrapExecutor en-methodenwrapExecutorService.ExecutorService Bijvoorbeeld

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

MAMIdentityExecutors neemt de actieve identiteit aan op basis van de normale volgorde van prioriteit.

Bestandsbeveiliging

Beveiligde bestanden schrijven

Zoals vermeld in App-gegevens organiseren op identiteit hierboven, koppelt de Intune App SDK de actieve identiteit (vanaf thread-/procesniveau) aan bestanden terwijl ze worden geschreven. Het is essentieel dat de juiste identiteit is ingesteld bij het maken van het bestand om de juiste versleuteling en functionaliteit voor selectief wissen te garanderen.

Uw app kan de identiteit van een bestand opvragen of wijzigen met behulp van de klasse MAMFileProtectionManager , met name MAMFileProtectionManager.getProtectionInfo voor het uitvoeren van query's en MAMFileProtectionManager.protect voor het wijzigen van gegevens.

De protect methode kan ook worden gebruikt om mappen te beveiligen. Directorybeveiliging is recursief van toepassing op alle bestanden en submappen in de map. Wanneer een map is beveiligd, wordt voor alle nieuwe bestanden die in de map worden gemaakt, automatisch dezelfde beveiliging toegepast. Omdat adreslijstbeveiliging recursief wordt toegepast, kan het enige tijd duren voordat de protect aanroep is voltooid voor grote mappen. Daarom willen apps die beveiliging toepassen op een map die een groot aantal bestanden bevat, mogelijk asynchroon worden uitgevoerd protect op een achtergrondthread.

Als u aanroept protect met een lege tekenreeks voor de id-parameter, wordt het bestand/de map gelabeld met de onbeheerde identiteit. Met deze bewerking wordt de versleuteling uit het bestand/de map verwijderd als deze eerder is versleuteld. Wanneer een opdracht voor selectief wissen wordt uitgegeven, wordt het bestand/de map niet verwijderd.

Inhoud van beveiligd bestand weergeven

Het is even belangrijk om de juiste identiteit in te stellen wanneer bestandsinhoud wordt weergegeven om te voorkomen dat onbevoegde gebruikers beheerde gegevens bekijken. De SDK kan niet automatisch een relatie afleiden tussen bestanden die worden gelezen en gegevens die worden weergegeven in een Activity. Apps moeten de ui-identiteit op de juiste manier instellen voordat beheerde gegevens worden weergegeven. Dit omvat gegevens die uit bestanden worden gelezen.

Als een bestand afkomstig is van buiten de app (van een ContentProvider of gelezen vanaf een openbaar beschrijfbare locatie), moet de app proberen de bestandsidentiteit te bepalen (met behulp van de juiste OVERBELASTING MAMFileProtectionManager.getProtectionInfo voor de gegevensbron) voordat informatie wordt weergegeven die uit het bestand is gelezen.

Als getProtectionInfo een niet-null, niet-lege identiteit wordt gerapporteerd, moet de app de gebruikersinterface-identiteit zo instellen dat deze overeenkomt met deze identiteit met behulp van MAMActivity.switchMAMIdentity of MAMPolicyManager.setUIPolicyIdentity. Als de identiteitswisseling mislukt, mogen gegevens uit het bestand niet worden weergegeven.

Bij het lezen van een inhouds-URI kan het nodig zijn om eerst de identiteit te lezen (via de getProtectionInfo overbelasting met een Uri), en vervolgens de context- of thread-identiteit op de juiste manier in te stellen. Dit moet worden gedaan voordat u een bestandsdescriptor of invoerstroom op de ContentResolveropent, anders kan de bewerking mislukken.

Een voorbeeldstroom kan er ongeveer als volgt uitzien:

• Gebruiker selecteert een document dat in de app moet worden geopend.

• Tijdens de open stroom bevestigt de app, voordat gegevens van de schijf worden gelezen, de identiteit die moet worden gebruikt om de inhoud weer te geven:

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

• De app wacht totdat er een resultaat wordt gerapporteerd aan callback.

• Als het gerapporteerde resultaat een fout is, wordt het document niet weergegeven in de app.

• De app wordt geopend en het bestand wordt weergegeven.

Als een app android DownloadManager gebruikt om bestanden te downloaden, probeert de SDK deze bestanden automatisch te beveiligen met behulp van de eerder beschreven identiteitsprioriteit. De context die wordt gebruikt om de DownloadManager op te halen, wordt gebruikt als de thread-identiteit niet is ingesteld. Als de gedownloade bestanden bedrijfsgegevens bevatten, is het de verantwoordelijkheid van de app om beveiliging aan te roepen als de bestanden na het downloaden worden verplaatst of opnieuw worden gemaakt.

Single-Identity naar overgang met meerdere identiteiten

Als een app die eerder is uitgebracht met Intune-integratie met één identiteit later meerdere identiteiten integreert, zullen eerder geïnstalleerde apps een overgang ervaren. Deze overgang is niet zichtbaar voor de gebruiker.

De app is niet vereist om deze overgang af te handelen. Alle bestanden die vóór de overgang zijn gemaakt, worden nog steeds beschouwd als beheerd (zodat ze versleuteld blijven als versleutelingsbeleid is ingeschakeld).

Als u niet wilt dat alle vorige app-gegevens worden gekoppeld aan de beheerde identiteit, kunt u deze overgang detecteren en de beveiliging expliciet verwijderen.

• Detecteer de upgrade door de versie van uw app te vergelijken met een bekende versie waarvoor ondersteuning voor meerdere identiteiten is toegevoegd.
• Roep protect aan met een lege tekenreeks voor de identiteitsparameter voor bestanden of mappen die u niet wilt koppelen aan de beheerde identiteit.

Offlinescenario's

De Intune App SDK wordt uitgevoerd in de modus Offline wanneer de Bedrijfsportal-app niet is geïnstalleerd. Bestandsidentiteitslabels zijn gevoelig voor de offlinemodus:

• Als de Bedrijfsportal niet is geïnstalleerd, kunnen bestanden niet worden gelabeld met identiteit. MamFileProtectionManager.protect aanroepen in de offlinemodus is veilig, maar heeft geen effect.

• Als de Bedrijfsportal is geïnstalleerd, maar de app geen app-beveiligingsbeleid heeft, kunnen bestanden niet betrouwbaar worden gelabeld met identiteit.

• Wanneer het taggen van bestandsidentiteiten beschikbaar is, worden alle eerder gemaakte bestanden behandeld als persoonlijk/niet-beheerd (behorend tot de lege-tekenreeksidentiteit), behalve in gevallen waarin de app eerder was geïnstalleerd als een door één identiteit beheerde app, zoals beschreven in Overgang van één identiteit naar meerdere identiteiten.

Om deze gevallen te voorkomen, moeten apps voorkomen dat bestanden met accountgegevens worden gemaakt totdat de accountregistratie is voltooid. Als uw app absoluut offline bestanden moet maken, kan deze MAMFileProtectionManager.protect gebruiken om de bijbehorende identiteit van het bestand te corrigeren zodra de SDK online is.

Gegevensbufferbeveiliging

Waarschuwing

Het wordt niet aanbevolen om gegevens van meerdere accounts in één bestand te schrijven. Organiseer de bestanden van uw app indien mogelijk op identiteit.

MamDataProtectionManager van de SDK biedt methoden voor het controleren en wijzigen van de gelabelde identiteit op specifieke gegevensbuffers in een byte[] of-indelingInputStream.

MAMDataProtectionManager.protect hiermee kan een app gegevens koppelen aan een identiteit en, als de identiteit momenteel is gericht op versleutelingsbeleid, de gegevens versleutelen. Deze versleutelde gegevens zijn geschikt voor het opslaan op schijf in een bestand.

MAMDataProtectionManager U kunt ook query's uitvoeren op de gegevens die zijn gekoppeld aan de identiteit en deze ontsleutelen.

Apps die gebruikmaken van MAMDataProtectionManager moeten een ontvanger implementeren voor de MANAGEMENT_REMOVED melding. Zie Registreren voor meldingen van de SDK voor meer informatie.

Nadat deze melding is voltooid, zijn buffers die zijn beveiligd via deze klasse niet meer leesbaar (als bestandsversleuteling is ingeschakeld toen de buffers werden beveiligd). Een app kan voorkomen dat deze buffers onleesbaar worden door alle buffers aan te roepen MAMDataProtectionManager.unprotect bij het verwerken van de MANAGEMENT_REMOVED melding. Het is ook veilig om te bellen protect tijdens deze melding, als u identiteitsgegevens wilt behouden. Versleuteling is gegarandeerd uitgeschakeld tijdens de melding en aanroepen protect in de handler versleutelt geen gegevensbuffers.

Inhoudsproviders

Een app met meerdere identiteiten moet ook gegevens beveiligen die worden gedeeld via ContentProviders om te voorkomen dat beheerde inhoud ongepast wordt gedeeld.

Uw app moet de statische MAMContentProvider-methodeisProvideContentAllowed(provider, contentIdentity) aanroepen voordat inhoud wordt geretourneerd. Als deze functie false retourneert, mag de inhoud niet worden geretourneerd naar de aanroeper.

Bellen isProvideContentAllowed is niet vereist als u ContentProvider een ParcelFileDescriptorretourneert. Bestandsdescriptors die worden geretourneerd via een inhoudsprovider, worden automatisch verwerkt op basis van de bestandsidentiteit.

Selectief wissen

Standaard verwerkt de Intune App SDK automatisch selectief wissen, waarbij alle bestanden worden verwijderd die zijn gekoppeld aan de beheerde identiteit. Daarna sluit de SDK de app soepel af, waardoor de activiteiten worden voltooid en het app-proces wordt beëindigd.

De SDK biedt de optionele mogelijkheid voor uw app om het standaard wisgedrag aan te vullen (aanbevolen) of te overschrijven.

De standaardhandler voor wissen van de SDK verwerkt geen gegevensbuffers die worden beveiligd door MAMDataProtectionManager. Als uw app deze functie heeft gebruikt, moet deze de standaard wishandler aanvullen of overschrijven om die gegevens te verwijderen.

Opmerking

Voor het aanvullen en overschrijven van het standaard wisgedrag is het afhandelen van specifieke SDK-meldingen vereist. Zie Registreren voor meldingen van de SDK voor meer informatie over het implementeren van meldingshandlers.

Standaard wisgedrag aanvullen

Als aanvulling op het standaard-SDK-wisgedrag kan uw app zich registreren voor het WIPE_USER_AUXILIARY_DATAMAMNotificationType.

Deze melding wordt verzonden door de SDK voordat deze het standaard selectief wissen uitvoert. De SDK wacht totdat de meldingshandler van uw app is voltooid voordat u gegevens verwijdert en de app beëindigt. Uw app moet gegevens synchroon wissen en niet terugkeren totdat alle opschoning is voltooid.

Apps moeten sterk overwegen om het standaard wisgedrag aan te vullen met WIPE_USER_AUXILIARY_DATA, omdat app-specifieke opschoning gebruikelijk is voor apps met meerdere identiteiten.

Standaard wisgedrag overschrijven

Als u het standaard-SDK-wisgedrag wilt overschrijven, kan uw app zich registreren voor het WIPE_USER_DATAMAMNotificationType.

Waarschuwing

Een app mag zich nooit registreren voor zowel WIPE_USER_AUXILIARY_DATAals WIPE_USER_DATA .

Als u het standaard-SDK-wisgedrag overschrijft, loopt uw app een aanzienlijk risico. Uw app is volledig verantwoordelijk voor het verwijderen van alle gegevens die zijn gekoppeld aan de beheerde identiteit, inclusief alle bestanden en gegevensbuffers die voor die identiteit zijn getagd.

• Als de beheerde identiteit is beveiligd met versleuteling en de aangepaste wishandler van uw app niet alle beheerde gegevens volledig verwijdert, blijven alle resterende beheerde bestanden versleuteld. Deze gegevens worden niet meer toegankelijk en uw app verwerkt mogelijk geen pogingen om versleutelde gegevens correct te lezen.
• De wishandler van uw app kan leiden tot gegevensverlies voor niet-beheerde gebruikers, als bestanden worden verwijderd die niet zijn getagd met de beheerde identiteit.

Als de aangepaste wishandler van uw app beheerde gegevens uit een bestand verwijdert, maar andere gegevens in het bestand wil laten staan, moet de identiteit van het bestand (via MAMFileProtectionManager.protect) worden gewijzigd in een onbeheerde identiteit of een lege tekenreeks.

De overschreven wishandler moet de gegevens synchroon wissen en niet terugkeren totdat alle opschoning is voltooid.

Overweeg uw app handmatig te sluiten na het voltooien van de stappen voor de aangepaste wishandler om te voorkomen dat de gebruiker toegang heeft tot gegevens in het geheugen nadat een wisbewerking is uitgevoerd.

Afsluitcriteria

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

• App-beveiligingsbeleid maken en toewijzen aan een account. Dit wordt uw door test beheerde account.
• Maak een ander account, maar wijs geen app-beveiligingsbeleid toe aan. 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 en de Intune-bedrijfsportal. 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 en de Intune-bedrijfsportal. 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 bevat 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 en de Intune-bedrijfsportal. 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.

Scenario's voor selectief wissen valideren

Uw app met meerdere identiteiten heeft mogelijk het standaard wisgedrag van de SDK aangevuld of overschreven. Deze tests helpen ervoor te zorgen dat uw integratie met meerdere identiteiten beheerde gegevens op de juiste manier verwijdert wanneer wisbewerkingen worden gestart, zonder dat dit van invloed is op onbeheerde gegevens.

Waarschuwing

Herinnering: als uw app gebruikmaakt van MAMDataProtectionManager.protect, moet er een handler worden geïmplementeerd voor of WIPE_USER_AUXILIARY_DATAWIPE_USER_DATA.

Voor deze tests installeert u uw app en de Intune-bedrijfsportal. Meld u aan met een beheerd en onbeheerd account voordat u de test start. Oefen voor beide accounts app-scenario's waarin accountgegevens worden opgeslagen.

Scenario	Voorwaarden	Stappen
Aanvullende wishandler	Uw app heeft een handler geïmplementeerd voor WIPE_USER_AUXILIARY_DATA	- Geef selectief wissen uit het Microsoft Intune-beheercentrum. - Bevestig (meestal via logboekregistratie) dat uw wishandler is uitgevoerd. - 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.
Overschreven wishandler	Uw app heeft een handler geïmplementeerd voor WIPE_USER_DATA	- Geef selectief wissen uit het Microsoft Intune-beheercentrum. - Bevestig (meestal via logboekregistratie) dat uw wishandler is uitgevoerd. - 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. - Controleer of uw app correct is afgesloten of nog steeds in een goede staat is nadat uw wishandler is voltooid.
Handmatige bestandsbeveiliging	- Uw app-aanroepen MAMFileProtectionManager.protect - Uw app heeft een handler geïmplementeerd voor WIPE_USER_DATA	- Zorg ervoor dat u scenario's hebt geoefend waarbij uw app ten minste één bestand van het beheerde account handmatig beveiligt. - Geef selectief wissen uit het Microsoft Intune-beheercentrum. - Controleer of de bestanden zijn verwijderd.
Handmatige gegevensbufferbeveiliging	- Uw app-aanroepen MAMDataProtectionManager.protect - Uw app heeft een handler geïmplementeerd voor of WIPE_USER_AUXILIARY_DATAWIPE_USER_DATA	- Zorg ervoor dat u scenario's hebt uitgevoerd waarbij uw app handmatig ten minste één gegevensbuffer van het beheerde account beveiligt. - Geef selectief wissen uit het Microsoft Intune-beheercentrum. - Controleer of de gegevensbuffers zijn verwijderd uit de bestanden waarin ze zijn opgeslagen en dat uw app de onbeheerde gegevens uit die bestanden nog steeds kan lezen.

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: App Configuration en Fase 7: Functies voor app-deelname, kunnen al dan niet vereist zijn, afhankelijk van de gewenste ondersteuning voor het app-beveiligingsbeleid van uw app. Als u niet zeker weet of een van deze secties van toepassing is op uw app, gaat u opnieuw naar Belangrijke beslissingen voor SDK-integratie.