Intune App SDK voor Android - meerdere identiteiten

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

Opmerking

Deze gids is onderverdeeld in verschillende verschillende fasen. Begin met het doornemen van fase 1: plan de integratie.

Fase 5: Multi-identiteit

Fase doelen

• Bepaal of je toepassing ondersteuning voor meerdere identiteiten nodig heeft.
• Begrijp hoe de Intune App SDK identiteiten waarneemt.
• Herstructureer uw toepassing voor identiteitsbewustzijn.
• Voeg code toe om de SDK op de hoogte te stellen van actieve en veranderende identiteiten in uw toepassing.
• Test de handhaving van het app-beveiligingsbeleid grondig voor zowel beheerde als onbeheerde identiteiten.

Identiteitterminologie

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

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

Achtergrond

Standaard wordt met de Intune App SDK beleid toegepast op uw gehele toepassing. Na het registreren van een account waarvoor het beschermingsbeleid voor apps is gericht, koppelt de SDK elk bestand en elke activiteit aan de identiteit van dat account en past de SDK het gerichte 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 toepassingen met één identiteit. Door de vorige fasen te voltooien, is uw toepassing met succes geïntegreerd als enkelvoudige identiteit en kan alle basisbeleidsregels worden afgedwongen. Apps die zijn bedoeld om een enkele identiteit te hebben, kunnen dit gedeelte overslaan en doorgaan naar fase 6: App Configuration.

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

Tip

Als u niet zeker weet of een toepassing beveiligingen met één of meerdere identiteiten moet ondersteunen, gaat u opnieuw naar Is mijn programma één identiteit of meerdere identiteiten?

Waarschuwing

Het ondersteunen van meerdere identiteiten is aanzienlijk complexer dan andere functies voor app-beveiliging. Onjuiste integratie van meerdere identiteiten kan leiden tot gegevenslekken en andere beveiligingsproblemen. Neem dit gedeelte zorgvuldig door en plan voldoende tijd in voor testen voordat u doorgaat naar de volgende fase.

'Identiteit' voor de SDK

Wanneer een met SDK geïntegreerde toepassing een account registreert met registerAccountForMAM, slaat de SDK alle opgegeven parameters (upn, aadId, tenantId en autoriteit) op als de identiteit. De meeste identiteits-API's van de SDK gebruiken echter de opgegeven OID (ook wel Microsoft Entra ID of AAD-id genoemd) als de id voor de identiteit. De MAM SDK-API's retourneren de OID-tekenreeks als de identiteit en vereisen de OID-tekenreeksparameter voor de identiteit. Bij sommige methoden kan ook een UPN-tekenreeks worden gebruikt of geretourneerd. In dat geval is de UPN alleen bedoeld ter informatie.

Identiteitsparameters zijn niet hoofdlettergevoelig. Aanvragen voor een identiteit aan de SDK retourneren mogelijk niet hetzelfde hoofdlettergebruik als bij het registreren of instellen van de identiteit.

Voorzichtigheid

Voor apps die afgeschafte methoden gebruiken die een UPN-tekenreeks gebruiken of retourneren, moeten apps ervoor zorgen dat de identiteit van de UPN-tekenreeks die wordt doorgegeven aan verschillende API-aanroepen consistent is. Het doorgeven van inconsistente UPN-tekenreeksen kan leiden tot gegevenslekken.

Beheerde versus onbeheerde identiteiten

Zoals beschreven in het 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 het 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 door de SDK als onbeheerd worden beschouwd.

Op dit moment 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 behandeld als niet-beheerd, zelfs als ze momenteel het doelwit zijn van app-beveiligingsbeleid.

Als er al een beheerde identiteit is geregistreerd op het apparaat en uw app registreert een andere identiteit die ook het doel is van het app-beveiligingsbeleid, keert de SDK terug MAMEnrollmentManager.Result.WRONG_USER en wordt de eindgebruiker gevraagd met opties voor herstel. Zie Registreren voor meldingen van de SDK voor meer informatie.

Opmerking

Een account waarvoor geen app-beveiligingsbeleid geldt op het moment van de registratie, wordt als onbeheerd beschouwd. Zelfs als het account niet is gelicentieerd voor of niet bedoeld is met app-beveiligingsbeleid, zal de SDK periodiek controleren of dit account op een later tijdstip wordt gelicentieerd en getarget. Als er geen andere beheerde identiteit is geregistreerd, behandelt de SDK deze identiteit als beheerd zodra er beleid op is gericht. De gebruiker hoeft zich niet af of opnieuw aan te melden bij dit account om deze wijziging door te voeren.

De actieve identiteit

In uw toepassing moet de SDK altijd op de hoogte worden gehouden 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 beveiligingen toe.

Omdat de SDK geen toepassingsspecifieke kennis heeft, moet deze erop vertrouwen dat de toepassing de juiste actieve identiteit deelt.

• Als in de toepassing ten onrechte aan de SDK wordt doorgegeven dat een onbeheerde identiteit actief is, terwijl de beheerde identiteit in feite in gebruik is, worden geen beveiligingen toegepast. Dit kan een datalek veroorzaken dat de gegevens van gebruikers in gevaar brengt.

• Als in de toepassing ten onrechte aan de SDK wordt doorgegeven dat de beheerde identiteit actief is, terwijl in werkelijkheid een onbeheerde identiteit in gebruik is, worden door de SDK ten onrechte beveiligingen toegepast. Dit is geen gegevenslek, maar dit kan onnodig onbeheerde gebruikers beperken en de gegevens van onbeheerde gebruikers het risico lopen te worden verwijderd.

Als uw toepassing gebruikersgegevens weergeeft, mogen alleen gegevens worden weergegeven die behoren tot de actieve identiteit. Als uw toepassing momenteel niet weet wie eigenaar is van de gegevens die worden weergegeven, moet u mogelijk de structuur van uw toepassing wijzigen voor een groter identiteitsbewustzijn voordat u begint met het integreren van ondersteuning voor meerdere identiteiten.

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 Writing Protected Files for details). De SDK gebruikt deze getagde bestandsidentiteit voor zowel bestandsversleuteling als selectief wissen.

Als het doel van de beheerde identiteit is met versleutelingsbeleid, worden alleen bestanden versleuteld die zijn gemarkeerd met de beheerde identiteit.

