Zestaw SDK aplikacji usługi Intune dla systemu iOS — Multi-Identity

Uwaga

Ten przewodnik jest podzielony na kilka odrębnych etapów. Zacznij od zapoznania się z etapem 1: Planowanie integracji.

Etap 5. Wiele tożsamości (opcjonalnie)

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

Aplikacja musi informować zestaw SDK aplikacji o zamiarze zmiany aktywnej tożsamości. Zestaw SDK powiadamia również aplikację, gdy jest wymagana zmiana tożsamości. Obecnie jest obsługiwana 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ądzaną. Pozostali użytkownicy w aplikacji będą traktowani jako niezarządzani z nieograniczonymi ustawieniami zasad.

Zauważ, że tożsamość jest po prostu zdefiniowana jako ciąg. W tożsamości nie jest uwzględniana wielkość liter. Żądania do zestawu SDK dotyczące tożsamości mogą nie zwracać tej samej wielkości liter, która była pierwotnie używana podczas ustawiania tożsamości.

Cele etapu

  • Określ, czy Twoja aplikacja wymaga obsługi wielu tożsamości.
  • Dowiedz się, jak zestaw SDK aplikacji usługi Intune postrzega tożsamości.
  • Refaktoryzacja aplikacji na potrzeby rozpoznawania tożsamości.
  • Dodaj kod, aby informować zestaw SDK o aktywnych i zmieniających się tożsamościach w całej aplikacji.
  • Dokładnie przetestuj wymuszanie zasad ochrony aplikacji zarówno dla tożsamości zarządzanych, jak i niezarządzanych.

Omówienie tożsamości

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

  • Tożsamość procesu: ustawia tożsamość dla całego procesu i jest używana głównie w przypadku pojedynczych aplikacji tożsamości. Ta tożsamość wpływa 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 wątku głównym, takich jak wycinanie/kopiowanie/wklejanie, numer PIN, uwierzytelnianie i udostępnianie danych. Tożsamość interfejsu użytkownika nie wpływa na zadania związane z plikami, takie jak szyfrowanie i tworzenie kopii zapasowych.

  • Tożsamość wątku: wpływa na to, jakie zasady są stosowane w bieżącym wątku. Ta tożsamość wpływa 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, czy nie.

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 (o ile w ogóle) powinny zostać zastosowane. Jeśli tożsamość to "brak tożsamości" lub użytkownik nie jest zarządzany, żadne zasady nie zostaną zastosowane. Poniższe diagramy przedstawiają sposób określania tożsamości efektywnych.

Intune App SDK iOS: Proces określania 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 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 zbudowany na bazie GCD, NSOperations będzie działał na tożsamości wątku w momencie dodawania zadań do NSOperationQueue. NSOperations lub funkcje wysyłane bezpośrednio przez GCD mogą również zmienić tożsamość bieżącego wątku podczas ich uruchamiania. Ta tożsamość zastąpi tożsamość odziedziczoną po wątku wysyłania.

W języku Swift, ze względu na konsekwencję sposobu, w jaki zestaw SDK propaguje tożsamości dla DispatchWorkItem, tożsamość skojarzona z a DispatchWorkItem jest tożsamością wątku, który utworzył element, a nie wątku, 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 otwierania pliku w trybie obcinania. Właściciel ma ustawioną efektywną tożsamość zadania pliku wątku, który wykonuje zadanie.

Alternatywnie aplikacje mogą jawnie ustawiać tożsamość właściciela pliku, używając plików .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.

Dane udostępnione

Jeśli aplikacja tworzy pliki, które zawierają dane zarówno użytkowników zarządzanych, jak i niezarządzanych, aplikacja odpowiada za szyfrowanie danych zarządzanego użytkownika. Dane można zaszyfrować przy użyciu interfejsów protect API i unprotect w IntuneMAMDataProtectionManagerpliku .

Ta protect metoda akceptuje tożsamość, która może być użytkownikiem zarządzanym lub niezarządzanym. Jeśli użytkownik jest zarządzany, dane będą szyfrowane. Jeśli użytkownik nie jest zarządzany, do danych kodujących tożsamość zostanie dodany nagłówek, ale dane nie będą szyfrowane. Za pomocą tej protectionInfo metody można pobrać właściciela danych.

Udostępnianie rozszerzeń

