適用於 Android 的 Intune 應用程式 SDK - 多重身分識別

適用於 Android 的 Microsoft Intune 應用程式 SDK 可讓您將 Intune 應用程式保護原則 (也稱為 MAM 原則) 併入原生 Java/Kotlin Android 應用程式。 Intune 受控應用程式是與 Intune 應用程式 SDK 整合的應用程式。 當 Intune 主動管理應用程式時，Intune 系統管理員可以輕鬆地將應用程式保護原則部署至 Intune 管理的應用程式。

第五階段：多重身分

階段 Goals

• 判斷您的應用程式是否需要多重身分識別支援。
• 瞭解 Intune 應用程式 SDK 如何感知身分識別。
• 重構您的應用程式以取得身分識別。
• 新增程式碼，以通知 SDK 整個應用程式的作用中和變更身分。
• 徹底測試受控和非受控身分識別的應用程式保護原則強制執行。

身分識別術語

術語「使用者」、「帳戶」和「身分」經常互換使用。 本指南嘗試區分如下：

• 使用者：使用軟體產品的人。 進一步區分為 使用者、使用 Android 應用程式的人員，以及 系統管理員 / 使用者 / IT 系統管理員 / IT 專業人員、使用 Microsoft Intune 系統管理中心的人員。
• 帳戶：屬於唯一識別使用者實體的組織的軟體記錄。 人類使用者可以有多個帳戶。
• 身分識別：Intune 應用程式 SDK 用來唯一識別帳戶的資料集。

Background

根據預設，Intune 應用程式 SDK 會將原則套用至整個應用程式。 註冊具有應用程式保護原則目標的帳戶之後，SDK 會將每個檔案和每個活動與該帳戶的身分識別產生關聯，並普遍套用該帳戶的目標原則。

對於許多開發人員來說，這是其應用程式所需的應用程式保護行為。 這些應用程式會被視為 單一身分識別。 完成上述階段後，您的應用程式已成功整合為單一身分識別，並可以強制執行所有基本原則。 想要保持單一身分識別的應用程式可以略過本節，並繼續進行階段 6：應用程式組態。

Intune 應用程式 SDK 可以選擇性地在每個身分識別層級強制執行原則。 如果您的應用程式已支援同時登入的多個帳戶，而且您想要透過應用程式保護原則保留此多帳戶支援，則您的應用程式會被視為 多重身分識別。

SDK 的「身分識別」

當 SDK 整合應用程式使用 registerAccountForMAM 註冊帳戶時，SDK 會將所有提供的參數 (upn、aadId、tenantId 和授權單位) 儲存為身分識別。 不過，大部分的 SDK 身分識別 API 都會使用提供的 OID (也稱為 Microsoft Entra ID 或 AAD ID) 作為身分識別碼。 MAM SDK API 會傳回 OID 字串作為身分識別，而且需要身分識別的 OID 字串參數。 某些方法也可能採用或傳回 UPN 字串，在此情況下，UPN 僅供參考。

身分識別參數不區分大小寫。 對身分識別的 SDK 要求可能不會傳回註冊或設定身分識別時使用的相同大小寫。

受控與非受控身分識別

如 註冊應用程式保護原則中所述，您的應用程式負責在使用者登入時通知 SDK。 登入時，使用者的帳戶可能會或可能不會受到應用程式保護原則的約束。 如果帳戶以應用程式保護原則為目標，SDK 會將其視為受控;否則，它不受管理。

SDK 會針對其視為受管理的身分強制執行原則。 SDK 不會針對其視為非受控的身分識別強制執行原則。

目前，Intune 應用程式 SDK 僅支援每個裝置的單一受控識別。 一旦 任何 SDK 整合應用程式註冊受控識別，所有後續註冊的身分識別 （即使它們目前是應用程式保護原則的目標） 都會被視為非受控識別。

如果受控識別已在裝置上註冊，且您的應用程式註冊另一個也以應用程式保護原則為目標的身分識別，SDK 會傳回 MAMEnrollmentManager.Result.WRONG_USER 並提示終端使用者提供補救選項。 如需詳細資訊，請參閱 註冊來自 SDK 的通知 。

主動身份

您的應用程式必須一律讓 SDK 通知目前使用的身分識別，也稱為作用中身分識別。 如果作用中身分識別是受管理的，SDK 會套用保護。 如果作用中身分識別未受管理，SDK 將不會套用保護。

由於 SDK 沒有應用程式特定的知識，因此必須信任應用程式才能共用正確的作用中身分識別。

