Intune App SDK für iOS – Multi-Identity

Hinweis

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

Phase 5: Mehrfachidentität (optional)

Standardmäßig wendet das SDK eine Richtlinie auf die App als Ganzes an. Mehrfachidentität ist ein MAM-Feature, das Sie aktivieren können, um eine Richtlinie auf Identitätsebene anzuwenden. Dies erfordert eine stärkere App-Beteiligung als andere MAM-Features.

Die App muss das App-SDK informieren, wenn es beabsichtigt, die aktive Identität zu ändern. Das SDK benachrichtigt die App auch, wenn eine Identitätsänderung erforderlich ist. Derzeit wird nur eine verwaltete Identität unterstützt. Nachdem der Benutzer das Gerät oder die App registriert hat, verwendet das SDK diese Identität und betrachtet sie als primäre verwaltete Identität. Andere Benutzer in der App werden als nicht verwaltet mit uneingeschränkten Richtlinieneinstellungen behandelt.

Beachten Sie, dass eine Identität einfach als Zeichenfolge definiert wird. Bei Identitäten 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 ursprünglich beim Festlegen der Identität verwendet wurde.

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.

Identity overview

Eine Identität ist einfach der Benutzername eines Kontos (z. B user@contoso.com. ). Entwickler können die Identität der App auf den folgenden Ebenen festlegen:

• Prozessidentität: Legt die prozessweite Identität fest und wird hauptsächlich für Anwendungen mit einer einzelnen Identität verwendet. Diese Identität wirkt sich auf alle Aufgaben, Dateien und die Benutzeroberfläche aus.

• UI-Identität: Bestimmt, welche Richtlinien auf UI-Aufgaben im Hauptthread angewendet werden, z. B. Ausschneiden/Kopieren/Einfügen, PIN, Authentifizierung und Datenfreigabe. Die Identität der Benutzeroberfläche hat keinen Einfluss auf Dateiaufgaben wie Verschlüsselung und Sicherung.

• Thread-Identität: Beeinflusst, welche Richtlinien auf den aktuellen Thread angewendet werden. Diese Identität wirkt sich auf alle Aufgaben, Dateien und die Benutzeroberfläche aus.

Die App ist für das entsprechende Festlegen der Identitäten verantwortlich, unabhängig davon, ob der Benutzer verwaltet wird oder nicht.

Jeder Thread verfügt jederzeit über eine effektive Identität für Benutzeroberflächen- und Dateiaufgaben. Dies ist die Identität, die verwendet wird, um zu überprüfen, welche Richtlinien gegebenenfalls angewendet werden sollen. Wenn die Identität "keine Identität" lautet oder der Benutzer nicht verwaltet wird, werden keine Richtlinien angewendet. Die folgenden Diagramme zeigen, wie die effektiven Identitäten bestimmt werden.

Threadwarteschlangen

Apps verteilen häufig asynchrone und synchrone Aufgaben an Threadwarteschlangen. Das SDK fängt Grand Central Dispatch (GCD)-Aufrufe ab und ordnet die aktuelle Threadidentität den verteilten Aufgaben zu. Wenn die Aufgaben abgeschlossen sind, ändert das SDK vorübergehend die Threadidentität in die den Aufgaben zugeordnete Identität, beendet die Aufgaben und stellt dann die ursprüngliche Threadidentität wieder her.

Weil NSOperationQueue auf GCD aufgebaut ist, NSOperations wird mit der Identität des Threads zum Zeitpunkt des Hinzufügens NSOperationQueueder Aufgaben ausgeführt. NSOperations oder Funktionen, die direkt über GCD verteilt werden, können auch die aktuelle Threadidentität während der Ausführung ändern. Diese Identität überschreibt die vom dispatching-Thread geerbte Identität.

In swift ist die mit einem DispatchWorkItem verbundenen Identität aufgrund einer Konsequenz der Weitergabe von Identitäten durch DispatchWorkItemdas SDK die Identität des Threads, der das Element erstellt hat, nicht des Threads, der es verteilt.

Dateibesitzer

Das SDK verfolgt die Identitäten lokaler Dateibesitzer und wendet Richtlinien entsprechend an. Ein Dateibesitzer wird eingerichtet, wenn eine Datei erstellt oder wenn eine Datei im Abbruchmodus geöffnet wird. Der Besitzer ist auf die effektive Dateiaufgabenidentität des Threads festgelegt, der die Aufgabe ausführt.