Als door de beheerder of het geconfigureerde beleid wordt gevraagd om beheerde gegevens te wissen, worden alleen bestanden verwijderd die zijn gemarkeerd met de beheerde identiteit.

De SDK kan niet meerdere identiteiten koppelen aan één bestand. Als uw app gegevens van meerdere gebruikers in hetzelfde bestand opslaat, leidt het standaardgedrag van de SDK tot onder- of overbeveiliging van deze gegevens. Het wordt sterk aangeraden om de gegevens van uw app op identiteit in te delen.

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

Multi-Identity implementeren

Als u ondersteuning voor meerdere identiteiten voor uw app wilt aangeven, begint u met het plaatsen van 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 op de volgende niveaus in aflopende prioriteit instellen:

1. Threadniveau
2. Context (algemeen Activity) niveau
3. Procesniveau

Een identiteitsset op threadniveau vervangt een identiteitsset op dat Context niveau, die een identiteitsset op procesniveau vervangt.

Een identiteitsset op a Context wordt alleen gebruikt in de juiste bijbehorende 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. In een app mogen geen gegevens voor een identiteit worden weergegeven, tenzij de Activity identiteit is ingesteld op dezelfde identiteit.

In het algemeen is de identiteit op procesniveau alleen nuttig als de app werkt met slechts één identiteit tegelijk op alle threads. Dit is niet gebruikelijk bij apps die meerdere accounts ondersteunen. U wordt sterk aangemoedigd om accountgegevens te scheiden en de actieve identiteit voor de thread of Context niveaus in te stellen.

Als uw app de Application context gebruikt om systeemservices te verkrijgen, moet u ervoor zorgen dat de thread- of procesidentiteit is ingesteld of dat u de gebruikersinterface-identiteit hebt ingesteld voor de context van uw Application app.

Als uw app een Service context gebruikt om intenties te starten, inhoudsresolvers gebruikt of gebruikmaakt van andere systeemservices, moet u ervoor zorgen dat u de identiteit instelt op de Service context. Als uw app een JobService context gebruikt om deze acties uit te voeren, moet u er ook voor zorgen dat u de identiteit instelt voor de JobService context of thread, zoals vereist door uw JobService implementatie. Als uw taken bijvoorbeeld voor één identiteit verwerkt, kunt u JobService overwegen de identiteit op de JobService context in te stellen. Als uw taken voor meerdere identiteiten verwerkt, kunt u JobService overwegen om de identiteit in te stellen op thread-niveau.

Voorzichtigheid

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

Opmerking

Omdat de CLIPBOARD_SERVICE wordt gebruikt voor UI-bewerkingen, gebruikt de SDK de UI-identiteit van de activiteit op de voorgrond 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 setUIPolicyIdentityOID(final Context context, final String oid,
                    final MAMSetUIIdentityCallback mamSetUIIdentityCallback, final EnumSet<IdentitySwitchOption> options);

public static String getUIPolicyIdentityOID(final Context context);

public static MAMIdentitySwitchResult setProcessIdentityOID(final String oid);

public static String getProcessIdentityOID();

public static MAMIdentitySwitchResult setCurrentThreadIdentityOID(final String oid);

public static String getCurrentThreadIdentityOID();

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

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


public static AppPolicy getPolicyForIdentityOID(final String oid);

public static boolean getIsIdentityOIDManaged(final String oid);

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

     public final void switchMAMIdentityOID(final String newIdentityOid, final EnumSet<IdentitySwitchOption> options);

Opmerking

Als uw app geen ondersteuning voor meerdere identiteiten heeft aangegeven in het manifest, wordt er bij het aanroepen van deze methoden om de identiteit in te stellen geen actie uitgevoerd en als ze een MAMIdentitySwitchResultretourneren, wordt dit altijd geretourneerd FAILED.

Veel voorkomende valkuilen bij het wisselen van identiteit

• Voor oproepen naar startActivitygaat de SDK van de Intune-app van Intune ervan uit dat de actieve identiteit op het Context niveau is gekoppeld aan de opgegeven Intent parameter. Het wordt sterk aangeraden om het Context niveau identiteit in te stellen met de Activitycontext 's', niet met de Application's context.

• Het wordt aanbevolen om de identiteit in te stellen tijdens de Context methode van onCreate een activiteit. Zorg er echter voor dat u ook andere toegangspunten behandelt, zoals onNewIntent. Als dat niet het geval is, wordt beleid mogelijk onjuist toegepast wanneer dezelfde activiteit opnieuw wordt gebruikt om gegevens weer te geven voor zowel beheerde als niet-beheerde identiteiten. Dit leidt tot onbeveiligde bedrijfsgegevens of onjuist beperkte persoonsgegevens.

Resultaten van identiteitswisseling

Alle methoden die worden gebruikt om de resultaatwaarden van het identiteitsrapport in te stellen via MAMIdentitySwitchResult. Er zijn vier waarden die kunnen worden geretourneerd:

Retourwaarde	Scenario
SUCCEEDED	De identiteitsverandering was succesvol.
NOT_ALLOWED	De identiteitswijziging is niet toegestaan. Dit gebeurt als wordt geprobeerd de identiteit van de gebruikersinterface (Context) in te stellen wanneer een andere identiteit is ingesteld op de huidige thread.
CANCELLED	De gebruiker heeft de identiteitswijziging geannuleerd, meestal door op de knop Vorige te drukken bij een pincode of verificatieprompt.
FAILED	De identiteitswijziging is om een onbekende reden mislukt.

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

Met de meeste methoden voor het instellen van de actieve identiteit wordt MAMIdentitySwitchResult synchroon geretourneerd. In het geval van het instellen van een Context identiteit via setUIPolicyIdentityOID, 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 een oproep wordt gedaan om setUIPolicyIdentityOID terwijl het resultaat van een vorige oproep naar setUIPolicyIdentityOIDhetzelfde Context nog niet is geleverd, vervangt de nieuwe callback de oude en zal de oorspronkelijke callback nooit een resultaat ontvangen.

Voorzichtigheid