• 如果應用程式錯誤地告知 SDK 在受控識別實際使用中時，非受控識別處於作用中狀態，則 SDK 將不會套用保護。 這可能會導致資料外洩，使使用者的資料面臨風險。

• 如果應用程式錯誤地告訴 SDK 受控識別在實際使用非受控識別時處於作用中狀態，則 SDK 會不適當地套用保護。 這不是資料外洩，但這可能會不必要地限制非受管理使用者，並使非受管理使用者的資料面臨刪除的風險。

如果您的應用程式顯示任何使用者的資料，則必須只顯示屬於作用中身分識別的資料。 如果您的應用程式目前不知道誰擁有所顯示的資料，您可能需要重構應用程式，以提高身分識別感知能力，才能開始整合多重身分識別支援。

依身分識別組織應用程式資料

每當您的應用程式寫入新檔案時，SDK 都會根據目前的作用中執行緒和進程身分識別 (也稱為「標籤」) 身分識別與該檔案產生關聯。 或者，您的應用程式可以直接呼叫 SDK，以手動標記具有特定身分識別的檔案 (如需詳細資訊) 請參閱 撰寫受保護的檔案 。 SDK 會使用此標記的檔案身分識別來進行檔案加密和選擇性抹除。

如果受控識別以加密原則為目標，則只會加密以受控識別標記的檔案。

如果系統管理員動作或設定的原則要求抹除受控資料，則只會刪除以受控識別標記的檔案。

SDK 無法將多個身分識別與單一檔案產生關聯。 如果您的應用程式將屬於多個使用者的資料儲存在同一個檔案中，SDK 的預設行為會導致這些資料保護不足或過度保護。 強烈建議您依身分識別來組織應用程式的資料。

如果您的應用程式絕對必須將屬於不同身分的資料儲存在相同的檔案中，SDK 會提供在檔案中標記資料子集的身分識別功能。 如需詳細資訊，請參閱 資料緩衝區保護 。

實作多重身分

若要宣告應用程式的多重身分識別支援，請先將下列中繼資料放在 AndroidManifest.xml 中。

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

設定作用中身分識別

您的應用程式可以在下列層級上設定作用中身分識別，並按遞減優先順序：

1. 執行緒層級
2. Context (一般) Activity 水平
3. 程序層級

執行緒層級的身分設定會取代層級 Context 的身分設定，而層級會取代處理程序層級的身分設定。

上 Context 設定的身分只會在適當的相關聯案例中使用。 例如，檔案 IO 作業沒有相關聯 Context的 。 最常見的是，應用程式會在 ContextActivity. 請考慮在 中Activity.onCreate設定Context身分。 應用程式 不得 顯示身分的資料，除非 Activity 身分設定為相同的身分。

一般而言，只有在應用程式一次只能在所有執行緒上使用單一身分識別時，進程層級身分識別才有用。 這不是支援多個帳戶的應用程式的典型行為。 強烈建議您將帳戶資料隔離，並在執行緒或 Context 層級上設定作用中身分。

如果您的應用程式使用內容來 Application 取得系統服務，請確定已設定執行緒或進程身分識別，或您已在應用程式的內容 Application 上設定 UI 身分識別。

如果您的應用程式使用 Service 內容來啟動意圖、使用內容解析器或利用其他系統服務，請務必在內容上 Service 設定身分識別。 同樣地，如果您的應用程式使用內容來JobService執行這些動作，請務必根據實作的要求JobService在內容或執行緒上JobService設定身分識別。 例如，如果您 JobService 處理單一身分的工作，請考慮在內容上 JobService 設定身分。 如果您 JobService 處理多個身分識別的工作，請考慮在執行緒層級設定身分識別。

MAMPolicyManager 中的下列方法可用來設定作用中身分識別，並擷取先前設定的身分識別值。

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);

為了方便起見，您也可以直接透過 MAMActivity 中的方法來設定活動的身份，而不是呼叫 MAMPolicyManager.setUIPolicyIdentityOID。 請使用下列方法：

     public final void switchMAMIdentityOID(final String newIdentityOid, final EnumSet<IdentitySwitchOption> options);

常見的身分切換陷阱

• 針對 的呼叫 startActivity，Intune 應用程式 SDK 會假設層級 Context 的作用中身分識別與提供的 Intent 參數相關聯。 我們強烈建議使用 的Activity上下文來設定Context層級身份，而不是 Application的上下文。

• 建議在活動的方法onCreate期間設定Context身分。 但是，請務必涵蓋其他進入點，例如 onNewIntent。 否則，當重複使用相同的活動來顯示受控和非受控身分識別的資料時，原則可能會不正確套用，導致未受保護的公司資料或不當限制個人資料。

身分切換結果

