Intune App SDK für Android – Multi-Identity

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

Hinweis

Dieser Leitfaden ist in mehrere Abschnitte unterteilt. Lesen Sie zunächst Phase 1: Planen der Integration.

Phase 5: Mehrfachidentität

Etappenziele

• Ermitteln Sie, ob Ihre Anwendung Unterstützung für mehrere Identitäten benötigt.
• Verstehen, wie das Intune App SDK Identitäten wahrnimmt.
• Gestalten Sie Ihre Anwendung für die Identitätserkennung um.
• Fügen Sie Code hinzu, um das SDK über aktive und sich ändernde Identitäten in Ihrer Anwendung zu informieren.
• Testen Sie die Durchsetzung von App-Schutzrichtlinien sowohl für verwaltete als auch für 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 unterschieden in Endbenutzer, der Mensch, der die Android-App verwendet, undAdmin-Administratorbenutzer / / ,IT-Administrator / IT Pro, der Mensch, der das Microsoft Intune Admin Center verwendet.
• Konto: Der Softwaredatensatz, der zu einer organization gehört und die Entität eines Benutzers eindeutig identifiziert. Ein menschlicher Benutzer kann mehrere Konten haben.
• Identität: die Gruppe von Daten, die das Intune App SDK verwendet, um ein Konto eindeutig zu identifizieren.

Hintergrund

Standardmäßig wendet das Intune App SDK Richtlinien auf Ihre gesamte Anwendung an. Nach der Registrierung eines Kontos mit einer gezielten 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 Anwendungen mit einer einzigen Identität betrachtet. Durch Abschluss der vorherigen Phasen wurde Ihre Anwendung erfolgreich als Einzelidentität integriert und kann alle grundlegenden Richtlinien erzwingen. Apps, die Single-Identity bleiben 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 mithilfe von App-Schutzrichtlinien beibehalten möchten, wird Ihre Anwendung als Anwendung mit mehreren Identitäten betrachtet.

Tipp

Wenn Sie sich nicht sicher sind, ob die Anwendung den Schutz für einzelne oder mehrere Identitäten unterstützen soll, lesen Sie erneut Ist meine Anwendung Single-Identity oder Multi-Identity?

Warnung

Die Unterstützung von Mehrfachidentitäten ist deutlich komplexer als bei anderen App-Schutzfunktionen. Eine nicht ordnungsgemäße Integration von Mehrfachidentitä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.

"Identity" für das SDK hinzufügen

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

Bei Identitätsparametern wird die Groß-/Kleinschreibung nicht beachtet. Anforderungen an das SDK für eine Identität geben möglicherweise nicht dieselbe 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 UPN-Zeichenfolge der Identität, die an verschiedene API-Aufrufe übergeben wird, konsistent ist. Die Übergabe inkonsistenter UPN-Zeichenfolgen kann zu Datenlecks führen.

Verwaltete und nicht verwaltete Identitäten

Wie unter Registrieren für die App-Schutzrichtlinie beschrieben, ist Ihre Anwendung dafür verantwortlich, das SDK zu informieren, wenn sich ein Benutzer anmeldet. Zum Zeitpunkt der Anmeldung kann das Konto des Benutzers von einer App-Schutzrichtlinie betroffen sein, muss es aber nicht. Wenn das Konto von einer App-Schutzrichtlinie betroffen ist, betrachtet das SDK es als verwaltet. Andernfalls wird sie nicht verwaltet.

Das SDK erzwingt Richtlinien 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 nachfolgend registrierten Identitäten, auch wenn sie derzeit von App-Schutzrichtlinien betroffen sind, als nicht verwaltet behandelt.

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

Hinweis

Ein Konto, auf das zum Zeitpunkt der Registrierung keine App-Schutzrichtlinie abzielt, gilt als nicht verwaltet. Auch wenn das Konto nicht für die App-Schutzrichtlinie lizenziert ist oder von dieser nicht als Ziel angesehen wird, überprüft das SDK in regelmäßigen Abständen, ob dieses Konto zu einem späteren Zeitpunkt lizenziert und als Zielgruppe eingestuft wird. Wenn keine andere verwaltete Identität registriert wurde, behandelt das SDK diese Identität als verwaltet, sobald sie mit einer Richtlinie als Ziel festgelegt wird. Der Benutzer muss sich nicht ab- und wieder anmelden, um diese Änderung vorzunehmen.

Die aktive Identität

Ihre Anwendung muss das SDK immer über die Identität informieren, die gerade verwendet wird, auch bekannt als die aktive Identität. Wenn die aktive Identität verwaltet wird, wendet das SDK Schutzmaßnahmen an. Wenn die aktive Identität nicht verwaltet wird, wendet das SDK keine Schutzmaßnahmen an.

Da das SDK über keine anwendungsspezifischen Kenntnisse verfügt, muss es der Anwendung vertrauen, dass sie die richtige aktive Identität teilt.

• Wenn die Anwendung dem SDK fälschlicherweise mitteilt, dass eine nicht verwaltete Identität aktiv ist, obwohl die verwaltete Identität tatsächlich verwendet wird, wendet das SDK keine Schutzmaßnahmen an. Dies könnte 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, obwohl tatsächlich eine nicht verwaltete Identität verwendet wird, wendet das SDK Schutzmaßnahmen in unangemessener Weise an. Dies ist kein Datenleck, aber dies kann nicht verwaltete Benutzer unnötig einschränken und die Daten nicht verwalteter Benutzer dem Risiko aussetzen, gelöscht zu werden.

Wenn Ihre Anwendung Benutzerdaten anzeigt, darf sie nur Daten anzeigen, 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 umgestalten, um ein größeres Identitätsbewusstsein zu erreichen, bevor Sie mit der Integration der Unterstützung für mehrere Identitäten beginnen.

Organisieren von App-Daten nach Identität

Immer wenn Ihre Anwendung eine neue Datei schreibt, ordnet das SDK dieser Datei eine Identität zu (auch als "Tags" bezeichnet), die auf der aktuellen aktiven Thread- und Prozessidentität basiert. 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 Files). Das SDK verwendet diese markierte Dateiidentität sowohl für die Dateiverschlüsselung als auch für die selektive Zurücksetzung.

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

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

Das SDK kann nicht mehrere Identitäten mit einer einzigen Datei verknüpfen. Wenn Ihre App Daten mehrerer Benutzer in derselben Datei speichert, führt das Standardverhalten des SDK dazu, dass diese Daten nicht oder nur unzureichend geschützt sind. Es wird dringend empfohlen, die Daten Ihrer App nach Identität zu organisieren.