Jeśli aplikacja ma rozszerzenie udostępniania, właściciela udostępnianego elementu można pobrać za pomocą protectionInfoForItemProvider metody podanej w IntuneMAMDataProtectionManager. Jeśli elementem udostępnionym jest plik, zestaw SDK zajmie się ustawianiem właściciela pliku. Jeśli elementem udostępnionym są dane, aplikacja jest odpowiedzialna za ustawienie właściciela pliku, jeśli te dane są utrwalane w pliku, oraz za wywołanie setUIPolicyAccountId interfejsu API przed wyświetleniem tych danych w interfejsie użytkownika.

Włączanie obsługi 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 z nazwą MultiIdentity i wartością YES do słownika IntuneMAMSettings w pliku Info.plist aplikacji.

Uwaga

Gdy włączona jest obsługa wielu tożsamości, tożsamość procesu, tożsamość interfejsu użytkownika i tożsamości wątków są ustawiane na wartość zero. Aplikacja jest odpowiedzialna za ich odpowiednie ustawienie.

Przełączanie tożsamości

Ważna

Zestaw SDK nie może niezależnie wykrywać zmian tożsamości. Polega całkowicie na aplikacji, która je zgłasza. Jeśli aplikacja nie powiadamia poprawnie zestawu SDK o przełączeniu tożsamości:

  • Zasady ochrony aplikacji mogą nie być wymuszane dla aktywnego użytkownika, pozostawiając zarządzane dane bez ochrony.
  • Dane niezarządzane mogą być niepoprawnie ograniczone.

Aplikacja musi wywoływać odpowiednie interfejsy API przełączania tożsamości (takie jak setUIPolicyAccountId) za każdym razem, gdy aktywny użytkownik dokona zmiany, w tym podczas uruchamiania aplikacji, podczas przełączania konta i podczas wyświetlania danych dla innego użytkownika.

  • Przełączanie tożsamości inicjowane przez aplikację:

    W momencie uruchamiania aplikacje obsługujące wiele tożsamości są uruchamiane w ramach nieznanego, niezarządzanego konta. 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żdorazową zmianę tożsamości. Zazwyczaj dzieje się tak za każdym razem, gdy aplikacja ma zamiar pokazać dane dla określonego konta użytkownika.

    Na przykład użytkownik próbuje otworzyć dokument, skrzynkę pocztową lub kartę w notesie. Aplikacja musi powiadomić zestaw SDK przed otwarciem pliku, skrzynki pocztowej lub karty. Odbywa się to za pomocą setUIPolicyAccountId interfejsu API w IntuneMAMPolicyManager. Ten interfejs API powinien być wywoływany niezależnie od tego, czy użytkownik jest zarządzany, czy nie. Jeśli użytkownik jest zarządzany, zestaw SDK wykona testy uruchamiania warunkowego, takie jak wykrywanie jailbreak, numer PIN i uwierzytelnianie.

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

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

    Aplikacje mogą również ustawiać tożsamość dla bieżącego wątku za pomocą i setCurrentThreadIdentity:setCurrentThreadIdentity:forScope:. Na przykład aplikacja może zduplikować wątek w tle, ustawić tożsamość na tożsamość zarządzaną, a następnie wykonywać operacje na plikach zarządzanych. Jeśli aplikacja używa setCurrentThreadAccountId:, powinna także używać getCurrentThreadAccountId aby móc przywrócić pierwotną tożsamość po zakończeniu. Jeśli jednak aplikacja używa setCurrentThreadAccountId:forScope: , przywrócenie starej tożsamości następuje automatycznie. Preferowane jest używanie setCurrentThreadAccountId:forScope:.

    W formacie swift, ze względu na async/await [IntuneMAMPolicyManager setCurrentThreadAccountId:] i [IntuneMAMPolicyManager setCurrentThreadAccountId:forScope:] nie są dostępne. Zamiast tego w swift, aby ustawić bieżące użycie IntuneMAMSwiftContextManager.setAccountId(_, forScope:)tożsamości . Istnieją warianty tego interfejsu API dla zamknięć asynchronicznych, zgłaszania i asynchronicznego wyrzucania, które mają być przekazywane.

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

    Czasami zestaw SDK musi poprosić aplikację o przełączenie się do określonej tożsamości. Aplikacje korzystające z wielu tożsamości muszą zaimplementować tę metodę identitySwitchRequiredForAccountIdIntuneMAMPolicyDelegate , aby obsłużyć to żądanie.

    Po wywołaniu tej metody, jeśli aplikacja może obsłużyć żądanie przełączenia do określonej tożsamości, powinno ono zostać przekazane IntuneMAMAddIdentityResultSuccess do procedury obsługi uzupełniania. Jeśli nie może obsłużyć przełączania tożsamości, aplikacja powinna przekazać IntuneMAMAddIdentityResultFailed do programu obsługi uzupełniania.

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

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

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

  • Selektywne wycieranie:

    Gdy aplikacja zostanie selektywnie wyczyszczona, zestaw SDK wywoła wipeDataForAccountId metodę w IntuneMAMPolicyDelegate. Aplikacja jest odpowiedzialna za usunięcie konta określonego użytkownika i wszelkich skojarzonych z nim danych. Zestaw SDK jest w stanie usunąć wszystkie pliki należące do użytkownika i zrobi to, jeśli aplikacja zwróci wartość FAŁSZ z wywołania wipeDataForAccountId .

    Należy pamiętać, że ta metoda jest wywoływana z wątku w tle. 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ść FAŁSZ).