用來設定身分識別的所有方法都會透過 MAMIdentitySwitchResult 回報結果值。 可以傳回四個值：

應用程式應該先確認 MAMIdentitySwitchResultSUCCEEDED 在顯示或使用受控帳戶的數據之前。

大部分設定作用中身分識別的方法都會同步傳回 MAMIdentitySwitchResult 。 如果透過 setUIPolicyIdentityOID 設定Context身分，則會以非同步方式報告結果。 應用程式可能會實作 MAMSetUIIdentityCallback 來接收此結果，或可能會傳遞回呼物件的 Null。 如果在先前ContextsetUIPolicyIdentityOID呼叫的結果尚未傳遞時進行呼叫，則setUIPolicyIdentityOID新的回呼將取代舊的回呼，而原始回呼將永遠不會收到結果。

目前，進程和執行緒身分識別切換一律會針對已啟用多身分識別的應用程式成功。 SDK 保留未來新增失敗條件的權利。

如果 UI 身分識別切換會與執行緒身分識別衝突，或使用者取消條件式啟動需求，例如， (按下 PIN 畫面上的返回按鈕，則可能會因無效引數而失敗) 。

活動上失敗的UI身分識別切換的預設行為是完成活動。 若要變更此行為，並接收活動身分變更嘗試的通知，您可以覆寫 中的方法 MAMActivity。

    public void onSwitchMAMIdentityComplete(final MAMIdentitySwitchResult result);

如果您覆寫 onSwitchMAMIdentityComplete (或呼叫 super 方法) ，則 必須 確保在身分切換失敗後不會顯示受管帳戶的資料。

身分識別、意圖和 IdentitySwitchOptions

除了使用作用中身分識別自動標記新檔案之外，SDK 也會使用作用中身分識別來標記 意圖 。 根據預設，SDK 會檢查傳入意圖的身分，並將其與作用中的身分進行比較。 如果這些身分不相符，SDK 通常會 (*) 要求身分切換， (請參閱下方的 隱含身分變更 ，以取得更多詳細資料) 。

SDK 也會儲存此傳入意圖身分識別以供日後使用。 當應用程式明確變更 UI 身分時，SDK 會將應用程式嘗試切換至的身分識別與最新的傳入意圖身分進行比較。 如果這些身分不相符，SDK 通常會 (*) 身分切換失敗。

SDK 會執行此檢查，因為它假設應用程式仍在顯示屬於意圖上標記身分的意圖內容。 此假設可防止應用程式在顯示受控資料時無意中關閉保護;不過，此假設可能不符合應用程式的實際行為。

選擇性 IdentitySwitchOption 列舉可以傳遞至 setUIPolicyIdentityOID 和 switchMAMIdentityOID API，以修改 SDK 的預設行為。

• IGNORE_INTENT：在UI層要求身分切換時，此選項會通知SDK略過將要求的身分引數與最近儲存的意圖身分進行比較。 當您的應用程式不再顯示屬於該身分識別的內容，且 SDK 不應封鎖此身分識別切換時，這很有用。 例如：

  1. 您的應用程式是文件檢視器。 它可以呈現從其他應用程式傳入的文件。 它還包含用戶可以切換帳戶的功能。 每當使用者使用此帳戶切換功能時，應用程式都會導覽至帳戶特定的登陸頁面，其中包含該帳戶最近的文件。
  2. 您的應用程式收到顯示文件的意圖。 此意圖會以受控識別標記。
  3. 您的應用程式會切換至受控識別，並顯示此檔，並正確套用保護。
  4. 使用者使用帳戶切換器變更為其個人帳戶。

  您的應用程式必須在步驟 4 中變更 UI 身分識別。 在此情況下，由於應用程式的行為是從受管理帳戶的資料 (意圖) 中的文件中導覽，因此應 IGNORE_INTENT 在身分切換呼叫中使用。 這可避免 SDK 不當地失敗此呼叫。

