Intune App SDK für Android – Multi-Identity

Mit dem Microsoft Intune App SDK für Android können Sie Intune App-Schutzrichtlinien (auch als APP- oder MAM-Richtlinien bezeichnet) in Ihre native Java/Kotlin Android-App integrieren. Eine Intune verwaltete Anwendung ist eine Anwendung, die in das Intune App SDK integriert ist. Intune Administratoren können App-Schutzrichtlinien ganz einfach für Ihre Intune verwaltete App bereitstellen, wenn Intune die App aktiv verwaltet.

Hinweis

Dieser Leitfaden ist in mehrere unterschiedliche Phasen unterteilt. Sehen Sie sich zunächst Phase 1: Planen der Integration an.

Phase 5: Mehrere Identitäten

Stage Goals

• Ermitteln Sie, ob Ihre Anwendung Unterstützung für mehrere Identitäten benötigt.
• Erfahren Sie, wie das Intune App SDK Identitäten wahrnimmt.
• Umgestalten Sie Ihre Anwendung für die Identitätserkennung.
• Fügen Sie Code hinzu, um das SDK über aktive und veränderbare Identitäten in Der gesamten Anwendung zu informieren.
• Testen Sie die Erzwingung von App-Schutzrichtlinien für verwaltete und nicht verwaltete Identitäten gründlich.

Identitätsterminologie

Die Begriffe "Benutzer", "Konto" und "Identität" werden häufig synonym verwendet. In diesem Leitfaden wird versucht, wie folgt zu unterscheiden:

• Benutzer: der Mensch, der das Softwareprodukt verwendet. Weiter differenziert als Endbenutzer, der Mensch, der die Android-App verwendet, und Administratoradministrator / benutzer / IT-Administrator / IT Pro, der Mensch, der das Microsoft Intune Admin Center verwendet.
• Konto: Der Softwaredatensatz, der zu einem organization gehört, der die Entität eines Benutzers eindeutig identifiziert. Ein menschlicher Benutzer kann über mehrere Konten verfügen.
• Identität: Der Satz von Daten, die das Intune App SDK verwendet, um ein Konto eindeutig zu identifizieren.

Hintergrund

Standardmäßig wendet das Intune App SDK eine Richtlinie auf Ihre gesamte Anwendung an. Nach der Registrierung eines Kontos mit zielorientierter App-Schutzrichtlinie ordnet das SDK jede Datei und jede Aktivität der Identität dieses Kontos zu und wendet die Zielrichtlinie dieses Kontos universell an.

Für viele Entwickler ist dies das gewünschte App-Schutzverhalten für ihre Anwendung. Diese Anwendungen werden als einzelidentitätsbasierte Anwendungen betrachtet. Nach Abschluss der vorherigen Phasen wurde Ihre Anwendung erfolgreich als einzelne Identität integriert und kann alle grundlegenden Richtlinien erzwingen. Apps, die eine einzelne Identität beibehalten sollen, können diesen Abschnitt überspringen und mit Phase 6: App Configuration fortfahren.

Das Intune App SDK kann optional Richtlinien auf Identitätsebene erzwingen. Wenn Ihre Anwendung bereits mehrere gleichzeitig angemeldete Konten unterstützt und Sie diese Unterstützung für mehrere Konten mit App-Schutzrichtlinien beibehalten möchten, wird Ihre Anwendung als mehrere Identitäten betrachtet.

Tipp

Wenn Sie nicht sicher sind, ob die Anwendung schutz mit einer oder mehreren Identitäten unterstützen soll, lesen Sie erneut: Ist meine Anwendung eine oder mehrere Identitäten?

Warnung

Die Unterstützung mehrerer Identitäten ist wesentlich komplexer als andere App-Schutzfunktionen. Eine unsachgemäße Integration mehrerer Identitäten kann zu Datenlecks und anderen Sicherheitsproblemen führen. Lesen Sie diesen Abschnitt sorgfältig durch, und planen Sie ausreichend Zeit für Tests ein, bevor Sie mit der nächsten Phase fortfahren.

"Identität" für das SDK

Wenn eine SDK-integrierte Anwendung ein Konto mit registerAccountForMAM registriert, speichert das SDK alle bereitgestellten Parameter (upn, aadId, tenantId und authority) als Identität. Die meisten Identitäts-APIs des SDK verwenden jedoch die bereitgestellte OID (auch als Microsoft Entra ID oder AAD-ID bezeichnet) als Bezeichner für die Identität. Die MAM SDK-APIs geben die OID-Zeichenfolge als Identität zurück und erfordern den OID-Zeichenfolgenparameter für die Identität. Einige Methoden können auch eine UPN-Zeichenfolge annehmen oder zurückgeben. In diesem Fall dient der UPN nur zu Informationszwecken.

Bei Identitätsparametern wird die Groß-/Kleinschreibung nicht beachtet. Anforderungen an das SDK für eine Identität geben möglicherweise nicht die gleiche Groß-/Kleinschreibung zurück, die beim Registrieren oder Festlegen der Identität verwendet wurde.

Achtung

Für Apps, die veraltete Methoden verwenden, die eine UPN-Zeichenfolge annehmen oder zurückgeben, müssen Apps sicherstellen, dass die an verschiedene API-Aufrufe übergebene Identitäts-UPN-Zeichenfolge konsistent ist. Das Übergeben inkonsistenter UPN-Zeichenfolgen kann zu Datenlecks führen.

Verwaltete und nicht verwaltete Identitäten

Wie unter Registrieren für App-Schutzrichtlinie beschrieben, ist Ihre Anwendung dafür verantwortlich, das SDK zu informieren, wenn sich ein Benutzer anmeldet. Zum Zeitpunkt der Anmeldung kann für das Konto des Benutzers eine App-Schutzrichtlinie gelten. Wenn für das Konto eine App-Schutzrichtlinie gilt, wird es vom SDK als verwaltet betrachtet. andernfalls ist es nicht verwaltet.

Das SDK erzwingt die Richtlinie für Identitäten, die es als verwaltet betrachtet. Das SDK erzwingt keine Richtlinie für Identitäten, die es als nicht verwaltet betrachtet.

Derzeit unterstützt das Intune App SDK nur eine einzelne verwaltete Identität pro Gerät. Sobald eine sdk-integrierte Anwendung eine verwaltete Identität registriert, werden alle anschließend registrierten Identitäten als nicht verwaltet behandelt, auch wenn sie derzeit app-Schutzrichtlinien verwenden.

Wenn bereits eine verwaltete Identität auf dem Gerät registriert wurde und Ihre App eine andere Identität registriert, für die auch eine App-Schutzrichtlinie gilt, gibt das SDK zurück MAMEnrollmentManager.Result.WRONG_USER und fordert den Endbenutzer mit Optionen zur Behebung auf. Weitere Informationen finden Sie unter Registrieren für Benachrichtigungen aus dem SDK .

Hinweis

Ein Konto, für das zum Zeitpunkt der Registrierung keine App-Schutzrichtlinie gilt, wird als nicht verwaltet betrachtet. Selbst wenn das Konto nicht für app-schutzrichtlinie lizenziert oder als Ziel verwendet wird, überprüft das SDK regelmäßig, ob dieses Konto zu einem späteren Zeitpunkt lizenziert und als Ziel verwendet wird. Wenn keine andere verwaltete Identität registriert wurde, beginnt das SDK, diese Identität als verwaltet zu behandeln, sobald sie als Ziel für die Richtlinie gilt. Der Benutzer muss sich nicht abmelden und wieder bei diesem Konto anmelden, um diese Änderung vorzunehmen.

Die aktive Identität

Ihre Anwendung muss das SDK immer über die Identität informieren, die aktuell verwendet wird( auch als aktive Identität bezeichnet). Wenn die aktive Identität verwaltet wird, wendet das SDK Schutzmaßnahmen an. Wenn die aktive Identität nicht verwaltet wird, wendet das SDK keinen Schutz an.

Da das SDK über keine anwendungsspezifischen Kenntnisse verfügt, muss es der Anwendung vertrauen, um die richtige aktive Identität zu teilen.

• Wenn die Anwendung dem SDK fälschlicherweise mitteilt, dass eine nicht verwaltete Identität aktiv ist, wenn die verwaltete Identität tatsächlich verwendet wird, wendet das SDK keinen Schutz an. Dies kann zu einem Datenleck führen, das die Daten der Benutzer gefährdet.

• Wenn die Anwendung dem SDK fälschlicherweise mitteilt, dass die verwaltete Identität aktiv ist, wenn eine nicht verwaltete Identität tatsächlich verwendet wird, wendet das SDK unangemessen Schutzmaßnahmen an. Dies ist kein Datenleck, aber dies kann nicht verwaltete Benutzer unnötig einschränken und die Daten nicht verwalteter Benutzer gefahrlos löschen.

Wenn Ihre Anwendung Benutzerdaten anzeigt, dürfen nur Daten angezeigt werden, die zur aktiven Identität gehören. Wenn Ihre Anwendung derzeit nicht weiß, wer besitzer der angezeigten Daten ist, müssen Sie Ihre Anwendung möglicherweise für ein besseres Identitätsbewusstsein umgestalten, bevor Sie mit der Integration der Unterstützung für mehrere Identitäten beginnen.

Organisieren von App-Daten nach Identität