Als het Context opgegeven aan setUIPolicyIdentityOID een Activityis, weet de SDK pas of de identiteitswijziging is geslaagd nadat de door de beheerder geconfigureerde voorwaardelijke startcontroles zijn uitgevoerd. Hiervoor moet de gebruiker mogelijk een pincode of bedrijfsreferenties invoeren.

Op dit moment zullen proces- en threadidentiteitswisselingen altijd slagen voor een app met meerdere identiteiten. De SDK behoudt zich het recht voor om in de toekomst foutvoorwaarden toe te voegen.

De identiteitsverandering voor de gebruikersinterface kan mislukken vanwege ongeldige argumenten, als deze in strijd zou zijn met de thread-identiteit of als de gebruiker annuleert vanwege voorwaardelijke startvereisten (bijvoorbeeld door op de knop Vorige op het PIN-scherm te drukken).

Het standaardgedrag bij een mislukte identiteitswijziging voor de gebruikersinterface van een activiteit is het voltooien van de activiteit. Als u dit gedrag wilt wijzigen en meldingen wilt ontvangen over pogingen tot het wijzigen van de identiteit van een activiteit, kunt u een methode overschrijven in MAMActivity.

    public void onSwitchMAMIdentityComplete(final MAMIdentitySwitchResult result);

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

Opmerking

Het kan nodig zijn de activiteit opnieuw te maken als u de identiteit wilt wijzigen. In dit geval wordt de onSwitchMAMIdentityComplete callback bezorgd bij het nieuwe exemplaar van de activiteit.

Identity, Intents, and IdentitySwitchOptions

Naast het automatisch labelen van nieuwe bestanden met de actieve identiteit, voegt de SDK ook intenties toe aan de actieve identiteit. Standaard controleert de SDK de identiteit van een binnenkomende intentie en vergelijkt deze met de actieve identiteit. Als deze identiteiten niet overeenkomen, vraagt de SDK doorgaans(*) om een identiteitswijziging (zie Impliciete identiteitswijzigingen hieronder voor meer informatie).

De SDK slaat ook deze binnenkomende intentie-identiteit op voor later gebruik. Wanneer de app de identiteit van de gebruikersinterface expliciet wijzigt, vergelijkt de SDK de identiteit waarnaar de app probeert over te schakelen met de meest recente binnenkomende intentie-identiteit. Als deze identiteiten niet overeenkomen, mislukt de identiteitsschakelaar meestal (*) door de SDK.

De SDK voert deze controle uit omdat wordt aangenomen dat de app nog steeds inhoud weergeeft van de intentie die behoort tot de identiteit die is getagd op de intentie. 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 setUIPolicyIdentityOID - en switchMAMIdentityOID-API's om het standaardgedrag van de SDK te wijzigen.

• IGNORE_INTENT: bij het aanvragen van een identiteitswisseling op de UI-laag, informeert deze optie de SDK om het vergelijken van de aangevraagde identiteitsparameter met de meest recent opgeslagen intentie-identiteit over te slaan. Dit is handig wanneer in uw app geen inhoud meer wordt weergegeven die tot die identiteit behoort en de SDK deze identiteitswisseling niet zou moeten blokkeren. Bijvoorbeeld:

  1. Uw app is een documentviewer. Het kan documenten weergeven die vanuit andere apps zijn doorgegeven. Het bevat ook een functie waarmee gebruikers van account kunnen wisselen. Wanneer de gebruiker deze accountwisselfunctie gebruikt, gaat de app naar een accountspecifieke bestemmingspagina met de recente documenten van dat account.
  2. Uw app ontvangt de 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, met de beveiliging op de juiste wijze toegepast.
  4. De gebruiker gebruikt de functie voor accountwisselaar om over te schakelen naar zijn persoonlijke account.

  De identiteit van de gebruikersinterface moet door uw app worden gewijzigd in stap 4. In dit geval moet de app worden gebruikt IGNORE_INTENT bij het aanroepen van de identiteitsschakelaar, omdat de app de gegevens van het beheerde account (het document in de intentie) verlaat. Hiermee wordt voorkomen dat de SDK deze aanroep ten onrechte mislukt.

• DATA_FROM_INTENT: bij het aanvragen van een identiteitswijziging op de UI-laag, informeert deze optie de SDK dat gegevens van de meest recent opgeslagen intentie-identiteit nog steeds worden weergegeven nadat de identiteitswijziging is geslaagd. Als gevolg hiervan evalueert de SDK het ontvangstbeleid volledig ten opzichte 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 vanuit andere apps zijn doorgegeven. Het bevat ook een functie waarmee gebruikers van account kunnen wisselen. In tegenstelling tot het eerdere voorbeeld gaat de app, telkens wanneer de gebruiker deze accountwisselfunctie gebruikt, naar een gedeelde pagina met recente documenten voor alle accounts'.
  2. Uw app ontvangt de 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, met de beveiliging op de juiste wijze toegepast.
  4. De gebruiker gebruikt de functie voor accountwisselaar om over te schakelen naar zijn persoonlijke account.

  De identiteit van de gebruikersinterface moet door uw app worden gewijzigd in stap 4. In dit geval, omdat de app de gegevens van de beheerde identiteit blijft weergeven (een voorbeeld van het document in de intentie), moet deze worden gebruikt DATA_FROM_INTENT bij het aanroepen van de identiteitsschakelaar. Hiermee wordt de SDK geïnformeerd om het geconfigureerde app-beveiligingsbeleid te controleren om te bepalen of het geschikt is om de gegevens weergegeven te laten.

(*) Het standaardgedrag van de SDK omvat een speciaal hoofdlettergebruik dat deze controle op gegevenstoegang overslaat als de intentie bijvoorbeeld afkomstig is van binnen dezelfde app of van het startprogramma voor systeem.

De actieve identiteit wissen

Uw toepassing heeft mogelijk scenario's die accountonafhankelijk zijn. Uw toepassing kan ook scenario's bevatten voor lokale, onbeheerde scenario's waarvoor geen aanmelding nodig is. In beide gevallen wil uw app mogelijk niet dat de SDK het beleid van de beheerde identiteit afdwingt, maar hebt u mogelijk geen expliciete identiteit om naar over te schakelen.

