zestaw SDK aplikacji Intune dla systemu iOS — wiele tożsamości

Uwaga

Ten przewodnik jest podzielony na kilka odrębnych etapów. Zacznij od przejrzenia etapu 1. Planowanie integracji.

Etap 5. Obsługa wielu tożsamości (opcjonalnie)

Domyślnie zestaw SDK stosuje zasady do całej aplikacji. Wiele tożsamości to funkcja zarządzania aplikacjami mobilnymi, którą można włączyć, aby zastosować zasady na poziomie poszczególnych tożsamości. Wymaga to większego udziału aplikacji niż inne funkcje zarządzania aplikacjami mobilnymi.

Aplikacja musi poinformować zestaw SDK aplikacji, kiedy zamierza zmienić aktywną tożsamość. Zestaw SDK powiadamia również aplikację, gdy wymagana jest zmiana tożsamości. Obecnie obsługiwana jest tylko jedna tożsamość zarządzana. Gdy użytkownik zarejestruje urządzenie lub aplikację, zestaw SDK użyje tej tożsamości i uzna ją za podstawową tożsamość zarządzana. Inni użytkownicy w aplikacji będą traktowani jako niezarządzani przy użyciu nieograniczonych ustawień zasad.

Należy pamiętać, że tożsamość jest po prostu zdefiniowana jako ciąg. Tożsamości nie uwzględniają wielkości liter. Żądania do zestawu SDK tożsamości mogą nie zwracać tej samej wielkości liter, która była pierwotnie używana podczas ustawiania tożsamości.

Goals etapów

• Ustal, czy aplikacja wymaga obsługi wielu tożsamości.
• Dowiedz się, jak zestaw SDK aplikacji Intune postrzega tożsamości.
• Refaktoryzacja aplikacji pod kątem świadomości tożsamości.
• Dodaj kod informujący zestaw SDK o aktywnych i zmieniających się tożsamościach w całej aplikacji.
• Dokładnie przetestuj wymuszanie zasad ochrony aplikacji dla tożsamości zarządzanych i niezarządzanych.

Omówienie tożsamości

Tożsamość to po prostu nazwa użytkownika konta (na przykład user@contoso.com). Deweloperzy mogą ustawić tożsamość aplikacji na następujących poziomach:

• Tożsamość procesu: ustawia tożsamość w całym procesie i jest używana głównie w aplikacjach z jedną tożsamością. Ta tożsamość ma wpływ na wszystkie zadania, pliki i interfejs użytkownika.

• Tożsamość interfejsu użytkownika: określa, jakie zasady są stosowane do zadań interfejsu użytkownika w głównym wątku, takich jak wycinanie/kopiowanie/wklejanie, numer PIN, uwierzytelnianie i udostępnianie danych. Tożsamość interfejsu użytkownika nie ma wpływu na zadania plików, takie jak szyfrowanie i tworzenie kopii zapasowych.

• Tożsamość wątku: wpływa na zasady stosowane w bieżącym wątku. Ta tożsamość ma wpływ na wszystkie zadania, pliki i interfejs użytkownika.

Aplikacja jest odpowiedzialna za odpowiednie ustawianie tożsamości, niezależnie od tego, czy użytkownik jest zarządzany.

W dowolnym momencie każdy wątek ma efektywną tożsamość dla zadań interfejsu użytkownika i zadań plików. Jest to tożsamość używana do sprawdzania, jakie zasady, jeśli istnieją, powinny być stosowane. Jeśli tożsamość jest "bez tożsamości" lub użytkownik nie jest zarządzany, nie zostaną zastosowane żadne zasady. Na poniższych diagramach przedstawiono sposób określania skutecznych tożsamości.

Kolejki wątków

Aplikacje często wysyłają zadania asynchroniczne i synchroniczne do kolejek wątków. Zestaw SDK przechwytuje wywołania usługi Grand Central Dispatch (GCD) i kojarzy bieżącą tożsamość wątku z wysłanymi zadaniami. Po zakończeniu zadań zestaw SDK tymczasowo zmienia tożsamość wątku na tożsamość skojarzoną z zadaniami, kończy zadania, a następnie przywraca oryginalną tożsamość wątku.

