Zestaw SDK aplikacji usługi Intune dla systemu Android — wiele tożsamości

Zestaw SDK aplikacji Microsoft Intune dla systemu Android umożliwia włączenie zasad ochrony aplikacji usługi Intune (znanych również jako zasady aplikacji lub zarządzania aplikacjami mobilnymi) do natywnej aplikacji Java/Kotlin dla systemu Android. Aplikacja zarządzana przez usługę Intune jest zintegrowana z zestawem SDK aplikacji usługi Intune. Administratorzy usługi Intune mogą łatwo wdrażać zasady ochrony aplikacji w aplikacji zarządzanej przez usługę Intune, gdy usługa Intune aktywnie zarządza aplikacją.

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

Goals etapów

• Ustal, czy aplikacja wymaga obsługi wielu tożsamości.
• Dowiedz się, jak zestaw SDK aplikacji usługi 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.

Terminologia tożsamości

Terminy "użytkownik", "konto" i "tożsamość" są często używane zamiennie. Ten przewodnik próbuje odróżnić w następujący sposób:

• Użytkownik: człowiek korzystający z oprogramowania. Bardziej zróżnicowany jako użytkownik końcowy, człowiek korzystający z aplikacji systemu Android i / administrator / administrator itadmin / IT Pro, człowiek korzystający z centrum administracyjnego Microsoft Intune.
• Konto: rekord oprogramowania należący do organizacji, który jednoznacznie identyfikuje jednostkę użytkownika. Użytkownik może mieć wiele kont.
• Tożsamość: zestaw danych używany przez zestaw SDK aplikacji usługi Intune do unikatowego identyfikowania konta.

Tło

Domyślnie zestaw SDK aplikacji usługi Intune stosuje zasady do całej aplikacji. Po zarejestrowaniu konta w zasadach ochrony aplikacji zestaw SDK kojarzy każdy plik i każde działanie z tożsamością tego konta i stosuje zasady docelowe tego konta w sposób uniwersalny.

Dla wielu deweloperów jest to pożądane zachowanie ochrony aplikacji dla aplikacji. Te aplikacje są traktowane jako pojedyncza tożsamość. Po ukończeniu poprzednich etapów aplikacja została pomyślnie zintegrowana jako pojedyncza tożsamość i może wymuszać wszystkie podstawowe zasady. Aplikacje, które mają pozostać pojedynczą tożsamością, mogą pominąć tę sekcję i przejść do etapu 6: App Configuration.

Zestaw SDK aplikacji usługi Intune może opcjonalnie wymuszać zasady na poziomie poszczególnych tożsamości. Jeśli aplikacja obsługuje już wiele kont zalogowanych jednocześnie i chcesz zachować obsługę wielu kont przy użyciu zasad ochrony aplikacji, aplikacja jest traktowana jako wieloaspektowa.

Porada

Jeśli nie masz pewności, czy aplikacja powinna obsługiwać ochronę jednej tożsamości lub wielu tożsamości, zapoznaj się z artykułem Czy moja aplikacja ma jedną tożsamość lub wiele tożsamości?

Ostrzeżenie

Obsługa wielu tożsamości jest znacznie bardziej złożona niż inne funkcje ochrony aplikacji. Niewłaściwa integracja wielu tożsamości może spowodować wycieki danych i inne problemy z zabezpieczeniami. Dokładnie przejrzyj tę sekcję i zaplanuj czas testowania przed przejściem do następnego etapu.

"Tożsamość" do zestawu SDK

Gdy aplikacja zintegrowana z zestawem SDK rejestruje konto przy użyciu funkcji registerAccountForMAM, zestaw SDK zapisuje jako tożsamość wszystkie podane parametry (upn, aadId, tenantId i authority). Jednak większość interfejsów API tożsamości zestawu SDK używa tylko podanej nazwy upn jako skrótu dla tożsamości. Te interfejsy API będą zwracać tylko ciąg nazwy upn jako tożsamość i wymagają tylko parametru ciągu nazwy upn dla tożsamości.

Tożsamości nie uwzględniają wielkości liter. Żądania do zestawu SDK dotyczące tożsamości mogą nie zwracać tej samej wielkości liter, która była używana podczas rejestrowania lub ustawiania tożsamości.

Porada

W przyszłości interfejsy API zestawu SDK mogą przedstawiać bardziej całościową strukturę tożsamości, która obejmuje wszystkie pola podane w czasie rejestracji konta, a nie tylko nazwę upn. Podczas integrowania obsługi wielu tożsamości upewnij się, że aplikacja ma również dostęp do identyfikatora aadId, identyfikatora dzierżawy i urzędu podczas ustawiania tożsamości przy użyciu bieżących interfejsów API.

Tożsamości zarządzane i niezarządzane

Zgodnie z opisem w temacie Rejestrowanie zasad ochrony aplikacji aplikacja jest odpowiedzialna za informowanie zestawu SDK podczas logowania użytkownika. W momencie logowania konto użytkownika może lub nie musi być objęte zasadami ochrony aplikacji. Jeśli konto jest objęte zasadami ochrony aplikacji, zestaw SDK uzna je za zarządzane. W przeciwnym razie jest niezarządzany.

Zestaw SDK wymusi zasady dla tożsamości, które uważa za zarządzane. Zestaw SDK nie będzie wymuszać zasad dla tożsamości, które uważa za niezarządzane.

Obecnie zestaw SDK aplikacji usługi Intune obsługuje tylko jedną tożsamość zarządzaną na urządzenie. Gdy tylko dowolna aplikacja zintegrowana z zestawem SDK zarejestruje tożsamość zarządzaną, wszystkie później zarejestrowane tożsamości, nawet jeśli są obecnie objęte zasadami ochrony aplikacji, będą traktowane jako niezarządzane.

Jeśli tożsamość zarządzana została już zarejestrowana na urządzeniu, a aplikacja rejestruje inną tożsamość, która jest również objęta zasadami ochrony aplikacji, zestaw SDK zwróci MAMEnrollmentManager.Result.WRONG_USER i wyświetli użytkownikowi końcowemu monit o opcje korygowania. Aby uzyskać więcej szczegółów, zobacz Rejestrowanie powiadomień z zestawu SDK .

Uwaga

Konto, które nie jest objęte zasadami ochrony aplikacji w czasie rejestracji, zostanie uznane za niezarządzane. Nawet jeśli konto nie jest licencjonowane lub objęte zasadami ochrony aplikacji, zestaw SDK okresowo sprawdza, czy to konto zostanie licencjonowane i objęte później. Jeśli żadna inna tożsamość zarządzana nie została zarejestrowana, zestaw SDK zacznie traktować tę tożsamość jako zarządzaną, gdy zostanie ona objęta zasadami. Aby wprowadzić tę zmianę, użytkownik nie musi wylogowywać się i logować się z powrotem na to konto.

Tożsamość aktywna