U kunt de actieve identiteit wissen door een van de ingestelde identiteitsmethoden aan te roepen waarbij de identiteitsparameter OID is ingesteld op null. Als de identiteit op één niveau wordt gewist, zoekt de SDK naar de actieve identiteit op andere niveaus, op basis van de prioriteitsvolgorde.

U kunt ook een lege tekenreeks doorgeven als de identiteits-OID-parameter, waarmee de identiteit wordt ingesteld op een speciale lege waarde die wordt behandeld als een onbeheerde identiteit. Door de actieve identiteit in te stellen op een lege tekenreeks, zorgt u dat de SDK geen beveiligingsbeleid voor apps mag afdwingen.

Impliciete identiteitswijzigingen

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

Luisteren naar deze impliciete identiteitswijzigingen is optioneel, maar wordt aanbevolen. De SDK wijzigt nooit de actieve identiteit zonder deze impliciete meldingen van identiteitswijzigingen te verstrekken.

Voorzichtigheid

Als uw app ervoor kiest 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 getCurrentThreadIdentityOIDmethoden , getUIPolicyIdentityOIDen getProcessIdentityOID om de actieve identiteit te bevestigen.

Bronnen van impliciete identiteitswijzigingen

• Gegevensinvoer vanuit andere door Intune beheerde apps kan 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 activiteit is verzonden.

    • Een activiteit om een Word-document weer te geven wordt bijvoorbeeld gestart vanuit een intentie vanuit Microsoft Outlook wanneer een gebruiker een documentbijlage selecteert. De identiteit van de documentvieweractiviteit van Office wordt overgeschakeld naar de identiteit van Outlook.

  • Voor services wordt de threadidentiteit op dezelfde manier ingesteld voor de duur van een onStart OF-aanroep onBind . Met oproepen naar de Binder ontvanger wordt onBind ook tijdelijk de thread-identiteit ingesteld.

  • Aanroepen naar een ContentProvider zal op dezelfde manier de thread-identiteit voor hun duur instellen.

• Door interactie van een gebruiker met een activiteit kan de actieve identiteit op contextniveau worden gewijzigd. Bijvoorbeeld:

  • Een gebruiker die een autorisatieprompt annuleert tijdens dit zal Resume een impliciete overschakeling naar een lege identiteit tot gevolg hebben.

Impliciete identiteitswijzigingen verwerken

Uw app kan optioneel luisteren naar en reageren op deze impliciete identiteitswijzigingen. Het kan bijvoorbeeld zijn dat uw toepassing meerdere stappen nodig heeft voordat een toegevoegd account bruikbaar is, zoals een e-mailapp die een nieuw Postvak IN instelt. Bij het zien van een poging tot identiteitswijziging naar de identiteit van dit onvolledige account, kan de handler van uw app de gebruiker omleiden naar de activiteit voor het instellen van het account voordat de identiteitswijziging wordt geaccepteerd. Een andere mogelijkheid is dat de handler van je app een foutdialoogvenster weergeeft en de identiteitsschakelaar blokkeert.

Uw app kan de MAMIdentityRequirementListener-interface implementeren op een Service of ContextProvider voor identiteitswijzigingen die van toepassing zijn op deze thread. De implementatie moet het volgende vervangen:

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

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

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

De AppIdentitySwitchReason opsommingsparameter beschrijft de bron van de impliciete identiteitsschakelaar.

Opsommingswaarde	Standaardgedrag van SDK	Beschrijving
CREATE	Identiteitswisseling toestaan.	De identiteitswisseling vindt plaats vanwege het creëren van een activiteit.
NEW_INTENT	Identiteitswisseling toestaan.	De identiteitswisseling vindt plaats omdat een nieuwe intentie aan een activiteit wordt toegewezen.
RESUME_CANCELLED	De identiteitsschakelaar blokkeren.	De identiteitswisseling vindt plaats omdat een cv is geannuleerd. Dit doet zich meestal voor wanneer de eindgebruiker op de knop Terug drukt op de pincode-, verificatie- of compliance-interface.

Met de parameter AppIdentitySwitchResultCallback kunnen ontwikkelaars het standaardgedrag voor de identiteitsschakelaar 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, behalve die welke zijn aangebracht via een Binder die is geretourneerd van MAMService.onMAMBind. De standaardimplementaties van onMAMIdentitySwitchRequired immediately call:

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

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

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

• Als een identiteitswisseling wordt geblokkeerd, werkt de eindgebruiker hetzelfde als wanneer de beveiligingsinstelling van de SDK 'gegevens ontvangen van andere apps' het binnendringen van gegevens had verboden.

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

• Bij Activity het maken ervan wordt onMAMIdentitySwitchRequired aangeroepen vóór onMAMCreate. Als de app de gebruikersinterface moet weergeven om te bepalen of de identiteitswisseling moet worden toegestaan, moet die gebruikersinterface worden weergegeven met een andere activiteit.

• In an Activity, wanneer een overschakeling naar de lege identiteit wordt aangevraagd met de reden als RESUME_CANCELLED, moet de app de hervatte activiteit wijzigen om gegevens weer te geven die consistent zijn met die identiteitswisseling. Als dit niet mogelijk is, moet de app de overschakeling weigeren en wordt de gebruiker opnieuw gevraagd om te voldoen aan het beleid voor het hervatten van de identiteit (bijvoorbeeld doordat het invoerscherm voor de pincode van de app wordt weergegeven).

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.getIsIdentityOIDManaged om dit 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 kan MAMActivity.onMAMIdentitySwitchRequired worden bereikt door de statische methode MAMActivity.defaultOnMAMIdentitySwitchRequired(activity, upn, oid, reason, callback)aan te roepen.

Evenzo, als u , MAMActivity.onSwitchMAMIdentityCompletekunt u implementeren MAMActivityIdentitySwitchListener zonder expliciet te erven van MAMActivity.

Identiteitswisselingen en beperkingen voor schermafbeeldingen

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

Bij het overschakelen van een identiteit van een identiteit waarvan het beleid vereist dat schermopnamen worden uitgeschakeld naar een identiteit waarvan dat niet het geval is, wordt de SDK gewist FLAG_SECURE. Als gevolg hiervan zou uw app er niet op moeten vertrouwen dat FLAG_SECURE deze ingesteld blijft na een identiteitswijziging.

Identiteit behouden bij asynchrone bewerkingen

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