Ponieważ NSOperationQueue jest on oparty na GCD, NSOperations będzie uruchamiany na tożsamości wątku w momencie dodania zadań do NSOperationQueue. NSOperations Funkcje wysyłane bezpośrednio za pośrednictwem usługi GCD mogą również zmieniać bieżącą tożsamość wątku podczas ich uruchamiania. Ta tożsamość zastąpi tożsamość dziedziczoną z wątku wysyłania.

Szybko, ze względu na konsekwencje propagacji tożsamości przez zestaw SDK dla DispatchWorkItemprogramu , tożsamość skojarzona z elementem DispatchWorkItem to tożsamość wątku, który utworzył element, a nie wątek, który go wysyła.

Właściciel pliku

Zestaw SDK śledzi tożsamości lokalnych właścicieli plików i odpowiednio stosuje zasady. Właściciel pliku jest ustanawiany podczas tworzenia pliku lub gdy plik jest otwierany w trybie obcinania. Właściciel jest ustawiony na obowiązującą tożsamość zadania pliku wątku, który wykonuje zadanie.

Alternatywnie aplikacje mogą jawnie ustawić tożsamość właściciela pliku przy użyciu polecenia IntuneMAMFilePolicyManager. Aplikacje mogą używać IntuneMAMFilePolicyManager do pobierania właściciela pliku i ustawiania tożsamości interfejsu użytkownika przed wyświetleniem zawartości pliku.

Udostępnione dane

Jeśli aplikacja tworzy pliki, które zawierają dane od użytkowników zarządzanych i niezarządzanych, aplikacja jest odpowiedzialna za szyfrowanie danych zarządzanego użytkownika. Dane można szyfrować przy użyciu protect interfejsów API i unprotect w programie IntuneMAMDataProtectionManager.

Metoda protect akceptuje tożsamość, która może być użytkownikiem zarządzanym lub niezarządzanym. Jeśli użytkownik jest zarządzany, dane zostaną zaszyfrowane. Jeśli użytkownik jest niezarządzany, nagłówek zostanie dodany do danych, które kodują tożsamość, ale dane nie zostaną zaszyfrowane. Możesz użyć metody , protectionInfo aby pobrać właściciela danych.

Udostępnianie rozszerzeń

Jeśli aplikacja ma rozszerzenie udziału, właściciel udostępnionego elementu może zostać pobrany za pośrednictwem metody w IntuneMAMDataProtectionManagerprogramie protectionInfoForItemProvider . Jeśli element udostępniony jest plikiem, zestaw SDK będzie obsługiwać ustawienie właściciela pliku. Jeśli element udostępniony to dane, aplikacja jest odpowiedzialna za ustawienie właściciela pliku, jeśli te dane są utrwalane w pliku, oraz za wywołanie interfejsu setUIPolicyAccountId API przed wyświetleniem tych danych w interfejsie użytkownika.

Włączanie wielu tożsamości

Domyślnie aplikacje są traktowane jako pojedyncza tożsamość. Zestaw SDK ustawia tożsamość procesu na zarejestrowanego użytkownika. Aby włączyć obsługę wielu tożsamości, dodaj ustawienie logiczne o nazwie MultiIdentity i wartości YES do słownika IntuneMAMSettings w pliku Info.plist aplikacji.

Uwaga

Po włączeniu wielu tożsamości tożsamość procesu, tożsamość interfejsu użytkownika i tożsamości wątków są ustawione na zero. Aplikacja jest odpowiedzialna za ich odpowiednie ustawienie.

Przełączanie tożsamości