Wenn Ihre Anwendung eine neue Datei schreibt, ordnet das SDK dieser Datei basierend auf dem aktuell aktiven Thread und der Prozessidentität eine Identität (auch als "Tags" bezeichnet) zu. Alternativ kann Ihre App das SDK direkt aufrufen, um eine Datei manuell mit einer bestimmten Identität zu markieren (weitere Informationen finden Sie unter Schreiben geschützter Dateien ). Das SDK verwendet diese markierte Dateiidentität sowohl für die Dateiverschlüsselung als auch für das selektive Zurücksetzen.

Wenn für die verwaltete Identität eine Verschlüsselungsrichtlinie gilt, werden nur Dateien verschlüsselt, die mit der verwalteten Identität gekennzeichnet sind.

Wenn eine Administratoraktion oder eine konfigurierte Richtlinie anfordert, dass verwaltete Daten zurückgesetzt werden, werden nur Dateien gelöscht, die mit der verwalteten Identität gekennzeichnet sind.

Das SDK kann einer einzelnen Datei nicht mehrere Identitäten zuordnen. Wenn Ihre App Daten, die mehreren Benutzern gehören, in derselben Datei speichert, führt das Standardverhalten des SDK dazu, dass diese Daten nicht oder übermäßig geschützt werden. Es wird dringend empfohlen, die Daten Ihrer App nach Identität zu organisieren.

Wenn Ihre App unbedingt Daten, die zu verschiedenen Identitäten gehören, in derselben Datei speichern muss, bietet das SDK Features zum Identitätstagging von Teilmengen von Daten innerhalb einer Datei. Weitere Informationen finden Sie unter Datenpufferschutz .

Implementieren mehrerer Identitäten

Um die Unterstützung für mehrere Identitäten für Ihre App zu deklarieren, platzieren Sie zunächst die folgenden Metadaten in AndroidManifest.xml.

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

Festlegen der aktiven Identität

Ihre Anwendung kann die aktive Identität auf den folgenden Ebenen in absteigender Priorität festlegen:

1. Threadebene
2. Context (in der Regel Activity) Niveau
3. Prozessebene

Eine Auf Threadebene festgelegte Identität ersetzt eine Auf der Ebene festgelegte Identität, die Context eine auf Prozessebene festgelegte Identität ablöst.

Eine für eine Context festgelegte Identität wird nur in entsprechenden zugeordneten Szenarien verwendet. Datei-E/A-Vorgänge haben z. B. keine zugeordnete Context. In den meisten Fällen legen Apps die Context Identität auf einem fest Activity. Erwägen Sie, die Context Identität in Activity.onCreatefestzulegen. Eine App darf keine Daten für eine Identität anzeigen, es sei denn, die Activity Identität ist auf dieselbe Identität festgelegt.

Im Allgemeinen ist die Identität auf Prozessebene nur nützlich, wenn die App nur mit einer einzelnen Identität gleichzeitig in allen Threads funktioniert. Dies ist kein typisches Verhalten für Apps, die mehrere Konten unterstützen. Es wird dringend empfohlen, Kontodaten zu trennen und die aktive Identität im Thread oder Context auf den Ebenen festzulegen.

Wenn Ihre App den Kontext zum Abrufen von Application Systemdiensten verwendet, stellen Sie sicher, dass die Thread- oder Prozessidentität festgelegt wurde oder dass Sie die Benutzeroberflächenidentität im Kontext Ihrer App Application festgelegt haben.

Wenn Ihre App einen Service Kontext verwendet, um Absichten zu starten, Inhaltskonfliktlöser zu verwenden oder andere Systemdienste zu nutzen, stellen Sie sicher, dass Sie die Identität im Service Kontext festlegen. Wenn Ihre App einen JobService Kontext verwendet, um diese Aktionen auszuführen, achten Sie auf ähnliche Weise darauf, dass Sie die Identität JobService im Kontext oder Thread festlegen, wie dies für Ihre JobService Implementierung erforderlich ist. Wenn Ihre JobService Aufträge beispielsweise für eine einzelne Identität verarbeitet, sollten Sie die Identität im JobService Kontext festlegen. Wenn Sie JobService Aufträge für mehrere Identitäten verarbeiten, sollten Sie die Identität auf Threadebene festlegen.

Achtung

Apps, die verwenden WorkManager , sollten beim Festlegen der Identität besonders vorsichtig sein. Insbesondere sollten diese Apps vermeiden, eine Identität für die festzulegen, die ContextWorker im Konstruktor übergeben wird. Diese Context instance kann von mehreren Worker Instanzen gleichzeitig gemeinsam verwendet werden. Um undefiniertes Verhalten zu vermeiden, sollten Apps stattdessen eine Threadidentität in Worker.doWork() festlegen, wie dies für die Worker Implementierung erforderlich ist.

Hinweis

Da für CLIPBOARD_SERVICE Benutzeroberflächenvorgänge verwendet wird, verwendet das SDK die Benutzeroberflächenidentität der Vordergrundaktivität für ClipboardManager Vorgänge.

Die folgenden Methoden in MAMPolicyManager können verwendet werden, um die aktive Identität festzulegen und die zuvor festgelegten Identitätswerte abzurufen.

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);

Der Einfachheit halber können Sie die Identität einer Aktivität auch direkt über eine Methode in MAMActivity festlegen, anstatt aufzurufen MAMPolicyManager.setUIPolicyIdentityOID. Verwenden Sie dazu die folgende Methode:

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

Hinweis

Wenn Ihre App im Manifest keine Unterstützung für mehrere Identitäten deklariert hat, führt das Aufrufen dieser Methoden zum Festlegen der Identität keine Aktion aus. Wenn sie eine MAMIdentitySwitchResultzurückgeben, wird immer zurückgegeben FAILED.

Häufige Fallstricke bei Identitätswechseln

• Bei Aufrufen von startActivitygeht das Intune App SDK davon aus, dass die aktive Identität auf der Context Ebene dem bereitgestellten Intent Parameter zugeordnet ist. Es wird dringend empfohlen, die Context Ebenenidentität mit einem Kontext von Activityfestzulegen, nicht mit dem Kontext von Application.

• Das Festlegen der Context Identität während der -Methode einer Aktivität onCreate wird empfohlen. Achten Sie jedoch darauf, dass Sie auch andere Einstiegspunkte wie abdecken onNewIntent. Wenn dieselbe Aktivität wiederverwendet wird, um Daten sowohl für verwaltete als auch für nicht verwaltete Identitäten anzuzeigen, wird die Richtlinie möglicherweise fälschlicherweise angewendet, was entweder zu ungeschützten Unternehmensdaten oder zu unzulässig eingeschränkten personenbezogenen Daten führt.

Ergebnisse des Identitätswechsels

Alle Methoden, die zum Festlegen der Identität verwendet werden, melden Ergebniswerte über MAMIdentitySwitchResult zurück. Es gibt vier Werte, die zurückgegeben werden können:

Rückgabewert	Szenario
SUCCEEDED	Die Identitätsänderung war erfolgreich.
NOT_ALLOWED	Die Identitätsänderung ist nicht zulässig. Dies tritt auf, wenn versucht wird, die Benutzeroberflächenidentität (Context) festzulegen, wenn im aktuellen Thread eine andere Identität festgelegt wird.
CANCELLED	Der Benutzer hat die Identitätsänderung in der Regel durch Drücken der Zurück-Taste an einer PIN oder Authentifizierungsaufforderung abgebrochen.
FAILED	Die Identitätsänderung ist aus einem nicht angegebenen Grund fehlgeschlagen.

Die App sollte überprüfen, ob MAMIdentitySwitchResult ist SUCCEEDED , bevor die Daten eines verwalteten Kontos angezeigt oder verwendet werden.

Die meisten Methoden zum Festlegen der aktiven Identität geben MAMIdentitySwitchResult synchron zurück. Beim Festlegen einer Context Identität über setUIPolicyIdentityOID wird das Ergebnis asynchron gemeldet. Die App kann ein MAMSetUIIdentityCallback implementieren, um dieses Ergebnis zu empfangen, oder null für das Rückrufobjekt übergeben. Wenn ein Aufruf von setUIPolicyIdentityOID erfolgt, während das Ergebnis eines vorherigen Aufrufs setUIPolicyIdentityOID von auf demselben Context noch nicht übermittelt wurde, ersetzt der neue Rückruf den alten Rückruf, und der ursprüngliche Rückruf erhält nie ein Ergebnis.

Achtung

Wenn die Context für setUIPolicyIdentityOID bereitgestellte ein Activityist, weiß das SDK erst nach der Ausführung der vom Administrator konfigurierten bedingten Startprüfungen, ob die Identitätsänderung erfolgreich war. Dies erfordert möglicherweise, dass der Benutzer eine PIN oder Unternehmensanmeldeinformationen eingibt.

Derzeit sind Prozess- und Threadidentitätswechsel für eine Multi-Identity-fähige App immer erfolgreich. Das SDK behält sich das Recht vor, in Zukunft Fehlerbedingungen hinzuzufügen.

Der Benutzeroberflächenidentitätsschalter schlägt möglicherweise bei ungültigen Argumenten fehl, wenn er mit der Threadidentität in Konflikt steht oder wenn der Benutzer die Anforderungen für bedingten Start abbricht (z. B. die Schaltfläche "Zurück" auf dem PIN-Bildschirm drückt).