Wenn Ihre App unbedingt Daten verschiedener Identitäten in derselben Datei speichern muss, bietet das SDK Features für das Identitäts-Tagging von Teilmengen von Daten innerhalb einer Datei. Weitere Informationen finden Sie unter Datenpufferschutz .

Implementieren von Multi-Identity

Um die Unterstützung mehrerer 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 (Allgemein Activity) Ebene
3. Prozessebene

Eine auf Threadebene festgelegte Identität ersetzt eine auf der Ebene festgelegte Identität, die Context wiederum eine auf Prozessebene festgelegte Identität ersetzt.

Eine auf einem festgelegte Context Identität wird nur in geeigneten 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 .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 dann nützlich, wenn die App in allen Threads nur mit einer einzigen Identität arbeitet. 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 auf dem Thread oder den Context Ebenen festzulegen.

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

Wenn Ihre App einen Service Kontext zum Starten von Absichten verwendet, Inhaltsauflösungen verwendet oder andere Systemdienste nutzt, stellen Sie sicher, dass Sie die Identität für den Service Kontext festlegen. Wenn Ihre App einen JobService Kontext verwendet, um diese Aktionen auszuführen, stellen Sie sicher, dass Sie die Identität für den Kontext oder Thread JobService festlegen, wie es für Ihre JobService Implementierung erforderlich ist. Wenn your JobService zum Beispiel Aufträge für eine einzelne Identität verarbeitet, sollten Sie die Identität für den JobService Kontext festlegen. Wenn Ihr Aufträge JobService für mehrere Identitäten verarbeitet, sollten Sie die Identität auf Threadebene festlegen.

Achtung

Apps, die diese WorkManager verwenden, sollten beim Festlegen der Identität besondere Sorgfalt walten lassen. Insbesondere sollten diese Apps vermeiden, eine Identität für den Context übergebenen im Konstruktor festzulegen Worker . Diese Context Instance kann von mehreren Worker Instances gleichzeitig gemeinsam genutzt werden. Um undefiniertes Verhalten zu vermeiden, sollten Apps stattdessen eine Threadidentität festlegen Worker.doWork() , wie es die Worker Implementierung erfordert.

Hinweis

Da das CLIPBOARD_SERVICE für UI-Vorgänge verwendet wird, verwendet das SDK die UI-Identitä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 MAMPolicyManager.setUIPolicyIdentityOID. Gehen Sie dazu folgendermaßen vor:

     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 der Aufruf dieser Methoden zum Festlegen der Identität keine Aktion aus und gibt immer FAILEDzurück, wenn sie einen zurückgebenMAMIdentitySwitchResult.

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 angegebenen Intent Parameter zugeordnet ist. Es wird dringend empfohlen, die Context Ebenenidentität mit dem Kontext eines Activity's festzulegen, nicht mit dem Kontext von 's Application.

• Es wird empfohlen, onCreate die Context Identität während der Methode einer Aktivität festzulegen. Achten Sie jedoch darauf, auch andere Einstiegspunkte wie onNewIntentabzudecken. Andernfalls, wenn dieselbe Aktivität wiederverwendet wird, um Daten für verwaltete und nicht verwaltete Identitäten anzuzeigen, kann die Richtlinie falsch angewendet werden, was entweder zu ungeschützten Unternehmensdaten oder zu unrechtmäßig 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. Dieses Problem tritt auf, wenn versucht wird, die Identität der Benutzeroberfläche (Context) festzulegen, wenn im aktuellen Thread eine andere Identität festgelegt ist.
CANCELLED	Der Benutzer hat die Identitätsänderung abgebrochen, in der Regel durch Drücken der Zurück-Taste auf einer PIN oder einer Authentifizierungsaufforderung.
FAILED	Die Identitätsänderung ist aus einem nicht näher bezeichneten Grund fehlgeschlagen.

Die App sollte überprüfen, ob MAMIdentitySwitchResult vorliegt 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. Im Falle des Setzens einer Context Identität über setUIPolicyIdentityOID wird das Ergebnis asynchron gemeldet. Die App implementiert möglicherweise einen MAMSetUIIdentityCallback , um dieses Ergebnis zu erhalten, oder übergibt NULL für das Rückrufobjekt. Wenn ein Anruf erfolgt setUIPolicyIdentityOID , während das Ergebnis eines vorherigen Aufrufs an setUIPolicyIdentityOIDdasselbe Context noch nicht übermittelt wurde, ersetzt der neue Rückruf den alten und der ursprüngliche Rückruf erhält nie ein Ergebnis.

Achtung

Wenn die für setUIPolicyIdentityOID bereitgestellte Context ID ein Activityist, weiß das SDK nicht, ob die Identitätsänderung erfolgreich war, bis die vom Administrator konfigurierten Prüfungen für bedingte Starts durchgeführt wurden. Dazu muss der Benutzer möglicherweise eine PIN oder Unternehmensanmeldeinformationen eingeben.

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

Der Schalter zur Benutzeroberflächenidentität kann bei ungültigen Argumenten fehlschlagen, wenn er mit der Threadidentität in Konflikt stehen würde oder wenn der Benutzer die bedingten Startanforderungen abbricht (z. B. die Zurück-Schaltfläche auf dem PIN-Bildschirm drückt).

Das Standardverhalten für einen fehlgeschlagenen UI-Identitätsschalter bei einer 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 die Methode außer Kraft onSwitchMAMIdentityComplete setzen (oder aufrufen super ), müssen Sie sicherstellen, dass die Daten eines verwalteten Kontos nach einem fehlgeschlagenen Identitätswechsel nicht angezeigt werden.

Hinweis

Der Wechsel der Identität kann es erforderlich machen, die Aktivität neu zu erstellen. In diesem Fall wird der onSwitchMAMIdentityComplete Rückruf an die neue Instance der Aktivität übermittelt.

Identity, Intents und IdentitySwitchOptions

Zusätzlich zum automatischen Taggen 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 bei einer eingehenden 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 Informationen finden Sie unten unter Änderungen impliziter Identitäten ).

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

Das SDK führt diese Überprüfung durch, da davon ausgegangen wird, dass die App weiterhin Inhalte aus der Absicht anzeigt, die zu der in der Absicht markierten Identität gehören. Diese Annahme schützt davor, dass die App beim Anzeigen verwalteter Daten versehentlich den Schutz deaktiviert. Diese Annahme ist jedoch möglicherweise nicht korrekt und entspricht möglicherweise nicht dem tatsächlichen Verhalten der App.

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