Alternativ können Apps die Identität des Dateibesitzers explizit mithilfe von IntuneMAMFilePolicyManagerfestlegen. Apps können verwendet werden IntuneMAMFilePolicyManager , um den Dateibesitzer abzurufen und die Identität der Benutzeroberfläche festzulegen, bevor der Dateiinhalt angezeigt wird.

Freigegebene Daten

Wenn die App Dateien erstellt, die Daten von verwalteten und nicht verwalteten Benutzern enthalten, ist die App für die Verschlüsselung der Daten des verwalteten Benutzers verantwortlich. Sie können Daten mithilfe der protect und-APIs unprotect in .IntuneMAMDataProtectionManager

Die protect Methode akzeptiert eine Identität, bei der es sich um einen verwalteten oder nicht verwalteten Benutzer handeln kann. Wenn der Benutzer verwaltet wird, werden die Daten verschlüsselt. Wenn der Benutzer nicht verwaltet wird, wird den Daten, die die Identität codieren, ein Header hinzugefügt, aber die Daten werden nicht verschlüsselt. Sie können die protectionInfo Methode verwenden, um den Besitzer der Daten abzurufen.

Erweiterungen freigeben

Wenn die App über eine Freigabeerweiterung verfügt, kann der Besitzer des freigegebenen Elements mithilfe der protectionInfoForItemProvider Methode in IntuneMAMDataProtectionManagerabgerufen werden. Wenn es sich bei dem freigegebenen Element um eine Datei handelt, übernimmt das SDK die Festlegung des Dateibesitzers. Wenn es sich bei dem freigegebenen Element um Daten handelt, ist die App dafür verantwortlich, den Dateibesitzer festzulegen, wenn diese Daten in einer Datei gespeichert werden, und die API aufzurufen setUIPolicyAccountId , bevor diese Daten auf der Benutzeroberfläche angezeigt werden.

Aktivieren von Mehrfachidentitäten

Standardmäßig werden Apps als einzelne Identität betrachtet. Das SDK legt die Prozessidentität auf den registrierten Benutzer fest. Um die Unterstützung mehrerer Identitäten zu aktivieren, fügen Sie dem IntuneMAMSettings-Wörterbuch in der Datei Info.plist der App eine boolesche Einstellung mit dem Namen MultiIdentity und dem Wert YES hinzu.

Hinweis

Wenn Mehrfachidentität aktiviert ist, werden die Prozessidentität, die Benutzeroberflächenidentität und die Threadidentitäten auf null festgelegt. Die App ist dafür verantwortlich, sie entsprechend festzulegen.

Wechseln von Identitäten

Wichtig

Das SDK kann Identitätsänderungen nicht unabhängig erkennen. Es verlässt sich vollständig auf die App, um sie zu melden. Wenn die App das SDK nicht ordnungsgemäß über einen Identitätswechsel informiert:

• Richtlinien zum App-Schutz werden für den aktiven Benutzer möglicherweise nicht erzwungen, sodass verwaltete Daten ungeschützt bleiben.
• Nicht verwaltete Daten sind möglicherweise fälschlicherweise eingeschränkt.

Die App muss die entsprechenden Identitätswechsel-APIs (z. B setUIPolicyAccountId. ) aufrufen, wenn sich der aktive Benutzer ändert, einschließlich beim App-Start, beim Kontowechsel und beim Anzeigen von Daten für einen anderen Benutzer.