Das Standardverhalten für einen fehlerhaften Benutzeroberflächenidentitätsschalter für eine Aktivität besteht darin, die Aktivität zu beenden. Um dieses Verhalten zu ändern und Benachrichtigungen über Identitätsänderungsversuche für eine Aktivität zu erhalten, können Sie eine -Methode in MAMActivityüberschreiben.

    public void onSwitchMAMIdentityComplete(final MAMIdentitySwitchResult result);

Wenn Sie überschreiben onSwitchMAMIdentityComplete (oder die super -Methode aufrufen), müssen Sie sicherstellen, dass die Daten eines verwalteten Kontos nach einem fehlerhaften Identitätswechsel nicht angezeigt werden.

Hinweis

Um die Identität zu ändern, muss die Aktivität möglicherweise neu erstellen. In diesem Fall wird der onSwitchMAMIdentityComplete Rückruf an den neuen instance der Aktivität übermittelt.

Identity, Intents und IdentitySwitchOptions

Zusätzlich zur automatischen Kennzeichnung neuer Dateien mit der aktiven Identität markiert das SDK auch Absichten mit der aktiven Identität. Standardmäßig überprüft das SDK die Identität für eine eingehende Absicht und vergleicht sie mit der aktiven Identität. Wenn diese Identitäten nicht übereinstimmen, fordert das SDK in der Regel(*) einen Identitätswechsel an (weitere Details finden Sie weiter unten unter Implizite Identitätsänderungen ).

Das SDK speichert auch diese eingehende Absichtsidentität zur späteren Verwendung. Wenn die App die Benutzeroberflächenidentität explizit ändert, vergleicht das SDK die Identität, zu der die App zu wechseln versucht, mit der zuletzt eingehenden Absichtsidentität. Wenn diese Identitäten nicht übereinstimmen, schlägt das SDK in der Regel(*) den Identitätswechsel fehl.

Das SDK führt diese Überprüfung aus, da es davon ausgeht, dass die App weiterhin Inhalte aus der Absicht anzeigt, die zur Identität gehört, die für die Absicht gekennzeichnet ist. Diese Annahme schützt davor, dass die App den Schutz bei der Anzeige verwalteter Daten unbeabsichtigt deaktiviert. Diese Annahme stimmt jedoch möglicherweise nicht mit dem tatsächlichen Verhalten der App.

Die optionalen IdentitySwitchOption-Enumerationen können an die APIs setUIPolicyIdentityOID und switchMAMIdentityOID übergeben werden, um das Standardverhalten des SDK zu ändern.

• IGNORE_INTENT: Beim Anfordern eines Identitätswechsels auf der Ui-Ebene informiert diese Option das SDK, den Vergleich des angeforderten Identitätsparameters mit der zuletzt gespeicherten Absichtsidentität zu überspringen. Dies ist nützlich, wenn Ihre App keine Inhalte mehr anzeigt, die zu dieser Identität gehören, und das SDK diesen Identitätswechsel nicht blockieren sollte. Zum Beispiel:

  1. Ihre App ist ein Dokument-Viewer. Es kann Dokumente rendern, die von anderen Apps übergeben wurden. Es enthält auch ein Feature, mit dem Benutzer Konten wechseln können. Wenn der Benutzer dieses Kontowechselfeature verwendet, navigiert die App zu einer kontospezifischen Landing Page mit den aktuellen Dokumenten dieses Kontos.
  2. Ihre App empfängt die Absicht, ein Dokument anzuzeigen. Diese Absicht ist mit der verwalteten Identität gekennzeichnet.
  3. Ihre App wird auf die verwaltete Identität umgestellt und zeigt dieses Dokument mit ordnungsgemäß angewendeten Schutzmaßnahmen an.
  4. Der Benutzer verwendet den Kontowechsel, um zu seiner persönliches Konto zu wechseln.

  Ihre App muss die Benutzeroberflächenidentität in Schritt 4 ändern. Da das Verhalten der App in diesem Fall darin besteht, von den Daten des verwalteten Kontos wegzu navigieren (das Dokument in der Absicht), sollte sie im Identitätswechselaufruf verwendet werden IGNORE_INTENT . Dadurch wird verhindert, dass das SDK diesen Aufruf unangemessen fehlschlägt.

• DATA_FROM_INTENT: Beim Anfordern eines Identitätswechsels auf der Ui-Ebene informiert diese Option das SDK darüber, dass Daten aus der zuletzt gespeicherten Absichtsidentität weiterhin angezeigt werden, nachdem der Identitätswechsel erfolgreich war. Daher wertet das SDK die Empfangsrichtlinie vollständig anhand der vorherigen Absichtsidentität aus, um zu bestimmen, ob sie angezeigt werden darf. Zum Beispiel:

  1. Ihre App ist ein Dokument-Viewer. Es kann Dokumente rendern, die von anderen Apps übergeben wurden. Es enthält auch ein Feature, mit dem Benutzer Konten wechseln können. Im Gegensatz zum vorherigen Beispiel navigiert die App immer dann, wenn der Benutzer dieses Kontowechselfeature verwendet, zu einer freigegebenen Seite, auf der zuletzt verwendete Dokumente für alle Konten angezeigt werden.
  2. Ihre App empfängt die Absicht, ein Dokument anzuzeigen. Diese Absicht ist mit der verwalteten Identität gekennzeichnet.
  3. Ihre App wird auf die verwaltete Identität umgestellt und zeigt dieses Dokument mit ordnungsgemäß angewendeten Schutzmaßnahmen an.
  4. Der Benutzer verwendet den Kontowechsel, um zu seiner persönliches Konto zu wechseln.

  Ihre App muss die Benutzeroberflächenidentität in Schritt 4 ändern. Da das Verhalten der App in diesem Fall darin besteht, weiterhin die Daten der verwalteten Identität anzuzeigen (eine Vorschau des Dokuments in der Absicht), sollte sie im Identitätswechselaufruf verwendet werden DATA_FROM_INTENT . Dadurch wird das SDK informiert, die konfigurierte App-Schutzrichtlinie zu überprüfen, um zu ermitteln, ob die Daten weiterhin angezeigt werden können.

(*) Das Standardverhalten des SDK umfasst eine spezielle Groß-/Kleinschreibung, die diese Dateneingangsprüfung überspringt, wenn z. B. die Absicht aus derselben App oder aus dem Systemstarter stammt.

Löschen der aktiven Identität

Ihre Anwendung kann szenarien aufweisen, die kontounabhängig sind. Ihre Anwendung verfügt möglicherweise auch über Szenarien für lokale nicht verwaltete Szenarien, für die keine Anmeldung erforderlich ist. In beiden Fällen möchte Ihre App möglicherweise nicht, dass das SDK die Richtlinien der verwalteten Identität erzwingt, aber Möglicherweise verfügen Sie nicht über eine explizite Identität, zu der Sie wechseln können.

Sie können die aktive Identität löschen, indem Sie eine der festgelegten Identitätsmethoden aufrufen, wobei der OID-Parameter der Identität auf festgelegt ist null. Das Löschen der Identität auf einer Ebene führt dazu, dass das SDK auf anderen Ebenen basierend auf der Rangfolge nach der aktiven Identität sucht.

Alternativ können Sie eine leere Zeichenfolge als Identitäts-OID-Parameter übergeben, der die Identität auf einen speziellen leeren Wert festlegt, der als nicht verwaltete Identität behandelt wird. Das Festlegen der aktiven Identität auf eine leere Zeichenfolge weist das SDK an, keine App-Schutzrichtlinie zu erzwingen.

Implizite Identitätsänderungen

Im obigen Abschnitt werden die verschiedenen Möglichkeiten beschrieben, wie Ihre App die aktive Identität explizit auf Thread-, Kontext- und Prozessebene festlegen kann. Die aktive Identität in Ihrer App kann sich jedoch auch ändern, ohne dass Ihre App eine dieser Methoden aufruft. In diesem Abschnitt wird beschrieben, wie Ihre App auf diese impliziten Identitätsänderungen lauschen und darauf reagieren kann.

Das Lauschen auf diese impliziten Identitätsänderungen ist optional, wird jedoch empfohlen. Das SDK ändert die aktive Identität nie, ohne diese impliziten Benachrichtigungen zur Identitätsänderung bereitzustellen.

Achtung

Wenn Ihre App sich dafür entscheidet, nicht auf implizite Identitätsänderungen zu lauschen, achten Sie besonders darauf, nicht die aktive Identität anzunehmen. Verwenden Sie im Zweifelsfall die getCurrentThreadIdentityOIDMethoden , getUIPolicyIdentityOIDund getProcessIdentityOID , um die aktive Identität zu bestätigen.

Quellen für implizite Identitätsänderungen