Aplikacja musi zawsze informować zestaw SDK o tożsamości, która jest aktualnie używana, w przeciwnym razie nazywanej aktywną tożsamością. Jeśli aktywna tożsamość jest zarządzana, zestaw SDK zastosuje ochronę. Jeśli aktywna tożsamość nie jest zarządzana, zestaw SDK nie zastosuje ochrony.

Ponieważ zestaw SDK nie ma wiedzy specyficznej dla aplikacji, musi ufać aplikacji, aby udostępnić poprawną aktywną tożsamość.

• Jeśli aplikacja niepoprawnie informuje zestaw SDK, że tożsamość niezarządzana jest aktywna, gdy tożsamość zarządzana jest faktycznie używana, zestaw SDK nie zastosuje ochrony. Może to spowodować wyciek danych, który naraża dane użytkowników na niebezpieczeństwo.

• Jeśli aplikacja niepoprawnie informuje zestaw SDK, że tożsamość zarządzana jest aktywna, gdy tożsamość niezarządzana jest rzeczywiście używana, zestaw SDK niewłaściwie zastosuje zabezpieczenia. Nie jest to wyciek danych, ale może to niepotrzebnie ograniczać niezarządzanych użytkowników i narażać dane niezarządzanych użytkowników na ryzyko usunięcia.

Jeśli aplikacja wyświetla dane dowolnego użytkownika, musi wyświetlać tylko dane należące do aktywnej tożsamości. Jeśli aplikacja nie wie obecnie, kto jest właścicielem wyświetlanych danych, może być konieczne refaktoryzowanie aplikacji w celu zwiększenia świadomości tożsamości przed rozpoczęciem integracji obsługi wielu tożsamości.

Organizowanie danych aplikacji według tożsamości

Za każdym razem, gdy aplikacja zapisuje nowy plik, zestaw SDK kojarzy tożsamość (znaną również jako "tagi") z tym plikiem na podstawie bieżącego aktywnego wątku i tożsamości procesu. Alternatywnie aplikacja może bezpośrednio wywołać zestaw SDK, aby ręcznie oznaczyć plik przy użyciu określonej tożsamości (szczegóły można znaleźć w temacie Pisanie plików chronionych ). Zestaw SDK używa tej otagowanej tożsamości pliku zarówno do szyfrowania plików, jak i selektywnego czyszczenia.

Jeśli tożsamość zarządzana jest objęta zasadami szyfrowania, szyfrowane będą tylko pliki oznaczone tożsamością zarządzaną.

Jeśli akcja administratora lub skonfigurowane żądania zasad, aby dane zarządzane zostały wyczyszczone, zostaną usunięte tylko pliki oznaczone tożsamością zarządzaną.

Zestaw SDK nie może skojarzyć wielu tożsamości z jednym plikiem. Jeśli aplikacja przechowuje dane należące do wielu użytkowników w tym samym pliku, domyślne zachowanie zestawu SDK spowoduje niedostateczną ochronę lub nadmierną ochronę tych danych. Zdecydowanie zachęcamy do organizowania danych aplikacji według tożsamości.

Jeśli aplikacja musi przechowywać dane należące do różnych tożsamości w tym samym pliku, zestaw SDK udostępnia funkcje do tagowania tożsamości podzbiorów danych w pliku. Aby uzyskać szczegółowe informacje, zobacz Ochrona buforu danych .

Implementowanie wielu tożsamości

Aby zadeklarować obsługę wielu tożsamości dla aplikacji, zacznij od umieszczenia następujących metadanych w AndroidManifest.xml.

  <meta-data
    android:name="com.microsoft.intune.mam.MAMMultiIdentity"
    android:value="true" />

Ustawianie aktywnej tożsamości

Twoja aplikacja może ustawić aktywną tożsamość na następujących poziomach z priorytetem malejącym:

1. Poziom wątku
2. Context (ogólnie rzecz biorąc Activity) Poziom
3. Poziom procesu

Tożsamość ustawiona na poziomie wątku zastępuje tożsamość ustawioną na Context poziomie, który zastępuje tożsamość ustawioną na poziomie procesu.

Tożsamość ustawiona na serwerze Context jest używana tylko w odpowiednich skojarzonych scenariuszach. Na przykład operacje we/wy plików nie mają skojarzonej operacji Context. Najczęściej aplikacje ustawiają Context tożsamość na .Activity Rozważ ustawienie tożsamości w programie ContextActivity.onCreate. Aplikacja nie może wyświetlać danych dla tożsamości, chyba że Activity tożsamość jest ustawiona na tę samą tożsamość.

Ogólnie rzecz biorąc, tożsamość na poziomie procesu jest przydatna tylko wtedy, gdy aplikacja działa tylko z jedną tożsamością jednocześnie we wszystkich wątkach. Nie jest to typowe zachowanie w przypadku aplikacji, które obsługują wiele kont. Zdecydowanie zachęcamy do segregowania danych konta i ustawiania aktywnej tożsamości na wątku lub Context poziomach.

Jeśli aplikacja używa kontekstu Application do uzyskiwania usług systemowych, upewnij się, że ustawiono tożsamość wątku lub procesu lub że ustawiono tożsamość interfejsu użytkownika w kontekście aplikacji Application .

Jeśli aplikacja używa kontekstu Service do uruchamiania intencji, używa rozpoznawania zawartości lub korzysta z innych usług systemowych, należy ustawić tożsamość w Service kontekście. Podobnie jeśli aplikacja używa kontekstu JobService do wykonywania tych akcji, należy ustawić tożsamość w kontekście lub wątku JobService zgodnie z wymaganiami JobService implementacji. Jeśli na przykład przetwarzasz JobService zadania dla jednej tożsamości, rozważ ustawienie tożsamości w JobService kontekście. Jeśli zadania JobService procesów dla wielu tożsamości, rozważ ustawienie tożsamości na poziomie wątku.

Uwaga

Aplikacje, które używają WorkManager , powinny zachować szczególną ostrożność podczas ustawiania tożsamości. W szczególności te aplikacje powinny unikać ustawiania tożsamości przekazanej Context w konstruktorze Worker . To Context wystąpienie może być współużytkowane jednocześnie przez wiele Worker wystąpień. Aby uniknąć niezdefiniowanego zachowania, aplikacje powinny zamiast tego ustawić tożsamość wątku zgodnie Worker.doWork() z wymaganiami implementacji Worker .

Uwaga

CLIPBOARD_SERVICE Ponieważ element jest używany do operacji interfejsu użytkownika, zestaw SDK używa tożsamości interfejsu użytkownika działania pierwszego planu dla ClipboardManager operacji.

Poniższe metody w narzędziu MAMPolicyManager mogą służyć do ustawiania aktywnej tożsamości i pobierania wcześniej ustawionych wartości tożsamości.

public static void setUIPolicyIdentity(final Context context, final String identity, final MAMSetUIIdentityCallback mamSetUIIdentityCallback,
final EnumSet<IdentitySwitchOption> options);