• Przełącznik tożsamości inicjowany przez aplikację:

  Podczas uruchamiania aplikacje z wieloma tożsamościami są uważane za uruchomione na nieznanym, niezarządzanym koncie. Interfejs użytkownika uruchamiania warunkowego nie zostanie uruchomiony i żadne zasady nie będą wymuszane w aplikacji. Aplikacja jest odpowiedzialna za powiadamianie zestawu SDK za każdym razem, gdy tożsamość powinna zostać zmieniona. Zazwyczaj dzieje się tak za każdym razem, gdy aplikacja ma wyświetlać dane dla określonego konta użytkownika.

  Przykładem jest próba otwarcia dokumentu, skrzynki pocztowej lub karty w notesie przez użytkownika. Aplikacja musi powiadomić zestaw SDK przed faktycznym otwarciem pliku, skrzynki pocztowej lub karty. Odbywa się to za pośrednictwem interfejsu API w programie setUIPolicyAccountIdIntuneMAMPolicyManager. Ten interfejs API powinien być wywoływany niezależnie od tego, czy użytkownik jest zarządzany. Jeśli użytkownik jest zarządzany, zestaw SDK przeprowadzi testy uruchamiania warunkowego, takie jak wykrywanie jailbreaka, numer PIN i uwierzytelnianie.

  Wynik przełącznika tożsamości jest zwracany do aplikacji asynchronicznie za pośrednictwem procedury obsługi uzupełniania. Aplikacja powinna odroczyć otwarcie dokumentu, skrzynki pocztowej lub karty do momentu zwrócenia kodu wyniku sukcesu. Jeśli przełączanie tożsamości nie powiodło się, aplikacja powinna anulować zadanie.

  Aplikacje z wieloma tożsamościami powinny unikać używania setProcessAccountId jako sposobu ustawiania tożsamości. Aplikacje korzystające z interfejsu użytkownika powinny używać interfejsu setUIPolicyAccountId:forWindow API do ustawiania tożsamości.

  Aplikacje mogą również ustawić tożsamość bieżącego wątku przy użyciu elementów setCurrentThreadIdentity: i setCurrentThreadIdentity:forScope:. Na przykład aplikacja może zduplikować wątek w tle, ustawić tożsamość na tożsamość zarządzaną, a następnie wykonać operacje na plikach zarządzanych. Jeśli aplikacja korzysta z setCurrentThreadAccountId:programu , aplikacja powinna również używać polecenia getCurrentThreadAccountId , aby mogła przywrócić oryginalną tożsamość po jej zakończeniu. Jeśli jednak aplikacja korzysta setCurrentThreadAccountId:forScope: z funkcji przywracania starej tożsamości, nastąpi to automatycznie. Preferowane jest użycie polecenia setCurrentThreadAccountId:forScope:.

  Szybko, z powodu asynchroniczności/oczekiwania, [IntuneMAMPolicyManager setCurrentThreadAccountId:] i [IntuneMAMPolicyManager setCurrentThreadAccountId:forScope:] nie są dostępne. Zamiast tego należy szybko ustawić bieżącą tożsamość za pomocą polecenia IntuneMAMSwiftContextManager.setAccountId(_, forScope:). Istnieją warianty tego interfejsu API na potrzeby asynchroniczno-rzucanych i asynchroniczno-zgłaszanych zamknięć, które mają zostać przekazane.

• Przełącznik tożsamości inicjowany przez zestaw SDK:

  Czasami zestaw SDK musi poprosić aplikację o przełączenie się na określoną tożsamość. Aplikacje obsługujące wiele tożsamości muszą zaimplementować metodę w systemie identitySwitchRequiredForAccountId w IntuneMAMPolicyDelegate celu obsługi tego żądania.

  Jeśli ta metoda jest wywoływana, jeśli aplikacja może obsłużyć żądanie przełączenia się do określonej tożsamości, powinna przejść IntuneMAMAddIdentityResultSuccess do procedury obsługi uzupełniania. Jeśli nie może obsłużyć przełączania tożsamości, aplikacja powinna przejść IntuneMAMAddIdentityResultFailed do procedury obsługi uzupełniania.

  Aplikacja nie musi wywoływać w setUIPolicyAccountId odpowiedzi na to wywołanie. Jeśli zestaw SDK wymaga, aby aplikacja przełączyła się na niezarządzane konto użytkownika, pusty ciąg zostanie przekazany do identitySwitchRequiredForAccountId wywołania.

• Automatyczna rejestracja tożsamości zainicjowana przez zestaw SDK:

  Gdy zestaw SDK musi automatycznie zarejestrować użytkownika w aplikacji, aby wykonać akcję, aplikacje muszą zaimplementować addIdentity:completionHandler: metodę w programie IntuneMAMPolicyDelegate. Następnie aplikacja musi wywołać procedurę obsługi uzupełniania i przekazać polecenie IntuneMAMAddIdentityResultSuccess, jeśli aplikacja może dodać tożsamość lub IntuneMAMAddIdentityResultFailed w przeciwnym razie.