• Dateneingang aus anderen Intune verwalteten Apps kann die aktive Identität auf Thread- und Kontextebene ändern.

  • Wenn eine Aktivität von einer gestartet wird, die von einer Intent anderen MAM-App gesendet wurde, wird die Identität der Aktivität basierend auf der aktiven Identität in der anderen App zum Zeitpunkt des Sendens Intent festgelegt.

    • Beispielsweise wird eine Aktivität zum Anzeigen eines Word Dokuments von einer Absicht aus Microsoft Outlook gestartet, wenn ein Benutzer eine Dokumentanlage auswählt. Die Identität der Office-Dokumentanzeigeaktivität wird von Outlook auf die Identität umgestellt.

  • Für Dienste wird die Threadidentität auf ähnliche Weise für die Dauer eines onStart - oder onBind -Aufrufs festgelegt. Aufrufe an den Binder zurückgegebenen von onBind werden auch vorübergehend die Threadidentität festlegen.

  • Aufrufe in einem ContentProvider legen die Threadidentität auf ähnliche Weise für ihre Dauer fest.

• Die Benutzerinteraktion mit einer Aktivität kann die aktive Identität auf Kontextebene ändern. Zum Beispiel:

  • Ein Benutzer, der während Resume einer Autorisierungsaufforderung abbricht, führt zu einem impliziten Wechsel zu einer leeren Identität.

Behandeln impliziter Identitätsänderungen

Ihre App kann optional auf diese impliziten Identitätsänderungen lauschen und darauf reagieren. Ihre Anwendung kann z. B. mehrere Schritte erfordern, bevor ein hinzugefügtes Konto verwendet werden kann, z. B. eine E-Mail-App, die einen neuen Posteingang einsetzt. Wenn ein Identitätsversuch zur Identität dieses unvollständigen Kontos wechselt, kann der Handler Ihrer App den Benutzer zur Kontoeinrichtungsaktivität umleiten, bevor der Identitätswechsel akzeptiert wird. Alternativ kann der Handler Ihrer App ein Fehlerdialogfeld anzeigen und den Identitätswechsel blockieren.

Ihre App kann die MAMIdentityRequirementListener-Schnittstelle für oder ServiceContextProvider für Identitätsänderungen implementieren, die auf diesen Thread angewendet werden. Ihre Implementierung muss Folgendes außer Kraft setzen:

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

Ihre App kann die MAMActivityIdentityRequirementListener-Schnittstelle für für Activity Identitätsänderungen implementieren, die auf diese Aktivität angewendet werden. Ihre Implementierung muss Folgendes außer Kraft setzen:

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

Der AppIdentitySwitchReason enum-Parameter beschreibt die Quelle des impliziten Identitätsschalters.

Enumerationswert	Standard-SDK-Verhalten	Beschreibung
CREATE	Lassen Sie den Identitätswechsel zu.	Der Identitätswechsel erfolgt aufgrund einer Aktivitätserstellung.
NEW_INTENT	Lassen Sie den Identitätswechsel zu.	Der Identitätswechsel tritt auf, weil einer Aktivität eine neue Absicht zugewiesen wird.
RESUME_CANCELLED	Blockieren Sie den Identitätswechsel.	Der Identitätswechsel tritt auf, weil eine Fortsetzung abgebrochen wurde. Dies ist am häufigsten der Fall, wenn der Endbenutzer die Zurück-Schaltfläche auf der PIN, der Authentifizierung oder der Compliance-Benutzeroberfläche drückt.

Mit dem Parameter AppIdentitySwitchResultCallback können Entwickler das Standardverhalten für den Identitätsswitch außer Kraft setzen:

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

onMAMIdentitySwitchRequired wird für alle impliziten Identitätsänderungen mit Ausnahme der änderungen aufgerufen, die über einen von MAMService.onMAMBindzurückgegebenen Binder vorgenommen werden. Die Standardimplementierungen von onMAMIdentitySwitchRequired rufen sofort Auf:

• callback.reportIdentitySwitchResult(FAILURE) , wenn der Grund ist RESUME_CANCELLED.

• callback.reportIdentitySwitchResult(SUCCESS) in allen anderen Fällen.

Es wird nicht erwartet, dass die meisten Apps einen Identitätswechsel auf andere Weise blockieren oder verzögern müssen, aber wenn eine App dies tun muss, müssen die folgenden Punkte berücksichtigt werden:

• Wenn ein Identitätswechsel blockiert wird, entspricht das Verhalten des Endbenutzers dem, wenn die App-Schutzeinstellung "Daten von anderen Apps empfangen" des SDK den Dateneingang untersagt hätte.

• Wenn ein Dienst im Standard Thread ausgeführt wird, reportIdentitySwitchResultmuss synchron aufgerufen werden, oder der UI-Thread reagiert nicht mehr.

• Für Activity die Erstellung wird onMAMIdentitySwitchRequired vor onMAMCreateaufgerufen. Wenn die App die Benutzeroberfläche anzeigen muss, um zu bestimmen, ob der Identitätswechsel zugelassen werden soll, muss diese Benutzeroberfläche mit einer anderen Aktivität angezeigt werden.

• Wenn in einem Activityein Wechsel zur leeren Identität mit dem Grund RESUME_CANCELLEDals angefordert wird, muss die App die fortgesetzte Aktivität so ändern, dass Daten angezeigt werden, die mit diesem Identitätswechsel konsistent sind. Wenn dies nicht möglich ist, sollte die App den Wechsel ablehnen, und der Benutzer wird erneut aufgefordert, die Richtlinie für die fortsetzbare Identität einzuhalten (z. B. indem der Pin-Eingabebildschirm der App angezeigt wird).

Achtung

Eine App mit mehreren Identitäten kann eingehende Daten sowohl von verwalteten als auch von nicht verwalteten Apps empfangen. Es liegt in der Verantwortung der App, Daten von verwalteten Identitäten auf verwaltete Weise zu behandeln.

Wenn eine angeforderte Identität verwaltet wird (verwenden Sie MAMPolicyManager.getIsIdentityOIDManaged zur Überprüfung), die App dieses Konto aber nicht verwenden kann (z. B. weil Konten, z. B. E-Mail-Konten, zuerst in der App eingerichtet werden müssen), sollte der Identitätswechsel abgelehnt werden.

Auf das Standardverhalten für MAMActivity.onMAMIdentitySwitchRequired kann durch Aufrufen der statischen Methode MAMActivity.defaultOnMAMIdentitySwitchRequired(activity, upn, oid, reason, callback)zugegriffen werden.

Wenn Sie überschreiben MAMActivity.onSwitchMAMIdentityCompletemüssen, können Sie auch implementieren MAMActivityIdentitySwitchListener , ohne explizit von MAMActivityzu erben.

Identitätswechsel und Screenshoteinschränkungen

Das Intune App SDK verwendet das FlagFLAG_SECURE, um die Window Screenshotrichtlinie zu erzwingen. Einige Apps können auch für ihre eigenen Zwecke festgelegt FLAG_SECURE werden. Wenn die App-Schutzrichtlinie Screenshots nicht einschränkt, ändert FLAG_SECUREdas SDK nicht .

Bei einem Identitätswechsel von einer Identität, deren Richtlinie die Deaktivierung von Screenshots erfordert, zu einer Identität, deren Richtlinie dies nicht tut, löscht FLAG_SECUREdas SDK . Daher sollte Ihre App nicht darauf angewiesen FLAG_SECURE sein, nach einem Identitätswechsel festgelegt zu bleiben.

Beibehalten der Identität in asynchronen Vorgängen

Apps senden häufig Hintergrundaufgaben aus dem UI-Thread, um Vorgänge für andere Threads zu verarbeiten. Eine App mit mehreren Identitäten muss sicherstellen, dass diese Hintergrundaufgaben mit der entsprechenden Identität arbeiten. Dies ist häufig dieselbe Identität, die von der Aktivität verwendet wird, die sie verteilt hat.

Das Intune App SDK stellt MAMAsyncTask und MAMIdentityExecutors bereit, um die Beibehaltung der Identität in asynchronen Vorgängen zu unterstützen. Ihre App muss entweder diese verwenden (oder explizit die Threadidentität für die Aufgaben festlegen), wenn ihre asynchronen Vorgänge Folgendes ermöglichen:

• Schreiben von Daten, die zu einer verwalteten Identität gehören, in eine Datei
• Kommunizieren mit anderen Apps

MAMAsyncTask

Um zu verwenden MAMAsyncTask, erben Sie einfach davon anstelle von AsyncTask und ersetzen Sie Außerkraftsetzungen von doInBackground und onPreExecutedoInBackgroundMAM durch bzw onPreExecuteMAM . . Der MAMAsyncTask Konstruktor akzeptiert einen Aktivitätskontext. Zum Beispiel:

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 wird die aktive Identität basierend auf der normalen Rangfolge angenommen.

MAMIdentityExecutors

MAMIdentityExecutorsermöglicht das Umschließen eines vorhandenen Executor oder instance als identitätserhaltendeExecutorService/Executor mit wrapExecutor - und wrapExecutorService -Methoden.ExecutorService Beispiel:

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

MAMIdentityExecutors wird die aktive Identität basierend auf der normalen Rangfolge angenommen.

Dateischutz

Schreiben geschützter Dateien

Wie oben in Organisieren von App-Daten nach Identität erwähnt, ordnet das Intune App SDK die aktive Identität (aus der Thread-/Prozessebene) Dateien zu, während sie geschrieben werden. Es ist wichtig, die richtige Identität zum Zeitpunkt der Dateierstellung festzulegen, um eine ordnungsgemäße Verschlüsselung und selektive Zurücksetzungsfunktionalität sicherzustellen.