public static String getUIPolicyIdentity(final Context context);

public static MAMIdentitySwitchResult setProcessIdentity(final String identity);

public static String getProcessIdentity();

public static MAMIdentitySwitchResult setCurrentThreadIdentity(final String identity);

public static String getCurrentThreadIdentity();

/**
 * Get the current app policy. This does NOT take the UI (Context) identity into account.
 * If the current operation has any context (e.g. an Activity) associated with it, use the overload below.
 */
public static AppPolicy getCurrentThreadPolicy();

/**
 * Get the current app policy. This DOES take the UI (Context) identity into account.
 * If the current operation has any context (e.g. an Activity) associated with it, use this function.
 */
public static AppPolicy getPolicy(final Context context);


public static AppPolicy getPolicyForIdentity(final String identity);

public static boolean getIsIdentityManaged(final String identity);

Dla wygody można również ustawić tożsamość działania bezpośrednio za pośrednictwem metody w funkcji MAMActivity zamiast wywoływania MAMPolicyManager.setUIPolicyIdentity. W tym celu użyj następującej metody:

     public final void switchMAMIdentity(final String newIdentity, final EnumSet<IdentitySwitchOption> options);

Uwaga

Jeśli aplikacja nie zadeklarowała obsługi wielu tożsamości w manifeście, wywołanie tych metod w celu ustawienia tożsamości nie spowoduje wykonania żadnej akcji, a jeśli zwróci MAMIdentitySwitchResultelement , zawsze zwróci FAILEDwartość .

Typowe pułapki dotyczące przełącznika tożsamości

• W przypadku wywołań do startActivityzestawu SDK aplikacji usługi Intune założono, że aktywna tożsamość na Context poziomie jest skojarzona z podanym parametrem Intent . Zdecydowanie zalecamy ustawienie Context tożsamości poziomu z kontekstem Activity's, a nie kontekstem Application.'s.

• Context Zalecane jest ustawienie tożsamości podczas metody działaniaonCreate. Należy jednak pamiętać o innych punktach wejścia, takich jak onNewIntent. W przeciwnym razie, gdy to samo działanie jest ponownie używane do wyświetlania danych zarówno dla tożsamości zarządzanych, jak i niezarządzanych, zasady mogą być niepoprawnie stosowane, co prowadzi do niechronionych danych firmowych lub nieprawidłowo ograniczonych danych osobowych.

Wyniki przełącznika tożsamości

Wszystkie metody służące do ustawiania wartości wyników raportu tożsamości z powrotem za pośrednictwem funkcji MAMIdentitySwitchResult. Istnieją cztery wartości, które można zwrócić:

Zwracana wartość	Scenariusz
SUCCEEDED	Zmiana tożsamości zakończyła się pomyślnie.
NOT_ALLOWED	Zmiana tożsamości nie jest dozwolona. Dzieje się tak, jeśli podjęto próbę ustawienia tożsamości interfejsu użytkownika (Context), gdy w bieżącym wątku ustawiono inną tożsamość.
CANCELLED	Użytkownik anulował zmianę tożsamości, zazwyczaj naciskając przycisk Wstecz w numerze PIN lub wierszu polecenia uwierzytelniania.
FAILED	Zmiana tożsamości nie powiodła się z nieokreślonego powodu.

Aplikacja powinna sprawdzić, czy element MAMIdentitySwitchResult znajduje SUCCEEDED się przed wyświetleniem lub użyciem danych konta zarządzanego.

Większość metod ustawiania aktywnej tożsamości zwraca synchronicznie wartość MAMIdentitySwitchResult . W przypadku ustawienia tożsamości za pośrednictwem ContextsetUIPolicyIdentity wynik jest raportowany asynchronicznie. Aplikacja może zaimplementować obiekt MAMSetUIIdentityCallback , aby otrzymać ten wynik, lub może przekazać wartość null dla obiektu wywołania zwrotnego. Jeśli wywołanie zostanie wykonane, setUIPolicyIdentity gdy wynik poprzedniego wywołania w setUIPolicyIdentitytym samym kontekście nie został jeszcze dostarczony, nowe wywołanie zwrotne zastąpi stare, a oryginalne wywołanie zwrotne nigdy nie otrzyma wyniku.

Uwaga

Context Jeśli podana wartość setUIPolicyIdentity to Activity, zestaw SDK nie wie, czy zmiana tożsamości powiodła się, dopóki nie zostanie przeprowadzona skonfigurowana przez administratora kontrola uruchamiania warunkowego. Może to wymagać od użytkownika wprowadzenia numeru PIN lub poświadczeń firmowych.

Obecnie przełączniki tożsamości procesów i wątków zawsze będą kończyć się powodzeniem dla aplikacji obsługującej wiele tożsamości. Zestaw SDK zastrzega sobie prawo do dodawania warunków awarii w przyszłości.

Przełącznik tożsamości interfejsu użytkownika może zakończyć się niepowodzeniem w przypadku nieprawidłowych argumentów, jeśli spowoduje to konflikt z tożsamością wątku lub jeśli użytkownik anuluje wymagania dotyczące uruchamiania warunkowego (na przykład naciska przycisk wstecz na ekranie numeru PIN).

Domyślnym zachowaniem nieudanego przełącznika tożsamości interfejsu użytkownika w działaniu jest zakończenie działania. Aby zmienić to zachowanie i otrzymywać powiadomienia o próbach zmiany tożsamości dla działania, możesz zastąpić metodę w programie MAMActivity.

    public void onSwitchMAMIdentityComplete(final MAMIdentitySwitchResult result);

Jeśli zastąpisz onSwitchMAMIdentityComplete (lub wywołasz super metodę), musisz upewnić się, że dane konta zarządzanego nie są wyświetlane po nieudanym przełączniku tożsamości.

Uwaga

Przełączenie tożsamości może wymagać ponownego utworzenia działania. W takim przypadku wywołanie onSwitchMAMIdentityComplete zwrotne zostanie dostarczone do nowego wystąpienia działania.

Identity, Intents i IdentitySwitchOptions

Oprócz automatycznego tagowania nowych plików przy użyciu aktywnej tożsamości zestaw SDK taguje również intencje przy użyciu aktywnej tożsamości. Domyślnie zestaw SDK sprawdzi tożsamość w intencji przychodzącej i porówna ją z aktywną tożsamością. Jeśli te tożsamości nie są zgodne, zestaw SDK zwykle (*) żąda przełącznika tożsamości (zobacz niejawne zmiany tożsamości poniżej, aby uzyskać więcej szczegółów).

Zestaw SDK przechowuje również tę tożsamość intencji przychodzącej do późniejszego użycia. Gdy aplikacja jawnie zmienia tożsamość interfejsu użytkownika, zestaw SDK porównuje tożsamość, na która próbuje przełączyć się aplikacja, z najnowszą tożsamością intencji przychodzącej. Jeśli te tożsamości nie są zgodne, zestaw SDK zazwyczaj (*) nie przełączy tożsamości.