• Selektywne czyszczenie:

  Po selektywnym wyczyszczeniu aplikacji zestaw SDK wywoła wipeDataForAccountId metodę w pliku IntuneMAMPolicyDelegate. Aplikacja jest odpowiedzialna za usunięcie konta określonego użytkownika i wszystkich skojarzonych z nim danych. Zestaw SDK może usunąć wszystkie pliki należące do użytkownika i zrobi to, jeśli aplikacja zwróci wartość FALSE z wipeDataForAccountId wywołania.

  Należy pamiętać, że ta metoda jest wywoływana z wątku tła. Aplikacja nie powinna zwracać wartości, dopóki wszystkie dane użytkownika nie zostaną usunięte (z wyjątkiem plików, jeśli aplikacja zwróci wartość FALSE).

Kryteria zakończenia

Zaplanuj poświęcenie znacznego czasu na zweryfikowanie integracji aplikacji z wieloma tożsamościami. Przed rozpoczęciem testowania:

• Twórca i przypisz zasady ochrony aplikacji do konta. Będzie to testowe konto zarządzane.
• Twórca, ale nie przypisuj zasad ochrony aplikacji do innego konta. Będzie to testowe konto niezarządzane. Alternatywnie, jeśli aplikacja obsługuje wiele typów kont poza kontami Microsoft Entra, możesz użyć istniejącego konta innego niż AAD jako niezarządzanego konta testowego.
• Ponownie zaaplikuj sobie sposób wymuszania zasad wewnątrz aplikacji. Testowanie wielu tożsamości wymaga łatwego rozróżnienia, kiedy aplikacja jest i nie działa z wymuszonymi zasadami. Ustawienie zasad ochrony aplikacji do blokowania zrzutów ekranu jest skuteczne w szybkim testowaniu wymuszania zasad.
• Rozważ cały zestaw interfejsu użytkownika, który oferuje Twoja aplikacja. Wylicz ekrany, na których są wyświetlane dane konta. Czy aplikacja wyświetla tylko dane pojedynczego konta jednocześnie, czy może jednocześnie przedstawia dane należące do wielu kont?
• Rozważmy cały zestaw plików tworzonych przez aplikację. Wylicz, które z tych plików zawierają dane należące do konta, w przeciwieństwie do danych na poziomie systemu.
  • Określ, w jaki sposób będziesz weryfikować szyfrowanie każdego z tych plików.
• Rozważ cały zestaw sposobów interakcji aplikacji z innymi aplikacjami. Wylicz wszystkie punkty ruchu przychodzącego i wychodzącego. Jakie typy danych może pozyskiwać aplikacja? Jakie intencje emituje? Jakich dostawców zawartości implementuje?
  • Określ sposób wykonywania każdej z tych funkcji udostępniania danych.
  • Przygotuj urządzenie testowe z aplikacjami zarządzanymi i niezarządzanymi, które mogą wchodzić w interakcje z twoją aplikacją.
• Zastanów się, w jaki sposób aplikacja umożliwia użytkownikowi końcowemu interakcję ze wszystkimi zalogowanymi kontami. Czy użytkownik musi ręcznie przełączyć się na konto przed wyświetleniem danych tego konta?

Po dokładnej ocenie bieżącego zachowania aplikacji zweryfikuj integrację z wieloma tożsamościami, wykonując następujący zestaw testów. Pamiętaj, że nie jest to kompleksowa lista i nie gwarantuje, że implementacja wielu tożsamości aplikacji jest wolna od usterek.

Weryfikowanie scenariuszy logowania i wylogowywania

Aplikacja z wieloma tożsamościami obsługuje maksymalnie 1 konto zarządzane i wiele kont niezarządzanych. Te testy pomagają zapewnić, że integracja z wieloma tożsamościami nie zmienia nieprawidłowo ochrony podczas logowania lub wylogowyowania użytkowników.

W przypadku tych testów zainstaluj aplikację na urządzeniu testowym. nie loguj się przed rozpoczęciem testu.