Ihre App kann die Identität einer Datei mithilfe der MAMFileProtectionManager-Klasse abfragen oder ändern, insbesondere MAMFileProtectionManager.getProtectionInfo zum Abfragen und MAMFileProtectionManager.protectForOID zum Ändern.

Die protectForOID -Methode kann auch zum Schützen von Verzeichnissen verwendet werden. Der Verzeichnisschutz wird rekursiv auf alle Dateien und Unterverzeichnisse angewendet, die im Verzeichnis enthalten sind. Wenn ein Verzeichnis geschützt ist, wird für alle neuen Dateien, die im Verzeichnis erstellt werden, automatisch derselbe Schutz angewendet. Da der Verzeichnisschutz rekursiv angewendet wird, kann der protectForOID Aufruf bei großen Verzeichnissen einige Zeit in Anspruch nehmen. Aus diesem Grund möchten Apps, die Schutz auf ein Verzeichnis anwenden, das eine große Anzahl von Dateien enthält, möglicherweise asynchron in einem Hintergrundthread ausgeführt werden protectForOID .

Wenn Sie protectForOID mit einer leeren Zeichenfolge für den Identity-Parameter aufrufen, wird die Datei/das Verzeichnis mit der nicht verwalteten Identität gekennzeichnet. Dieser Vorgang entfernt die Verschlüsselung aus der Datei/dem Verzeichnis, wenn sie zuvor verschlüsselt wurde. Wenn ein Befehl zum selektiven Zurücksetzen ausgegeben wird, wird die Datei/das Verzeichnis nicht gelöscht.

Warnung

Es ist wichtig sicherzustellen, dass nur Dateien, die zu einer bestimmten Identität gehören, mit dieser Identität geschützt werden. Andernfalls kann es bei anderen Identitäten zu Datenverlusten kommen, wenn sich die besitzende Identität abmeldet, da Dateien zurückgesetzt werden und der Verschlüsselungsschlüsselzugriff verloren geht.

Anzeigen von geschützten Dateiinhalten

Ebenso wichtig ist es, die richtige Identität festzulegen, wenn Dateiinhalte angezeigt werden, um zu verhindern, dass nicht autorisierte Benutzer verwaltete Daten anzeigen. Das SDK kann nicht automatisch eine Beziehung zwischen dateien ableiten, die gelesen werden, und Daten, die in einem Activityangezeigt werden. Apps müssen die Benutzeroberflächenidentität entsprechend festlegen, bevor verwaltete Daten angezeigt werden. Dies schließt Daten ein, die aus Dateien gelesen werden.

Wenn eine Datei von außerhalb der App stammt (entweder von einem oder von einem ContentProvider öffentlich beschreibbaren Speicherort gelesen), muss die App versuchen, die Dateiidentität zu ermitteln (mit der richtigen MAMFileProtectionManager.getProtectionInfo-Überladung für die Datenquelle), bevor aus der Datei gelesene Informationen angezeigt werden.

Wenn getProtectionInfo eine Nicht-NULL-Identität meldet, muss die App die Benutzeroberflächenidentität so festlegen, dass sie mit MAMActivity.switchMAMIdentityOID oder MAMPolicyManager.setUIPolicyIdentityOID übereinstimmt. Wenn der Identitätswechsel fehlschlägt, dürfen daten aus der Datei nicht angezeigt werden.

Beim Lesen aus einem Inhalts-URI kann es erforderlich sein, zuerst die Identität zu lesen (über die getProtectionInfo Überladung, die eine Uriverwendet), und dann den Kontext oder die Threadidentität entsprechend festzulegen. Dies muss vor dem Öffnen eines Dateideskriptors oder Eingabestreams ContentResolverim erfolgen. Andernfalls schlägt der Vorgang möglicherweise fehl.

Ein Beispielflow könnte in etwa wie folgt aussehen:

• Der Benutzer wählt ein Dokument aus, das in der App geöffnet werden soll.

• Während des geöffneten Flows bestätigt die App vor dem Lesen von Daten vom Datenträger die Identität, die zum Anzeigen des Inhalts verwendet werden soll:

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

• Die App wartet, bis ein Ergebnis an den Rückruf gemeldet wird.

• Wenn das gemeldete Ergebnis ein Fehler ist, zeigt die App das Dokument nicht an.

• Die App wird geöffnet und rendert die Datei.

Wenn eine App Android DownloadManager zum Herunterladen von Dateien verwendet, versucht das SDK, diese Dateien automatisch mithilfe der zuvor beschriebenen Identitätspriorität zu schützen. Der zum Abrufen von DownloadManager verwendete Kontext wird verwendet, wenn die Threadidentität nicht festgelegt ist. Wenn die heruntergeladenen Dateien Unternehmensdaten enthalten, liegt es in der Verantwortung der App , protectForOID aufzurufen, wenn die Dateien nach dem Download verschoben oder neu erstellt werden.

übergang von Single-Identity zu mehreren Identitäten

Wenn eine App, die zuvor mit einer einzelnen Identität Intune Integration veröffentlicht wurde, später mehrere Identitäten integriert, werden zuvor installierte Apps einen Übergang erfahren. Dieser Übergang ist für den Benutzer nicht sichtbar.

Die App ist für diesen Übergang nicht erforderlich . Alle Dateien, die vor dem Übergang erstellt wurden, werden weiterhin als verwaltet betrachtet (sodass sie verschlüsselt bleiben, wenn die Verschlüsselungsrichtlinie aktiviert ist).

Wenn Sie nicht möchten, dass der verwalteten Identität alle vorherigen App-Daten zugeordnet werden, können Sie diesen Übergang erkennen und den Schutz explizit entfernen.

• Ermitteln Sie das Upgrade, indem Sie die Version Ihrer App mit einer bekannten Version vergleichen, in der Unterstützung für mehrere Identitäten hinzugefügt wurde.
• Rufen Sie protectForOID mit einer leeren Zeichenfolge für den Identitätsparameter für Dateien oder Verzeichnisse auf, die der verwalteten Identität nicht zugeordnet werden sollen.

Offlineszenarien

Das Intune App SDK wird im Offlinemodus ausgeführt, wenn die Unternehmensportal App nicht installiert ist. Das Tagging der Dateiidentität ist für den Offlinemodus empfindlich:

• Wenn die Unternehmensportal nicht installiert ist, können Dateien nicht mit identitätsbasierten Tags versehen werden. Das Aufrufen von MAMFileProtectionManager.protectForOID im Offlinemodus ist sicher, hat aber keine Auswirkungen.

• Wenn die Unternehmensportal installiert ist, die App aber nicht über eine App-Schutzrichtlinie verfügt, können Dateien nicht zuverlässig identitätsmarkiert werden.

• Wenn das Tagging der Dateiidentität verfügbar wird, werden alle zuvor erstellten Dateien als persönlich/nicht verwaltet (gehören zur identitätsleeren Zeichenfolge) behandelt, außer in Fällen, in denen die App zuvor als verwaltete App mit einer einzelnen Identität installiert wurde, wie unter Übergang von einzelidentität zu mehreren Identitäten beschrieben.

Um diese Fälle zu vermeiden, sollten Apps das Erstellen von Dateien mit Kontodaten vermeiden, bis die Kontoregistrierung erfolgreich abgeschlossen wurde. Wenn Ihre App unbedingt Dateien erstellen muss, während sie offline ist, kann sie MAMFileProtectionManager.protectForOID verwenden, um die zugeordnete Identität der Datei zu korrigieren, sobald das SDK online ist.

Schutz von Datenpuffern

Warnung

Das Schreiben von Daten, die zu mehreren Konten gehören, in einer einzigen Datei wird nicht empfohlen. Organisieren Sie nach Möglichkeit die Dateien Ihrer App nach Identität.

Der MAMDataProtectionManager des SDK stellt Methoden zum Überprüfen und Ändern der markierten Identität für bestimmte Datenpuffer im byte[] Format oder InputStream bereit.

MAMDataProtectionManager.protectForOID ermöglicht einer App das Zuordnen von Daten zu einer Identität und, wenn die Identität derzeit eine Verschlüsselungsrichtlinie umfasst, die Daten zu verschlüsseln. Diese verschlüsselten Daten eignen sich zum Speichern auf einem Datenträger in einer Datei.

MAMDataProtectionManager ermöglicht es Ihnen auch, die der Identität zugeordneten Daten abzufragen und sie wieder zu entschlüsseln.

Apps, die von MAMDataProtectionManager verwenden, sollten einen Empfänger für die MANAGEMENT_REMOVED Benachrichtigung implementieren. Weitere Informationen finden Sie unter Registrieren für Benachrichtigungen aus dem SDK .

Nach Abschluss dieser Benachrichtigung sind Puffer, die über diese Klasse geschützt wurden, nicht mehr lesbar (wenn die Dateiverschlüsselung aktiviert war, als die Puffer geschützt wurden). Eine App kann verhindern, dass diese Puffer unlesbar werden, indem sie bei der Verarbeitung der MANAGEMENT_REMOVED Benachrichtigung für alle Puffer aufruftMAMDataProtectionManager.unprotect. Es ist auch sicher, während dieser Benachrichtigung aufzurufen protectForOID , wenn Sie Identitätsinformationen beibehalten möchten. Die Verschlüsselung wird während der Benachrichtigung garantiert deaktiviert, und das Aufrufen protectForOID im Handler verschlüsselt keine Datenpuffer.