De Intune App SDK biedt MAMAsyncTask en MAMIdentityExecutors als een gemak om te helpen bij het behouden van de identiteit in asynchrone bewerkingen. Uw app moet deze gebruiken (of expliciet de thread-identiteit instellen voor de taken) als de asynchrone bewerkingen kunnen:

• Gegevens die tot een beheerde identiteit behoren, naar een bestand schrijven
• Communiceren met andere apps

MAMAsyncTask

Als u wilt gebruiken MAMAsyncTask, neemt u er gewoon van over in plaats van AsyncTask en vervangt u de overschrijvingen van doInBackground en onPreExecute met doInBackgroundMAM respectievelijk en onPreExecuteMAM . De MAMAsyncTask constructor gebruikt 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 prioriteitsvolgorde.

MAMIdentityExecutors

MAMIdentityExecutorsHiermee kunt u een bestaande Executor of instantie verpakken als een identiteitsbehoudende wrapExecutorExecutorServiceExecutor/met en wrapExecutorService methoden.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 prioriteitsvolgorde.

Bestandsbeveiliging

Beveiligde Files schrijven

Zoals hierboven is beschreven in App-gegevens ordenen op identiteit, koppelt de Intune App SDK de actieve identiteit (vanaf thread-/procesniveau) aan bestanden terwijl deze worden geschreven. Het is van cruciaal belang dat u de juiste identiteit hebt ingesteld op het moment dat u bestanden maakt, zodat u verzekerd bent van de juiste versleuteling en selectieve wisfunctionaliteit.

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

De protectForOID methode kan ook worden gebruikt om mappen te beveiligen. Adreslijstbeveiliging is recursief van toepassing op alle bestanden en submappen in de map. Wanneer een directory is beveiligd, wordt op alle nieuwe bestanden die binnen de directory worden gemaakt automatisch dezelfde beveiliging toegepast. Omdat adreslijstbeveiliging recursief wordt toegepast, kan de protectForOID aanroep voor grote adreslijsten enige tijd duren. Om die reden willen apps die bescherming toepassen op een map die een groot aantal bestanden bevat, mogelijk asynchroon worden uitgevoerd protectForOID op een achtergrondthread.

Als u aanroept protectForOID met een lege tekenreeks voor de identiteitsparameter, wordt het bestand of de adreslijst gelabeld met de onbeheerde identiteit. Met deze bewerking wordt versleuteling van het bestand/de directory verwijderd als deze voorheen versleuteld was. Wanneer een opdracht voor selectief wissen wordt gegeven, wordt het bestand of de map niet verwijderd.

Waarschuwing

Het is belangrijk ervoor te zorgen dat alleen bestanden die tot een bepaalde identiteit behoren, met die identiteit worden beveiligd. Anders kunnen andere identiteiten gegevensverlies ervaren wanneer de identiteit van de eigenaar zich afmeldt, omdat bestanden worden gewist en de toegang tot de versleutelingssleutel verloren gaat.

Beveiligde bestandsinhoud weergeven

Het is al even belangrijk dat u de juiste identiteit instelt wanneer bestandsinhoud wordt weergegeven , om te voorkomen dat onbevoegde gebruikers beheerde gegevens kunnen 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 identiteit van de gebruikersinterface correct instellen voordat beheerde gegevens worden weergegeven. Dit geldt ook voor gegevens die uit bestanden worden gelezen.

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

Als getProtectionInfo een niet-null, niet-lege identiteit wordt gerapporteerd, moet de app de UI-identiteit instellen om met deze identiteit te overeenstemmen met behulp van MAMActivity.switchMAMIdentityOID of MAMPolicyManager.setUIPolicyIdentityOID. Als de identiteitswisseling mislukt, mogen de gegevens uit het bestand niet worden weergegeven.

Bij het lezen vanuit een inhouds-URI kan het nodig zijn om eerst de identiteit te lezen (via de getProtectionInfo overbelasting die a Uri) en vervolgens de context- of thread-identiteit op de juiste manier in te stellen. U moet dit doen voordat u een bestandsdescriptor of invoerstream opent op de ContentResolver, anders kan de bewerking mislukken.

Een voorbeeldstroom kan er bijvoorbeeld als volgt uitzien:

• De gebruiker selecteert een document om in de app te openen.

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

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

• De app wacht totdat een resultaat wordt gerapporteerd om terug te bellen.

• Als het gemelde resultaat een fout is, wordt het document niet weergegeven.

• 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 voor het ophalen van de DownloadManager thread, wordt gebruikt als de thread-identiteit wordt uitgeschakeld. Als de gedownloade bestanden bedrijfsgegevens bevatten, is het de verantwoordelijkheid van de app om protectForOID aan te roepen als de bestanden na het downloaden worden verplaatst of opnieuw worden gemaakt.

Single-Identity naar de overgang naar meerdere identiteiten

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

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

Als u niet wilt dat alle voorgaande 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 waaraan ondersteuning voor meerdere identiteiten is toegevoegd.
• Aanroepen protectForOID 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 'offline' modus wanneer de Bedrijfsportal-app niet is geïnstalleerd. Tagging van bestandsidentiteiten is gevoelig voor de offlinemodus:

• Als de Bedrijfsportal niet is geïnstalleerd, kunnen bestanden geen identificatielabel krijgen. Het is veilig om MAMFileProtectionManager.protectForOID aan te roepen in de offlinemodus, maar heeft geen effect.

• Als de Bedrijfsportal is geïnstalleerd, maar de app geen app-beveiligingsbeleid heeft, kunnen bestanden niet op betrouwbare wijze worden voorzien van een id-markering.

• Wanneer het taggen van bestandsidentiteiten weer beschikbaar wordt, worden alle eerder gemaakte bestanden behandeld als persoonlijk/onbeheerd (behorend tot de identiteit met de lege tekenreeks), behalve in gevallen waarin de app eerder was geïnstalleerd als een app die wordt beheerd door één identiteit, zoals beschreven in de overgang van één identiteit naar meerdere identiteiten.

Om deze gevallen te voorkomen, moeten apps geen bestanden met accountgegevens maken totdat de accountregistratie is voltooid. Als uw app absoluut bestanden moet maken terwijl u offline bent, kan deze MAMFileProtectionManager.protectForOID gebruiken om de gekoppelde identiteit van het bestand te corrigeren zodra de SDK online is.

