Intune App SDK für iOS – Mehrere Identitäten

Hinweis

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

Phase 5: Mehrere Identitäten (optional)

Standardmäßig wendet das SDK eine Richtlinie auf die App als Ganzes an. Multi-Identity ist ein MAM-Feature, das Sie aktivieren können, um eine Richtlinie auf Identitätsebene anzuwenden. Dies erfordert mehr App-Teilnahme als andere MAM-Features.

Die App muss das App SDK informieren, wenn die aktive Identität geändert werden soll. 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 mit uneingeschränkten Richtlinieneinstellungen als nicht verwaltet 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 verwendet wurde, als die Identität festgelegt wurde.

Stage Goals

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

Identitätsübersicht

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 Einzelidentitätsanwendungen verwendet. Diese Identität wirkt sich auf alle Aufgaben, Dateien und Die Benutzeroberfläche aus.

• Benutzeroberflächenidentität: Legt fest, welche Richtlinien auf Benutzeroberflächenaufgaben im Standard Thread angewendet werden, z. B. Ausschneiden/Kopieren/Einfügen, PIN, Authentifizierung und Datenfreigabe. Die Benutzeroberflächenidentität wirkt sich nicht auf Dateiaufgaben wie Verschlüsselung und Sicherung aus.

• Threadidentität: Wirkt sich darauf aus, 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 dafür verantwortlich, die Identitäten entsprechend festzulegen, unabhängig davon, ob der Benutzer verwaltet wird oder nicht.

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

Threadwarteschlangen

Apps senden häufig asynchrone und synchrone Aufgaben an Threadwarteschlangen. Das SDK fängt Grand Central Dispatch-Aufrufe (GCD) 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 Identität, die den Aufgaben zugeordnet ist, beendet die Aufgaben und stellt dann die ursprüngliche Threadidentität wieder her.

Da NSOperationQueue auf GCD basiert, NSOperations wird auf der Identität des Threads ausgeführt, wenn die Aufgaben zu NSOperationQueuehinzugefügt werden. NSOperations oder Funktionen, die direkt über GCD verteilt werden, können auch die aktuelle Threadidentität ändern, während sie ausgeführt werden. Diese Identität überschreibt die vom Verteilerthread geerbte Identität.

Aufgrund der Art und Weise, wie das SDK Identitäten für DispatchWorkItemweitergibt, ist die Identität, die einem DispatchWorkItem zugeordnet ist, die Identität des Threads, der das Element erstellt hat, nicht der Thread, der es verteilt.

Dateibesitzer

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

Alternativ können Apps die Identität des Dateibesitzers mithilfe von IntuneMAMFilePolicyManagerexplizit festlegen. Apps können verwenden IntuneMAMFilePolicyManager , um den Dateibesitzer abzurufen und die Benutzeroberflächenidentität festzulegen, bevor der Dateiinhalt angezeigt wird.

Freigegebene Daten

Wenn die App Dateien erstellt, die Daten sowohl von verwalteten als auch von 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 APIs und unprotect in IntuneMAMDataProtectionManagerverschlüsseln.

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.

Freigabeerweiterungen

Wenn die App über eine Freigabeerweiterung verfügt, kann der Besitzer des freigegebenen Elements über die protectionInfoForItemProvider -Methode in IntuneMAMDataProtectionManagerabgerufen werden. Wenn das freigegebene Element eine Datei ist, übernimmt das SDK das Festlegen des Dateibesitzers. Wenn das freigegebene Element Daten ist, ist die App dafür verantwortlich, den Dateibesitzer festzulegen, wenn diese Daten in einer Datei gespeichert werden, und für den Aufruf der setUIPolicyAccountId API, bevor diese Daten auf der Benutzeroberfläche angezeigt werden.

Aktivieren von mehreren Identitä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 mehrere Identitäten aktiviert sind, werden die Prozessidentität, die Benutzeroberflächenidentität und die Threadidentitäten auf null festgelegt. Die App ist dafür verantwortlich, sie entsprechend festzulegen.

Identitäten wechseln