Warnung

Verschlüsselungsvorgänge sollten frühzeitig im App-Prozess vermieden werden. Das SDK führt die Verschlüsselungsinitialisierung so früh wie möglich nach dem Start der App asynchron aus. Wenn eine App jedoch beim App-Start eine Verschlüsselungsanforderung sendet, wird sie möglicherweise blockiert, bis die Verschlüsselungsinitialisierung abgeschlossen ist.

Hinweis

Die Intune App SDK-Verschlüsselungs-API sollte nur verwendet werden, um Daten gemäß Intune Richtlinie zu verschlüsseln. Für Konten, für die keine Verschlüsselungsrichtlinie aktiviert ist, wird kein Schutz angewendet, sodass sie nicht als universelle Verschlüsselungsbibliothek verwendet werden kann.

Inhaltsanbieter

Eine App mit mehreren Identitäten muss auch Daten schützen, die über ContentProviders freigegeben werden, um die unangemessene Freigabe von verwalteten Inhalten zu verhindern.

Ihre App muss die statische MAMContentProvider-MethodeisProvideContentAllowedForOid(provider, oid) aufrufen, bevor Inhalt zurückgegeben wird. Wenn diese Funktion false zurückgibt, darf der Inhalt nicht an den Aufrufer zurückgegeben werden.

Der Aufruf isProvideContentAllowedForOid ist nicht erforderlich, wenn von ContentProvider zurückgegeben ParcelFileDescriptorwird. Dateideskriptoren, die über einen Inhaltsanbieter zurückgegeben werden, werden automatisch basierend auf der Dateiidentität behandelt.

Selektives Zurücksetzen

Standardmäßig verarbeitet das Intune App SDK automatisch selektive Zurücksetzungen und löscht alle Dateien, die der verwalteten Identität zugeordnet wurden. Anschließend schließt das SDK die App ordnungsgemäß, beendet Aktivitäten und beendet den App-Prozess.

Das SDK bietet die optionale Möglichkeit für Ihre App, das Standardzurücksetzungsverhalten zu ergänzen (empfohlen) oder außer Kraft zu setzen.

Der Standardzurücksetzungshandler des SDK verarbeitet keine Durch geschützten MAMDataProtectionManagerDatenpuffer. Wenn Ihre App dieses Feature verwendet hat, muss sie den Standardzurücksetzungshandler ergänzen oder überschreiben, um diese Daten zu entfernen.

Hinweis

Um das Standardzurücksetzungsverhalten zu ergänzen und zu überschreiben, müssen bestimmte SDK-Benachrichtigungen behandelt werden. Weitere Informationen zum Implementieren von Benachrichtigungshandlern finden Sie unter Registrieren für Benachrichtigungen aus dem SDK .

Ergänzung des standardmäßigen Zurücksetzungsverhaltens

Um das Standardverhalten der SDK-Zurücksetzung zu ergänzen, kann Ihre App für MAMNotificationTypeWIPE_USER_AUXILIARY_DATA registriert werden.

Diese Benachrichtigung wird vom SDK gesendet, bevor die standardmäßige selektive Zurücksetzung ausgeführt wird. Das SDK wartet auf den Abschluss des Benachrichtigungshandlers Ihrer App, bevor Daten gelöscht und die App beendet wird. Ihre App sollte Daten synchron löschen und erst dann zurückgeben, wenn alle Bereinigungen abgeschlossen sind.

Apps sollten dringend erwägen, das Standardzurücksetzungsverhalten durch WIPE_USER_AUXILIARY_DATAzu ergänzen, da app-spezifische Bereinigung für Apps mit mehreren Identitäten üblich ist.

Überschreiben des standardmäßigen Zurücksetzungsverhaltens

Um das Standardverhalten der SDK-Zurücksetzung außer Kraft zu setzen, kann Ihre App für MAMNotificationTypeWIPE_USER_DATA registriert werden.

Warnung

Eine App darf sich niemals für und WIPE_USER_DATAWIPE_USER_AUXILIARY_DATAregistrieren.

Das Überschreiben des standardmäßigen SDK-Zurücksetzungsverhaltens birgt ein erhebliches Risiko für Ihre App. Ihre App ist vollständig für das Entfernen aller Daten verantwortlich, die der verwalteten Identität zugeordnet sind, einschließlich aller Dateien und Datenpuffer, die für diese Identität gekennzeichnet wurden.

• Wenn die verwaltete Identität durch Verschlüsselung geschützt wurde und der benutzerdefinierte Zurücksetzungshandler Ihrer App nicht alle verwalteten Daten vollständig entfernt, bleiben alle verbleibenden verwalteten Dateien verschlüsselt. Auf diese Daten kann nicht mehr zugegriffen werden, und Ihre App verarbeitet den Versuch, verschlüsselte Daten ordnungsgemäß zu lesen.
• Der Zurücksetzungshandler Ihrer App kann zu Datenverlusten für nicht verwaltete Benutzer führen, wenn dateien entfernt werden, die nicht mit der verwalteten Identität gekennzeichnet sind.

Wenn der benutzerdefinierte Zurücksetzungshandler Ihrer App verwaltete Daten aus einer Datei entfernt, aber andere Daten in der Datei belassen möchte, muss die Identität der Datei (über MAMFileProtectionManager.protectForOID) in eine nicht verwaltete Identität oder eine leere Zeichenfolge geändert werden.

Der überschriebene Zurücksetzungshandler sollte Daten synchron löschen und erst zurückgeben, wenn alle Bereinigungen abgeschlossen sind.

Schließen Sie Ihre App nach Abschluss der Schritte für den benutzerdefinierten Zurücksetzungshandler manuell, um zu verhindern, dass der Benutzer nach einer Zurücksetzung auf In-Memory-Daten zugreifen kann.

Exitkriterien

Planen Sie, viel Zeit für die Überprüfung der Integration mehrerer Identitäten in Ihrer App aufwenden zu müssen. Bevor Sie mit dem Testen beginnen:

• Erstellen sie eine App-Schutzrichtlinie, und weisen Sie sie einem Konto zu. Dies ist Ihr testverwaltetes Konto.
• Erstellen Sie ein anderes Konto, weisen Sie die App-Schutzrichtlinie jedoch nicht zu. Dies ist Ihr nicht verwaltetes Testkonto. Wenn Ihre App mehrere Kontotypen über Microsoft Entra Konten hinaus unterstützt, können Sie alternativ ein vorhandenes Nicht-Entra-Konto als nicht verwaltetes Testkonto verwenden.
• Machen Sie sich damit vertraut, wie die Richtlinie in Ihrer App erzwungen wird. Bei Tests mit mehreren Identitäten müssen Sie leicht erkennen, wann Ihre App mit der erzwungenen Richtlinie funktioniert und nicht. Die Einstellung der App-Schutzrichtlinie zum Blockieren von Screenshots ist beim schnellen Testen der Richtlinienerzwingung wirksam.
• Berücksichtigen Sie die gesamte Benutzeroberfläche, die Ihre App bietet. Listet die Bildschirme auf, auf denen Kontodaten angezeigt werden. Zeigt Ihre App immer nur die Daten eines einzelnen Kontos gleichzeitig an, oder kann sie Daten anzeigen, die zu mehreren Konten gleichzeitig gehören?
• Betrachten Sie den gesamten Satz von Dateien, die Ihre App erstellt. Listet auf, welche dieser Dateien Daten enthalten, die zu einem Konto gehören, im Gegensatz zu Daten auf Systemebene.
  • Bestimmen Sie, wie Sie die Verschlüsselung für jede dieser Dateien überprüfen.
• Berücksichtigen Sie die gesamte Reihe von Möglichkeiten, wie Ihre App mit anderen Apps interagieren kann. Listet alle Eingangs- und Ausgangspunkte auf. Welche Arten von Daten kann Ihre App erfassen? Welche Absichten werden übertragen? Welche Inhaltsanbieter werden implementiert?
  • Bestimmen Sie, wie Sie die einzelnen Datenfreigabefeatures nutzen.
  • Bereiten Sie ein Testgerät vor, das sowohl über verwaltete als auch über nicht verwaltete Apps verfügt, die mit Ihrer App interagieren können.
• Überlegen Sie, wie Ihre App es dem Endbenutzer ermöglicht, mit allen angemeldeten Konten zu interagieren. Muss der Benutzer manuell zu einem Konto wechseln, bevor die Daten dieses Kontos angezeigt werden?

Nachdem Sie das aktuelle Verhalten Ihrer App gründlich bewertet haben, überprüfen Sie die Integration mit mehreren Identitäten, indem Sie die folgenden Tests ausführen. Beachten Sie, dass dies keine umfassende Liste ist und nicht garantiert, dass die Multiidentitätsimplementierung Ihrer App fehlerfrei ist.

Überprüfen von Anmelde- und Abmeldeszenarien

Ihre App mit mehreren Identitäten unterstützt bis zu einem verwalteten Konto und mehrere nicht verwaltete Konten. Diese Tests tragen dazu bei, sicherzustellen, dass ihre Integration mit mehreren Identitäten den Schutz nicht falsch ändert, wenn Sich Benutzer anmelden oder sich abmelden.