Bescherming van gegevensbuffers

Waarschuwing

Het wordt afgeraden 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 of-indeling byte[]InputStream.

MAMDataProtectionManager.protectForOID Hiermee kan een app gegevens koppelen aan een identiteit en, als de identiteit momenteel het doel is van het versleutelingsbeleid, de gegevens versleutelen. Deze versleutelde gegevens zijn geschikt om in een bestand op schijf op te slaan.

MAMDataProtectionManager Ook kunt u een query uitvoeren op de gegevens die aan de identiteit zijn gekoppeld en deze ontsleutelen.

Apps die gebruik maken 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 via deze klasse zijn beveiligd, niet langer leesbaar (als bestandsversleuteling was 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 afhandelen van de MANAGEMENT_REMOVED melding. Het is ook veilig om tijdens deze melding te bellen protectForOID als u identiteitsgegevens wilt bewaren. Versleuteling is gegarandeerd uitgeschakeld tijdens de melding en als u de geleider inschakelt protectForOID , worden de gegevensbuffers niet versleuteld.

Waarschuwing

Versleutelingsbewerkingen moeten vroeg in het app-proces worden vermeden. De initialisatie van de SDK wordt asynchroon versleuteld, zo vroeg mogelijk na het opstarten van de app. Als een app echter een versleutelingsaanvraag doet bij het opstarten van een app, kan deze worden geblokkeerd totdat de initialisatie van de versleuteling is voltooid.

Opmerking

De Intune App SDK-versleutelings-API mag alleen worden gebruikt voor het versleutelen van gegevens zoals vereist door Intune beleid. Er wordt geen beveiliging toegepast op accounts waarvoor het versleutelingsbeleid niet is ingeschakeld, dus het kan niet worden gebruikt als algemene coderingsbibliotheek.

Inhoudsproviders

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

Uw app moet de statische MAMContentProvider-methodeisProvideContentAllowedForOid(provider, oid) aanroepen voordat inhoud wordt geretourneerd. Als deze functie 'onwaar' als resultaat geeft, moet de inhoud niet worden geretourneerd aan de aanvrager.

Bellen isProvideContentAllowedForOid is niet nodig als u ContentProvider een ParcelFileDescriptor. Bestandsdescriptoren die worden geretourneerd door een inhoudsprovider, worden automatisch verwerkt op basis van de bestandsidentiteit.

Selectief wissen

Standaard verwerkt de Intune App SDK automatisch selectieve wissingen, waarbij alle bestanden worden verwijderd die zijn gekoppeld aan de beheerde identiteit. Daarna sluit de SDK de app op een nette manier, waardoor activiteiten worden voltooid en het app-proces wordt beëindigd.

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

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

Opmerking

Voor het aanvullen en overschrijven van het standaardgedrag bij wissen moeten specifieke SDK-meldingen worden verwerkt. Zie Registreren voor meldingen van de SDK voor meer informatie over het implementeren van meldingshandlers.

Aanvulling op standaard wisgedrag

Als aanvulling op het standaardgedrag van het wissen van de SDK kan uw app zich registreren voor het WIPE_USER_AUXILIARY_DATAMAMNotificationType.

Deze melding wordt verzonden door de SDK voordat de SDK standaard selectief wissen uitvoert. De SDK wacht totdat de meldingshandler van uw app is voltooid voordat gegevens worden verwijderd en de app wordt beëindigd. De app moet gegevens synchroon wissen en pas terugkeren als alle opschoning is voltooid.

Apps moeten sterk overwegen om het standaardgedrag bij wissen aan te vullen met WIPE_USER_AUXILIARY_DATA, aangezien app-specifiek opschonen gebruikelijk is voor apps met meerdere identiteiten.

Standaardgedrag bij wissen overschrijven

Als u het standaardwisgedrag van de SDK wilt negeren, kan uw app zich registreren voor het WIPE_USER_DATAMAMNotificationType.

Waarschuwing

Een app mag zich nooit registreren voor zowel en WIPE_USER_DATAWIPE_USER_AUXILIARY_DATA.

Als u het standaardgedrag bij het wissen van de SDK overschrijft, loopt uw app aanzienlijke risico's. Uw app is volledig verantwoordelijk voor het verwijderen van alle gegevens die zijn gekoppeld aan de beheerde identiteit, inclusief alle bestanden en gegevensbuffers die zijn getagd voor die identiteit.

• Als de beheerde identiteit is beveiligd met versleuteling en de aangepaste wipe-handler van uw app niet alle beheerde gegevens volledig verwijdert, blijven de resterende beheerde bestanden versleuteld. Deze gegevens worden dan niet meer toegankelijk en uw app kan pogingen om versleutelde gegevens mogelijk niet op een correcte manier te lezen, aan.
• De wipe-handler van uw app kan leiden tot gegevensverlies voor onbeheerde gebruikers als bestanden worden verwijderd die niet zijn gekoppeld aan de beheerde identiteit.

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

De overschreven veeghandler moet de gegevens synchroon wissen en pas terugkeren als alle opschoning is voltooid.

Overweeg om de app handmatig te sluiten na het voltooien van de stappen voor de aangepaste veeg-handler om te voorkomen dat de gebruiker toegang heeft tot gegevens in het geheugen nadat een verwijdering heeft plaatsgevonden.

Exit-criteria

Trek voldoende tijd uit voor het valideren van de integratie van meerdere identiteiten in uw app. Voordat u begint met testen:

• Beveiligingsbeleid voor apps maken en toewijzen aan een account. Dit wordt het door de test beheerde account.
• Een ander account maken, maar geen app-beveiligingsbeleid toewijzen aan. Dit wordt het onbeheerde testaccount. Als je app meerdere accounttypen naast Microsoft Entra-accounts ondersteunt, kun je ook een bestaand niet-Entra-account gebruiken als het onbeheerde testaccount.
• Maak jezelf opnieuw vertrouwd met hoe beleid wordt afgedwongen in je app. Bij het testen van meerdere identiteiten moet u eenvoudig kunnen onderscheiden wanneer uw app wel en niet werkt met afgedwongen beleid. De beleidsinstelling app-beveiliging om schermopnamen te blokkeren, is effectief voor het snel testen van beleidsafdwinging.
• Houd rekening met de volledige gebruikersinterface die uw app biedt. Sommen de schermen op waarop accountgegevens worden weergegeven. Presenteert uw app altijd slechts de gegevens van één account tegelijk, of kan het gegevens van meerdere accounts tegelijk presenteren?
• Denk aan de volledige set bestanden die door de app worden gemaakt. Noem welke van deze bestanden gegevens bevatten die bij een account horen, in tegenstelling tot gegevens op systeemniveau.
  • Bepaal hoe u versleuteling voor elk van deze bestanden wilt valideren.
• Houd rekening met alle manieren waarop uw app kan communiceren met andere apps. Sommen alle in- en uitgangspunten op. Welke typen gegevens kan door uw app worden opgenomen? Welke intenties zendt het uit? Welke inhoudsproviders worden geïmplementeerd?
  • Bepaal hoe je 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 uw app de eindgebruiker in staat stelt te communiceren met alle aangemelde accounts. Moet de gebruiker handmatig overschakelen naar een account voordat de gegevens van dat account worden weergegeven?

Nadat u het huidige gedrag van uw app grondig hebt beoordeeld, valideert u de integratie met meerdere identiteiten door de volgende reeks tests uit te voeren. Houd er rekening mee dat dit geen volledige lijst is en het biedt geen garantie dat de implementatie van meerdere identiteiten van je app bugvrij is.

Scenario's voor aan- en afmelden valideren

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

Installeer voor deze tests uw app en de Intune-bedrijfsportal. Meld u niet aan voordat u de test hebt gestart.

Scenario	Stappen
Eerst beheerd aanmelden	- Log eerst in met een beheerd account en controleer of de gegevens van dat account worden beheerd. - Log in met een onbeheerd account en controleer of de gegevens van dat account niet worden beheerd.
Eerst onbeheerd aanmelden	- Log eerst in met een onbeheerd account en controleer of de gegevens van dat account niet worden beheerd. - Log in met een beheerd account en controleer of de gegevens van dat account worden beheerd.
Aanmelden met meerdere beheerde accounts	- Log eerst in met een beheerd account en controleer of de gegevens van dat account worden beheerd. - Log in met een tweede beheerd account en controleer of de gebruiker is geblokkeerd voor inloggen zonder eerst het oorspronkelijke beheerde account te verwijderen.
Beheerd afmelden	- Log in op uw app met zowel een beheerd als 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. - Controleer of het onbeheerde account nog steeds is ingelogd, dat er geen gegevens van het onbeheerde account zijn verwijderd en dat het beleid nog steeds niet is toegepast.
Onbeheerd afmelden	- Log in op uw app met zowel een beheerd als onbeheerd account. - Log uit bij het onbeheerde account. - Controleer of het onbeheerde account is verwijderd uit je 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 onbeheerde 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 het huidige in gebruik zijnde account expliciet te wijzigen. Er kunnen ook weergaven worden weergegeven met gegevens van meerdere accounts tegelijk. 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 zowel een beheerd als een onbeheerd account voordat u de test start.

Scenario	Stappen
Weergave van één account, beheerd	- Schakel over naar het beheerde account. - Navigeer naar alle pagina's in uw app met de gegevens van één account. - Bevestig dat het beleid op elke pagina wordt toegepast.
Weergave van één account, onbeheerd	- Schakel over naar het onbeheerde account. - Navigeer naar alle pagina's in uw app met de gegevens van één account. - Bevestig dat het beleid op geen enkele pagina wordt toegepast.
Weergave met meerdere accounts	- Navigeer naar alle pagina's in uw app waarop de gegevens van meerdere accounts tegelijk worden gepresenteerd. - Bevestig dat het beleid op elke pagina wordt toegepast.
Beheerde pauze	- Onderbreek de app op een scherm waarop beheerde gegevens worden weergegeven en beleid actief is door naar het startscherm van het apparaat of een andere app te navigeren. - Hervat de app. - Bevestig dat het beleid nog steeds wordt toegepast.
Onbeheerde pauze	- Onderbreek op een scherm waarop onbeheerde gegevens worden weergegeven en geen actief beleid actief is de app door naar het startscherm van het apparaat of een andere app te navigeren. - Hervat de app. - Bevestig dat het beleid niet wordt toegepast.
Managed kill	- Sluit de app geforceerd af op een scherm waarop beheerde gegevens worden weergegeven en het beleid actief is. - Start de app opnieuw. - Controleer 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 is toegepast.
Onbeheerde kill	- Op een scherm waarop onbeheerde gegevens worden weergegeven en beleid actief is, moet u de app geforceerd afsluiten. - Start de app opnieuw. - Controleer 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.
Identiteitwisseling ad hoc	- Experimenteer met schakelen tussen accounts en pauzeren / hervatten / doden / opnieuw opstarten van de app. - Controleer of de gegevens van het beheerde account altijd zijn beveiligd en dat de gegevens van het onbeheerde 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 beveiligingsbeleid voor apps 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 en de Intune-bedrijfsportal. Meld u aan met zowel een beheerd als een onbeheerd account voordat u de test start. Bijkomend:

• Stel het beleid van het beheerde account in als:
  • 'Organisatiegegevens verzenden naar andere apps' in 'Door beleid beheerde apps'.
  • 'Gegevens ontvangen van andere apps' in '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 onbeheerde app waarmee gegevens kunnen worden verzonden en ontvangen.
• Meld u aan bij de andere beheerde app met het beheerde testaccount. Meld u alleen aan met het beheerde account, zelfs als de andere beheerde app meerdere identiteiten heeft.

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

Scenario	Stappen
Beheerde identiteit verzenden naar onbeheerde app	- Schakel over naar het beheerde account. - Navigeer naar waar uw app gegevens naartoe kan verzenden. - Poging om gegevens te verzenden naar een onbeheerde app. - U zou moeten worden geblokkeerd voor het verzenden van gegevens naar de onbeheerde app.
Beheerde identiteit verzenden naar beheerde app	- Schakel over naar het beheerde account. - Navigeer naar waar uw app gegevens naartoe kan verzenden. - Probeer gegevens te verzenden naar de andere beheerde app terwijl het beheerde account is aangemeld. - Het moet mogelijk zijn om gegevens naar de beheerde app te verzenden.
Onbeheerde identiteit verzenden naar beheerde app	- Schakel over naar het onbeheerde account. - Navigeer naar waar uw app gegevens naartoe kan verzenden. - Probeer gegevens te verzenden naar de andere beheerde app terwijl het beheerde account is aangemeld. - Het verzenden van gegevens naar de andere beheerde app zou geblokkeerd moeten zijn.
Onbeheerde identiteit verzenden naar onbeheerde app	- Schakel over naar het onbeheerde account. - Navigeer naar waar uw app gegevens naartoe kan verzenden. - Poging om gegevens te verzenden naar een onbeheerde app. - U moet altijd de toestemming hebben om de gegevens van een onbeheerd account naar een onbeheerde app te verzenden.

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 waarin een document wordt geopend vanuit een Microsoft Outlook-bijlage. Het beveiligingsbeleid voor apps ontvangen dekt beide scenario's.

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

Scenario	Stappen
Beheerde identiteiten importeren uit onbeheerde app	- Schakel over naar het beheerde account. - Navigeer naar waar uw app gegevens uit andere apps kan importeren. - Poging tot het importeren van gegevens uit een onbeheerde app. - U zou moeten worden geblokkeerd voor het importeren van gegevens uit onbeheerde apps.
Beheerde identiteiten importeren uit beheerde app	- Schakel over naar het beheerde account. - Navigeer naar waar uw app gegevens uit andere apps kan importeren. - Probeer gegevens te importeren uit de andere beheerde app terwijl het beheerde account is aangemeld. - U moet gegevens uit de andere beheerde app kunnen importeren.
Onbeheerde identiteitsimport uit beheerde app	- Schakel over naar het onbeheerde account. - Navigeer naar waar uw app gegevens uit andere apps kan importeren. - Probeer gegevens te importeren uit de andere beheerde app terwijl het beheerde account is aangemeld. - U moet worden geblokkeerd voor het importeren van gegevens uit de andere beheerde app.
Onbeheerde identiteiten importeren uit onbeheerde app	- Schakel over naar het onbeheerde account. - Navigeer naar waar uw app gegevens uit andere apps kan importeren. - Poging tot het importeren van gegevens uit een onbeheerde app. - U moet altijd toestemming hebben om gegevens te importeren uit een onbeheerde app voor een onbeheerd account.

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

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

Fouten in deze tests kunnen erop wijzen dat uw app niet de juiste actieve identiteit heeft ingesteld bij het verzenden of ontvangen van gegevens. U kunt dit onderzoeken door gebruik te maken van de SDK's get identity API's op het moment van verzenden/ontvangen om te controleren of de actieve identiteit correct is ingesteld.

Scenario's voor selectief wissen valideren

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

Waarschuwing

Ter herinnering: als uw app gebruik maakt MAMDataProtectionManager.protectForOIDvan , moet deze een handler implementeren voor een WIPE_USER_AUXILIARY_DATA of .WIPE_USER_DATA

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

Scenario	Randvoorwaarden	Stappen
Aanvullende veeghandler	Uw app heeft een handler geïmplementeerd voor WIPE_USER_AUXILIARY_DATA	- Een selectieve wisbewerking uitvoeren vanuit het Microsoft Intune-beheercentrum. - Bevestig (meestal via logging) dat uw veeghandler met succes is uitgevoerd. - Controleer of het beheerde account is verwijderd uit uw app en dat alle gegevens van dat account zijn verwijderd. - Controleer of het onbeheerde account nog steeds is ingelogd, dat er geen gegevens van het onbeheerde account zijn verwijderd en dat het beleid nog steeds niet is toegepast.
Overschreven veeghandler	Uw app heeft een handler geïmplementeerd voor WIPE_USER_DATA	- Een selectieve wisbewerking uitvoeren vanuit het Microsoft Intune-beheercentrum. - Bevestig (meestal via logging) dat uw veeghandler met succes is uitgevoerd. - Controleer of het beheerde account is verwijderd uit uw app en dat alle gegevens van dat account zijn verwijderd. - Controleer of het onbeheerde account nog steeds is ingelogd, dat er geen gegevens van het onbeheerde account zijn verwijderd en dat het beleid nog steeds niet is toegepast. - Controleer of uw app correct is afgesloten of nog steeds in een gezonde staat verkeert nadat de veeg-handler is voltooid.
Handmatige bestandsbeveiliging	- Uw app-oproepen MAMFileProtectionManager.protectForOID - Je app heeft een handler geïmplementeerd voor WIPE_USER_DATA	- Zorg ervoor dat u scenario's hebt uitgevoerd waarin uw app ten minste één bestand van het beheerde account handmatig zou beveiligen. - Een selectieve wisbewerking uitvoeren vanuit het Microsoft Intune-beheercentrum. - Controleer of de bestanden zijn verwijderd.
Handmatige bescherming van gegevensbuffers	- Uw app-oproepen MAMDataProtectionManager.protectForOID - Je app heeft een handler geïmplementeerd voor een of WIPE_USER_AUXILIARY_DATAWIPE_USER_DATA	- Zorg ervoor dat u scenario's hebt uitgevoerd waarin uw app ten minste één gegevensbuffer van het beheerde account handmatig zou beschermen. - Een selectieve wisbewerking uitvoeren vanuit het Microsoft Intune-beheercentrum. - Controleer of de gegevensbuffers zijn verwijderd uit alle bestanden waarin ze zijn opgeslagen en of uw app de onbeheerde gegevens uit die bestanden nog steeds kan lezen.

Volgende stappen

Nadat u aan alle bovenstaande afsluitcriteria hebt voldaan, is uw app nu geïntegreerd als meerdere identiteiten en kan beveiligingsbeleid voor apps per identiteit worden afgedwongen. De volgende secties, Fase 6: App Configuration en Fase 7: Functies voor deelname aan apps, zijn mogelijk niet vereist, afhankelijk van de gewenste ondersteuning voor het app-beveiligingsbeleid voor uw app. Als u niet zeker weet of een van deze secties van toepassing is op uw app, gaat u terug naar Belangrijke beslissingen voor SDK-integratie.