Kryteria zakończenia

Zaplanuj poświęcenie znacznej ilości czasu na sprawdzenie poprawności integracji wielu tożsamości w Twojej aplikacji. Zanim rozpoczniesz testowanie:

  • Utwórz i przypisz zasady ochrony aplikacji do konta. Będzie to Twoje testowe konto zarządzane.
  • Utwórz, ale nie przypisz zasad ochrony aplikacji do innego konta. Będzie to Twoje testowe konto niezarządzane. Alternatywnie, jeśli aplikacja obsługuje wiele typów kont poza kontami usługi Microsoft Entra, możesz użyć istniejącego konta innego niż AAD jako niezarządzanego konta testowego.
  • Zapoznaj się ponownie ze sposobem wymuszania zasad w aplikacji. Testowanie wielu tożsamości wymaga łatwego rozróżnienia, kiedy aplikacja działa z wymuszanymi zasadami, a kiedy nie. Ustawienie zasad ochrony aplikacji powodujące blokowanie zrzutów ekranu jest skuteczne w przypadku szybkiego testowania wymuszania zasad.
  • Rozważ cały zestaw elementów interfejsu użytkownika aplikacji. Wylicz ekrany, na których są wyświetlane dane konta. Czy aplikacja zawsze pokazuje jednocześnie dane tylko jednego konta, czy może prezentować dane należące do wielu kont jednocześnie?
  • Uwzględnij cały zestaw plików tworzonych przez aplikację. Wylicz, które z tych plików zawierają dane należące do konta, a nie dane na poziomie systemu.
    • Określ sposób weryfikacji szyfrowania każdego z tych plików.
  • Przeanalizuj cały zestaw sposobów interakcji aplikacji z innymi aplikacjami. Wylicz wszystkie punkty wejścia i wyjścia. Jakie typy danych może pozyskać Twoja aplikacja? Jakie intencje emituje? Jacy dostawcy zawartości są implementowani?
    • Określ sposób korzystania z każdej z tych funkcji udostępniania danych.
    • Przygotuj urządzenie testowe zawierające zarówno zarządzane, jak i niezarządzane aplikacje, które mogą współdziałać z Twoją aplikacją.
  • Zastanów się, w jaki sposób Twoja aplikacja umożliwia użytkownikowi końcowemu interakcję ze wszystkimi zalogowanymi kontami. Czy użytkownik musi ręcznie przełączyć się na konto, aby jego dane były wyświetlane?

Po dokładnym określeniu bieżącego zachowania aplikacji zweryfikuj integrację z wieloma tożsamościami, wykonując poniższy zestaw testów. Pamiętaj, że ta lista nie jest pełna i nie gwarantuje, że implementacja wielu tożsamości w Twojej aplikacji jest wolna od błędów.

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 zmieni nieprawidłowo ochrony podczas logowania lub wylogowywania użytkowników.

Na potrzeby tych testów zainstaluj aplikację na urządzeniu testowym. Nie loguj się przed rozpoczęciem testu.