Scenariusz	Kroki
Zaloguj się jako pierwszy zarządzany	— Zaloguj się najpierw przy użyciu konta zarządzanego i sprawdź, czy dane konta są zarządzane. — Zaloguj się przy użyciu konta niezarządzanego i sprawdź, czy dane konta nie są zarządzane.
Najpierw zaloguj się niezarządzane	— Zaloguj się najpierw przy użyciu konta niezarządzanego i sprawdź, czy dane konta nie są zarządzane. — Zaloguj się przy użyciu konta zarządzanego i sprawdź, czy dane konta są zarządzane.
Logowanie wielu zarządzanych	— Zaloguj się najpierw przy użyciu konta zarządzanego i sprawdź, czy dane konta są zarządzane. — Zaloguj się przy użyciu drugiego zarządzanego konta i sprawdź, czy użytkownik nie może zalogować się bez uprzedniego usunięcia oryginalnego konta zarządzanego.
Wyloguj zarządzane	— Zaloguj się do aplikacji przy użyciu zarządzanego konta niezarządzanego. — Wyloguj się z konta zarządzanego. — Upewnij się, że konto zarządzane zostało usunięte z aplikacji i wszystkie dane tego konta zostały usunięte. — Upewnij się, że konto niezarządzane jest nadal zalogowane, żadne z danych niezarządzanego konta nie zostało usunięte, a zasady nadal nie są stosowane.
Wyloguj niezarządzane	— Zaloguj się do aplikacji przy użyciu zarządzanego konta niezarządzanego. — Wyloguj się z konta niezarządzanego. — Upewnij się, że konto niezarządzane zostało usunięte z aplikacji i wszystkie dane tego konta zostały usunięte. — Upewnij się, że konto zarządzane jest nadal zalogowane, żadne z danych niezarządzanego konta nie zostało usunięte i zasady są nadal stosowane.

Weryfikowanie aktywnej tożsamości i cyklu życia aplikacji

Aplikacja z wieloma tożsamościami może przedstawiać widoki z danymi jednego konta i zezwalać użytkownikowi na jawną zmianę bieżącego konta w użyciu. Może również przedstawiać widoki z danymi wielu kont w tym samym czasie. Te testy pomagają zapewnić, że integracja z wieloma tożsamościami zapewnia właściwą ochronę aktywnej tożsamości na każdej stronie w całym cyklu życia aplikacji.

W przypadku tych testów zainstaluj aplikację na urządzeniu testowym. Przed rozpoczęciem testu zaloguj się przy użyciu konta zarządzanego i niezarządzanego.

Scenariusz	Kroki
Widok pojedynczego konta, zarządzany	— Przełącz się do konta zarządzanego. — Przejdź do wszystkich stron w aplikacji, które przedstawiają dane pojedynczego konta. — Upewnij się, że zasady są stosowane na każdej stronie.
Widok pojedynczego konta, niezarządzany	— Przejdź do konta niezarządzanego. — Przejdź do wszystkich stron w aplikacji, które przedstawiają dane pojedynczego konta. — Upewnij się, że zasady nie są stosowane na żadnej stronie.
Widok z wieloma kontami	— Przejdź do wszystkich stron w aplikacji, które jednocześnie przedstawiają dane wielu kont. — Upewnij się, że zasady są stosowane na każdej stronie.
Wstrzymanie zarządzane	— Na ekranie z wyświetlonymi danymi zarządzanymi i aktywnymi zasadami wstrzymaj aplikację, przechodząc do ekranu głównego urządzenia lub innej aplikacji. — Wznów aplikację. — Upewnij się, że zasady są nadal stosowane.
Wstrzymanie niezarządzane	— Na ekranie z wyświetlonymi danymi niezarządzanymi i bez aktywnych zasad wstrzymaj aplikację, przechodząc do ekranu głównego urządzenia lub innej aplikacji. — Wznów aplikację. — Upewnij się, że zasady nie są stosowane.
Zarządzane zabijanie	— Na ekranie z wyświetlonymi danymi zarządzanymi i aktywnymi zasadami wymuś zabicie aplikacji. — Uruchom ponownie aplikację. — Upewnij się, że jeśli aplikacja zostanie wznowiona na ekranie z danymi konta zarządzanego (oczekiwane), zasady będą nadal stosowane. Jeśli aplikacja zostanie wznowiona na ekranie z danymi niezarządzanego konta, upewnij się, że zasady nie są stosowane.
Niezarządzane zabijanie	— Na ekranie z wyświetlonymi danymi niezarządzanymi i aktywnymi zasadami wymuś zabicie aplikacji. — Uruchom ponownie aplikację. — Upewnij się, że jeśli aplikacja zostanie wznowiona na ekranie z danymi niezarządzanego konta (oczekiwane), zasady nie zostaną zastosowane. Jeśli aplikacja zostanie wznowiona na ekranie z danymi konta zarządzanego, upewnij się, że zasady są nadal stosowane.
Przełącznik tożsamości ad hoc	— Eksperyment przełączania między kontami i wstrzymywania / wznawiania / zabijania / ponownego uruchamiania aplikacji. — Upewnij się, że dane konta zarządzanego są zawsze chronione, a dane niezarządzanego konta nigdy nie są chronione.