• IGNORE_INTENT: Beim Anfordern eines Identitätswechsels auf der Benutzeroberflächenebene 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 zu dieser Identität gehörenden Inhalte mehr anzeigt 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 eine Funktion, mit der Benutzer Konten wechseln können. Immer wenn der Benutzer dieses Feature für den Kontowechsel verwendet, navigiert die App zu einer kontospezifischen Landing Page mit den zuletzt verwendeten Dokumenten dieses Kontos.
  2. Ihre App erhält eine 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 Kontowechsler, um zu seinem persönlichen Konto zu wechseln.

  Ihre App muss die Identität der Benutzeroberfläche in Schritt 4 ändern. Da die App sich in diesem Fall verhält, von den Daten des verwalteten Kontos (dem Dokument in der Absicht) wegzunavigieren, sollte sie sie im Identitätswechsel-Aufruf verwenden IGNORE_INTENT . Dadurch wird vermieden, dass das SDK diesen Aufruf unangemessenerweise fehlschlägt.

• DATA_FROM_INTENT: Beim Anfordern eines Identitätswechsels auf der Benutzeroberflächenebene informiert diese Option das SDK, dass Daten aus der zuletzt gespeicherten Absichtsidentität weiterhin angezeigt werden, nachdem der Identitätswechsel erfolgreich war. Als Ergebnis 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 eine Funktion, mit der Benutzer Konten wechseln können. Anders als im vorherigen Beispiel navigiert die App immer dann, wenn der Benutzer dieses Feature zum Wechseln des Kontos verwendet, zu einer freigegebenen Seite, auf der aktuelle Dokumente für alle Konten angezeigt werden."
  2. Ihre App erhält eine 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 Kontowechsler, um zu seinem persönlichen Konto zu wechseln.

  Ihre App muss die Identität der Benutzeroberfläche in Schritt 4 ändern. Da die App sich in diesem Fall verhält, weiterhin die Daten der verwalteten Identität anzuzeigen (eine Vorschau des Dokuments in der Absicht), sollte sie sie im Aufruf des Identitätswechsels verwenden DATA_FROM_INTENT . Dadurch wird das SDK angewiesen, die konfigurierte App-Schutzrichtlinie zu überprüfen, um festzustellen, ob die Daten weiterhin angezeigt werden sollen.

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

Löschen der aktiven Identität

In Ihrer Anwendung gibt es möglicherweise Szenarien, die kontounabhängig sind. Ihre Anwendung kann auch Szenarien für lokale, nicht verwaltete Szenarien haben, die keine Anmeldung erfordern. In beiden Fällen möchte Ihre App möglicherweise nicht, dass das SDK die Richtlinien der verwalteten Identität erzwingt, aber Sie haben möglicherweise keine explizite Identität, zu der Sie wechseln möchten.

Sie können die aktive Identität löschen, indem Sie eine beliebige der set identity-Methoden aufrufen, bei der der Parameter identity OID auf festgelegt ist null. Wenn Sie die Identität auf einer Ebene löschen, sucht das SDK basierend auf der Rangfolge auf anderen Ebenen nach der aktiven Identität.

Alternativ können Sie eine leere Zeichenfolge als OID-Parameter der Identität übergeben, wodurch die Identität auf einen speziellen leeren Wert festgelegt wird, der als nicht verwaltete Identität behandelt wird. Wenn Sie die aktive Identität auf eine leere Zeichenfolge festlegen, wird das SDK angewiesen, keine App-Schutzrichtlinien zu erzwingen.

Änderungen der impliziten Identität

Im obigen Abschnitt werden die verschiedenen Möglichkeiten beschrieben, mit denen 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 Änderungen der impliziten Identität lauschen und darauf reagieren kann.

Das Lauschen auf diese impliziten Identitätsänderungen ist optional, wird jedoch empfohlen. Das SDK ändert niemals die aktive Identität, ohne diese impliziten Identitätsänderungsbenachrichtigungen bereitzustellen.

Achtung

Wenn Ihre App nicht auf implizite Identitätsänderungen hören möchte, achten Sie besonders darauf, nicht die aktive Identität anzunehmen. Verwenden Sie im Zweifelsfall die getCurrentThreadIdentityOIDgetUIPolicyIdentityOID, und getProcessIdentityOID Methoden, um die aktive Identität zu bestätigen.

Quellen von Änderungen der impliziten Identität

• Eingehende Daten aus anderen von Intune verwalteten Apps können die aktive Identität auf Thread- und Kontextebene ändern.

  • Wenn eine Aktivität von einer Intent von einer anderen MAM-App gesendeten App gestartet wird, 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 absichtlich von Microsoft Outlook aus gestartet, wenn ein Benutzer eine Dokumentanlage auswählt. Die Identität der Dokumentanzeige-Aktivität von Office wird von Outlook in die Identität geändert.

  • Für Dienste wird die Threadidentität für die Dauer eines onStart oder-Aufrufs onBind auf ähnliche Weise festgelegt. Aufrufe in das Binder zurückgegebene von onBind legen auch vorübergehend die Threadidentität fest.

  • Aufrufe eines ContentProvider Testaments 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:

  • Wenn ein Benutzer eine Autorisierungsaufforderung abbricht Resume , führt dies zu einem impliziten Wechsel zu einer leeren Identität.

Verarbeiten von Änderungen der impliziten Identität

Ihre App kann optional auf diese impliziten Identitätsänderungen lauschen und darauf reagieren. Ihre Anwendung kann beispielsweise mehrere Schritte erfordern, bevor ein hinzugefügtes Konto verwendet werden kann, wie eine E-Mail-App, die einen neuen Posteingang einrichtet. Wenn ein versuchter Identitätswechsel zur Identität dieses unvollständigen Kontos angezeigt wird, leitet der App-Handler den Benutzer möglicherweise zur Kontoeinrichtungsaktivität um, bevor der Identitätswechsel akzeptiert wird. Alternativ könnte der Handler Ihrer App ein Fehlerdialogfeld anzeigen und den Identitätswechsel blockieren.

Ihre App kann die MAMIdentityRequirementListener-Schnittstelle in einem Service oder ContextProvider für Identitätsänderungen implementieren, die für diesen Thread gelten. 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 Identitätsänderungen Activity implementieren, die für diese Aktivität gelten. Ihre Implementierung muss Folgendes außer Kraft setzen:

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

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