Installieren Sie für diese Tests Ihre App und die Intune-Unternehmensportal. Melden Sie sich nicht an, bevor Sie den Test starten.

Szenario	Schritte
Melden Sie sich zuerst bei der verwalteten Anmeldung an.	– Melden Sie sich zuerst mit einem verwalteten Konto an, und überprüfen Sie, ob die Daten des Kontos verwaltet werden. – Melden Sie sich mit einem nicht verwalteten Konto an, und überprüfen Sie, ob die Daten des Kontos nicht verwaltet werden.
Melden Sie sich zuerst nicht verwaltet an.	– Melden Sie sich zuerst mit einem nicht verwalteten Konto an, und überprüfen Sie, ob die Daten des Kontos nicht verwaltet werden. – Melden Sie sich mit einem verwalteten Konto an, und überprüfen Sie, ob die Daten des Kontos verwaltet werden.
Anmelden bei mehreren verwalteten	– Melden Sie sich zuerst mit einem verwalteten Konto an, und überprüfen Sie, ob die Daten des Kontos verwaltet werden. – Melden Sie sich mit einem zweiten verwalteten Konto an, und überprüfen Sie, ob die Anmeldung des Benutzers blockiert ist, ohne zuerst das ursprüngliche verwaltete Konto zu entfernen.
Abmelden verwaltet	– Melden Sie sich bei Ihrer App mit einem verwalteten und nicht verwalteten Konto an. – Melden Sie sich vom verwalteten Konto ab. – Vergewissern Sie sich, dass das verwaltete Konto aus Ihrer App entfernt und alle Daten dieses Kontos entfernt wurden. – Vergewissern Sie sich, dass das nicht verwaltete Konto weiterhin angemeldet ist, keine Daten des nicht verwalteten Kontos entfernt wurden und die Richtlinie immer noch nicht angewendet wird.
Nicht verwaltete Abmelden	– Melden Sie sich bei Ihrer App mit einem verwalteten und nicht verwalteten Konto an. – Melden Sie sich vom nicht verwalteten Konto ab. – Vergewissern Sie sich, dass das nicht verwaltete Konto aus Ihrer App entfernt und alle Daten dieses Kontos entfernt wurden. – Vergewissern Sie sich, dass das verwaltete Konto weiterhin angemeldet ist, dass keine Daten des nicht verwalteten Kontos entfernt wurden und die Richtlinie weiterhin angewendet wird.

Überprüfen der aktiven Identität und des App-Lebenszyklus

Ihre App mit mehreren Identitäten kann Ansichten mit den Daten eines einzelnen Kontos darstellen und es dem Benutzer ermöglichen, das aktuelle verwendete Konto explizit zu ändern. Es kann auch Ansichten mit Daten mehrerer Konten gleichzeitig darstellen. Diese Tests tragen dazu bei, dass Ihre Integration mit mehreren Identitäten den richtigen Schutz für die aktive Identität auf jeder Seite während des gesamten App-Lebenszyklus bietet.

Installieren Sie für diese Tests Ihre App und die Intune-Unternehmensportal. Melden Sie sich mit einem verwalteten und nicht verwalteten Konto an, bevor Sie den Test starten.

Szenario	Schritte
Einzelkontoansicht, verwaltet	– Wechseln Sie zum verwalteten Konto. – Navigieren Sie zu allen Seiten in Ihrer App, die die Daten eines einzelnen Kontos darstellen. – Vergewissern Sie sich, dass die Richtlinie auf jede Seite angewendet wird.
Einzelkontoansicht, nicht verwaltet	– Wechseln Sie zum nicht verwalteten Konto. – Navigieren Sie zu allen Seiten in Ihrer App, die die Daten eines einzelnen Kontos darstellen. – Vergewissern Sie sich, dass die Richtlinie auf keiner Seite angewendet wird.
Ansicht mit mehreren Konten	– Navigieren Sie zu allen Seiten in Ihrer App, auf denen die Daten mehrerer Konten gleichzeitig angezeigt werden. – Vergewissern Sie sich, dass die Richtlinie auf jede Seite angewendet wird.
Verwaltete Pause	– Auf einem Bildschirm, auf dem verwaltete Daten angezeigt werden und die Richtlinie aktiv ist, halten Sie die App an, indem Sie zum Startbildschirm des Geräts oder zu einer anderen App navigieren. – Setzen Sie die App fort. – Vergewissern Sie sich, dass die Richtlinie weiterhin angewendet wird.
Nicht verwaltete Pause	– Auf einem Bildschirm, auf dem nicht verwaltete Daten angezeigt werden und keine Richtlinie aktiv ist, halten Sie die App an, indem Sie zum Startbildschirm des Geräts oder einer anderen App navigieren. – Setzen Sie die App fort. – Vergewissern Sie sich, dass die Richtlinie nicht angewendet wird.
Verwalteter Kill	– Auf einem Bildschirm, auf dem verwaltete Daten angezeigt werden und die Richtlinie aktiv ist, erzwingen Sie die Beendigung der App. – Starten Sie die App neu. – Vergewissern Sie sich, dass die Richtlinie weiterhin angewendet wird, wenn die App auf einem Bildschirm mit den Daten des verwalteten Kontos (erwartet) fortgesetzt wird. Wenn die App auf einem Bildschirm mit den Daten des nicht verwalteten Kontos fortgesetzt wird, vergewissern Sie sich, dass die Richtlinie nicht angewendet wird.
Nicht verwalteter Kill	– Auf einem Bildschirm, auf dem nicht verwaltete Daten angezeigt werden und die Richtlinie aktiv ist, erzwingen Sie die Beendigung der App. – Starten Sie die App neu. – Vergewissern Sie sich, dass die Richtlinie nicht angewendet wird, wenn die App auf einem Bildschirm mit den Daten des nicht verwalteten Kontos (erwartet) fortgesetzt wird. Wenn die App auf einem Bildschirm mit den Daten des verwalteten Kontos fortgesetzt wird, vergewissern Sie sich, dass die Richtlinie weiterhin angewendet wird.
Identitätswechsel ad hoc	- Experimentieren Sie zwischen Konten wechseln und die App anhalten/fortsetzen/beenden/neu starten. – Vergewissern Sie sich, dass die Daten des verwalteten Kontos immer geschützt sind und die Daten des nicht verwalteten Kontos nie geschützt sind.

Überprüfen von Datenfreigabeszenarien

Ihre App mit mehreren Identitäten kann Daten an andere Apps senden und von diesen empfangen. Intune App-Schutzrichtlinien verfügen über Einstellungen, die dieses Verhalten vorschreiben. Diese Tests tragen dazu bei, dass ihre Integration mit mehreren Identitäten diese Datenfreigabeeinstellungen berücksichtigt.

Installieren Sie für diese Tests Ihre App und die Intune-Unternehmensportal. Melden Sie sich mit einem verwalteten und nicht verwalteten Konto an, bevor Sie den Test starten. Außerdem:

• Legen Sie die Richtlinie des verwalteten Kontos auf Folgendes fest:
  • "Senden von Organisationsdaten an andere Apps" an "Richtlinienverwaltete Apps".
  • "Empfangen von Daten von anderen Apps" in "Richtlinienverwaltete Apps".
• Installieren Sie andere Apps auf dem Testgerät:
  • Eine verwaltete App mit der gleichen Richtlinie wie Ihre App, die Daten (z. B. Microsoft Outlook) senden und empfangen kann.
  • Jede nicht verwaltete App, die Daten senden und empfangen kann.
• Melden Sie sich mit dem verwalteten Testkonto bei der anderen verwalteten App an. Selbst wenn die andere verwaltete App mehrere Identitäten aufweist, melden Sie sich nur mit dem verwalteten Konto an.

Wenn Ihre App daten an andere Apps senden kann, z. B. microsoft Outlook, das eine Dokumentanlage an Microsoft Office sendet:

Szenario	Schritte
Senden einer verwalteten Identität an nicht verwaltete App	– Wechseln Sie zum verwalteten Konto. – Navigieren Sie zu dem Ort, an den Ihre App Daten senden kann. – Versuch, Daten an eine nicht verwaltete App zu senden. – Das Senden von Daten an die nicht verwaltete App sollte blockiert werden.
An verwaltete App sendende verwaltete Identität	– Wechseln Sie zum verwalteten Konto. – Navigieren Sie zu dem Ort, an den Ihre App Daten senden kann. – Versuchen Sie, Daten an die andere verwaltete App zu senden, wobei das verwaltete Konto angemeldet ist. – Sie sollten daten an die verwaltete App senden dürfen.
Nicht verwaltete Identität, die an verwaltete App gesendet wird	– Wechseln Sie zum nicht verwalteten Konto. – Navigieren Sie zu dem Ort, an den Ihre App Daten senden kann. – Versuchen Sie, Daten an die andere verwaltete App zu senden, wobei das verwaltete Konto angemeldet ist. – Das Senden von Daten an die andere verwaltete App sollte blockiert werden.
Nicht verwaltete Identität, die an nicht verwaltete App gesendet wird	– Wechseln Sie zum nicht verwalteten Konto. – Navigieren Sie zu dem Ort, an den Ihre App Daten senden kann. – Versuch, Daten an eine nicht verwaltete App zu senden. – Sie sollten immer berechtigt sein, die Daten eines nicht verwalteten Kontos an eine nicht verwaltete App zu senden.

