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

Zestaw SDK aplikacji usługi Microsoft Intune dla systemu Android umożliwia dołączanie zasad ochrony aplikacji usługi Intune (znanych również jako zasady zarządzania aplikacjami mobilnymi) do natywnej aplikacji systemu Android Java/Kotlin. Aplikacja zarządzana przez usługę Intune to aplikacja 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 tą aplikacją.

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

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.

Terminologia dotycząca tożsamości

Terminy "użytkownik", "konto" i "tożsamość" są często używane zamiennie. W tym przewodniku podjęto próbę rozróżnienia w następujący sposób:

• Użytkownik: istota ludzka korzystająca z oprogramowania. Dalej rozróżniane jako użytkownik końcowy, człowiek korzystający z aplikacji dla systemu Android i / administrator administrator / administrator IT / Administrator IT Pro, człowiek korzystający z centrum administracyjnego usługi 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, których zestaw SDK aplikacji usługi Intune używa do unikatowego identyfikowania konta.

Tło

Domyślnie zestaw SDK aplikacji usługi Intune stosuje zasady do całej aplikacji. Po zarejestrowaniu konta z ukierunkowanymi zasadami ochrony aplikacji zestaw SDK kojarzy każdy plik i każde działanie z tożsamością tego konta i będzie uniwersalnie stosować docelowe zasady tego konta.

Dla wielu deweloperów jest to pożądane zachowanie ochrony aplikacji dla ich aplikacji. Te aplikacje są uważane za pojedyncze tożsamości. Po wykonaniu poprzednich etapów Twoja 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: Konfiguracja aplikacji.

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 za pomocą zasad ochrony aplikacji, aplikacja jest uznawana za obsługującą wiele tożsamości.

Porada

Jeśli nie masz pewności, czy aplikacja powinna obsługiwać ochronę pojedynczej tożsamości, czy wielu tożsamości, ponownie odwiedź stronę Czy moja aplikacja jest pojedynczą tożsamością, czy wieloma tożsamościami?

Ostrzeżenie

Obsługa wielu tożsamości jest znacznie bardziej złożona niż w przypadku innych funkcji ochrony aplikacji. Niewłaściwa integracja wielu tożsamości może spowodować wyciek danych i inne problemy z zabezpieczeniami. Przejrzyj dokładnie tę sekcję i zaplanuj wystarczająco dużo czasu na testy, zanim przejdziesz do następnego etapu.

"Tożsamość" do zestawu SDK

Gdy aplikacja zintegrowana z zestawem SDK rejestruje konto przy użyciu registerAccountForMAM, zestaw SDK zapisuje wszystkie podane parametry (upn, aadId, tenantId i authority) jako tożsamość. Jednak większość interfejsów API tożsamości zestawu SDK używa podanego identyfikatora OID (znanego również jako identyfikator usługi Microsoft Entra ID lub identyfikator AAD) jako identyfikatora tożsamości. Interfejsy API zestawu SDK zarządzania aplikacjami mobilnymi zwrócą ciąg identyfikatora OID jako tożsamość i będą wymagać parametru ciągu OID dla tożsamości. Niektóre metody mogą również przyjmować lub zwracać ciąg głównej nazwy użytkownika, w którym to przypadku główna nazwa użytkownika jest przeznaczona tylko do celów informacyjnych.

W parametrach 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 została użyta podczas rejestrowania lub ustawiania tożsamości.

Uwaga

W przypadku aplikacji korzystających z przestarzałych metod, które przyjmują lub zwracają ciąg UPN, aplikacje muszą upewnić się, że ciąg UPN tożsamości przekazywany do różnych wywołań interfejsu API jest spójny. Przekazywanie niespójnych ciągów głównych nazw użytkowników może powodować wycieki danych.

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

Zgodnie z opisem w temacie Rejestrowanie się w celu ochrony aplikacji Twoja aplikacja jest odpowiedzialna za informowanie zestawu SDK, gdy użytkownik się loguje. W momencie logowania konto użytkownika może, ale 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 nie jest zarządzany.

Zestaw SDK będzie wymuszał zasady dotyczące tożsamości uważanych za zarządzane. Zestaw SDK nie wymusza zasad dotyczących tożsamości uznanych 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 powróci MAMEnrollmentManager.Result.WRONG_USER i poprosi użytkownika końcowego o opcje naprawy. Aby uzyskać więcej szczegółowych informacji, zobacz Zarejestruj się, aby otrzymywać powiadomienia z zestawu SDK .

Uwaga