• Von der 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 den bedingten Start wird nicht ausgeführt, und es werden keine Richtlinien für die App erzwungen. Die App ist dafür verantwortlich, das SDK zu benachrichtigen, wenn die Identität geändert werden soll. In der Regel geschieht dies immer dann, wenn die App Daten für ein bestimmtes Benutzerkonto anzeigen soll.

  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 erfolgt über die setUIPolicyAccountId API in IntuneMAMPolicyManager. Diese API sollte unabhängig davon aufgerufen werden, ob der Benutzer verwaltet wird. Wenn der Benutzer verwaltet wird, führt das SDK die Überprüfungen zum bedingten Start durch, z. B. jailbreak-Erkennung, PIN und Authentifizierung.

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

  Apps mit mehreren Identitäten sollten die Verwendung setProcessAccountId von als Möglichkeit zum Festlegen der Identität vermeiden. 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 mithilfe von 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 verwendet setCurrentThreadAccountId:, sollte die App auch verwenden getCurrentThreadAccountId , damit sie die ursprüngliche Identität wiederherstellen kann, sobald dies abgeschlossen ist. Wenn die App jedoch verwendet setCurrentThreadAccountId:forScope: , erfolgt die Wiederherstellung der alten Identität automatisch. Es wird empfohlen, zu verwenden setCurrentThreadAccountId:forScope:.

  In swift, aufgrund von async/await [IntuneMAMPolicyManager setCurrentThreadAccountId:] und [IntuneMAMPolicyManager setCurrentThreadAccountId:forScope:] sind nicht verfügbar. Verwenden Sie IntuneMAMSwiftContextManager.setAccountId(_, forScope:)stattdessen in swift, um die aktuelle Identität festzulegen. Es gibt Varianten dieser API für asynchrone, auslösende und asynchrone Auslösen von Schließ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 in IntuneMAMPolicyDelegate implementieren, 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 Vervollständigungshandler übergeben IntuneMAMAddIdentityResultSuccess werden. Wenn der Wechsel der Identität nicht möglich ist, sollte die App an den Vervollständigungshandler übergeben IntuneMAMAddIdentityResultFailed werden.

  Die App muss als Reaktion auf diesen Aufruf nicht aufrufen setUIPolicyAccountId . Wenn das SDK die App zum Wechseln 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 Vervollständigungshandler aufrufen und IntuneMAMAddIdentityResultSuccess übergeben, wenn die App die Identität oder Andernfalls IntuneMAMAddIdentityResultFailed hinzufügen kann.

• Selektives Zurücksetzen:

  Wenn die App selektiv zurückgesetzt wird, ruft das SDK die wipeDataForAccountId -Methode in IntuneMAMPolicyDelegateauf. Die App ist dafür verantwortlich, das konto des angegebenen Benutzers 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 FALSE aus dem wipeDataForAccountId Aufruf zurückgibt.

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

Exitkriterien

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

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

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

Überprüfen von Anmelde- und Abmeldeszenarien

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

Installieren Sie für diese Tests Ihre App auf einem Testgerät. melden Sie sich nicht an, bevor Sie den Test starten.

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

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

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

Installieren Sie für diese Tests Ihre App auf einem Testgerät. Melden Sie sich sowohl mit einem verwalteten als auch mit einem nicht verwalteten Konto an, bevor Sie den Test starten.

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

Überprüfen von Datenfreigabeszenarien

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

Installieren Sie für diese Tests Ihre App auf einem Testgerät. Melden Sie sich sowohl mit einem verwalteten als auch mit einem nicht verwalteten Konto an, bevor Sie den Test starten. Außerdem:

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

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

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

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

Wenn Ihre App aktiv Daten aus anderen Apps importieren kann:

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

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

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

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

Nächste Schritte

Nachdem Sie alle oben genannten Exitkriterien erfüllt haben, ist Ihre App nun erfolgreich als Multiidentität integriert und kann App-Schutzrichtlinien auf Identitätsbasis erzwingen. In den folgenden Abschnitten, Phase 6: Unterstützung für bedingten Zugriff für App-Schutz und Phase 7: Webansichtsfeatures, sind abhängig von der unterstützung der gewünschten App-Schutzrichtlinie für Ihre App möglicherweise erforderlich.