Ihre App importiert möglicherweise aktiv Daten aus anderen Apps, z. B. microsoft Outlook beim Anfügen einer Datei aus Microsoft OneDrive. Ihre App kann auch passiv Daten von anderen Apps empfangen, z. B. von Microsoft Office beim Öffnen eines Dokuments aus einer Microsoft Outlook-Anlage. Die Einstellung für die Empfangs-App-Schutzrichtlinie deckt beide Szenarien ab.

Wenn Ihre App aktiv Daten aus anderen Apps importieren kann:

Szenario	Schritte
Importieren einer verwalteten Identität aus einer nicht verwalteten App	– Wechseln Sie zum verwalteten Konto. – Navigieren Sie zu dem Ort, an dem Ihre App Daten aus anderen Apps importieren kann. – Versuch, Daten aus einer nicht verwalteten App zu importieren. – Das Importieren von Daten aus nicht verwalteten Apps sollte blockiert werden.
Importieren verwalteter Identitäten aus einer verwalteten App	– Wechseln Sie zum verwalteten Konto. – Navigieren Sie zu dem Ort, an dem Ihre App Daten aus anderen Apps importieren kann. – Versuchen Sie, Daten aus der anderen verwalteten App mit dem angemeldeten verwalteten Konto zu importieren. – Sie sollten Daten aus der anderen verwalteten App importieren dürfen.
Nicht verwalteter Identitätsimport aus einer verwalteten App	– Wechseln Sie zum nicht verwalteten Konto. – Navigieren Sie zu dem Ort, an dem Ihre App Daten aus anderen Apps importieren kann. – Versuchen Sie, Daten aus der anderen verwalteten App mit dem angemeldeten verwalteten Konto zu importieren. – Das Importieren von Daten aus der anderen verwalteten App sollte blockiert werden.
Nicht verwalteter Identitätsimport aus einer nicht verwalteten App	– Wechseln Sie zum nicht verwalteten Konto. – Navigieren Sie zu dem Ort, an dem Ihre App Daten aus anderen Apps importieren kann. – Versuch, Daten aus einer nicht verwalteten App zu importieren. – Sie sollten immer daten aus einer nicht verwalteten App für ein nicht verwaltetes Konto importieren dürfen.

Wenn Ihre App die Möglichkeit hat, Daten von anderen Apps passiv zu empfangen:

Szenario	Schritte
Empfangen einer verwalteten Identität von einer nicht verwalteten App	– Wechseln Sie zum verwalteten Konto. – Wechseln Sie zur nicht verwalteten App. – Navigieren Sie zu dem Ort, an den Daten gesendet werden können. – Versuchen Sie, Daten aus der nicht verwalteten App an Ihre App zu senden. – Das verwaltete Konto Ihrer App sollte keine Daten von der nicht verwalteten App empfangen können.
Empfangen einer verwalteten Identität von einer verwalteten App	– Wechseln Sie zum verwalteten Konto. – Wechseln Sie zur anderen verwalteten App, bei der das verwaltete Konto angemeldet ist. – Navigieren Sie zu dem Ort, an den Daten gesendet werden können. – Versuchen Sie, Daten von der verwalteten App an Ihre App zu senden. – Das verwaltete Konto Ihrer App sollte daten von der anderen verwalteten App empfangen dürfen.
Nicht verwaltete Identität, die von einer verwalteten App empfangen wird	– Wechseln Sie zum nicht verwalteten Konto. – Wechseln Sie zur anderen verwalteten App, bei der das verwaltete Konto angemeldet ist. – Navigieren Sie zu dem Ort, an den Daten gesendet werden können. – Versuchen Sie, Daten von der verwalteten App an Ihre App zu senden. – Das nicht verwaltete Konto Ihrer App sollte keine Daten von der verwalteten App empfangen können.
Nicht verwaltete Identität, die von einer nicht verwalteten App empfangen wird	– Wechseln Sie zum nicht verwalteten Konto. – Wechseln Sie zur nicht verwalteten App. – Navigieren Sie zu dem Ort, an den Daten gesendet werden können. – Versuchen Sie, Daten aus der nicht verwalteten App an Ihre App zu senden. – Das nicht verwaltete Konto Ihrer App sollte immer berechtigt sein, Daten von der nicht verwalteten App zu empfangen.

Fehler in diesen Tests können darauf hindeuten, dass Ihre App nicht über die richtige aktive Identität verfügt, wenn sie versucht, Daten zu senden oder zu empfangen. Sie können dies untersuchen, indem Sie die Get Identity-APIs des SDK beim Senden/Empfangen nutzen, um zu bestätigen, dass die aktive Identität ordnungsgemäß festgelegt ist.

Überprüfen von Szenarien für das selektive Zurücksetzen

Ihre App mit mehreren Identitäten hat möglicherweise das Standardzurücksetzungsverhalten des SDK ergänzt oder überschrieben. Diese Tests tragen dazu bei, dass ihre Integration mit mehreren Identitäten verwaltete Daten ordnungsgemäß entfernt, wenn Zurücksetzungen initiiert werden, ohne dass sich dies auf nicht verwaltete Daten auswirkt.

Warnung

Erinnerung: Wenn Ihre App genutzt hat MAMDataProtectionManager.protectForOID, muss sie einen Handler für oder WIPE_USER_AUXILIARY_DATAWIPE_USER_DATAimplementieren.

Installieren Sie für diese Tests Ihre App und die Intune-Unternehmensportal. Melden Sie sich mit einem verwalteten und nicht verwalteten Konto an, bevor Sie den Test starten. Führen Sie für beide Konten App-Szenarien aus, in denen Kontodaten gespeichert werden.

Szenario	Vorbedingungen	Schritte
Ergänzender Zurücksetzungshandler	Ihre App hat einen Handler für implementiert. WIPE_USER_AUXILIARY_DATA	- Geben Sie eine selektive Zurücksetzung über das Microsoft Intune Admin Center aus. – Bestätigen Sie (in der Regel über die Protokollierung), dass Ihr Zurücksetzungshandler erfolgreich ausgeführt wurde. – Vergewissern Sie sich, dass das verwaltete Konto aus Ihrer App entfernt und alle Daten dieses Kontos entfernt wurden. – Vergewissern Sie sich, dass das nicht verwaltete Konto weiterhin angemeldet ist, keine Daten des nicht verwalteten Kontos entfernt wurden und die Richtlinie immer noch nicht angewendet wird.
Überschriebener Zurücksetzungshandler	Ihre App hat einen Handler für implementiert. WIPE_USER_DATA	- Geben Sie eine selektive Zurücksetzung über das Microsoft Intune Admin Center aus. – Bestätigen Sie (in der Regel über die Protokollierung), dass Ihr Zurücksetzungshandler erfolgreich ausgeführt wurde. – Vergewissern Sie sich, dass das verwaltete Konto aus Ihrer App entfernt und alle Daten dieses Kontos entfernt wurden. – Vergewissern Sie sich, dass das nicht verwaltete Konto weiterhin angemeldet ist, keine Daten des nicht verwalteten Kontos entfernt wurden und die Richtlinie immer noch nicht angewendet wird. – Vergewissern Sie sich, dass Ihre App entweder ordnungsgemäß beendet wurde oder sich nach Abschluss des Zurücksetzungshandlers noch in einem fehlerfreien Zustand befindet.
Manueller Dateischutz	– Ihre App ruft auf MAMFileProtectionManager.protectForOID – Ihre App hat einen Handler für implementiert. WIPE_USER_DATA	– Stellen Sie sicher, dass Sie Szenarien ausgeführt haben, in denen Ihre App mindestens eine Datei, die zum verwalteten Konto gehört, manuell schützt. - Geben Sie eine selektive Zurücksetzung über das Microsoft Intune Admin Center aus. – Vergewissern Sie sich, dass die Dateien entfernt wurden.
Manueller Schutz von Datenpuffern	– Ihre App ruft auf MAMDataProtectionManager.protectForOID – Ihre App hat einen Handler für oder WIPE_USER_AUXILIARY_DATA implementiert. WIPE_USER_DATA	– Stellen Sie sicher, dass Sie Szenarien ausgeführt haben, in denen Ihre App mindestens einen Datenpuffer, der zum verwalteten Konto gehört, manuell schützt. - Geben Sie eine selektive Zurücksetzung über das Microsoft Intune Admin Center aus. – Vergewissern Sie sich, dass die Datenpuffer aus den Dateien entfernt werden, in denen sie gespeichert wurden, und Dass Ihre App die nicht verwalteten Daten weiterhin aus diesen Dateien lesen kann.

Nächste Schritte

Nachdem Sie alle oben genannten Exitkriterien erfüllt haben, ist Ihre App nun erfolgreich als Multiidentität integriert und kann App-Schutzrichtlinien auf Identitätsbasis erzwingen. Die nachfolgenden Abschnitte Phase 6: App Configuration und Phase 7: Features für die App-Teilnahme sind je nach gewünschter Unterstützung der App-Schutzrichtlinie möglicherweise erforderlich. Wenn Sie nicht sicher sind, ob einer dieser Abschnitte für Ihre App gilt, lesen Sie die wichtigsten Entscheidungen für die SDK-Integration erneut.