Zestaw SDK wykonuje to sprawdzanie, ponieważ zakłada, że aplikacja nadal wyświetla zawartość z intencji należącej do tożsamości otagowanej w intencji. To założenie chroni przed niezamierzonym wyłączeniem ochrony aplikacji podczas wyświetlania danych zarządzanych; jednak to założenie może nie być poprawne dla rzeczywistego zachowania aplikacji.

Opcjonalne wyliczenia IdentitySwitchOption można przekazać do jednostki setUIPolicyIdentity i switchMAMIdentity w celu zmodyfikowania domyślnego zachowania zestawu SDK.

• IGNORE_INTENT: podczas żądania przełącznika tożsamości w warstwie interfejsu użytkownika ta opcja informuje zestaw SDK o pominięciu porównywania żądanego parametru tożsamości z ostatnio przechowywaną tożsamością intencji. Jest to przydatne, gdy aplikacja nie wyświetla już zawartości należącej do tej tożsamości, a zestaw SDK nie powinien blokować tego przełącznika tożsamości. Przykład:

  1. Aplikacja jest przeglądarką dokumentów. Może renderować dokumenty przekazywane z innych aplikacji. Zawiera również funkcję, w której użytkownicy mogą przełączać konta. Za każdym razem, gdy użytkownik korzysta z tej funkcji przełączania konta, aplikacja przechodzi do strony docelowej specyficznej dla konta z najnowszymi dokumentami tego konta.
  2. Aplikacja otrzymuje zamiar wyświetlenia dokumentu. Ta intencja jest oznaczana tożsamością zarządzaną.
  3. Aplikacja została przełączona na tożsamość zarządzana i wyświetla ten dokument z prawidłowo zastosowanymi zabezpieczeniami.
  4. Użytkownik używa przełącznika konta do zmiany konta osobistego.

  Aplikacja musi zmienić tożsamość interfejsu użytkownika w kroku 4. W takim przypadku, ponieważ zachowanie aplikacji polega na odjechaniu od danych konta zarządzanego (dokumentu w intencji), należy go użyć IGNORE_INTENT w wywołaniu przełącznika tożsamości. Pozwala to uniknąć niewłaściwego niepowodzenia tego wywołania przez zestaw SDK.

• DATA_FROM_INTENT: podczas żądania przełącznika tożsamości w warstwie interfejsu użytkownika ta opcja informuje zestaw SDK, że dane z ostatnio przechowywanej tożsamości intencji będą nadal wyświetlane po pomyślnym przełączeniu tożsamości. W związku z tym zestaw SDK w pełni oceni zasady odbierania względem poprzedniej tożsamości intencji, aby określić, czy można je wyświetlić. Przykład:

  1. Aplikacja jest przeglądarką dokumentów. Może renderować dokumenty przekazywane z innych aplikacji. Zawiera również funkcję, w której użytkownicy mogą przełączać konta. W przeciwieństwie do wcześniejszego przykładu za każdym razem, gdy użytkownik korzysta z tej funkcji przełączania konta, aplikacja przechodzi do udostępnionej strony, na której są wyświetlane najnowsze dokumenty dla wszystkich kont".
  2. Aplikacja otrzymuje zamiar wyświetlenia dokumentu. Ta intencja jest oznaczana tożsamością zarządzaną.
  3. Aplikacja została przełączona na tożsamość zarządzana i wyświetla ten dokument z prawidłowo zastosowanymi zabezpieczeniami.
  4. Użytkownik używa przełącznika konta do zmiany konta osobistego.

  Aplikacja musi zmienić tożsamość interfejsu użytkownika w kroku 4. W takim przypadku, ponieważ zachowanie aplikacji polega na kontynuowaniu wyświetlania danych tożsamości zarządzanej (wersja zapoznawcza dokumentu w intencji), powinna być używana DATA_FROM_INTENT w wywołaniu przełącznika tożsamości. Informuje to zestaw SDK o sprawdzeniu skonfigurowanych zasad ochrony aplikacji w celu określenia, czy dane są odpowiednie do dalszego wyświetlania.

(*) Domyślne zachowanie zestawu SDK obejmuje specjalną obudowę, która pomija tę kontrolę ruchu przychodzącego danych, jeśli na przykład intencja pochodzi z tej samej aplikacji lub z uruchamiania systemu.

Czyszczenie aktywnej tożsamości

Aplikacja może mieć scenariusze niezależne od konta. Aplikacja może mieć również scenariusze dla lokalnych scenariuszy niezarządzanych, które nie wymagają logowania. W obu tych przypadkach aplikacja może nie chcieć, aby zestaw SDK wymuszał zasady tożsamości zarządzanej, ale może nie mieć jawnej tożsamości, na którą można się przełączyć.

Aktywną tożsamość można wyczyścić, wywołując dowolną z metod tożsamości zestawu z parametrem tożsamości ustawionym na null. Wyczyszczenie tożsamości na jednym poziomie spowoduje, że zestaw SDK wyszuka aktywną tożsamość na innych poziomach na podstawie kolejności pierwszeństwa.

Alternatywnie można przekazać pusty ciąg jako parametr tożsamości, który ustawia tożsamość na specjalną pustą wartość, która jest traktowana jako tożsamość niezarządzana. Ustawienie aktywnej tożsamości na pusty ciąg informuje zestaw SDK, aby nie wymuszał żadnych zasad ochrony aplikacji.

Niejawne zmiany tożsamości

W powyższej sekcji opisano różne sposoby, w jakie aplikacja może jawnie ustawić aktywną tożsamość na poziomie wątku, kontekstu i procesu. Jednak aktywna tożsamość w aplikacji może również ulec zmianie bez wywoływania przez aplikację żadnej z tych metod. W tej sekcji opisano, jak aplikacja może nasłuchiwać tych niejawnych zmian tożsamości i reagować na niejawne zmiany tożsamości.

Nasłuchiwanie tych niejawnych zmian tożsamości jest opcjonalne, ale zalecane. Zestaw SDK nigdy nie zmieni aktywnej tożsamości bez podawania tych niejawnych powiadomień o zmianie tożsamości.

Uwaga

Jeśli aplikacja nie chce nasłuchiwać niejawnych zmian tożsamości, należy zachować szczególną ostrożność, aby nie zakładać aktywnej tożsamości. W razie wątpliwości użyj getCurrentThreadIdentitymetod , getUIPolicyIdentityi getProcessIdentity , aby potwierdzić aktywną tożsamość.

Źródła niejawnych zmian tożsamości