Enumerationswert	Standardverhalten des SDK	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 erfolgt, weil einer Aktivität eine neue Absicht zugewiesen wird.
RESUME_CANCELLED	Blockieren Sie den Identitätswechsel.	Der Identitätswechsel erfolgt, weil ein Lebenslauf abgebrochen wurde. Dies ist am häufigsten der Fall, wenn der Endbenutzer die Zurück-Schaltfläche auf der PIN-, Authentifizierungs- oder Compliance-Benutzeroberfläche drückt.

Mit dem Parameter AppIdentitySwitchResultCallback können Entwickler das Standardverhalten für den Identitätsschalter 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 aufgerufen, mit Ausnahme derjenigen, die durch einen von zurückgegebenen Binder MAMService.onMAMBindvorgenommen wurden. Die Standardimplementierungen von onMAMIdentitySwitchRequired immediately rufen Folgendes auf:

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

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

Es ist nicht zu erwarten, 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, ist das Verhalten des Endbenutzers dasselbe, als hätte die App-Schutzeinstellung "Daten von anderen Apps empfangen" des SDK den Dateneingang verhindert.

• Wenn ein Dienst im Hauptthread ausgeführt wird, reportIdentitySwitchResult synchron aufgerufen werden muss, oder der Benutzeroberflächenthread reagiert nicht mehr.

• Für Activity die Erstellung wird onMAMIdentitySwitchRequired aufgerufen, bevor onMAMCreate. 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.