• DATA_FROM_INTENT：在UI層要求身分切換時，此選項會通知SDK，身分 切換成功後，將繼續顯示最近儲存的意圖身分的資料。 因此，SDK 會根據先前的意圖身分完整評估接收原則，以判斷是否允許顯示該原則。 例如：

  1. 您的應用程式是文件檢視器。 它可以呈現從其他應用程式傳入的文件。 它還包含用戶可以切換帳戶的功能。 與前面的示例不同，每當用戶使用此帳戶切換功能時，應用程序都會導航到一個共享頁面，該頁面顯示 所有帳戶的最近文檔。
  2. 您的應用程式收到顯示文件的意圖。 此意圖會以受控識別標記。
  3. 您的應用程式會切換至受控識別，並顯示此檔，並正確套用保護。
  4. 使用者使用帳戶切換器變更為其個人帳戶。

  您的應用程式必須在步驟 4 中變更 UI 身分識別。 在此情況下，由於應用程式的行為是繼續在意圖) 中顯示受控識別的資料 (文件預覽，因此它應該在 DATA_FROM_INTENT 身分識別切換呼叫中使用。 這會通知 SDK 檢查已設定的應用程式保護原則，以判斷是否適合繼續顯示資料。

(*) SDK 的預設行為確實包含特殊大小/合併，例如，如果意圖來自同一個應用程式內部或系統啟動器，則會略過此資料輸入檢查。

清除作用中身分

您的應用程式可能具有與帳戶無關的案例。 您的應用程式也可能有不需要任何登入的本機非受控案例案例。 在這兩種情況下，您的應用程式可能不希望 SDK 強制執行受控識別的原則，但您可能沒有要切換至的明確身分識別。

您可以呼叫任何將身分識別 OID 參數設定為 null的設定身分識別方法，以清除作用中身分識別。 清除一個層級的身分識別會導致 SDK 根據優先順序在其他層級尋找作用中的身分識別。

或者，您可以傳遞空字串作為身分識別 OID 參數，這會將身分識別設定為特殊的空值，該值會被視為非受控識別。 將作用中身分識別設定為空字串，會告知 SDK 不要強制執行 任何 應用程式保護原則。

隱含身分變更

上一節說明您的應用程式可以在執行緒、內容和進程層級明確設定作用中身分識別的不同方式。 不過，應用程式中的作用中身分也可以變更，而不需要應用程式呼叫任何這些方法。 本節說明您的應用程式如何接聽和回應這些隱含身分變更。

接聽這些隱含身分變更是選擇性的，但建議使用。 SDK 絕不會在未提供這些隱含身分變更通知的情況下變更作用中身分識別。

隱含身分變更的來源

• 來自 其他 Intune 受控應用程式 的數據輸入可能會變更執行緒和內容層級的作用中身分識別。

  • 如果活動是從另一個 MAM 應用程式所傳送的活動 Intent 啟動，則活動的身分識別會根據傳送時其他應用程式 Intent 中的作用中身分識別來設定。

    • 例如，當使用者選取文件附件時，會從 Microsoft Outlook 的意圖啟動檢視 Word 文件的活動。 Office 的文件檢視器活動的身分識別會切換至 Outlook 中的身分識別。

  • 針對服務，執行緒身分識別會在 or onStartonBind 呼叫期間以類似的方式設定。 呼叫傳回的 Binder 來源 onBind 也會暫時設定執行緒身分識別。

  • 呼叫 a ContentProvider 會類似地設定其持續時間的執行緒身分識別。

• 使用者與活動的互動可以變更環境定義層級上的作用中身分識別。 例如：

  • 使用者取消授權提示 Resume 將導致隱含切換至空身分。

處理隱含身分變更

您的應用程式可以選擇性地接聽這些隱含身分變更並做出反應。 例如，您的應用程式可能需要多個步驟才能使用新增的帳戶，例如電子郵件應用程式設定新的收件匣。 在看到嘗試將身分切換至這個不完整帳戶的身分時，應用程式的處理常式可能會先將使用者重新導向至帳戶設定活動，然後再接受身分切換。 或者，應用程式的處理常式可能會顯示錯誤對話方塊，並封鎖身分識別切換。

您的應用程式可以在 或 上ContextProvider實作 MAMIdentityRequirementListener 介面Service，以取得套用至此執行緒的身分識別變更。 您的實作必須覆寫：

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

您的應用程式可以在套用至此活動的身分識別變更上Activity實作 MAMActivityIdentityRequirementListener 介面。 您的實作必須覆寫：

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

AppIdentitySwitchReason列舉參數描述隱含身分識別開關的來源。

AppIdentitySwitchResultCallback 參數可讓開發人員覆寫身分識別參數的預設行為：

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

onMAMIdentitySwitchRequired 會針對所有隱含身分變更呼叫，但透過從 傳 MAMService.onMAMBind回的 Binder 所做的變更除外。 立即呼叫的 onMAMIdentitySwitchRequired 預設實作：

• callback.reportIdentitySwitchResult(FAILURE) 當原因是 RESUME_CANCELLED.

• callback.reportIdentitySwitchResult(SUCCESS) 在所有其他情況下。

預期大部分的應用程式都不需要以不同的方式封鎖或延遲身分識別切換，但如果應用程式需要這樣做，則必須考慮下列幾點：

• 如果身分識別切換遭到封鎖，使用者行為會與 SDK 的「從其他應用程式接收資料」應用程式保護設定禁止資料輸入相同。

• 如果服務在主執行緒上執行，reportIdentitySwitchResult則必須同步呼叫，否則 UI 執行緒會停止回應。

• 若要建立，ActivityonMAMIdentitySwitchRequired 會在 之前呼叫onMAMCreate。 如果應用程式必須顯示 UI 才能判斷是否允許身分識別切換，則必須使用 不同的 活動來顯示該 UI。

• 在 中， Activity當要求切換至空白身分識別且原因為 RESUME_CANCELLED時，應用程式必須修改繼續的活動，以顯示與該身分識別切換一致的資料。 如果無法做到這一點，應用程式應該拒絕切換，而且系統會再次要求使用者遵守繼續身分識別 (的原則，例如，在應用程式 PIN 輸入畫面) 。

如果要求的身分識別是受控 (使用 MAMPolicyManager.getIsIdentityOIDManaged 來檢查) ，但應用程式無法使用該帳戶 (例如，因為必須先在應用程式中設定帳戶，) 例如電子郵件帳戶，然後應該拒絕身分識別切換。

的 MAMActivity.onMAMIdentitySwitchRequired 預設行為可以透過呼叫靜態方法 MAMActivity.defaultOnMAMIdentitySwitchRequired(activity, upn, oid, reason, callback)來存取。

同樣，如果您需要重寫 MAMActivity.onSwitchMAMIdentityComplete，則可以在不明確繼承自 MAMActivity的情況下實作MAMActivityIdentitySwitchListener。

身分切換和螢幕截圖限制

Intune 應用程式 SDK 會使用 Window 旗標 FLAG_SECURE 來強制執行螢幕擷取畫面原則。 某些應用程式也可能為自己的目的而設定 FLAG_SECURE 。 當應用程式保護原則不限制螢幕擷取畫面時，SDK 不會修改 FLAG_SECURE。

在身分識別從原則需要停用螢幕擷取畫面的身分切換至原則不需要停用的身分識別時，SDK 會清除 FLAG_SECURE。 因此，您的應用程式不應依賴 FLAG_SECURE 身分識別切換後的保留設定。

在非同步作業中保留身分識別

應用程式通常會從 UI 執行緒分派背景工作，以處理其他執行緒上的作業。 多重身分識別應用程式必須確保這些背景工作以適當的身分運作，這通常是分派它們的活動所使用的相同身分。

Intune 應用程式 SDK 提供 MAMAsyncTask 和 MAMIdentityExecutors ，以協助在非同步作業中保留身分識別。 您的應用程式必須使用這些 (，或明確設定工作上的執行緒身分識別，) 如果其非同步作業可以：

• 將屬於受控識別的資料寫入檔案
• 與其他應用程式通訊

MAMAsyncTask

若要使用 MAMAsyncTask，只需從中繼承，而不是 AsyncTask 和 分別取代 doInBackgroundMAMonPreExecuteMAM 和 onPreExecute 的覆寫doInBackground。 建構函式會 MAMAsyncTask 採用活動內容。 例如：

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 將根據正常優先順序採用作用中身分。

MAMIdentity執行程式

MAMIdentityExecutors可讓您將現有Executor或執行個體包裝為身分保留 ExecutorExecutorService/with wrapExecutor 和wrapExecutorService方法。ExecutorService 例如

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

MAMIdentityExecutors 將根據正常優先順序採用作用中身分。

檔案保護

寫入受保護的檔案

如上述依 身分識別組織應用程式資料 中所述，Intune 應用程式 SDK 會在撰寫檔案時，將執行緒/進程層級) 的作用中身分識別 (與檔案產生關聯。 在檔案建立時設定正確的身分至關重要，以確保正確的加密和選擇性擦除功能。

您的應用程式可能會使用 MAMFileProtectionManager 類別來查詢或變更檔案的身分識別，特別是 MAMFileProtectionManager.getProtectionInfo 用於查詢和 MAMFileProtectionManager.protectForOID 變更。

此 protectForOID 方法也可用於保護目錄。 目錄保護會遞迴套用至目錄中包含的所有檔案和子目錄。 當目錄受到保護時，在目錄內建立的所有新檔案都會自動套用相同的保護。 由於目錄保護會遞迴 protectForOID 套用，因此大型目錄的呼叫可能需要一些時間才能完成。 因此，將保護套用至包含大量檔案的目錄的應用程式可能想要在背景執行緒上非同步執行 protectForOID 。

使用身分識別參數的空字串呼叫， protectForOID 會使用非受控識別來標記檔案/目錄。 如果先前已加密，此作業會從檔案/目錄中移除加密。 發出選擇性抹除命令時，不會刪除檔案/目錄。

顯示受保護的檔案內容

在 顯示 檔案內容時，設定正確的身分識別也同樣重要，以防止未經授權的使用者檢視受管理資料。 SDK 無法自動推斷正在讀取的檔案與顯示在 .Activity 應用程式 必須 先適當地設定 UI 身分識別，才能顯示任何受控資料。 這包括從檔案讀取的資料。

如果檔案來自應用程式外部 (ContentProvider 來自公開可寫入位置) 或從讀取，則應用程式 必須 先嘗試使用資料來源) 的正確 MAMFileProtectionManager.getProtectionInfo 多載來判斷檔案身分識別 (，才能顯示從檔案讀取的資訊。

如果報告非 Null、非空白身分識別，應用程式getProtectionInfo必須使用 MAMActivity.switchMAMIdentityOID 或 MAMPolicyManager.setUIPolicyIdentityOID 來設定 UI 身分識別，以符合此身分識別。 如果身分切換失敗，則 不得 顯示檔案中的資料。

從內容 URI 讀取時，可能需要先透過多載) 讀取 getProtectionInfoUri 身分識別 (，然後適當地設定內容或執行緒身分識別。 這必須在 上開啟檔案描述子或輸入串流 ContentResolver之前完成，否則作業可能會失敗。

範例流程可能如下所示：

• 使用者選取要在應用程式中開啟的文件。

• 在開啟流程期間，在從磁碟讀取資料之前，應用程式會確認應該用來顯示內容的身分識別：

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

• 應用程式會等待，直到結果報告給回呼。

• 如果報告的結果是失敗，應用程式不會顯示文件。

• 應用程式會開啟並轉譯檔案。

如果應用程式使用 Android DownloadManager 下載檔案，SDK 會嘗試使用 先前所述的身分識別優先順序自動保護這些檔案。 如果未設定執行緒身分識別，則會使用用來擷取 的內容 DownloadManager 。 如果下載的檔案包含公司數據，如果下載後移動或重新建立檔案，應用程式有責任呼叫 protectForOID 。

Single-Identity 到多重身份的過渡

如果先前發行具有單一身分識別 Intune 整合的應用程式稍後整合多重身分識別，則先前安裝的應用程式將會經歷轉換。 使用者看不到此轉換。

應用程式 不需要 處理此轉換。 在轉換之前建立的所有檔案都會繼續被視為受管理 (，因此如果加密原則處於) 狀態，它們會保持加密狀態。

如果您不想讓所有先前的應用程式資料都與受控識別相關聯，您可以偵測此轉換，並明確移除保護。

• 將應用程式的版本與新增多重身分識別支援的已知版本進行比較，以偵測升級。
• 在您不想與受控識別相關聯的檔案或目錄上，使用空字串呼叫 protectForOID 身分識別參數。

離線場景

Intune 應用程式 SDK 會在未安裝公司入口網站應用程式時以「離線」模式執行。 檔案身分標籤對離線模式敏感：

• 如果未安裝公司入口網站，則無法為檔案加上身分識別標籤。 在離線模式中呼叫 MAMFileProtectionManager.protectForOID 是安全的，但不會有任何影響。

• 如果已安裝公司入口網站，但應用程式沒有應用程式保護原則，則無法可靠地標示檔案。

• 當檔案身分識別標記變成可用時，所有先前建立的檔案都會被視為屬於空字串身分識別) 的個人/非受控 (，除非應用程式先前已安裝為單一身分識別受控應用程式，如 單一身分識別到多重身分識別轉換中所述。

為了避免這些情況，應用程式應避免建立包含帳戶資料的檔案，直到帳戶註冊成功完成為止。 如果您的應用程式絕對必須在離線時建立檔案，它可以使用 MAMFileProtectionManager.protectForOID 在 SDK 上線時更正檔案的相關聯身分識別。

資料緩衝區保護

SDK 的 MAMDataProtectionManager 提供方法，以 或 InputStream 格式檢查byte[]和變更特定資料緩衝區上的標記身分識別。

MAMDataProtectionManager.protectForOID 允許應用程式將資料與身分建立關聯，如果身分目前是加密原則的目標，則會加密資料。 這種加密數據適合以文件的形式存儲到磁盤。

MAMDataProtectionManager 也可讓您查詢與身分相關聯的資料，並取消加密。

使用 的 MAMDataProtectionManager 應用程式應該實作通知的 MANAGEMENT_REMOVED 接收者。 如需詳細資訊，請參閱 註冊來自 SDK 的通知 。

此通知完成之後，透過此類別保護的緩衝區將不再可讀， (如果緩衝區受到) 保護時已啟用檔案加密。 應用程式可以在處理MANAGEMENT_REMOVED通知時呼叫MAMDataProtectionManager.unprotect所有緩衝區，以防止這些緩衝區變得無法讀取。 如果您想保留身分資訊，在此通知期間致電也是安全的 protectForOID 。 加密保證會在通知期間停用，而且呼叫 protectForOID 處理常式不會加密資料緩衝區。

內容提供者

多重身分識別應用程式也必須保護透過 ContentProvider共用的資料，以防止不當共用受管理內容。

您的應用程式必須先呼叫靜態 MAMContentProvider 方法 isProvideContentAllowedForOid(provider, oid) ，才能傳回內容。 如果此函式傳回 false，則 不得 將內容傳回給呼叫端。

isProvideContentAllowedForOid如果您ContentProvider要傳回 ParcelFileDescriptor. 透過內容提供者傳回的檔案描述元會根據檔案身分識別自動處理。

選擇性擦除

根據預設，Intune 應用程式 SDK 會自動處理選擇性抹除，並刪除與受控識別相關聯的所有 檔案 。 之後，SDK 會正常關閉應用程式，完成活動並終止應用程式進程。

SDK 為您的應用程式提供選擇性功能 (以補充建議的) 或覆寫預設抹除行為。

SDK 的預設抹除處理常式不會處理受 保護的資料緩衝區 MAMDataProtectionManager。 如果您的應用程式使用此功能，則 必須 補充或覆寫預設抹除處理常式，才能移除該資料。

補充預設抹除行為

若要補充預設的 SDK 抹除行為，您的應用程式可以註冊 WIPE_USER_AUXILIARY_DATAMAMNotificationType。

此通知將由 SDK 在執行預設選擇性抹除 之前 傳送。 SDK 會等待應用程式的通知處理常式完成，然後再刪除資料並終止應用程式。 您的應用程式應該同步清除資料，直到所有清除完成為止不會傳回。

應用程式應該強烈考慮使用 WIPE_USER_AUXILIARY_DATA來補充預設抹除行為，因為應用程式特定的清除對於多重身分識別應用程式來說很常見。

覆寫預設抹除行為

若要覆寫預設的 SDK 抹除行為，您的應用程式可以註冊 WIPE_USER_DATAMAMNotificationType。

覆寫預設的 SDK 抹除行為會為您的應用程式帶來相當大的風險。 您的應用程式將全權負責移除與受控識別相關聯的所有資料，包括已標記該身分識別的所有檔案和資料緩衝區。

• 如果受控識別受到加密保護，且應用程式的自訂抹除處理常式未完全移除所有受控資料，則任何剩餘的受控檔案都會保持加密狀態。 這些資料將變得無法存取，而且您的應用程式可能無法正常處理嘗試讀取加密資料。
• 如果應用程式的抹除處理常式移除未以受控識別標記的檔案，可能會導致未受控使用者的資料遺失。

如果應用程式的自訂抹除處理常式會從檔案中移除受控資料，但想要將其他資料保留在檔案中，則 必須 透過 MAMFileProtectionManager.protectForOID) 將檔案的身分識別 (變更為非受控識別或空字串。

覆寫的抹除處理常式應該同步清除資料，直到所有清除完成為止不會傳回。

請考慮在完成自訂抹除處理常式步驟之後手動關閉應用程式，以防止使用者在抹除發生後存取記憶體內資料。

退出條件

計劃投入大量時間來驗證應用程式的多重身分識別整合。 開始測試之前：

• 建立應用程式保護原則並將其指派給帳戶。 這將是您的測試受管帳戶。
• 建立，但不要將應用程式保護原則指派給另一個帳戶。 這將是您測試的非受管帳戶。 或者，如果您的應用程式支援 Microsoft Entra 帳戶以外的多種帳戶類型，您可以使用現有的非 Entra 帳戶作為未受控測試帳戶。
• 重新熟悉應用程式內強制執行原則的方式。 多重身分識別測試需要您輕鬆區分應用程式何時在強制執行原則的情況下運作和未運作。 封鎖螢幕擷取畫面的應用程式保護原則設定可有效快速測試原則強制執行。
• 請考慮應用程式提供的整組 UI。 列舉顯示帳戶資料的畫面。 您的應用程式是否一次只顯示單一帳戶的資料，還是可以同時顯示屬於多個帳戶的資料？
• 請考慮應用程式建立的整組檔案。 列舉這些檔案中哪些包含屬於帳戶的資料，而不是系統層級的資料。
  • 決定如何驗證每個檔案的加密。
• 請考慮您的應用程式與其他應用程式互動的整組方式。 列舉所有輸入和輸出點。 您的應用程式可以擷取哪些類型的資料？ 它廣播了什麼意圖？ 它實作哪些內容提供者？
  • 決定您將如何運用這些資料共用功能。
  • 準備測試裝置，其中包含可與您的應用程式互動的受控和非受控應用程式。
• 請考慮您的應用程式如何讓終端使用者與所有登入的帳戶互動。 使用者是否需要手動切換至帳戶，才能顯示該帳戶的資料？

徹底評估應用程式目前的行為後，請執行下列一組測試來驗證多重身分識別整合。 請注意，這不是完整的清單，也不保證應用程式的多重身分實作沒有錯誤。

驗證登入及登出實務範例

您的多重身分識別應用程式最多支援 1 個受控帳戶和多個非受控帳戶。 這些測試有助於確保您的多重身分識別整合不會在使用者登入或登出時不當地變更保護措施。

針對這些測試，請安裝您的應用程式和 Intune 公司入口網站;在開始測試之前，請勿登入。

驗證作用中身分識別和應用程式生命週期

您的多重身分識別應用程式可能會顯示包含單一帳戶資料的檢視畫面，並允許使用者明確變更目前使用中的帳戶。 它也可以同時顯示包含多個帳戶資料的檢視。 這些測試有助於確保您的多重身分整合在整個應用程式生命週期中為每個頁面上的活動身分提供正確的保護。

針對這些測試，請安裝您的應用程式和 Intune 公司入口網站;在開始測試之前，請先使用受控和非受控帳戶登入。

驗證資料共用實務範例

您的多重身分識別應用程式可能會傳送資料給其他應用程式，並從其他應用程式接收資料。 Intune 的應用程式保護原則具有指定此行為的設定。 這些測試有助於確保您的多重身分整合遵循這些資料共用設定。

針對這些測試，請安裝您的應用程式和 Intune 公司入口網站;在開始測試之前，請先使用受控和非受控帳戶登入。 此外：

• 將受管理帳戶的政策設定為：
  • 「將組織資料傳送至其他應用程式」變更為「原則受控應用程式」。
  • 「從其他應用程式接收資料」變更為「原則管理的應用程式」。
• 在測試裝置上安裝其他應用程式：
  • 以與應用程式相同的原則為目標的受控應用程式，可以傳送和接收資料 (，例如 Microsoft Outlook) 。
  • 任何可以傳送和接收資料的非受控應用程式。
• 使用受管理的測試帳戶登入其他受管理的應用程式。 即使其他受控應用程式是多重身分識別，也只能使用受控帳戶登入。

如果您的應用程式能夠將資料傳送至其他應用程式，例如 Microsoft Outlook 將文件附件傳送至 Microsoft Office：

您的應用程式可能會主動從其他應用程式匯入資料，例如 Microsoft Outlook 附加來自 Microsoft OneDrive 的檔案。 您的應用程式也可能被動地從其他應用程式接收資料，例如 Microsoft Office 從 Microsoft Outlook 附件開啟文件。 接收應用程式保護原則設定涵蓋這兩種案例。

如果您的應用程式能夠主動從其他應用程式匯入資料：

如果您的應用程式能夠被動地接收來自其他應用程式的資料：

這些測試失敗可能表示您的應用程式在嘗試傳送或接收資料時沒有設定正確的作用中身分識別。 您可以在傳送/接收時利用 SDK 的取得身分識別 API，以確認作用中身分識別已正確設定，以進行此問題。

驗證選擇性清除案例

您的多重身分識別應用程式可能已補充或覆寫 SDK 的預設抹除行為。 這些測試有助於確保您的多重身分識別整合在啟動抹除時正確移除受管理資料，而不會影響非受管理資料。

針對這些測試，請安裝您的應用程式和 Intune 公司入口網站;在開始測試之前，請先使用受控和非受控帳戶登入。 針對這兩個帳戶，請練習儲存帳戶資料的應用程式案例。

後續步驟

完成上述所有 結束準則 之後，您的應用程式現在已成功整合為多重身分識別，並可以針對每個身分識別強制執行應用程式保護原則。 後續區段 階段 6：應用程式組態和階段 7：應用程式參與功能 可能需要，也可能不需要，視您應用程式所需的應用程式保護原則支援而定。 如果您不確定這些部分是否適用於您的應用程式，請重新瀏覽 SDK 整合的關鍵決策。