Scenariusz Kroki
Najpierw zaloguj się zarządzany - Najpierw zaloguj się za pomocą zarządzanego konta i zweryfikuj, czy dane tego konta są zarządzane.
- Zaloguj się przy użyciu konta niezarządzanego i sprawdź, czy dane tego konta nie są zarządzane.
Najpierw zaloguj się niezarządzany - Zaloguj się najpierw przy użyciu konta niezarządzanego i sprawdź, czy dane tego konta nie są zarządzane.
- Zaloguj się za pomocą zarządzanego konta i sprawdź, czy dane tego konta są zarządzane.
Logowanie wielu zarządzanych - Najpierw zaloguj się za pomocą zarządzanego konta i zweryfikuj, czy dane tego konta są zarządzane.
- Zaloguj się przy użyciu drugiego zarządzanego konta i sprawdź, czy użytkownik ma zablokowaną możliwość logowania bez uprzedniego usunięcia pierwotnego zarządzanego konta.
Wylogowanie zarządzane - Zaloguj się do aplikacji zarówno za pomocą zarządzanego, jak i niezarządzanego konta.
- Wyloguj się z zarządzanego konta.
- Upewnij się, że zarządzane konto zostało usunięte z aplikacji, a wszystkie dane tego konta zostały usunięte.
- Upewnij się, że konto niezarządzane jest nadal zalogowane, żadne dane konta niezarządzanego nie zostały usunięte, a zasady nadal nie są stosowane.
Wylogowanie niezarządzane - Zaloguj się do aplikacji zarówno za pomocą zarządzanego, jak i niezarządzanego konta.
- Wyloguj się z konta niezarządzanego.
- Upewnij się, że konto niezarządzane zostało usunięte z aplikacji, a wszystkie dane tego konta zostały usunięte.
- Upewnij się, że zarządzane konto jest nadal zalogowane, żadne dane konta niezarządzanego nie zostały usunięte, a zasady są nadal stosowane.

Sprawdzanie poprawności aktywnej tożsamości i cyklu życia aplikacji

Aplikacja z wieloma tożsamościami może prezentować widoki z danymi jednego konta i umożliwiać użytkownikowi jawną zmianę bieżącego używanego konta. Może również prezentować widoki z danymi wielu kont jednocześnie. Te testy pomagają upewnić się, że integracja z wieloma tożsamościami zapewnia odpowiednią ochronę aktywnej tożsamości na każdej stronie w całym cyklu życia aplikacji.

Na potrzeby 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 jednego klienta, zarządzany - Przełącz się na konto zarządzane.
- Przejdź do wszystkich stron w aplikacji, które prezentują dane jednego konta.
- Upewnij się, że zasady są stosowane na każdej stronie.
Widok jednego konta, niezarządzany - Przełącz się na konto niezarządzane.
- Przejdź do wszystkich stron w aplikacji, które prezentują dane jednego konta.
- Upewnij się, że zasady nie są stosowane na żadnej stronie.
Widok wielu kont - Przejdź do wszystkich stron w aplikacji, które prezentują dane wielu kont jednocześnie.
- Upewnij się, że zasady są stosowane na każdej stronie.
Zarządzana wstrzymanie - 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.
Niezarządzana pauza - 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.
Zabójstwo zarządzane - Na ekranie z wyświetlonymi danymi zarządzanymi i aktywnymi zasadami wymuś zamknięcie aplikacji.
- Uruchom ponownie aplikację.
- Potwierdź, że jeśli aplikacja wznowi działanie na ekranie z danymi zarządzanego konta (oczekiwane), zasady będą nadal stosowane. Jeśli aplikacja wznowi działanie na ekranie z danymi konta niezarządzanego, upewnij się, że zasada nie jest zastosowana.
Niezarządzane zabijanie - Na ekranie z wyświetlonymi danymi niezarządzanymi i aktywnymi zasadami wymuś zabicie aplikacji.
- Uruchom ponownie aplikację.
- Potwierdź, że jeśli aplikacja wznowi działanie na ekranie z danymi konta niezarządzanego (oczekiwane), zasady nie zostaną zastosowane. Jeśli aplikacja wznowi pracę na ekranie z danymi zarządzanego konta, potwierdź, że zasada jest nadal stosowana.
Zmiana tożsamości ad hoc - Eksperymentuj z przełączaniem się między kontami i wstrzymywaniem/wznawianiem/zabijaniem/ponownym uruchamianiem aplikacji.
- Upewnij się, że dane zarządzanego konta są zawsze chronione, a dane niezarządzanego konta nigdy nie są chronione.

Sprawdzanie scenariuszy udostępniania danych

Aplikacja obsługująca wiele tożsamości może wysyłać i odbierać dane z innych aplikacji. Zasady ochrony aplikacji usługi Intune mają ustawienia, które dyktują to zachowanie. Te testy pomagają zapewnić, że integracja z wieloma tożsamościami honoruje te ustawienia udostępniania danych.