Konto, które nie jest objęte zasadami ochrony aplikacji w czasie rejestracji, będzie uznawane za niezarządzane. Nawet jeśli konto nie jest licencjonowane ani objęte zasadami ochrony aplikacji, zestaw SDK będzie okresowo sprawdzać, czy to konto stanie się licencjonowane i przeznaczone w późniejszym czasie. Jeśli nie zarejestrowano żadnej innej tożsamości zarządzanej, zestaw SDK zacznie traktować tę tożsamość jako zarządzaną, gdy zostanie skierowana do zasad. Użytkownik nie musi wylogować się i zalogować ponownie na to konto, aby wprowadzić tę zmianę.

Aktywna tożsamość

Aplikacja musi zawsze informować zestaw SDK o tożsamości, która jest obecnie używana, nazywanej inaczej aktywną tożsamością. Jeśli aktywna tożsamość jest zarządzana, zestaw SDK zastosuje zabezpieczenia. Jeśli aktywna tożsamość nie jest zarządzana, zestaw SDK nie będzie stosować ochrony.

Ponieważ zestaw SDK nie ma wiedzy specyficznej dla aplikacji, musi ufać aplikacji w kwestii udostępniania poprawnej aktywnej tożsamości.

• Jeśli aplikacja niepoprawnie informuje zestaw SDK, że tożsamość niezarządzana jest aktywna, podczas 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 ryzyko.

• Jeśli aplikacja nieprawidłowo informuje zestaw SDK, że tożsamość zarządzana jest aktywna, podczas gdy tożsamość niezarządzana jest faktycznie używana, zestaw SDK niewłaściwie zastosuje zabezpieczenia. Nie jest to wyciek danych, ale może niepotrzebnie ograniczyć liczbę niezarządzanych użytkowników i narazić ich dane 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ć konieczna refaktoryzacja aplikacji w celu uzyskania większej świadomości tożsamości przed rozpoczęciem integrowania 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 (znane również jako "tagi") tożsamość z tym plikiem na podstawie bieżącego aktywnego wątku i tożsamości procesu. Ewentualnie aplikacja może bezpośrednio wywołać zestaw SDK, aby ręcznie oznaczyć plik przy użyciu określonej tożsamości (zobacz Zapisywanie chronionych Files, aby uzyskać szczegółowe informacje). Zestaw SDK używa tej tożsamości otagowanego 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 przy użyciu tożsamości zarządzanej.

Jeśli działanie administratora lub skonfigurowane zasady zażądają wyczyszczenia zarządzanych danych, zostaną usunięte tylko pliki oznaczone przy użyciu tożsamości zarządzanej.

Zestaw SDK nie może kojarzyć 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ą lub nadmierną ochronę tych danych. Zdecydowanie zaleca się organizowanie danych aplikacji według tożsamości.

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

Implementowanie wielu tożsamości

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

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

Ustawianie tożsamości aktywnej

Aplikacja może ustawić aktywną tożsamość na następujących poziomach w malejącym priorytecie:

1. Poziom wątku
2. Context (ogólnie 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 a Context jest używana tylko w odpowiednich skojarzonych scenariuszach. Na przykład operacje we/wy pliku nie mają skojarzonego Context. Najczęściej aplikacje ustawiają Context tożsamość na Activitypliku . Rozważ ustawienie Context tożsamości w .Activity.onCreate Aplikacja nie może wyświetlać danych tożsamości, Activity chyba że 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ą naraz we wszystkich wątkach. Nie jest to typowe zachowanie w przypadku aplikacji, które obsługują wiele kont. Zdecydowanie zalecamy oddzielenie danych konta i ustawienie aktywnej tożsamości w wątku lub Context poziomach.

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

Jeśli aplikacja używa Service kontekstu do uruchamiania intencji, używa funkcji rozpoznawania zawartości lub korzysta z innych usług systemowych, pamiętaj, aby ustawić tożsamość w Service kontekście. Podobnie, jeśli aplikacja używa JobService kontekstu do wykonywania tych akcji, upewnij się, że ustawiono tożsamość w JobService kontekście lub wątku zgodnie z JobService wymaganiami implementacji. Jeśli JobService na przykład zadania przetwarzania dla pojedynczej tożsamości, rozważ ustawienie tożsamości w JobService kontekście. Jeśli przetwarzanie JobService zadań dla wielu tożsamości rozważ ustawienie tożsamości na poziomie wątku.

Uwaga

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

Uwaga

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

Następujące metody w MAMPolicyManager mogą służyć do ustawiania aktywnej tożsamości i pobierania wcześniej ustawionych wartości tożsamości.

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

public static String getUIPolicyIdentityOID(final Context context);

public static MAMIdentitySwitchResult setProcessIdentityOID(final String oid);

public static String getProcessIdentityOID();

public static MAMIdentitySwitchResult setCurrentThreadIdentityOID(final String oid);

public static String getCurrentThreadIdentityOID();

/**
 * 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 getPolicyForIdentityOID(final String oid);

public static boolean getIsIdentityOIDManaged(final String oid);

Dla wygody możesz również ustawić tożsamość działania bezpośrednio za pomocą metody w MAMActivity zamiast wywoływać MAMPolicyManager.setUIPolicyIdentityOID. W tym celu zastosuj następującą metodę:

     public final void switchMAMIdentityOID(final String newIdentityOid, 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ócą MAMIdentitySwitchResult, zawsze zwróci FAILED.

Typowe pułapki związane ze zmianą tożsamości

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

• Zalecane jest ustawienie Context tożsamości podczas metody Ćwiczenia onCreate . Pamiętaj jednak, aby uwzględnić również inne punkty wejścia, takie jak onNewIntent. W przeciwnym razie, gdy to samo działanie zostanie ponownie użyte do wyświetlenia danych zarówno dla tożsamości zarządzanych, jak i niezarządzanych, zasady mogą zostać zastosowane nieprawidłowo, co doprowadzi do niechronionych danych firmowych lub niewłaściwie ograniczonych danych osobowych.

Wyniki przełączania tożsamości

Wszystkie metody używane do ustawiania tożsamości zgłaszają wartości wyników za pośrednictwem MAMIdentitySwitchResult. Istnieją cztery wartości, które można zwrócić:

Wartość zwracana	Scenariusz
SUCCEEDED	Zmiana tożsamości zakończyła się sukcesem.
NOT_ALLOWED	Zmiana tożsamości nie jest dozwolona. Dzieje się tak, jeśli zostanie podjęta próba 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, na ogół przez naciśnięcie przycisku Wstecz na numerze PIN lub monicie o uwierzytelnienie.
FAILED	Zmiana tożsamości nie powiodła się z nieokreślonej przyczyny.

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

Większość metod ustawiania tożsamości aktywnej zwraca MAMIdentitySwitchResult synchronicznie. W przypadku ustawiania Context tożsamości za pomocą setUIPolicyIdentityOID wynik jest zgłaszany asynchronicznie. Aplikacja może zaimplementować MAMSetUIIdentityCallback , aby odebrać ten wynik, lub może przekazać null dla obiektu wywołania zwrotnego. Jeśli wywołanie zostanie wykonane setUIPolicyIdentityOID , gdy wynik poprzedniego wywołania setUIPolicyIdentityOIDna tym samym Context nie został jeszcze dostarczony, nowe wywołanie zwrotne zastąpi stare, a oryginalne wywołanie zwrotne nigdy nie otrzyma wyniku.

Uwaga

Jeśli podany do ContextsetUIPolicyIdentityOID jest Activity, zestaw SDK nie wie, czy zmiana tożsamości powiodła się, dopóki nie wykona testów uruchamiania warunkowego skonfigurowanych przez administratora. Może to wymagać od użytkownika wprowadzenia numeru PIN lub poświadczeń firmowych.

Obecnie przełączanie tożsamości procesów i wątków zawsze zakończy się pomyślnie w przypadku aplikacji obsługującej wiele tożsamości. Zestaw SDK zastrzega sobie prawo do dodawania warunków niepowodzenia w przyszłości.

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

Domyślnym zachowaniem nieudanego przełączenia 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 danego działania, możesz zastąpić metodę opisaną w MAMActivityustawieniach .

    public void onSwitchMAMIdentityComplete(final MAMIdentitySwitchResult result);

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

Uwaga

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

Identity, Intents, and IdentitySwitchOptions

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

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

Zestaw SDK wykonuje to sprawdzanie, ponieważ zakłada, że aplikacja nadal wyświetla zawartość z intencji, która należy do tożsamości oznaczonej w intencji. To założenie chroni przed niezamierzonym wyłączaniem ochrony przez aplikację podczas wyświetlania zarządzanych danych; Jednak to założenie może nie być zgodne z rzeczywistym zachowaniem aplikacji.

Opcjonalne wyliczenia IdentitySwitchOption można przekazać do interfejsów API setUIPolicyIdentityOID i switchMAMIdentityOID w celu zmodyfikowania domyślnego zachowania zestawu SDK.

• IGNORE_INTENT: podczas żądania przełączenia tożsamości w warstwie interfejsu użytkownika ta opcja informuje zestaw SDK, aby pominął porównywanie żądanego parametru tożsamości z ostatnio zapisaną tożsamością intencji. Jest to przydatne, gdy w aplikacji nie jest już wyświetlana zawartość należąca do tej tożsamości, a zestaw SDK nie powinien blokować tego przełączenia tożsamości. Przykład:

  1. Aplikacja jest przeglądarką dokumentów. Może renderować dokumenty przekazane z innych aplikacji. Zawiera również funkcję, za pomocą której użytkownicy mogą przełączać konta. Za każdym razem, gdy użytkownik korzysta z tej funkcji przełączania kont, aplikacja przechodzi do strony docelowej specyficznej dla konta z ostatnimi dokumentami tego konta.
  2. Aplikacja otrzymuje intencję wyświetlenia dokumentu. Ta intencja jest oznaczona tożsamością zarządzaną.
  3. Aplikacja zostanie przełączona do tożsamości zarządzanej i będzie w niej wyświetlany ten dokument z prawidłowo zastosowanymi zabezpieczeniami.
  4. Użytkownik korzysta z przełącznika kont, aby przejść na swoje konto osobiste.

  Aplikacja musi zmienić tożsamość interfejsu użytkownika w kroku 4. W tym przypadku, ponieważ zachowanie aplikacji polega na odchodzeniu od danych zarządzanego konta (dokumentu w intencji), powinna ona użyć IGNORE_INTENT w wywołaniu przełączania tożsamości. Pozwala to uniknąć nieprawidłowego niepowodzenia tego wywołania zestawu SDK.

• DATA_FROM_INTENT: podczas żądania przełączenia tożsamości w warstwie interfejsu użytkownika ta opcja informuje zestaw SDK, że dane z ostatnio zapisanej 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 pod kątem poprzedniej tożsamości intencji, aby określić, czy można ją wyświetlić. Przykład:

  1. Aplikacja jest przeglądarką dokumentów. Może renderować dokumenty przekazane z innych aplikacji. Zawiera również funkcję, za pomocą 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 kont, aplikacja przechodzi do udostępnionej strony, która pokazuje ostatnio używane dokumenty dla wszystkich kont.
  2. Aplikacja otrzymuje intencję wyświetlenia dokumentu. Ta intencja jest oznaczona tożsamością zarządzaną.
  3. Aplikacja zostanie przełączona do tożsamości zarządzanej i będzie w niej wyświetlany ten dokument z prawidłowo zastosowanymi zabezpieczeniami.
  4. Użytkownik korzysta z przełącznika kont, aby przejść na swoje konto osobiste.

  Aplikacja musi zmienić tożsamość interfejsu użytkownika w kroku 4. W takim przypadku, ponieważ zachowanie aplikacji polega na dalszym wyświetlaniu danych tożsamości zarządzanej (podglądu dokumentu w intencji), powinna ona użyć DATA_FROM_INTENT w wywołaniu przełączania tożsamości. Informuje to zestaw SDK o konieczności sprawdzenia skonfigurowanych zasad ochrony aplikacji w celu ustalenia, czy jest to właściwe dla dalszego wyświetlania danych.

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

Czyszczenie tożsamości aktywnej

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

Aktywną tożsamość można wyczyścić, wywołując dowolną z ustawionych metod tożsamości z parametrem OID tożsamości ustawionym na null. Wyczyszczenie tożsamości na jednym poziomie spowoduje, że zestaw SDK będzie wyszukiwał aktywną tożsamość na innych poziomach zgodnie z kolejnością pierwszeństwa.

Alternatywnie można przekazać pusty ciąg jako parametr identyfikatora OID 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 wykrywać te niejawne zmiany tożsamości i reagować na nie.

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

Uwaga

Jeśli aplikacja nie chce nasłuchiwać niejawnych zmian tożsamości, zachowaj szczególną ostrożność, aby nie przyjmować aktywnej tożsamości. W razie wątpliwości użyj getCurrentThreadIdentityOIDmetod , getUIPolicyIdentityOID, i , getProcessIdentityOID aby potwierdzić aktywną tożsamość.

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

• Dane przychodzące z innych aplikacji zarządzanych przez usługę Intune mogą zmienić aktywną tożsamość na poziomie wątku i kontekstu.

  • Jeśli działanie jest uruchamiane z Intent wysłanej przez inną aplikację MAM, tożsamość działania zostanie ustawiona na podstawie aktywnej tożsamości w innej aplikacji w momencie, w którym została wysłana Intent .

    • Na przykład działanie wyświetlania dokumentu programu Word jest uruchamiane z intencji z poziomu programu Microsoft Outlook, gdy użytkownik wybierze załącznik dokumentu. Tożsamość aktywności 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 wywołania onStart lub onBind . Wywołania do zwracanego Binder od onBind również tymczasowo ustawią tożsamość wątku.

  • Wywołania ContentProvider do woli podobnie ustawiają 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:

  • Użytkownik anulujący monit autoryzacji w trakcie Resume tego okresu spowoduje niejawne przełączenie 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 nie. Na przykład aplikacja może wymagać wielu kroków, zanim dodane konto będzie można używać, takich jak konfigurowanie nowej skrzynki odbiorczej przez aplikację poczty e-mail. W przypadku wykrycia 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łączenia tożsamości. Ewentualnie program obsługi aplikacji może wyświetlić okno dialogowe błędu i zablokować zmianę tożsamości.

Aplikacja może implementować interfejs MAMIdentityRequirementListener na Service lub ContextProvider dla zmian tożsamości mających zastosowanie do tego wątku. Twoja implementacja musi zastępować:

public abstract void onMAMIdentitySwitchRequired(String upn, String oid,
        AppIdentitySwitchResultCallback callback);

Aplikacja może zaimplementować interfejs MAMActivityIdentityRequirementListener w Activity przypadku zmian tożsamości mających zastosowanie do tego działania. Twoja implementacja musi zastępować:

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

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

Wartość wyliczenia	Domyślne zachowanie zestawu SDK	Opis
CREATE	Zezwalaj na przełączenie tożsamości.	Zmiana tożsamości następuje z powodu utworzenia działania.
NEW_INTENT	Zezwalaj na przełączenie tożsamości.	Zmiana tożsamości ma miejsce, ponieważ do działania przypisywano nową intencję.
RESUME_CANCELLED	Zablokuj przełącznik tożsamości.	Zmiana tożsamości nastąpiła z powodu anulowania życiorysu. Jest to najbardziej typowe, gdy użytkownik końcowy naciska przycisk Wstecz w interfejsie użytkownika kodu PIN, uwierzytelniania lub 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 dokonanych za pośrednictwem segregatora zwróconego z MAMService.onMAMBind. Domyślne implementacje natychmiastowego wywołania onMAMIdentitySwitchRequired :

• 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 blokować lub opóźniać przełączanie tożsamości w inny sposób, ale jeśli aplikacja musi to zrobić, należy wziąć pod uwagę następujące kwestie:

• Jeśli przełączenie tożsamości jest zablokowane, zachowanie użytkownika końcowego jest takie samo, jak gdyby ustawienie ochrony aplikacji "odbieranie danych z innych aplikacji" zestawu SDK zakazało wchodzenia danych.

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

• Na potrzeby Activity tworzenia element onMAMIdentitySwitchRequired zostanie wywołany przed onMAMCreate. Jeśli aplikacja musi wyświetlać interfejs użytkownika w celu ustalenia, czy zezwolić na przełączenie tożsamości, ten interfejs użytkownika musi być wyświetlany przy użyciu innego działania.

• W , Activitygdy żądane jest przełączenie na pustą tożsamość z powodem jako RESUME_CANCELLED, aplikacja musi zmodyfikować wznowione działanie, aby wyświetlić dane zgodne z tym przełączeniem tożsamości. Jeśli nie jest to możliwe, aplikacja powinna odrzucić przełączenie, a użytkownik zostanie ponownie poproszony o zachowanie zgodności z zasadami dotyczącymi wznawiania tożsamości (na przykład poprzez wyświetlenie ekranu wprowadzania numeru PIN aplikacji).

Uwaga

Aplikacja obsługująca wiele tożsamości 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.getIsIdentityOIDManaged to check), ale aplikacja nie może użyć tego konta (na przykład dlatego, że konta, takie jak konta e-mail, muszą być najpierw skonfigurowane w aplikacji), przełączanie tożsamości powinno zostać odrzucone.

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

Podobnie, jeśli chcesz nadpisać MAMActivity.onSwitchMAMIdentityComplete, możesz zaimplementować MAMActivityIdentitySwitchListener bez jawnego dziedziczenia z MAMActivity.

Przełączniki tożsamości i ograniczenia dotyczące zrzutów ekranu

The Intune App SDK uses the Window flag FLAG_SECURE to enforce screenshot policy. Niektóre aplikacje mogą być także ustawiane FLAG_SECURE do ich własnych celów. Jeśli zasady ochrony aplikacji nie ograniczają zrzutów ekranu, zestaw SDK nie będzie modyfikować FLAG_SECURE.

Po przełączeniu tożsamości z tożsamości, której zasady wymagają wyłączenia zrzutów ekranu, do tożsamości, której zasady tego nie robią, zestaw SDK wyczyści FLAG_SECURE. W związku z tym aplikacja nie powinna polegać na FLAG_SECURE pozostaniu w ustawieniach 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 do 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 często jest tą samą tożsamością, która została użyta przez działanie, które je wysłało.

Zestaw SDK aplikacji usługi Intune udostępnia funkcje MAMAsyncTask i MAMIdentityExecutors jako udogodnienie, aby pomóc w zachowaniu tożsamości w operacjach asynchronicznych. Aplikacja musi używać tych funkcji (lub jawnie ustawić tożsamość wątku w zadaniach), jeśli jej operacje asynchroniczne mogą:

• Zapisywanie danych należących do tożsamości zarządzanej do pliku
• Komunikowanie się z innymi aplikacjami

MAMAsyncTask

Aby użyć MAMAsyncTask, po prostu dziedzicz z niego zamiast AsyncTask i zamień przesłonięcia z doInBackground i onPreExecuteonPreExecuteMAM odpowiedniodoInBackgroundMAM. 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 przyjmie aktywną tożsamość zgodnie z normalną kolejnością pierwszeństwa.

MAMIdentityExecutors

MAMIdentityExecutorsUmożliwia opakowywanie istniejącego Executor lub wystąpienia jako metod zachowujących wrapExecutorwrapExecutorServiceExecutorExecutorService/tożsamość.ExecutorService Na przykład

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

MAMIdentityExecutors przyjmie aktywną tożsamość zgodnie z normalną kolejnością pierwszeństwa.

Ochrona plików

Zapisywanie chronionych plików typu Files

Jak wspomniano w sekcji Organizowanie danych aplikacji według tożsamości powyżej, zestaw SDK aplikacji usługi Intune kojarzy aktywną tożsamość (z poziomu wątku/procesu) z plikami podczas ich zapisywania. Ustawienie poprawnej tożsamości podczas tworzenia pliku ma kluczowe znaczenie dla zapewnienia prawidłowego szyfrowania i funkcji selektywnego czyszczenia.

Aplikacja może wysyłać zapytania dotyczące tożsamości pliku lub ją zmieniać przy użyciu klasy MAMFileProtectionManager , w szczególności MAMFileProtectionManager.getProtectionInfo do wykonywania zapytań i MAMFileProtectionManager.protectForOID zmieniania.

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

Wywołanie protectForOID pustego ciągu dla parametru tożsamości spowoduje otagowanie pliku/katalogu przy użyciu tożsamości niezarządzanej. Ta operacja usunie szyfrowanie z pliku/katalogu, jeśli był wcześniej zaszyfrowany. Po wydaniu polecenia selektywnego czyszczenia plik/katalog nie zostanie usunięty.

Ostrzeżenie

Należy zadbać o to, aby tylko pliki należące do określonej tożsamości były objęte tą tożsamością. W przeciwnym razie w przypadku innych tożsamości może dojść do utraty danych, gdy tożsamość będąca właścicielem wyloguje się, pliki zostaną wyczyszczone, a dostęp do klucza szyfrowania zostanie utracony.

Wyświetlanie zawartości pliku chronionego

Równie ważne jest ustawienie poprawnej 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. Dotyczy to również danych odczytanych z plików.

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

Jeśli getProtectionInfo zgłasza niepustą tożsamość inną niż null, aplikacja musi ustawić tożsamość interfejsu użytkownika tak, aby była zgodna z tą tożsamością przy użyciu MAMActivity.switchMAMIdentityOID lub MAMPolicyManager.setUIPolicyIdentityOID. Jeśli przełączenie 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 (poprzez przeciążenie getProtectionInfo biorąc Uri), a następnie odpowiednio ustawić tożsamość kontekstu lub wątku. Należy to zrobić przed otwarciem deskryptora pliku lub strumienia wejściowego ContentResolverna , w przeciwnym razie operacja może zakończyć się niepowodzeniem.

Przykładowy przepływ może wyglądać podobnie do następującego:

• Użytkownik wybiera dokument, aby otworzyć go w aplikacji.

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

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

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

• Jeśli zgłoszony wynik jest błędem, aplikacja nie wyświetla dokumentu.

• Aplikacja otworzy plik i zacznie go renderować.

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

Single-Identity przejścia do wielu tożsamości

Jeśli aplikacja, która została wcześniej wydana z integracją z pojedynczą tożsamością usługi Intune, później będzie integrować wiele tożsamości, wcześniej zainstalowane aplikacje przejdą zmianę. 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 (pozostaną więc zaszyfrowane, jeśli są włączone zasady szyfrowania).

Jeśli nie chcesz, aby wszystkie poprzednie dane aplikacji były skojarzone z tożsamością zarządzaną, 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 protectForOID pusty ciąg dla parametru tożsamości w plikach lub katalogach, które nie mają być skojarzone z tożsamością zarządzaną.

Scenariusze offline

Zestaw SDK aplikacji usługi Intune działa w trybie offline, gdy nie jest zainstalowana aplikacja Portal firmy. Tagowanie tożsamości plików jest wrażliwe na tryb offline:

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

• Jeśli jest zainstalowany Portal firmy, ale aplikacja nie ma zasad ochrony aplikacji, nie można niezawodnie oznaczać plików tożsamością.

• Gdy tagowanie tożsamości plików stanie się dostępne, wszystkie utworzone wcześniej pliki są traktowane jako osobiste/niezarządzane (należące do tożsamości pustego ciągu), z wyjątkiem przypadków, gdy aplikacja została wcześniej zainstalowana jako aplikacja zarządzana jedną tożsamością, zgodnie z opisem w temacie Przejście z pojedynczej tożsamości na wiele tożsamości.

Aby uniknąć takich przypadków, aplikacje powinny unikać tworzenia plików zawierających dane konta do momentu pomyślnego zakończenia rejestracji konta. Jeśli aplikacja bezwzględnie musi tworzyć pliki w trybie offline, może użyć polecenia MAMFileProtectionManager.protectForOID , aby poprawić skojarzoną tożsamość pliku, gdy zestaw SDK będzie w trybie online.

Ochrona buforu danych

Ostrzeżenie

Nie zaleca się zapisywania danych należących do wielu kont w jednym pliku. Jeśli to możliwe, uporządkuj pliki aplikacji według tożsamości.

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

MAMDataProtectionManager.protectForOID Umożliwia aplikacji kojarzenie danych z tożsamością i, jeśli tożsamość jest obecnie celem zasad szyfrowania, szyfrowanie danych. Te zaszyfrowane dane nadają się do przechowywania na dysku w pliku.

MAMDataProtectionManager Umożliwia także wysyłanie zapytań do danych skojarzonych z tożsamością i ich odszyfrowywanie.

Aplikacje, które z nich MAMDataProtectionManager korzystają, powinny implementować odbiornik MANAGEMENT_REMOVED powiadomień. Aby uzyskać więcej szczegółowych informacji, zobacz Zarejestruj się, aby otrzymywać powiadomienia z zestawu SDK .

Po zakończeniu tego powiadomienia bufory, które były chronione za pośrednictwem tej klasy, nie będą już czytelne (jeśli szyfrowanie plików było włączone, gdy bufory były chronione). Aplikacja może zapobiec sytuacji, w której te bufory staną się nieczytelne, wywołując MAMDataProtectionManager.unprotect wszystkie bufory podczas obsługi powiadomienia MANAGEMENT_REMOVED . Możesz również bezpiecznie zadzwonić protectForOID podczas tego powiadomienia, jeśli chcesz zachować informacje dotyczące tożsamości. Szyfrowanie na pewno zostanie wyłączone podczas powiadamiania, a wywołanie protectForOID programu obsługi nie spowoduje zaszyfrowania buforów danych.

Ostrzeżenie

Należy unikać operacji szyfrowania na wczesnym etapie procesu aplikacji. Zestaw SDK wykona inicjowanie szyfrowania asynchronicznie tak wcześnie, jak to możliwe po uruchomieniu aplikacji. Jeśli jednak aplikacja wyśle żądanie szyfrowania podczas uruchamiania aplikacji, może ona zostać zablokowana do czasu ukończenia inicjowania szyfrowania.

Uwaga

Interfejs API szyfrowania zestawu SDK aplikacji usługi Intune powinien być używany tylko do szyfrowania danych zgodnie z wymaganiami zasad usługi Intune. Żadna ochrona nie będzie stosowana do kont, które nie są objęte włączonymi zasadami szyfrowania, więc nie może być używana jako biblioteka szyfrowania ogólnego przeznaczenia.

Dostawcy zawartości

Aplikacja obsługująca wiele tożsamości musi również chronić dane udostępniane za pośrednictwem ContentProviderkonsoli, aby zapobiec niewłaściwemu udostępnianiu zawartości zarządzanej.

Przed zwróceniem zawartości aplikacja musi wywołać statyczną metodę isProvideContentAllowedForOid(provider, oid)MAMContentProvider. Jeśli ta funkcja zwraca wartość false, zawartość nie może zostać zwrócona do obiektu wywołującego.

Dzwonienie isProvideContentAllowedForOid nie jest wymagane, jeśli ContentProvider zwracasz ParcelFileDescriptor. Deskryptory plików zwracane za pośrednictwem dostawcy 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, które zostały skojarzone z tożsamością zarządzaną. Następnie zestaw SDK z wdziękiem zamknie aplikację, kończąc działania i zabijając proces aplikacji.

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

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

Uwaga

Uzupełnienie i zastąpienie domyślnego zachowania czyszczenia wymaga obsługi określonych powiadomień zestawu SDK. Aby uzyskać więcej szczegółowych informacji na temat implementowania procedur obsługi powiadomień, zobacz Rejestrowanie powiadomień z zestawu SDK .

Uzupełnienie domyślnego zachowania czyszczenia

Aby uzupełnić domyślne zachowanie czyszczenia zestawu SDK, aplikacja może zarejestrować się dla WIPE_USER_AUXILIARY_DATAelementu MAMNotificationType.

To powiadomienie zostanie wysłane przez zestaw SDK przed wykonaniem domyślnego czyszczenia selektywnego. Zestaw SDK będzie czekał na zakończenie obsługi powiadomień aplikacji, zanim usunie dane i zakończy działanie aplikacji. Aplikacja powinna wyczyścić dane synchronicznie i nie powrócić do normalnego stanu konfiguracji, dopóki oczyszczanie nie zostanie ukończone.

Aplikacje powinny zdecydowanie rozważyć uzupełnienie domyślnego zachowania czyszczenia o WIPE_USER_AUXILIARY_DATA, ponieważ oczyszczanie specyficzne dla aplikacji jest typowe dla aplikacji obsługujących wiele tożsamości.

Zastępowanie domyślnego zachowania czyszczenia

Aby zastąpić domyślne zachowanie czyszczenia zestawu SDK, aplikacja może zarejestrować się dla WIPE_USER_DATAelementu MAMNotificationType.

Ostrzeżenie

Aplikacja nie może nigdy rejestrować się dla obu WIPE_USER_DATA .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 otagowane dla tej tożsamości.

• Jeśli tożsamość zarządzana była chroniona przy użyciu szyfrowania, a niestandardowy program obsługi czyszczenia aplikacji nie usunie w pełni wszystkich danych zarządzanych, wszelkie pozostałe pliki zarządzane pozostaną zaszyfrowane. Te dane staną się niedostępne, a aplikacja może nie obsługiwać prób płynnego 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 przy użyciu tożsamości zarządzanej.

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

Zastąpiony program obsługi czyszczenia powinien wyczyścić dane synchronicznie i nie powrócić do pracy po zakończeniu oczyszczania.

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

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 Microsoft Entra, możesz użyć istniejącego konta innego niż konto Entra 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.

W przypadku tych testów zainstaluj aplikację i usługę Intune — Portal firmy; 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.

W przypadku tych testów zainstaluj aplikację i usługę Intune — Portal firmy; 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.

W przypadku tych testów zainstaluj aplikację i usługę 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" 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.

Weryfikacja 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 wielu tożsamości prawidłowo usuwa dane zarządzane podczas inicjowania czyszczenia bez wpływu na dane niezarządzane.

Ostrzeżenie

Przypomnijmy, że jeśli aplikacja wykorzystała MAMDataProtectionManager.protectForOID, musi implementować program obsługi dla albo WIPE_USER_AUXILIARY_DATAWIPE_USER_DATA.

W przypadku tych testów zainstaluj aplikację i usługę Intune — Portal firmy; przed rozpoczęciem testu zaloguj się przy użyciu konta zarządzanego i niezarządzanego. W przypadku obu kont przećwicz scenariusze aplikacji, które przechowują dane konta.

Scenariusz	Warunki wstępne	Kroki
Dodatkowa obsługa czyszczenia	W aplikacji zaimplementowano program obsługi WIPE_USER_AUXILIARY_DATA	- Wykonywanie selektywnego czyszczenia z centrum administracyjnego usługi Microsoft Intune. - Potwierdź (zazwyczaj przez zalogowanie), że program obsługi czyszczenia wykonał się pomyślnie. - 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.
Overrided wipe handler	W aplikacji zaimplementowano program obsługi WIPE_USER_DATA	- Wykonywanie selektywnego czyszczenia z centrum administracyjnego usługi Microsoft Intune. - Potwierdź (zazwyczaj przez zalogowanie), że program obsługi czyszczenia wykonał się pomyślnie. - 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. - Upewnij się, że aplikacja została zamknięta z wdziękiem lub nadal jest w dobrej kondycji po zakończeniu obsługi czyszczenia.
Ręczna ochrona plików	- Twoja aplikacja wywołuje MAMFileProtectionManager.protectForOID - Twoja aplikacja ma zaimplementowany program obsługi WIPE_USER_DATA	- Upewnij się, że wykonano scenariusze, w których aplikacja chroniłaby ręcznie co najmniej jeden plik należący do zarządzanego konta. - Wykonywanie selektywnego czyszczenia z centrum administracyjnego usługi Microsoft Intune. - Potwierdź, że pliki zostały usunięte.
Ręczna ochrona bufora danych	- Twoja aplikacja wywołuje MAMDataProtectionManager.protectForOID - Twoja aplikacja ma zaimplementowany program obsługi dla lub WIPE_USER_AUXILIARY_DATAWIPE_USER_DATA	- Upewnij się, że wykonano scenariusze, w których aplikacja ręcznie chroniłaby co najmniej jeden bufor danych należący do zarządzanego konta. - Wykonywanie selektywnego czyszczenia z centrum administracyjnego usługi Microsoft Intune. - Upewnij się, że bufory danych zostały usunięte 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 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: konfiguracja aplikacji i etap 7: funkcje uczestnictwa w aplikacji, mogą, ale nie muszą być wymagane, w zależności od żądanej obsługi zasad ochrony aplikacji aplikacji. Jeśli nie masz pewności, czy którakolwiek z tych sekcji dotyczy Twojej aplikacji, wróć do tematu Kluczowe decyzje dotyczące integracji z zestawem SDK.