適用於 iOS 的 Intune App SDK - 多重身分識別

階段 5：多重身分識別 (選擇性)

根據預設，SDK 會將原則套用至整個應用程式。 多重身分識別是一項 MAM 功能，您可以啟用該功能以在每個身分識別層級套用原則。 這需要比其他 MAM 功能更多的應用程式參與。

當應用程式想要變更使用中的身分識別時，應用程式必須通知應用程式 SDK。 SDK 也會在需要身分識別變更時通知應用程式。 目前僅支援一個受控識別。 使用者註冊裝置或應用程式後，SDK 會使用此身分識別，並將其視為主要受控識別。 應用程式中的其他使用者將被視為未受管理，且原則設定不受限制。

請注意，識別僅定義為字串。 身分識別不區分大小寫。 對 SDK 的身分識別要求可能不會傳回設定身分識別時原本使用的相同大小寫。

階段目標

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

身分識別概觀

身分識別只是帳戶的使用者名稱 (例如 user@contoso.com) 。 開發人員可以在下列層級設定應用程式的身分識別：

• 處理程序識別：設定整個處理程序的識別，主要用於單一識別應用程式。 此身分識別會影響所有工作、檔案和 UI。

• UI 身分識別：決定哪些原則套用至主執行緒上的 UI 工作，例如剪下/複製/貼上、PIN、驗證和資料共用。 UI 識別不會影響加密和備份等檔案工作。

• 執行緒身分識別：影響目前執行緒上套用的原則。 此身分識別會影響所有工作、檔案和 UI。

無論使用者是否受到管理，應用程式都負責適當地設定身分識別。

在任何時候，每個執行緒都有 UI 工作和檔案工作的有效身分識別。 這是用來檢查應套用哪些原則的身分識別。 如果身分識別為「無身分識別」或使用者不受管理，則不會套用任何原則。 下列圖表顯示如何判斷有效身分識別。

執行緒佇列

應用程式通常會將非同步和同步工作分派至執行緒佇列。 SDK 會攔截 Grand Central Dispatch (GCD) 呼叫，並將目前執行緒身分識別與已分派的工作建立關聯。 工作完成後，SDK 會暫時將執行緒身分變更為與工作相關聯的身分識別、完成工作，然後還原原始執行緒身分。

因為建置在 GCD 之上，NSOperations所以NSOperationQueue會在新增工作NSOperationQueue時以執行緒的身分識別執行。 NSOperations 或直接透過 GCD 分派的函式也可以在執行時變更目前的執行緒身分識別。 此身分識別將覆寫從發送執行緒繼承的身分識別。

在 swift 中，由於 SDK 傳播身分識別 DispatchWorkItem的方式，與 相關 DispatchWorkItem 聯的身分識別是建立項目的執行緒的身分識別，而不是分派該項目的執行緒。

檔案擁有者

SDK 會追蹤本機檔案擁有者的身分識別，並據此套用原則。 建立檔案或以截斷模式開啟檔案時，即會建立檔案擁有者。 擁有者會設定為執行工作的執行緒的有效檔案工作身分識別。

或者，應用程式可以使用明確 IntuneMAMFilePolicyManager設定檔案擁有者身分識別。 應用程式可用於 IntuneMAMFilePolicyManager 擷取檔案擁有者，並在顯示檔案內容之前設定 UI 身分識別。

共用資料

如果應用程式建立的檔案同時含有受管理和非受管理使用者的資料，則該應用程式會負責加密受管理使用者的資料。 您可以使用中的 IntuneMAMDataProtectionManager和 unprotect API 來加密資料protect。

方法 protect 接受可以是受管理或未受管理使用者的身分識別。 如果使用者是受管理的，資料將會加密。 如果使用者未受管理，標頭會新增至編碼身分識別的資料，但資料不會加密。 您可以使用方法 protectionInfo 來擷取資料的擁有者。

共用額外資訊

如果應用程式具有共用擴充功能，則可以透過 中IntuneMAMDataProtectionManager的方法protectionInfoForItemProvider擷取所共用項目的擁有者。 如果共用項目是檔案，SDK 會處理設定檔案擁有者。 如果共用項目是資料，應用程式會負責設定檔案擁有者（如果此資料會保存到檔案），並在 UI 中顯示此資料之前呼叫 setUIPolicyAccountId API。

開啟多重身分識別

根據預設，應用程式會被視為單一身分識別。 SDK 會將處理序身分識別設定為已註冊的使用者。 若要啟用多重身分識別支援，請將名稱 MultiIdentity 和值為 YES 的布林值設定新增至應用程式 Info.plist 檔案中的 IntuneMAMSettings 字典。

切換身分識別