Na potrzeby 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" na wartość "Aplikacje zarządzane przez zasady".
    • "Odbieraj dane z innych aplikacji" na wartość "Aplikacje zarządzane przez zasady".
  • Zainstaluj inne aplikacje na urządzeniu testowym:
    • Aplikacja zarządzana podlegająca tym samym zasadom co aplikacja, która może wysyłać i odbierać dane (np. 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 aplikacja zarządzana obsługuje wiele tożsamości, loguj się tylko przy użyciu konta zarządzanego.

Jeśli aplikacja ma możliwość wysyłania danych do innych aplikacji, takich jak Microsoft Outlook wysyłający załącznik dokumentu do pakietu Microsoft Office:

Scenariusz Kroki
Tożsamość zarządzana Wyślij do aplikacji niezarządzanej - Przełącz się na konto zarządzane.
- Przejdź do miejsca, w którym Twoja aplikacja może wysyłać dane.
- Spróbuj wysłać dane do aplikacji niezarządzanej.
- Wysyłanie danych do aplikacji niezarządzanej powinno być zablokowane.
Tożsamość zarządzana Wysyłanie do aplikacji zarządzanej - Przełącz się na konto zarządzane.
- Przejdź do miejsca, w którym Twoja aplikacja może wysyłać dane.
- Spróbuj wysłać dane do innej zarządzanej aplikacji z zalogowanym zarządzanym kontem.
- Powinno być możliwe wysyłanie danych do zarządzanej aplikacji.
Tożsamość niezarządzana Wysyłanie do aplikacji zarządzanej - Przełącz się na konto niezarządzane.
- Przejdź do miejsca, w którym Twoja aplikacja może wysyłać dane.
- Spróbuj wysłać dane do innej zarządzanej aplikacji z zalogowanym zarządzanym kontem.
- Wysyłanie danych do innej zarządzanej aplikacji powinno być zablokowane.
Tożsamość niezarządzana wysyłana do aplikacji niezarządzanej - Przełącz się na konto niezarządzane.
- Przejdź do miejsca, w którym Twoja aplikacja może wysyłać dane.
- Spróbuj wysłać dane do aplikacji niezarządzanej.
- Zawsze powinno się mieć możliwość wysyłania danych konta niezarządzanego do aplikacji niezarządzanej.

Aplikacja może aktywnie importować dane z innych aplikacji, takich jak program Microsoft Outlook, dołączając plik z usługi Microsoft OneDrive. Aplikacja może również pasywnie odbierać dane z innych aplikacji, na przykład otwierać dokument 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ę na konto zarządzane.
- Przejdź do miejsca, w którym Twoja aplikacja może importować dane z innych aplikacji.
- Spróbuj zaimportować dane z aplikacji niezarządzanej.
- Importowanie danych z aplikacji niezarządzanych powinno być zablokowane.
Importowanie tożsamości zarządzanej z aplikacji zarządzanej - Przełącz się na konto zarządzane.
- Przejdź do miejsca, w którym Twoja aplikacja może importować dane z innych aplikacji.
- Spróbuj zaimportować dane z innej zarządzanej aplikacji z zalogowanym kontem zarządzanym.
- Powinno być możliwe importowanie danych z innej zarządzanej aplikacji.
Niezarządzane importowanie tożsamości z aplikacji zarządzanej - Przełącz się na konto niezarządzane.
- Przejdź do miejsca, w którym Twoja aplikacja może importować dane z innych aplikacji.
- Spróbuj zaimportować dane z innej zarządzanej aplikacji z zalogowanym kontem zarządzanym.
- Importowanie danych z innej zarządzanej aplikacji powinno być zablokowane.
Niezarządzane importowanie tożsamości z aplikacji niezarządzanej - Przełącz się na konto niezarządzane.
- Przejdź do miejsca, w którym Twoja aplikacja może importować dane z innych aplikacji.
- Spróbuj zaimportować dane z aplikacji niezarządzanej.
- Zawsze powinno być możliwe importowanie danych z aplikacji niezarządzanych dla konta zarządzanego.

Jeśli aplikacja ma możliwość pasywnego odbierania danych z innych aplikacji:

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

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

Następne kroki

Po spełnieniu wszystkich powyższych kryteriów zakończenia Twoja aplikacja jest teraz pomyślnie zintegrowana jako multi-identity i może wymuszać zasady ochrony aplikacji dla poszczególnych tożsamości. Kolejne sekcje, etap 6: obsługa dostępu warunkowego ochrony aplikacji i etap 7: funkcje widoku sieci Web, mogą, ale nie muszą być wymagane, w zależności od żądanej obsługi zasad ochrony aplikacji aplikacji.

  • Last updated on