• Ruch przychodzący danych z innych aplikacji zarządzanych przez usługę Intune może zmienić aktywną tożsamość na poziomie wątku i kontekstu.

  • Jeśli działanie zostanie uruchomione z poziomu wysłanej przez inną Intent aplikację mam, tożsamość działania zostanie ustawiona na podstawie aktywnej tożsamości w innej aplikacji w momencie Intent wysłania.

    • Na przykład działanie umożliwiające wyświetlenie dokumentu Word jest uruchamiane z intencji programu Microsoft Outlook, gdy użytkownik wybierze załącznik dokumentu. Tożsamość działania przeglądarki dokumentów pakietu Office jest przełączana na tożsamość z programu Outlook.

  • W przypadku usług tożsamość wątku zostanie ustawiona podobnie na czas trwania onStart wywołania lub onBind . Wywołania zwracanego Binder elementu onBind również tymczasowo ustawią tożsamość wątku.

  • Wywołania do ContentProvider elementu będą podobnie ustawiać tożsamość wątku na czas ich trwania.

• Interakcja użytkownika z działaniem może zmienić aktywną tożsamość na poziomie kontekstu. Przykład:

  • Anulowanie przez użytkownika monitu o autoryzację podczas Resume zostaną wywołane niejawnym przejściem na pustą tożsamość.

Obsługa niejawnych zmian tożsamości

Aplikacja może opcjonalnie nasłuchiwać tych niejawnych zmian tożsamości i reagować na niejawne zmiany. Na przykład aplikacja może wymagać wielu kroków, zanim dodane konto będzie możliwe do użycia, na przykład aplikacja poczty e-mail konfigurująca nową skrzynkę odbiorczą. Po wyświetleniu próby przełączenia tożsamości na tożsamość tego niekompletnego konta program obsługi aplikacji może przekierować użytkownika do działania konfiguracji konta przed zaakceptowaniem przełącznika tożsamości. Alternatywnie program obsługi aplikacji może wyświetlić okno dialogowe błędu i zablokować przełącznik tożsamości.

Aplikacja może zaimplementować interfejs MAMIdentityRequirementListener w pliku lub ContextProvider na Service potrzeby zmian tożsamości stosowanych do tego wątku. Implementacja musi zostać zastąpiona:

public abstract void onMAMIdentitySwitchRequired(String identity,
        AppIdentitySwitchResultCallback callback);

Aplikacja może zaimplementować interfejs MAMActivityIdentityRequirementListener na potrzeby Activity zmian tożsamości stosowanych do tego działania. Implementacja musi zostać zastąpiona:

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

Parametr AppIdentitySwitchReason wyliczenia opisuje źródło niejawnego przełącznika tożsamości.

Wartość wyliczenia	Domyślne zachowanie zestawu SDK	Opis
CREATE	Zezwalaj na przełącznik tożsamości.	Przełącznik tożsamości występuje z powodu utworzenia działania.
NEW_INTENT	Zezwalaj na przełącznik tożsamości.	Przełącznik tożsamości występuje, ponieważ nowa intencja jest przypisywana do działania.
RESUME_CANCELLED	Blokuj przełącznik tożsamości.	Przełącznik tożsamości występuje, ponieważ życiorys został anulowany. Dzieje się tak najczęściej, gdy użytkownik końcowy naciśnie przycisk wstecz w numerze PIN, uwierzytelnianiu lub interfejsie użytkownika zgodności.

Parametr AppIdentitySwitchResultCallback umożliwia deweloperom zastąpienie domyślnego zachowania przełącznika tożsamości:

public interface AppIdentitySwitchResultCallback {
  /**
    * @param result
    *            whether the identity switch can proceed.
    */
  void reportIdentitySwitchResult(AppIdentitySwitchResult result);
}
// Where [AppIdentitySwitchResult] is either `SUCCESS` or `FAILURE`.

onMAMIdentitySwitchRequired jest wywoływana dla wszystkich niejawnych zmian tożsamości, z wyjątkiem tych wprowadzonych za pośrednictwem obiektu binder zwróconego z MAMService.onMAMBindprogramu . Domyślne implementacje natychmiastowego onMAMIdentitySwitchRequired wywołania:

• callback.reportIdentitySwitchResult(FAILURE) gdy przyczyną jest RESUME_CANCELLED.

• callback.reportIdentitySwitchResult(SUCCESS) we wszystkich innych przypadkach.

Nie oczekuje się, że większość aplikacji będzie musiała zablokować lub opóźnić przełącznik tożsamości w inny sposób, ale jeśli aplikacja musi to zrobić, należy rozważyć następujące kwestie:

• Jeśli przełącznik tożsamości jest zablokowany, zachowanie użytkownika końcowego jest takie samo, jak wtedy, gdy ustawienie ochrony aplikacji "odbieranie danych z innych aplikacji" zestawu SDK zabroniło ruchu przychodzącego danych.

• Jeśli usługa jest uruchomiona w wątku głównym, reportIdentitySwitchResultmusi być wywoływana synchronicznie lub wątek interfejsu użytkownika przestaje odpowiadać.

• W przypadku Activity tworzenia obiekt onMAMIdentitySwitchRequired zostanie wywołany przed onMAMCreate. Jeśli aplikacja musi wyświetlać interfejs użytkownika, aby określić, czy zezwolić na przełączanie tożsamości, ten interfejs użytkownika musi być wyświetlany przy użyciu innego działania.

• W elemencie Activity, gdy jest wymagane przełączenie do pustej tożsamości z przyczyną jako RESUME_CANCELLED, aplikacja musi zmodyfikować wznowione działanie, aby wyświetlić dane zgodne z tym przełącznikiem tożsamości. Jeśli nie jest to możliwe, aplikacja powinna odmówić przełączenia, a użytkownik zostanie ponownie poproszony o przestrzeganie zasad dla wznawianej tożsamości (na przykład poprzez przedstawienie ekranu wprowadzania numeru PIN aplikacji).

Uwaga

Aplikacja z wieloma tożsamościami może odbierać dane przychodzące zarówno z aplikacji zarządzanych, jak i niezarządzanych. Aplikacja jest odpowiedzialna za traktowanie danych z tożsamości zarządzanych w sposób zarządzany.

Jeśli żądana tożsamość jest zarządzana (użyj polecenia MAMPolicyManager.getIsIdentityManaged do sprawdzenia), ale aplikacja nie może używać tego konta (na przykład dlatego, że konta, takie jak konta e-mail, muszą być najpierw skonfigurowane w aplikacji), należy odmówić przełączania tożsamości.

Do domyślnego MAMActivity.onMAMIdentitySwitchRequired zachowania elementu można uzyskać dostęp, wywołując metodę MAMActivity.defaultOnMAMIdentitySwitchRequired(activity, identity, reason, callback)statyczną .

Podobnie, jeśli trzeba zastąpić , można zaimplementować MAMActivity.onSwitchMAMIdentityCompleteMAMActivityIdentitySwitchListener bez jawnej dziedziczenia z MAMActivity.

Ograniczenia dotyczące przełączników tożsamości i zrzutów ekranu