• App-initiierter Identitätswechsel:

  Beim Start werden Apps mit mehreren Identitäten als unter einem unbekannten, nicht verwalteten Konto ausgeführt. Die Benutzeroberfläche für bedingten Start wird nicht ausgeführt, und für die App werden keine Richtlinien erzwungen. Die App ist dafür verantwortlich, das SDK zu benachrichtigen, wenn die Identität geändert werden soll. Dies geschieht in der Regel immer dann, wenn die App Daten für ein bestimmtes Benutzerkonto anzeigen möchte.

  Ein Beispiel ist, wenn der Benutzer versucht, ein Dokument, ein Postfach oder eine Registerkarte in einem Notizbuch zu öffnen. Die App muss das SDK benachrichtigen, bevor die Datei, das Postfach oder die Registerkarte tatsächlich geöffnet wird. Dies geschieht über die setUIPolicyAccountId API in IntuneMAMPolicyManager. Diese API sollte unabhängig davon aufgerufen werden, ob der Benutzer verwaltet wird oder nicht. Wenn der Benutzer verwaltet wird, führt das SDK die Überprüfungen für bedingte Starts durch, z. B. Jailbreak-Erkennung, PIN und Authentifizierung.

  Das Ergebnis des Identitätswechsels wird asynchron über einen Abschlusshandler an die App zurückgegeben. Die App sollte das Öffnen des Dokuments, des Postfachs oder der Registerkarte verschieben, bis ein Erfolgsergebniscode zurückgegeben wird. Wenn der Identitätswechsel fehlgeschlagen ist, sollte die App die Aufgabe abbrechen.

  Apps mit mehreren Identitäten sollten nicht als Methode zum Festlegen der Identität verwendet werden setProcessAccountId . Apps, die UIScenes verwenden, sollten die setUIPolicyAccountId:forWindow API verwenden, um die Identität festzulegen.

  Apps können die Identität für den aktuellen Thread auch mit setCurrentThreadIdentity: und setCurrentThreadIdentity:forScope:festlegen. Beispielsweise kann die App einen Hintergrundthread erzeugen, die Identität auf die verwaltete Identität festlegen und dann Dateivorgänge für verwaltete Dateien ausführen. Wenn die App setCurrentThreadAccountId:verwendet , sollte die App auch verwenden getCurrentThreadAccountId , damit die ursprüngliche Identität wiederhergestellt werden kann, sobald dies abgeschlossen ist. Wenn die App setCurrentThreadAccountId:forScope: jedoch verwendet, erfolgt die Wiederherstellung der alten Identität automatisch. Es wird empfohlen, " zu verwenden setCurrentThreadAccountId:forScope:.

  In swift, due to async/await [IntuneMAMPolicyManager setCurrentThreadAccountId:] und [IntuneMAMPolicyManager setCurrentThreadAccountId:forScope:] sind nicht verfügbar. Stattdessen verwenden Sie in swift, um die aktuelle Identität IntuneMAMSwiftContextManager.setAccountId(_, forScope:)festzulegen. Es gibt Varianten dieser API für asynchrone, auslösende und asynchrone Wurfschließungen, die übergeben werden sollen.

• SDK-initiierter Identitätswechsel:

  Manchmal muss das SDK die App auffordern, zu einer bestimmten Identität zu wechseln. Apps mit mehreren Identitäten müssen die identitySwitchRequiredForAccountId Methode implementieren IntuneMAMPolicyDelegate , um diese Anforderung zu verarbeiten.

  Wenn diese Methode aufgerufen wird und die App die Anforderung zum Wechseln zur angegebenen Identität verarbeiten kann, sollte sie an den Abschlusshandler übergeben IntuneMAMAddIdentityResultSuccess werden. Wenn sie den Wechsel der Identität nicht verarbeiten kann, sollte die App an den Abschlusshandler übergeben werden IntuneMAMAddIdentityResultFailed .

  Die App muss als Reaktion auf diesen Aufruf keinen Anruf tätigen setUIPolicyAccountId . Wenn das SDK die App zum Wechsel zu einem nicht verwalteten Benutzerkonto benötigt, wird die leere Zeichenfolge an den identitySwitchRequiredForAccountId Aufruf übergeben.

• SDK-initiierte automatische Identitätsregistrierung:

  Wenn das SDK einen Benutzer automatisch in der App registrieren muss, um eine Aktion auszuführen, müssen Apps die addIdentity:completionHandler: Methode in IntuneMAMPolicyDelegateimplementieren. Die Anwendung muss dann den Abschlusshandler aufrufen und IntuneMAMAddIdentityResultSuccess übergeben, wenn die App die Identität oder andernfalls IntuneMAMAddIdentityResultFailed hinzufügen kann.

• Selektives Löschen:

  Wenn die App selektiv zurückgesetzt wird, ruft das SDK die wipeDataForAccountId Methode in IntuneMAMPolicyDelegateauf. Die App ist dafür verantwortlich, das angegebene Benutzerkonto und alle damit verbundenen Daten zu entfernen. Das SDK kann alle Dateien entfernen, die sich im Besitz des Benutzers befinden, und tut dies, wenn die App nach dem wipeDataForAccountId Aufruf FALSE zurückgibt.

  Beachten Sie, dass diese Methode aus einem Hintergrundthread aufgerufen wird. Die App sollte erst dann einen Wert zurückgeben, wenn alle Daten für den Benutzer entfernt wurden (mit Ausnahme von Dateien, wenn die App FALSCH zurückgibt).

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-AAD-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 Ihre App für diese Tests auf einem Testgerät. 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 Ihre App für diese Tests auf einem Testgerät. 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 Ihre App für diese Tests auf einem Testgerät. 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.

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, Stufe 6: Unterstützung des bedingten App-Zugriffs und Phase 7: Webansichtsfeatures, sind möglicherweise erforderlich, abhängig von der gewünschten Unterstützung der App-Schutzrichtlinie für Ihre App.