• In einer , Activitywenn ein Wechsel zur leeren Identität mit dem Grund als RESUME_CANCELLEDangefordert wird, muss die App die fortgesetzte Aktivität ändern, um Daten anzuzeigen, die mit diesem Identitätswechsel konsistent sind. Wenn dies nicht möglich ist, sollte die App den Wechsel verweigern und der Benutzer wird erneut aufgefordert, die Richtlinie für die Wiederaufnahme der Identität einzuhalten (z. B. indem ihm der App-PIN-Eingabebildschirm 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 jedoch nicht verwenden kann (z. B. weil Konten wie 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.onSwitchMAMIdentityComplete" müssen, können Sie auch eine Implementierung MAMActivityIdentitySwitchListener durchführen, ohne explizit von MAMActivityzu erben.

Identitätswechsel und Screenshot-Einschränkungen

Das Intune App SDK verwendet das Window FlagFLAG_SECURE, um die Screenshot-Richtlinie zu erzwingen. Einige Apps werden möglicherweise auch für eigene Zwecke festgelegt FLAG_SECURE . Wenn die App-Schutzrichtlinie Screenshots nicht einschränkt, wird das SDK nicht geändert FLAG_SECURE.

Bei einem Identitätswechsel von einer Identität, deren Richtlinie das Deaktivieren von Screenshots erfordert, zu einer Identität, deren Richtlinie dies nicht tut, löscht FLAG_SECUREdas SDK . Daher sollte sich Ihre App nicht darauf verlassen FLAG_SECURE , dass sie nach einem Identitätswechsel festgelegt bleibt.

Beibehalten der Identität in asynchronen Vorgängen

Apps versenden häufig Hintergrundaufgaben vom UI-Thread, um Vorgänge in anderen Threads zu behandeln. Eine App mit mehreren Identitäten muss sicherstellen, dass diese Hintergrundaufgaben mit der entsprechenden Identität ausgeführt werden, bei der es sich häufig um dieselbe Identität handelt, die von der Aktivität verwendet wird, die sie bereitgestellt hat.

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

• 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 von ihm anstelle von AsyncTask und ersetzen Sie Überschreibungen von doInBackground und onPreExecute mit doInBackgroundMAM bzw onPreExecuteMAM . Der MAMAsyncTask Konstruktor nimmt einen Aktivitätskontext an. 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 nimmt die aktive Identität gemäß der normalen Rangfolge an.

MAMIdentityExecutors

MAMIdentityExecutorsErmöglicht es Ihnen, eine vorhandene Executor oder ExecutorService instance als identitätserhaltende/ExecutorServiceExecutorWITH-Methoden wrapExecutorwrapExecutorService zu umschließen. Beispiel:

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

MAMIdentityExecutors nimmt die aktive Identität gemäß der normalen Rangfolge an.

Dateischutz

Schreiben geschützter Files

Wie oben unter Organisieren von App-Daten nach Identität erwähnt, ordnet das Intune App SDK Dateien während des Schreibens die aktive Identität (von der Thread-/Prozessebene) zu. Es ist wichtig, dass zum Zeitpunkt der Dateierstellung die richtige Identität festgelegt wird, um eine ordnungsgemäße Verschlüsselung und selektive Löschfunktionalitä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 Schutz von Verzeichnissen verwendet werden. Der Verzeichnisschutz gilt rekursiv für alle im Verzeichnis enthaltenen Dateien und Unterverzeichnisse. Wenn ein Verzeichnis geschützt ist, wird auf alle neuen Dateien, die innerhalb des Verzeichnisses 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 mit einer leeren Zeichenfolge für den Identitätsparameter aufrufen protectForOID , wird die Datei/das Verzeichnis mit der nicht verwalteten Identität gekennzeichnet. Durch diesen Vorgang wird die Verschlüsselung aus der Datei/dem Verzeichnis entfernt, wenn sie zuvor verschlüsselt war. Wenn ein Befehl zum selektiven Löschen 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 bei anderen Identitäten ein Datenverlust auftreten, wenn sich die besitzende Identität abmeldet, da Dateien gelöscht werden und der Zugriff auf den Verschlüsselungsschlüssel verloren geht.

Anzeigen von geschütztem Dateiinhalt

Ebenso wichtig ist es, beim Anzeigen von Dateiinhalten die richtige Identität festzulegen, um zu verhindern, dass nicht autorisierte Benutzer verwaltete Daten anzeigen. Das SDK kann nicht automatisch auf eine Beziehung zwischen gelesenen Dateien und Daten schließen, die in einer .Activity 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 ContentProvider öffentlich beschreibbaren Speicherort oder von einem öffentlich beschreibbaren Speicherort gelesen), muss die App versuchen, die Dateiidentität zu ermitteln (mithilfe der richtigen MAMFileProtectionManager.getProtectionInfo-Überladung für die Datenquelle), bevor aus der Datei gelesene Informationen angezeigt werden.

Wenn getProtectionInfo eine nicht-NULL-, nicht leere Identität gemeldet wird, muss die App die Benutzeroberflächenidentität so festlegen, dass sie mit dieser Identität übereinstimmt, indem entweder MAMActivity.switchMAMIdentityOID oder MAMPolicyManager.setUIPolicyIdentityOID verwendet wird. Wenn der Identitätsschalter fehlschlägt, dürfen keine Daten aus der Datei angezeigt werden.

Beim Lesen aus einem Inhalts-URI kann es erforderlich sein, zuerst die Identität zu lesen (über die Überladung, die getProtectionInfo ein ), Uriund dann den Kontext oder die Threadidentität entsprechend festzulegen. Dies muss vor dem Öffnen eines Dateideskriptors oder Eingabedatenstroms auf dem ContentResolvererfolgen, da der Vorgang andernfalls fehlschlägt.

Ein Beispielablauf 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 Flusses 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 ö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 Kontext, der zum Abrufen des DownloadManager verwendet wird, 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 der Single-Identity-Intune-Integration veröffentlicht wurde, später Multi-Identity integriert, werden zuvor installierte Apps einem Übergang unterzogen. 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 (sie bleiben also verschlüsselt, wenn die Verschlüsselungsrichtlinie aktiviert ist).

Wenn Sie nicht möchten, dass alle vorherigen App-Daten der verwalteten Identität 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, bei der die Unterstützung mehrerer Identitäten hinzugefügt wurde.
• Aufruf protectForOID mit leerer Zeichenfolge für den Identitätsparameter für Dateien oder Verzeichnisse, die nicht der verwalteten Identität zugeordnet werden sollen.

Offline Szenarien

Das Intune App SDK wird im "Offline"-Modus ausgeführt, wenn die Unternehmensportal-App nicht installiert ist. Die Kennzeichnung der Dateiidentität ist im Offlinemodus unterschiedlich:

• Wenn das Unternehmensportal nicht installiert ist, können Dateien nicht mit einer Identitätskennzeichnung versehen werden. Das Aufrufen von MAMFileProtectionManager.protectForOID im Offlinemodus ist sicher, hat aber keine Auswirkungen.

• Wenn das Unternehmensportal installiert ist, die App jedoch nicht über eine App-Schutzrichtlinie verfügt, können Dateien nicht zuverlässig mit einer Identitätskennzeichnung versehen werden.

• Wenn das Dateiidentitäts-Tagging verfügbar wird, werden alle zuvor erstellten Dateien als persönlich/nicht verwaltet behandelt (zur Identität mit leerer Zeichenkette), außer in Fällen, in denen die App zuvor als verwaltete App mit einer einzigen Identität installiert wurde, wie unter Übergang zwischen einer einzelnen Identität und mehreren Identitäten beschrieben.

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

Schutz des Datenpuffers

Warnung

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

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

MAMDataProtectionManager.protectForOID Ermöglicht es einer App, Daten mit einer Identität zu verknüpfen und, wenn die Identität derzeit mit einer Verschlüsselungsrichtlinie gekennzeichnet ist, die Daten zu verschlüsseln. Diese verschlüsselten Daten eignen sich zum Speichern auf dem Datenträger in einer Datei.

MAMDataProtectionManager ermöglicht es Ihnen außerdem, die mit der Identität verknüpften Daten abzufragen und sie zu entschlüsseln.

Apps, die dies MAMDataProtectionManager verwenden, sollten einen Empfänger für die MANAGEMENT_REMOVED Benachrichtigung implementieren. Weitere Informationen finden Sie unter Registrieren für Benachrichtigungen vom 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 alle Puffer aufruftMAMDataProtectionManager.unprotect. Es ist auch sicher, während dieser Benachrichtigung anzurufen protectForOID , wenn Sie Identitätsinformationen aufbewahren möchten. Die Verschlüsselung ist während der Benachrichtigung garantiert deaktiviert, und durch den Aufruf protectForOID des Handlers werden keine Datenpuffer verschlüsselt.

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 durch. Wenn eine App jedoch beim App-Start eine Verschlüsselungsanforderung sendet, kann diese blockiert werden, bis die Verschlüsselungsinitialisierung abgeschlossen ist.

Hinweis

Die Intune App SDK-Verschlüsselungs-API sollte nur zum Verschlüsseln von Daten verwendet werden, wie es die Intune-Richtlinie erfordert. Es wird kein Schutz auf Konten angewendet, für die keine Verschlüsselungsrichtlinien aktiviert sind, sodass sie nicht als allgemeine Verschlüsselungsbibliothek verwendet werden können.

Inhaltsanbieter

Eine App mit mehreren Identitäten muss auch die über ContentProviders freigegebenen Daten schützen, um eine unangemessene Freigabe verwalteter Inhalte zu verhindern.

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

Ein Anruf isProvideContentAllowedForOid ist nicht erforderlich, wenn Sie ContentProvider eine ParcelFileDescriptor. Über einen Inhaltsanbieter zurückgegebene Dateideskriptoren werden automatisch basierend auf der Dateiidentität verarbeitet.

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 standardmäßige Löschverhalten entweder zu ergänzen (empfohlen) oder außer Kraft zu setzen.

Der Standard-Löschhandler des SDK verarbeitet keine Datenpuffer, die durch geschützt sind MAMDataProtectionManager. Wenn Ihre App dieses Feature verwendet hat, muss sie den Standardlöschhandler ergänzen oder außer Kraft setzen, um diese Daten zu entfernen.

Hinweis

Das Ergänzen und Überschreiben des standardmäßigen Löschverhaltens erfordert die Behandlung spezifischer SDK-Benachrichtigungen. Weitere Informationen zum Implementieren von Benachrichtigungshandlern finden Sie unter Registrieren für Benachrichtigungen aus dem SDK .

Ergänzen des standardmäßigen Löschverhaltens

Um das Standardverhalten beim Löschen des SDK zu ergänzen, kann sich Ihre App für MAMNotificationTypeWIPE_USER_AUXILIARY_DATA registrieren.

Diese Benachrichtigung wird vom SDK gesendet, bevor die standardmäßige selektive Löschung 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 zurückkehren, wenn die gesamte Bereinigung abgeschlossen ist.

Apps sollten unbedingt in Erwägung ziehen, das Standardlöschverhalten durch WIPE_USER_AUXILIARY_DATAzu ergänzen, da die App-spezifische Bereinigung für Apps mit mehreren Identitäten üblich ist.

Überschreiben des standardmäßigen Löschverhaltens

Um das Standardverhalten beim Löschen des SDK außer Kraft zu setzen, kann sich Ihre App für MAMNotificationTypeWIPE_USER_DATA registrieren.

Warnung

Eine App darf sich niemals sowohl für als auch WIPE_USER_DATAWIPE_USER_AUXILIARY_DATAregistrieren.

Das Überschreiben des standardmäßigen SDK-Löschverhaltens stellt ein erhebliches Risiko für Ihre App dar. Ihre App trägt die volle Verantwortung für das Entfernen aller Daten, 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 war und der benutzerdefinierte Löschhandler 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 möglicherweise nicht den Versuch, verschlüsselte Daten ordnungsgemäß zu lesen.
• Der Löschhandler Ihrer App kann zu Datenverlusten bei nicht verwalteten Benutzern führen, wenn er Dateien entfernt, die nicht mit der verwalteten Identität gekennzeichnet sind.

Wenn der benutzerdefinierte Löschhandler Ihrer App verwaltete Daten aus einer Datei entfernt, aber andere Daten in der Datei belassen möchte, muss er die Identität der Datei (über MAMFileProtectionManager.protectForOID) entweder in eine nicht verwaltete Identität oder eine leere Zeichenfolge ändern.

Der überschriebene Löschhandler sollte Daten synchron löschen und erst zurückkehren, wenn die gesamte Bereinigung abgeschlossen ist.

Erwägen Sie, Ihre App manuell zu schließen, nachdem Sie die Schritte zum benutzerdefinierten Löschhandler abgeschlossen haben, um zu verhindern, dass der Benutzer nach einer Zurücksetzung auf In-Memory-Daten zugreift.

Beendigungskriterien

Planen Sie viel Zeit für die Überprüfung der Integration von Mehrfachidentitäten in Ihre App ein. Bevor Sie mit dem Testen beginnen:

• Erstellen Sie eine App-Schutzrichtlinie, und weisen Sie sie einem Konto zu. Dies ist Ihr testverwaltetes Konto.
• Erstellen, aber nicht Zuweisen einer App-Schutzrichtlinie zu einem anderen Konto. 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 erneut damit vertraut, wie Richtlinien in Ihrer App durchgesetzt werden. Bei Tests für mehrere Identitäten müssen Sie leicht unterscheiden können, wann Ihre App mit einer erzwungenen Richtlinie ausgeführt wird und wann nicht. Die Richtlinieneinstellung für den App-Schutz zum Blockieren von Screenshots ist effektiv, um die Richtlinienerzwingung schnell zu testen.
• Berücksichtigen Sie den gesamten Satz von Benutzeroberflächen, die Ihre App bietet. Zählen Sie die Bildschirme auf, auf denen Kontodaten angezeigt werden. Zeigt Ihre App immer nur die Daten eines einzelnen Kontos gleichzeitig an, oder kann sie Daten mehrerer Konten gleichzeitig anzeigen?
• Betrachten Sie den gesamten Satz von Dateien, die Ihre App erstellt. Zählen Sie auf, welche dieser Dateien Daten enthalten, die zu einem Konto gehören, im Gegensatz zu Daten auf Systemebene.
  • Legen Sie fest, wie die Verschlüsselung für jede dieser Dateien überprüft werden soll.
• Berücksichtigen Sie alle Möglichkeiten, wie Ihre App mit anderen Apps interagieren kann. Zählen Sie alle Ein- und Ausgangspunkte auf. Welche Datentypen kann Ihre App erfassen? Welche Absichten überträgt es? Welche Inhaltsanbieter implementiert es?
  • Legen Sie fest, wie Sie die einzelnen Datenfreigabefeatures nutzen möchten.
  • Bereiten Sie ein Testgerät vor, das sowohl verwaltete als auch nicht verwaltete Apps enthält, 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 mehrerer Identitäten, indem Sie die folgenden Tests ausführen. Beachten Sie, dass dies keine vollständige Liste ist und nicht garantiert, dass die Implementierung Ihrer App für mehrere Identitäten fehlerfrei ist.

Überprüfen von Anmelde- und Abmeldeszenarien

Ihre Multi-Identity-App unterstützt bis zu 1 verwaltetes Konto und mehrere nicht verwaltete Konten. Diese Tests tragen dazu bei, dass Ihre Integration mehrerer Identitäten den Schutz beim Anmelden oder Abmelden von Benutzern nicht unsachgemäß ändert.

Installieren Sie für diese Tests Ihre App und das Intune-Unternehmensportal; melden Sie sich nicht an, bevor Sie mit dem Test beginnen.

Szenario	Schritte
Log in managed first	- Melden Sie sich zuerst mit einem verwalteten Konto an und überprüfen Sie, ob die Daten dieses Kontos verwaltet werden. - Melden Sie sich mit einem nicht verwalteten Konto an und überprüfen Sie, ob die Daten dieses Kontos nicht verwaltet werden.
Melden Sie sich zuerst unmanaged an	- Melden Sie sich zuerst mit einem nicht verwalteten Konto an und überprüfen Sie, ob die Daten dieses Kontos nicht verwaltet werden. - Melden Sie sich mit einem verwalteten Konto an und bestätigen Sie, dass die Daten dieses Kontos verwaltet werden.
Melden Sie sich bei mehreren verwalteten	- Melden Sie sich zuerst mit einem verwalteten Konto an und überprüfen Sie, ob die Daten dieses Kontos verwaltet werden. - Melden Sie sich mit einem zweiten verwalteten Konto an und überprüfen Sie, ob der Benutzer sich nicht anmelden kann, ohne zuerst das ursprüngliche verwaltete Konto zu entfernen.
Verwaltete melden	- Melden Sie sich bei Ihrer App mit einem verwalteten und einem nicht verwalteten Konto an. - Melden Sie sich vom verwalteten Konto ab. - Vergewissern Sie sich, dass das verwaltete Konto aus Ihrer App entfernt wurde und alle Daten dieses Kontos entfernt wurden. - Vergewissern Sie sich, dass das nicht verwaltete Konto immer noch angemeldet ist, keine der Daten des nicht verwalteten Kontos entfernt wurden und die Richtlinie immer noch nicht angewendet wird.
Abmelden nicht verwaltet	- Melden Sie sich bei Ihrer App mit einem verwalteten und einem nicht verwalteten Konto an. - Melden Sie sich vom nicht verwalteten Konto ab. - Bestätigen Sie, dass das nicht verwaltete Konto aus Ihrer App entfernt wurde und alle Daten dieses Kontos entfernt wurden. - Vergewissern Sie sich, dass das verwaltete Konto weiterhin angemeldet ist, keine Daten des nicht verwalteten Kontos entfernt wurden und die Richtlinie noch angewendet wird.

Überprüfen der aktiven Identität und des Lebenszyklus von Apps

Ihre App für mehrere Identitäten kann Ansichten mit den Daten eines einzelnen Kontos darstellen und dem Benutzer ermöglichen, das aktuell verwendete Konto explizit zu ändern. Es können auch Ansichten mit mehreren Kontodaten gleichzeitig angezeigt werden. Diese Tests tragen dazu bei, dass Ihre Integration mehrerer 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 das Intune-Unternehmensportal; melden Sie sich sowohl mit einem verwalteten als auch mit einem nicht verwalteten Konto an, bevor Sie mit dem Test beginnen.

Szenario	Schritte
Einzelkontoansicht, verwaltet	- Wechseln Sie zum verwalteten Konto. - Navigieren Sie zu allen Seiten in Ihrer App, die die Daten eines einzelnen Kontos präsentieren. - Vergewissern Sie sich, dass die Richtlinie auf jeder 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 präsentieren. - Vergewissern Sie sich, dass die Richtlinie auf keiner Seite angewendet wird.
Ansicht mehrerer Konten	- Navigieren Sie zu allen Seiten in Ihrer App, die die Daten mehrerer Konten gleichzeitig anzeigen. - Vergewissern Sie sich, dass die Richtlinie auf jeder Seite angewendet wird.
Verwaltete Pause	- Halten Sie auf einem Bildschirm mit angezeigten verwalteten Daten und aktiver Richtlinie 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	- Halten Sie auf einem Bildschirm, auf dem nicht verwaltete Daten angezeigt werden und keine Richtlinie aktiv ist, 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 nicht angewendet wird.
Verwaltete Tötung	- Erzwingen Sie auf einem Bildschirm mit angezeigten verwalteten Daten und aktiver Richtlinie das Beenden der App. - Starten Sie die App neu. - Vergewissern Sie sich, dass die Richtlinie weiterhin angewendet wird, wenn die App (erwartet) auf einem Bildschirm mit den Daten des verwalteten Kontos 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 verwaltete Tötung	- Erzwingen Sie auf einem Bildschirm mit nicht verwalteten Daten und aktiver Richtlinie das Beenden der App. - Starten Sie die App neu. - Vergewissern Sie sich, dass die Richtlinie nicht angewendet wird, wenn die App (erwartet) auf einem Bildschirm mit den Daten des nicht verwalteten Kontos fortgesetzt wird. Wenn die App auf einem Bildschirm mit den Daten des verwalteten Kontos fortgesetzt wird, überprüfen Sie, ob die Richtlinie weiterhin angewendet wird.
Ad-hoc-Identitätswechsel	- Experimentieren Sie mit dem Wechseln zwischen Konten und dem Anhalten / Fortsetzen / Beenden / Neustarten der App. - Vergewissern Sie sich, dass die Daten des verwalteten Kontos immer geschützt sind und die Daten des nicht verwalteten Kontos niemals geschützt sind.

Überprüfen von Datenfreigabeszenarien

Ihre Multi-Identity-App kann Daten an andere Apps senden und von diesen empfangen. Die App-Schutzrichtlinien von Intune weisen Einstellungen auf, die dieses Verhalten vorgeben. Diese Tests tragen dazu bei, dass Ihre Integration für mehrere Identitäten diese Einstellungen für die Datenfreigabe berücksichtigt.

Installieren Sie für diese Tests Ihre App und das Intune-Unternehmensportal; melden Sie sich sowohl mit einem verwalteten als auch mit einem nicht verwalteten Konto an, bevor Sie mit dem Test beginnen. Außerdem:

• Legen Sie die Richtlinie des verwalteten Kontos wie folgt fest:
  • "Senden von Organisationsdaten an andere Apps" in "Richtlinienverwaltete Apps".
  • "Daten von anderen Apps empfangen" in "Richtlinienverwaltete Apps".
• Installieren anderer Apps auf dem Testgerät:
  • Eine verwaltete App, die mit derselben Richtlinie wie Ihre App zielgerichtet ist und Daten senden und empfangen kann (wie Microsoft Outlook).
  • Alle nicht verwalteten Apps, die Daten senden und empfangen können.
• Melden Sie sich bei der anderen verwalteten App mit dem verwalteten Testkonto an. Auch wenn die andere verwaltete App mehrere Identitäten besitzt, melden Sie sich nur mit dem verwalteten Konto an.

Wenn Ihre App in der Lage ist, Daten an andere Apps zu senden, z. B. Microsoft Outlook, wenn Sie eine Dokumentanlage an Microsoft Office senden:

Szenario	Schritte
Verwaltete Identität, Senden an nicht verwaltete App	- Wechseln Sie zum verwalteten Konto. - Navigieren Sie zu dem Ort, an den Ihre App Daten senden kann. - Versuchen Sie, Daten an eine nicht verwaltete App zu senden. - Sie sollten daran gehindert werden, Daten an die nicht verwaltete App zu senden.
Verwaltete Identität, Senden an verwaltete App	- 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, bei der das verwaltete Konto angemeldet ist. – Sie sollten Daten an die verwaltete App senden dürfen.
Nicht verwaltete Identität An verwaltete App senden	- 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, bei der das verwaltete Konto angemeldet ist. – Sie sollten daran gehindert werden, Daten an die andere verwaltete App zu senden.
Nicht verwaltete Identität An nicht verwaltete App senden	- Wechseln Sie zum nicht verwalteten Konto. - Navigieren Sie zu dem Ort, an den Ihre App Daten senden kann. - Versuchen Sie, Daten an eine nicht verwaltete App zu senden. - Es sollte Ihnen immer erlaubt 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. aus Microsoft Outlook, das eine Datei aus Microsoft OneDrive anfügt. Ihre App kann auch passiv Daten von anderen Apps empfangen, z. B. beim Öffnen eines Dokuments aus einer Microsoft Outlook-Anlage. Die Richtlinieneinstellung "App-Schutz empfangen" deckt beide Szenarien ab.

Wenn Ihre App über die Möglichkeit verfügt, Daten aus anderen Apps aktiv zu importieren:

Szenario	Schritte
Import verwalteter Identitäten 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. - Versuchen Sie, Daten aus einer nicht verwalteten App zu importieren. - Sie sollten daran gehindert werden, Daten aus nicht verwalteten Apps zu importieren.
Importieren von verwalteten Identitäten aus verwalteter 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 angemeldetem verwalteten Konto zu importieren. - Sie sollten Daten aus der anderen verwalteten App importieren dürfen.
Nicht verwalteter Identitätsimport aus verwalteter 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 angemeldetem verwalteten Konto zu importieren. - Sie sollten am Importieren von Daten aus der anderen verwalteten App gehindert werden.
Nicht verwaltete Identität aus einer nicht verwalteten App importieren	- 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 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 in der Lage ist, passiv Daten von anderen Apps zu empfangen:

Szenario	Schritte
Verwaltete Identität von nicht verwalteter App empfangen	- Wechseln Sie zum verwalteten Konto. - Wechseln Sie zur nicht verwalteten App. - Navigieren Sie dorthin, wohin 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.
Verwaltete Identität von verwalteter App empfangen	- Wechseln Sie zum verwalteten Konto. - Wechseln Sie zur anderen verwalteten App, bei der das verwaltete Konto angemeldet ist. - Navigieren Sie dorthin, wohin Daten gesendet werden können. – Versuchen Sie, Daten aus 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 von verwalteter App empfangen	- Wechseln Sie zum nicht verwalteten Konto. - Wechseln Sie zur anderen verwalteten App, bei der das verwaltete Konto angemeldet ist. - Navigieren Sie dorthin, wohin Daten gesendet werden können. – Versuchen Sie, Daten aus 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 von nicht verwalteter App empfangen	- Wechseln Sie zum nicht verwalteten Konto. - Wechseln Sie zur nicht verwalteten App. - Navigieren Sie dorthin, wohin 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 Daten von der nicht verwalteten App empfangen dürfen.

Fehler in diesen Tests können darauf hinweisen, dass Ihre App nicht die richtige aktive Identität festgelegt hat, wenn sie versucht, Daten zu senden oder zu empfangen. Sie können dies untersuchen, indem Sie die APIs des SDK zum Abrufen von Identitäten zum Zeitpunkt des Sendens/Empfangens nutzen, um zu bestätigen, dass die aktive Identität ordnungsgemäß festgelegt ist.

Überprüfen von Szenarien für selektives Zurücksetzen

Ihre App für mehrere Identitäten hat möglicherweise das standardmäßige Löschverhalten des SDK ergänzt oder überschrieben. Diese Tests tragen dazu bei, dass Ihre Integration für mehrere Identitäten verwaltete Daten ordnungsgemäß entfernt, wenn Zurücksetzungen initiiert werden, ohne dass sich dies auf nicht verwaltete Daten auswirkt.

Warnung

Zur Erinnerung: Wenn Ihre App verwendet hat MAMDataProtectionManager.protectForOID, muss sie einen Handler für entweder WIPE_USER_AUXILIARY_DATA oder WIPE_USER_DATAimplementieren.

Installieren Sie für diese Tests Ihre App und das Intune-Unternehmensportal; melden Sie sich sowohl mit einem verwalteten als auch mit einem nicht verwalteten Konto an, bevor Sie mit dem Test beginnen. Für beide Konten Übungs-App-Szenarien, in denen Kontodaten gespeichert werden.

Szenario	Voraussetzungen	Schritte
Zusätzlicher Löschhandler	Ihre App hat einen Handler für WIPE_USER_AUXILIARY_DATA	- Führen Sie eine selektive Zurücksetzung aus dem Microsoft Intune Admin Center aus. - Vergewissern Sie sich (normalerweise über Protokollierung), dass Ihr Löschhandler erfolgreich ausgeführt wurde. - Vergewissern Sie sich, dass das verwaltete Konto aus Ihrer App entfernt wurde und alle Daten dieses Kontos entfernt wurden. - Vergewissern Sie sich, dass das nicht verwaltete Konto immer noch angemeldet ist, keine der Daten des nicht verwalteten Kontos entfernt wurden und die Richtlinie immer noch nicht angewendet wird.
Überschriebener Löschhandler	Ihre App hat einen Handler für WIPE_USER_DATA	- Führen Sie eine selektive Zurücksetzung aus dem Microsoft Intune Admin Center aus. - Vergewissern Sie sich (normalerweise über Protokollierung), dass Ihr Löschhandler erfolgreich ausgeführt wurde. - Vergewissern Sie sich, dass das verwaltete Konto aus Ihrer App entfernt wurde und alle Daten dieses Kontos entfernt wurden. - Vergewissern Sie sich, dass das nicht verwaltete Konto immer noch angemeldet ist, keine der 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 noch in einem fehlerfreien Zustand befindet, nachdem Ihr Löschhandler beendet ist.
Manueller Dateischutz	- Ihre App-Aufrufe MAMFileProtectionManager.protectForOID - Ihre App hat einen Handler für WIPE_USER_DATA	- Stellen Sie sicher, dass Sie Szenarien ausgeübt haben, in denen Ihre App mindestens eine Datei, die zum verwalteten Konto gehört, manuell schützen würde. - Führen Sie eine selektive Zurücksetzung aus dem Microsoft Intune Admin Center aus. - Bestätigen Sie, dass die Dateien entfernt wurden.
Manueller Datenpufferschutz	- Ihre App-Aufrufe MAMDataProtectionManager.protectForOID - Ihre App hat einen Handler für entweder WIPE_USER_AUXILIARY_DATA oder WIPE_USER_DATA	- Stellen Sie sicher, dass Sie Szenarien ausgeübt haben, in denen Ihre App mindestens einen Datenpuffer, der zum verwalteten Konto gehört, manuell schützen würde. - Führen Sie eine selektive Zurücksetzung aus dem Microsoft Intune Admin Center aus. - Vergewissern Sie sich, dass die Datenpuffer aus den Dateien, in denen sie gespeichert wurden, entfernt wurden und Ihre App die nicht verwalteten Daten aus diesen Dateien weiterhin lesen kann.

Nächste Schritte

Nachdem Sie alle oben genannten Beendigungskriterien erfüllt haben, ist Ihre App nun erfolgreich als Mehrfachidentität integriert und kann App-Schutzrichtlinien auf Identitätsbasis erzwingen. Die nachfolgenden Abschnitte, Phase 6: App Configuration und Phase 7: App-Teilnahmefeatures, sind möglicherweise erforderlich, abhängig von der gewünschten Unterstützung der App-Schutzrichtlinie Ihrer App. Wenn Sie nicht sicher sind, ob einer dieser Abschnitte auf Ihre App zutrifft, lesen Sie erneut die wichtigsten Entscheidungen für die SDK-Integration.