Zestaw SDK aplikacji usługi Intune używa flagi FLAG_SECURE do wymuszania zasad zrzutów Window ekranu. Niektóre aplikacje mogą również być ustawione FLAG_SECURE dla własnych celów. Jeśli zasady ochrony aplikacji nie ograniczają zrzutów ekranu, zestaw SDK nie zmodyfikuje elementu FLAG_SECURE.

W przypadku przełączania tożsamości z tożsamości, której zasady wymagają wyłączenia zrzutów ekranu dla tożsamości, której zasady nie mają, zestaw SDK wyczyści FLAG_SECUREpolecenie . W związku z tym aplikacja nie powinna polegać na FLAG_SECURE pozostałym zestawie po przełączeniu tożsamości.

Zachowywanie tożsamości w operacjach asynchronicznych

Aplikacje często wysyłają zadania w tle z wątku interfejsu użytkownika w celu obsługi operacji w innych wątkach. Aplikacja z wieloma tożsamościami musi zapewnić, że te zadania w tle działają z odpowiednią tożsamością, która jest często tą samą tożsamością używaną przez działanie, które je wysłało.

Zestaw SDK aplikacji usługi Intune zapewnia funkcje MAMAsyncTask i MAMIdentityExecutors jako wygodę ułatwiającą zachowanie tożsamości w operacjach asynchronicznych. Aplikacja musi użyć tych elementów (lub jawnie ustawić tożsamość wątku dla zadań), jeśli jej operacje asynchroniczne mogą:

• Zapisywanie danych należących do tożsamości zarządzanej w pliku
• Komunikacja z innymi aplikacjami

MAMAsyncTask

Aby użyć , MAMAsyncTaskpo prostu dziedziczyć z niego zamiast AsyncTask i zastąpić zastąpienia doInBackground i onPreExecute odpowiednio z doInBackgroundMAM i onPreExecuteMAM . Konstruktor MAMAsyncTask przyjmuje kontekst działania. Przykład:

AsyncTask<Object, Object, Object> task = new MAMAsyncTask<Object, Object, Object>(thisActivity) {

    @Override
    protected Object doInBackgroundMAM(final Object[] params) {
        // Do operations.
    }

    @Override
    protected void onPreExecuteMAM() {
        // Do setup.
    };
}

MAMAsyncTask Przyjmuje aktywną tożsamość na podstawie normalnej kolejności pierwszeństwa.

MAMIdentityExecutors

MAMIdentityExecutorsUmożliwia opakowywanie istniejącego Executor wystąpienia lub ExecutorService jako zachowania tożsamości za pomocą wrapExecutor metod iwrapExecutorService.Executor/ExecutorService Na przykład

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

MAMIdentityExecutors Przyjmuje aktywną tożsamość na podstawie normalnej kolejności pierwszeństwa.

Ochrona plików

Pisanie chronionych plików

Jak wspomniano powyżej w temacie Organizowanie danych aplikacji według tożsamości , zestaw SDK aplikacji usługi Intune kojarzy aktywną tożsamość (z poziomu wątku/procesu) z plikami w trakcie ich pisania. Ważne jest, aby w czasie tworzenia pliku ustawić poprawną tożsamość, aby zapewnić prawidłowe szyfrowanie i selektywne czyszczenie.

Aplikacja może wykonywać zapytania lub zmieniać tożsamość pliku przy użyciu klasy MAMFileProtectionManager , w szczególności MAMFileProtectionManager.getProtectionInfo do wykonywania zapytań i MAMFileProtectionManager.protect zmiany.

Metoda może być również używana protect do ochrony katalogów. Ochrona katalogów jest stosowana cyklicznie do wszystkich plików i podkatalogów zawartych w katalogu. Gdy katalog jest chroniony, wszystkie nowe pliki utworzone w katalogu będą automatycznie miały taką samą ochronę. Ponieważ ochrona katalogów jest stosowana cyklicznie, protect wykonanie wywołania może zająć trochę czasu w przypadku dużych katalogów. Z tego powodu aplikacje stosujące ochronę do katalogu zawierającego dużą liczbę plików mogą chcieć działać protect asynchronicznie w wątku w tle.

Wywołanie protect z pustym ciągiem dla parametru tożsamości spowoduje oznaczenie pliku/katalogu tożsamością niezarządzaną. Ta operacja spowoduje usunięcie szyfrowania z pliku/katalogu, jeśli zostało ono wcześniej zaszyfrowane. Po wydaniu polecenia selektywnego czyszczenia plik/katalog nie zostanie usunięty.

Wyświetlanie zawartości chronionego pliku

Równie ważne jest ustawienie prawidłowej tożsamości podczas wyświetlania zawartości pliku, aby uniemożliwić nieautoryzowanym użytkownikom wyświetlanie zarządzanych danych. Zestaw SDK nie może automatycznie wywnioskować relacji między odczytywanymi plikami a danymi wyświetlanymi w pliku Activity. Aplikacje muszą odpowiednio ustawić tożsamość interfejsu użytkownika przed wyświetleniem jakichkolwiek zarządzanych danych. Obejmuje to dane odczytane z plików.

Jeśli plik pochodzi spoza aplikacji (z ContentProvider lokalizacji lub odczytu z publicznie zapisywalnej lokalizacji), aplikacja musi podjąć próbę określenia tożsamości pliku (przy użyciu poprawnego przeciążenia MAMFileProtectionManager.getProtectionInfo dla źródła danych) przed wyświetleniem informacji odczytanych z pliku.

Jeśli getProtectionInfo zgłasza tożsamość niepustą, niepustą, aplikacja musi ustawić tożsamość interfejsu użytkownika tak, aby była zgodna z tą tożsamością przy użyciu elementu MAMActivity.switchMAMIdentity lub MAMPolicyManager.setUIPolicyIdentity. Jeśli przełącznik tożsamości nie powiedzie się, dane z pliku nie mogą być wyświetlane.

Podczas odczytywania z identyfikatora URI zawartości może być konieczne najpierw odczytanie tożsamości (za pośrednictwem getProtectionInfo przeciążenia przy użyciu Urielementu ), a następnie odpowiednie ustawienie kontekstu lub tożsamości wątku. Należy to zrobić przed otwarciem deskryptora pliku lub strumienia wejściowego w systemie ContentResolver, w przeciwnym razie operacja może zakończyć się niepowodzeniem.

Przykładowy przepływ może wyglądać mniej więcej tak:

• Użytkownik wybiera dokument do otwarcia w aplikacji.

• Podczas otwartego przepływu przed odczytem danych z dysku aplikacja potwierdza tożsamość, która powinna być używana do wyświetlania zawartości:

  MAMFileProtectionInfo info = MAMFileProtectionManager.getProtectionInfo(docPath)
  if (info != null)
      MAMPolicyManager.setUIPolicyIdentity(activity, info.getIdentity(), callback, EnumSet.noneOf<IdentitySwitchOption.class>)
  

• Aplikacja czeka, aż wynik zostanie zgłoszony do wywołania zwrotnego.