Weryfikowanie scenariuszy udostępniania danych

Aplikacja z wieloma tożsamościami może wysyłać dane do innych aplikacji i odbierać je z innych aplikacji. Zasady ochrony aplikacji Intune mają ustawienia, które dyktują to zachowanie. Te testy pomagają zapewnić, że integracja z wieloma tożsamościami uwzględnia te ustawienia udostępniania danych.

W przypadku tych testów zainstaluj aplikację na urządzeniu testowym. Przed rozpoczęciem testu zaloguj się przy użyciu konta zarządzanego i niezarządzanego. Dodatkowo:

• Ustaw zasady konta zarządzanego jako:
  • "Wyślij dane organizacji do innych aplikacji" do "Aplikacje zarządzane przez zasady".
  • "Odbieranie danych z innych aplikacji" do "Aplikacje zarządzane przez zasady".
• Zainstaluj inne aplikacje na urządzeniu testowym:
  • Zarządzana aplikacja, przeznaczona dla tych samych zasad co aplikacja, która może wysyłać i odbierać dane (na przykład Microsoft Outlook).
  • Dowolna niezarządzana aplikacja, która może wysyłać i odbierać dane.
• Zaloguj się do innej zarządzanej aplikacji przy użyciu zarządzanego konta testowego. Nawet jeśli druga zarządzana aplikacja ma wiele tożsamości, zaloguj się tylko przy użyciu konta zarządzanego.

Jeśli aplikacja może wysyłać dane do innych aplikacji, takich jak program Microsoft Outlook, wysyłając załącznik dokumentu do pakietu Microsoft Office:

Scenariusz	Kroki
Tożsamość zarządzana wysyłana do aplikacji niezarządzanej	— Przełącz się do konta zarządzanego. — Przejdź do miejsca, w którym aplikacja może wysyłać dane. — Spróbuj wysłać dane do niezarządzanej aplikacji. — Powinno zostać zablokowane wysyłanie danych do niezarządzanej aplikacji.
Tożsamość zarządzana wysyłana do aplikacji zarządzanej	— Przełącz się do konta zarządzanego. — Przejdź do miejsca, w którym aplikacja może wysyłać dane. — Spróbuj wysłać dane do innej aplikacji zarządzanej przy użyciu zalogowanego konta zarządzanego. — Powinno być dozwolone wysyłanie danych do aplikacji zarządzanej.
Wysyłanie tożsamości niezarządzanej do aplikacji zarządzanej	— Przejdź do konta niezarządzanego. — Przejdź do miejsca, w którym aplikacja może wysyłać dane. — Spróbuj wysłać dane do innej aplikacji zarządzanej przy użyciu zalogowanego konta zarządzanego. — Wysyłanie danych do innej zarządzanej aplikacji powinno być zablokowane.
Wysyłanie tożsamości niezarządzanej do aplikacji niezarządzanej	— Przejdź do konta niezarządzanego. — Przejdź do miejsca, w którym aplikacja może wysyłać dane. — Spróbuj wysłać dane do niezarządzanej aplikacji. — Zawsze powinno być dozwolone wysyłanie danych niezarządzanego konta do niezarządzanej aplikacji.

Aplikacja może aktywnie importować dane z innych aplikacji, takich jak program Microsoft Outlook dołączający plik z usługi Microsoft OneDrive. Aplikacja może również pasywnie odbierać dane z innych aplikacji, takich jak otwieranie dokumentu z załącznika programu Microsoft Outlook w pakiecie Microsoft Office. Ustawienie zasad odbierania ochrony aplikacji obejmuje oba scenariusze.

Jeśli aplikacja ma możliwość aktywnego importowania danych z innych aplikacji:

Scenariusz	Kroki
Importowanie tożsamości zarządzanej z aplikacji niezarządzanej	— Przełącz się do konta zarządzanego. — przejdź do miejsca, w którym aplikacja może importować dane z innych aplikacji. — Spróbuj zaimportować dane z niezarządzanej aplikacji. — Importowanie danych z niezarządzanych aplikacji powinno być zablokowane.
Importowanie tożsamości zarządzanej z aplikacji zarządzanej	— Przełącz się do konta zarządzanego. — przejdź do miejsca, w którym aplikacja może importować dane z innych aplikacji. — Spróbuj zaimportować dane z innej aplikacji zarządzanej przy użyciu zalogowanego konta zarządzanego. — Powinno być dozwolone importowanie danych z innej zarządzanej aplikacji.
Importowanie tożsamości niezarządzanych z aplikacji zarządzanej	— Przejdź do konta niezarządzanego. — przejdź do miejsca, w którym aplikacja może importować dane z innych aplikacji. — Spróbuj zaimportować dane z innej aplikacji zarządzanej przy użyciu zalogowanego konta zarządzanego. — Importowanie danych z innej aplikacji zarządzanej powinno być zablokowane.
Importowanie tożsamości niezarządzanych z niezarządzanej aplikacji	— Przejdź do konta niezarządzanego. — przejdź do miejsca, w którym aplikacja może importować dane z innych aplikacji. — Spróbuj zaimportować dane z niezarządzanej aplikacji. — Zawsze powinno być dozwolone importowanie danych z niezarządzanej aplikacji dla konta niezarządzanego.

Jeśli aplikacja może pasywnie odbierać dane z innych aplikacji:

Scenariusz	Kroki
Tożsamość zarządzana odbierana z aplikacji niezarządzanej	— Przełącz się do konta zarządzanego. — Przełącz się do aplikacji niezarządzanej. — Przejdź do miejsca, w którym może wysyłać dane. — Spróbuj wysłać dane z niezarządzanej aplikacji do aplikacji. — Konto zarządzane aplikacji nie powinno mieć możliwości odbierania danych z niezarządzanej aplikacji.
Tożsamość zarządzana odbierana z aplikacji zarządzanej	— Przełącz się do konta zarządzanego. — Przełącz się do innej aplikacji zarządzanej z zalogowanym kontem zarządzanym. — Przejdź do miejsca, w którym może wysyłać dane. — Spróbuj wysłać dane z aplikacji zarządzanej do aplikacji. — Konto zarządzane aplikacji powinno mieć możliwość odbierania danych z innej aplikacji zarządzanej.
Odbieranie tożsamości niezarządzanej z aplikacji zarządzanej	— Przejdź do konta niezarządzanego. — Przełącz się do innej aplikacji zarządzanej z zalogowanym kontem zarządzanym. — Przejdź do miejsca, w którym może wysyłać dane. — Spróbuj wysłać dane z aplikacji zarządzanej do aplikacji. — Niezarządzane konto aplikacji nie powinno mieć możliwości odbierania danych z zarządzanej aplikacji.
Odbieranie tożsamości niezarządzanej z niezarządzanej aplikacji	— Przejdź do konta niezarządzanego. — Przełącz się do aplikacji niezarządzanej. — Przejdź do miejsca, w którym może wysyłać dane. — Spróbuj wysłać dane z niezarządzanej aplikacji do aplikacji. — Konto niezarządzane aplikacji powinno zawsze mieć możliwość odbierania danych z niezarządzanej aplikacji.

Błędy w tych testach mogą wskazywać, że aplikacja nie ma odpowiedniej aktywnej tożsamości ustawionej podczas próby wysłania lub odebrania danych. Możesz to zbadać, korzystając z interfejsów API uzyskiwania tożsamości zestawu SDK w momencie wysyłania/odbierania, aby potwierdzić, że aktywna tożsamość jest prawidłowo ustawiona.

Następne kroki

Po zakończeniu wszystkich powyższych kryteriów zakończenia aplikacja została pomyślnie zintegrowana jako wiele tożsamości i może wymuszać zasady ochrony aplikacji na podstawie poszczególnych tożsamości. Kolejne sekcje, Etap 6: Obsługa dostępu warunkowego usługi App Protection i Etap 7: Funkcje widoku internetowego, mogą być wymagane, w zależności od wymaganej obsługi zasad ochrony aplikacji.