• 應用程式啟動的身分識別切換：

  啟動時，多重身分識別應用程式會被視為在未知的未受管理帳戶下執行。 條件式啟動 UI 不會執行，且不會在應用程式上強制執行任何原則。 應用程式負責在需要變更身分識別時通知 SDK。 通常，每當應用程式即將顯示特定使用者帳戶的資料時，就會發生這種情況。

  例如，當使用者嘗試開啟筆記本中的文件、信箱或索引標籤時。 在實際開啟檔案、信箱或索引標籤之前，應用程式必須通知 SDK。 這是透過 中的 IntuneMAMPolicyManagerAPI 完成setUIPolicyAccountId的。 無論使用者是否受管理，都應該呼叫此 API。 如果使用者是受管理的，SDK 將會執行有條件的啟動檢查，例如越獄偵測、PIN 和驗證。

  身分識別切換的結果會透過完成處理常式以非同步方式傳回應用程式。 應用程式應延後開啟文件、信箱或索引標籤，直到傳回成功結果碼為止。 如果身分識別切換失敗，應用程式應該會取消該工作。

  多重身分識別應用程式應該避免用 setProcessAccountId 來設定身分識別。 使用 UIScenes 的應用程式應該使用 setUIPolicyAccountId:forWindow API 來設定身分識別。

  應用程式也可以使用 setCurrentThreadIdentity: 和 setCurrentThreadIdentity:forScope:設定目前執行緒的身分識別。 例如，應用程式會產生背景執行緒、將身分識別設定為受控識別，然後對受管理的檔案執行檔案作業。 如果應用程式使用 setCurrentThreadAccountId:，應用程式也應該使用 getCurrentThreadAccountId ，以便在完成後還原原始身分識別。 不過，如果應用程式使用 setCurrentThreadAccountId:forScope: ，則會自動還原舊的身分識別。 最好使用 setCurrentThreadAccountId:forScope:。

  由於 async/await， [IntuneMAMPolicyManager setCurrentThreadAccountId:] 並且 [IntuneMAMPolicyManager setCurrentThreadAccountId:forScope:] 無法使用。 而是在 swift 中設定當前身份使用 IntuneMAMSwiftContextManager.setAccountId(_, forScope:)。 此 API 有各種變體，用於傳遞非同步、擲回和非同步擲回閉包。

• SDK 啟動的身分識別切換：

  有時候，SDK 需要要求應用程式切換到特定身分識別。 多重身分識別應用程式必須實作 identitySwitchRequiredForAccountId 來 IntuneMAMPolicyDelegate 處理此要求的方法。

  呼叫這個方法時，如果應用程式可以處理切換至指定身分識別的要求，它應該傳遞 IntuneMAMAddIdentityResultSuccess 至完成處理常式。 如果它無法處理切換身分識別，應用程式應該傳遞 IntuneMAMAddIdentityResultFailed 至完成處理常式。

  應用程式不需要呼叫 setUIPolicyAccountId 來回應此呼叫。 如果 SDK 需要應用程式切換到未受管理的使用者帳戶，則會將空字串傳遞至呼叫中 identitySwitchRequiredForAccountId 。

• SDK 起始身分識別自動註冊：

  當 SDK 需要在應用程式中自動註冊使用者以執行指令時，應用程式必須在 中IntuneMAMPolicyDelegate實作addIdentity:completionHandler:方法。 接著，應用程式必須呼叫完成處理常式，並傳入 IntuneMAMAddIdentityResultSuccess，如果應用程式能夠新增身分識別，否則 IntuneMAMAddIdentityResultFailed。

• 選擇性抹除：

  選擇性抹除應用程式時，SDK 會呼叫 IntuneMAMPolicyDelegate中的方法wipeDataForAccountId。 該應用程序負責刪除指定用戶的帳戶以及與其相關的任何數據。 SDK 能夠移除使用者擁有的所有檔案，如果應用程式從呼叫中 wipeDataForAccountId 傳回 FALSE，也會這麼做。

  請注意，此方法是從背景執行緒呼叫的。 在移除使用者的所有資料之前，應用程式不應傳回值， (如果應用程式傳回 FALSE) ，則檔案除外。

結束準則

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

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

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

驗證登入和登出案例

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

針對這些測試，請在測試裝置上安裝您的應用程式;開始測試前請勿登入。

驗證使用中身分識別與應用程式生命週期

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

針對這些測試，請在測試裝置上安裝您的應用程式;開始測試之前，請同時使用託管和非託管帳戶登入。

驗證資料共用案例

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

針對這些測試，請在測試裝置上安裝您的應用程式;開始測試之前，請同時使用託管和非託管帳戶登入。 此外：

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

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

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

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

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

這些測試的失敗可能表示您的應用程式在嘗試傳送或接收資料時未設定正確的主動身分識別。 您可以在傳送/接收時運用 SDK 的取得身分識別 API 來調查這個問題，以確認使用中身分識別已正確設定。

後續步驟

完成上述所有 結束準則 之後，您的應用程式現在已成功整合為多重身分識別，並能根據每個身分識別強制執行應用程式防護原則。 後續章節「 階段 6：應用程式保護條件式存取支援 」和 「階段 7：Web 檢視功能」可能需要也可能不必要，這取決於您應用程式所需的應用程式保護原則支援。