• Jeśli zgłoszony wynik jest niepowodzeniem, aplikacja nie wyświetli dokumentu.

• Aplikacja otwiera i renderuje plik.

Jeśli aplikacja pobiera pliki za pomocą systemu Android DownloadManager , zestaw SDK podejmie próbę automatycznej ochrony tych plików przy użyciu priorytetu tożsamości opisanego wcześniej. Kontekst użyty DownloadManager do pobrania elementu będzie używany, jeśli tożsamość wątku jest niez ustawiona. Jeśli pobrane pliki zawierają dane firmowe, aplikacja jest odpowiedzialna za wywołanie ochrony , jeśli pliki zostaną przeniesione lub ponownie utworzone po pobraniu.

Single-Identity do przenoszenia wielu tożsamości

Jeśli aplikacja, która została wcześniej wydana z integracją usługi Intune z jedną tożsamością, później zintegruje wiele tożsamości, wcześniej zainstalowane aplikacje będą przechodzić. To przejście nie jest widoczne dla użytkownika.

Aplikacja nie jest wymagana do obsługi tego przejścia. Wszystkie pliki utworzone przed przejściem będą nadal traktowane jako zarządzane (dlatego pozostaną zaszyfrowane, jeśli zasady szyfrowania są włączone).

Jeśli nie chcesz, aby wszystkie poprzednie dane aplikacji były skojarzone z tożsamością zarządzanej, możesz wykryć to przejście i jawnie usunąć ochronę.

• Wykryj uaktualnienie, porównując wersję aplikacji ze znaną wersją, w której dodano obsługę wielu tożsamości.
• Wywołaj protect z pustym ciągiem parametru tożsamości w plikach lub katalogach, które nie mają być skojarzone z tożsamością zarządzanej.

Scenariusze trybu offline

Zestaw SDK aplikacji usługi Intune działa w trybie offline, gdy aplikacja Portal firmy nie jest zainstalowana. Tagowanie tożsamości pliku jest poufne dla trybu offline:

• Jeśli Portal firmy nie jest zainstalowana, nie można oznaczyć plików tożsamości. Wywoływanie pliku MAMFileProtectionManager.protect w trybie offline jest bezpieczne, ale nie będzie miało żadnego wpływu.

• Jeśli Portal firmy jest zainstalowany, ale aplikacja nie ma zasad ochrony aplikacji, pliki nie mogą być niezawodnie oznaczone tożsamością.

• Gdy tagowanie tożsamości plików stanie się dostępne, wszystkie wcześniej utworzone pliki będą traktowane jako osobiste/niezarządzane (należące do tożsamości z pustym ciągiem), z wyjątkiem przypadków, gdy aplikacja została wcześniej zainstalowana jako aplikacja zarządzana z jedną tożsamością, zgodnie z opisem w temacie Single-Identity to Multi-Identity Transition (Przenoszenie pojedynczej tożsamości do wielu tożsamości).

Aby uniknąć tych przypadków, aplikacje powinny unikać tworzenia plików zawierających dane konta, dopóki rejestracja konta nie zakończy się pomyślnie. Jeśli aplikacja musi absolutnie tworzyć pliki w trybie offline, może użyć pliku MAMFileProtectionManager.protect , aby poprawić skojarzoną tożsamość pliku, gdy zestaw SDK będzie w trybie online.

Ochrona buforu danych

Ostrzeżenie

Zapisywanie danych należących do wielu kont w jednym pliku nie jest zalecane. Jeśli to możliwe, zorganizuj pliki aplikacji według tożsamości.

Menedżer MAMDataProtectionManager zestawu SDK udostępnia metody sprawdzania i zmieniania oznakowanej tożsamości w określonych buforach danych w formacie byte[] lub InputStream .

MAMDataProtectionManager.protect Umożliwia aplikacji skojarzenie danych z tożsamością, a jeśli tożsamość jest obecnie objęta zasadami szyfrowania, szyfrowanie danych. Te zaszyfrowane dane są odpowiednie do przechowywania na dysku w pliku.

MAMDataProtectionManager Umożliwia również wykonywanie zapytań dotyczących danych skojarzonych z tożsamością i odszyfrowywanie ich.

Aplikacje, z których MAMDataProtectionManager korzystasz, powinny implementować odbiornik dla MANAGEMENT_REMOVED powiadomienia. Aby uzyskać więcej szczegółów, zobacz Rejestrowanie powiadomień z zestawu SDK .

Po zakończeniu tego powiadomienia bufory chronione za pośrednictwem tej klasy nie będą już czytelne (jeśli szyfrowanie plików zostało włączone, gdy bufory były chronione). Aplikacja może zapobiec nieczytelnym odczytaniu tych buforów, wywołując MAMDataProtectionManager.unprotect wszystkie bufory podczas obsługi MANAGEMENT_REMOVED powiadomienia. Można również bezpiecznie wywołać podczas protect tego powiadomienia, jeśli chcesz zachować informacje o tożsamości. Szyfrowanie jest gwarantowane, że zostanie wyłączone podczas powiadomienia, a wywołanie protect w programie obsługi nie zaszyfruje buforów danych.

Dostawcy zawartości

Aplikacja z wieloma tożsamościami musi również chronić dane udostępniane za pośrednictwem ContentProviderfunkcji s, aby zapobiec niewłaściwemu udostępnianiu zawartości zarządzanej.

Aplikacja musi wywołać statyczną metodę isProvideContentAllowed(provider, contentIdentity)MAMContentProvider przed zwróceniem zawartości. Jeśli ta funkcja zwraca wartość false, zawartość nie może być zwracana do obiektu wywołującego.

Wywołanie isProvideContentAllowed nie jest wymagane, jeśli ContentProvider zwracasz element ParcelFileDescriptor. Deskryptory plików zwracane przez dostawcę zawartości są obsługiwane automatycznie na podstawie tożsamości pliku.

Selektywne czyszczenie

Domyślnie zestaw SDK aplikacji usługi Intune automatycznie obsługuje selektywne czyszczenie, usuwając wszystkie pliki skojarzone z tożsamością zarządzanej. Następnie zestaw SDK bezpiecznie zamknie aplikację, kończąc działania i zabijając proces aplikacji.

Zestaw SDK zapewnia opcjonalną możliwość uzupełniania aplikacji (zalecane) lub zastępowania domyślnego zachowania czyszczenia.

Domyślna procedura obsługi czyszczenia zestawu SDK nie obsługuje buforów danych chronionych przez MAMDataProtectionManagerprogram . Jeśli aplikacja używała tej funkcji, musi uzupełnić lub zastąpić domyślną procedurę obsługi czyszczenia, aby usunąć te dane.

Uwaga

Uzupełnianie i zastępowanie domyślnego zachowania czyszczenia wymaga obsługi określonych powiadomień zestawu SDK. Zobacz Rejestrowanie powiadomień z zestawu SDK , aby uzyskać więcej szczegółów na temat implementowania procedur obsługi powiadomień.

Uzupełnianie domyślnego zachowania czyszczenia

Aby uzupełnić domyślne zachowanie czyszczenia zestawu SDK, aplikacja może zarejestrować się w typie WIPE_USER_AUXILIARY_DATAMAMNotificationType.

To powiadomienie zostanie wysłane przez zestaw SDK przed wykonaniem domyślnego selektywnego czyszczenia. Zestaw SDK będzie czekać na ukończenie procedury obsługi powiadomień aplikacji przed usunięciem danych i zakończeniem działania aplikacji. Aplikacja powinna wyczyścić dane synchronicznie i nie zwracać ich do momentu ukończenia wszystkich czynności czyszczenia.

Aplikacje powinny zdecydowanie rozważyć uzupełnienie domyślnego zachowania czyszczenia za pomocą WIPE_USER_AUXILIARY_DATApolecenia , ponieważ oczyszczanie specyficzne dla aplikacji jest typowe dla aplikacji z wieloma tożsamościami.

Zastępowanie domyślnego zachowania czyszczenia

Aby zastąpić domyślne zachowanie czyszczenia zestawu SDK, aplikacja może zarejestrować się w typie WIPE_USER_DATAMAMNotificationType.

Ostrzeżenie

Aplikacja nigdy nie może rejestrować się dla obu elementów WIPE_USER_DATA i WIPE_USER_AUXILIARY_DATA.

Zastąpienie domyślnego zachowania czyszczenia zestawu SDK stwarza znaczne ryzyko dla aplikacji. Aplikacja będzie w pełni odpowiedzialna za usunięcie wszystkich danych skojarzonych z tożsamością zarządzaną, w tym wszystkich plików i buforów danych, które zostały oznaczone dla tej tożsamości.

• Jeśli tożsamość zarządzana była chroniona za pomocą szyfrowania, a niestandardowa procedura obsługi czyszczenia aplikacji nie usuwa w pełni wszystkich zarządzanych danych, wszystkie pozostałe pliki zarządzane pozostaną zaszyfrowane. Te dane staną się niedostępne, a aplikacja może nie obsługiwać próby pomyślnego odczytu zaszyfrowanych danych.
• Procedura obsługi czyszczenia aplikacji może spowodować utratę danych dla niezarządzanych użytkowników, jeśli usunie pliki, które nie są oznaczone tożsamością zarządzaną.

Jeśli niestandardowy program obsługi czyszczenia aplikacji usuwa dane zarządzane z pliku, ale chce pozostawić inne dane w pliku, musi zmienić tożsamość pliku (za pośrednictwem polecenia MAMFileProtectionManager.protect) na tożsamość niezarządzaną lub pusty ciąg.

Program obsługi przesłoniętego czyszczenia powinien wyczyść dane synchronicznie i nie powinien zwracać danych do momentu ukończenia wszystkich operacji oczyszczania.

Rozważ ręczne zamknięcie aplikacji po wykonaniu niestandardowych kroków procedury obsługi czyszczenia, aby uniemożliwić użytkownikowi dostęp do danych w pamięci po zakończeniu czyszczenia.

Kryteria zakończenia

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

• Tworzenie i przypisywanie zasad ochrony aplikacji do konta. Będzie to testowe konto zarządzane.
• Utwórz, 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ę i Intune — Portal firmy; 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ę i Intune — Portal firmy; 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 usługi 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ę i Intune — Portal firmy; 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.

Weryfikowanie scenariuszy selektywnego czyszczenia

Aplikacja z wieloma tożsamościami mogła uzupełnić lub zastąpić domyślne zachowanie czyszczenia zestawu SDK. Te testy pomagają zapewnić, że integracja z wieloma tożsamościami prawidłowo usuwa zarządzane dane podczas inicjowania czyszczenia bez wpływu na dane niezarządzane.

Ostrzeżenie

Przypomnienie, jeśli aplikacja wykorzystała MAMDataProtectionManager.protectfunkcję , musi zaimplementować procedurę obsługi dla programu WIPE_USER_AUXILIARY_DATA lub WIPE_USER_DATA.

W przypadku tych testów zainstaluj aplikację i Intune — Portal firmy; przed rozpoczęciem testu zaloguj się przy użyciu konta zarządzanego i niezarządzanego. W przypadku obu kont należy wykonywać scenariusze aplikacji przechowujące dane konta.

Scenariusz	Warunki wstępne	Kroki
Uzupełniająca procedura obsługi czyszczenia	Aplikacja zaimplementowała procedurę obsługi dla WIPE_USER_AUXILIARY_DATA	- Wystawianie selektywnego czyszczenia z centrum administracyjnego Microsoft Intune. — Upewnij się (zazwyczaj za pośrednictwem rejestrowania), że procedura obsługi czyszczenia została pomyślnie wykonana. — 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.
Zastąpiona procedura obsługi czyszczenia	Aplikacja zaimplementowała procedurę obsługi dla WIPE_USER_DATA	- Wystawianie selektywnego czyszczenia z centrum administracyjnego Microsoft Intune. — Upewnij się (zazwyczaj za pośrednictwem rejestrowania), że procedura obsługi czyszczenia została pomyślnie wykonana. — 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. — Upewnij się, że aplikacja została pomyślnie zakończona lub jest nadal w dobrej kondycji po zakończeniu procedury obsługi czyszczenia.
Ręczna ochrona plików	— Wywołania aplikacji MAMFileProtectionManager.protect — Aplikacja zaimplementowała procedurę obsługi dla WIPE_USER_DATA	— Upewnij się, że zostały spełnione scenariusze, w których aplikacja ręcznie chroniłaby co najmniej jeden plik należący do konta zarządzanego. - Wystawianie selektywnego czyszczenia z centrum administracyjnego Microsoft Intune. — Upewnij się, że pliki zostały usunięte.
Ręczna ochrona buforu danych	— Wywołania aplikacji MAMDataProtectionManager.protect — Aplikacja zaimplementowała program obsługi dla programu WIPE_USER_AUXILIARY_DATA lub WIPE_USER_DATA	— Upewnij się, że zostały spełnione scenariusze, w których aplikacja ręcznie chroniłaby co najmniej jeden bufor danych należący do konta zarządzanego. - Wystawianie selektywnego czyszczenia z centrum administracyjnego Microsoft Intune. — Upewnij się, że bufory danych są usuwane z plików, w których były przechowywane, a aplikacja nadal może odczytywać niezarządzane dane z tych plików.

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: App Configuration i Etap 7: Funkcje uczestnictwa w aplikacji, mogą być wymagane, w zależności od wymaganej obsługi zasad ochrony aplikacji. Jeśli nie masz pewności, czy którakolwiek z tych sekcji ma zastosowanie do twojej aplikacji, ponownie zapoznaj się z kluczowymi decyzjami dotyczącymi integracji zestawu SDK.