共用方式為


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

注意事項

本指南分成數個不同的階段。 從檢閱 階段 1:規劃整合開始。

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

根據預設,SDK 會將原則套用至整個應用程式。 多重身分識別是一項 MAM 功能,可讓您在每個身分識別層級上套用原則。 相較於其他 MAM 功能,這需要更多應用程式參與。

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

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

階段 Goals

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

身分識別概觀

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

  • 進程身分識別:設定整個進程的身分識別,且主要用於單一身分識別應用程式。 此身分識別會影響所有工作、檔案和UI。

  • UI 身分識別:決定要將哪些原則套用至主線程上的UI工作,例如剪下/複製/貼上、PIN、驗證和數據共用。 UI 身分識別不會影響檔案工作,例如加密和備份。

  • 線程身分識別:影響目前線程上套用的原則。 此身分識別會影響所有工作、檔案和UI。

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

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

Intune App SDK iOS:身分識別判斷程式

線程佇列

應用程式通常會將異步和同步工作分派給線程佇列。 SDK 會攔截大中央分派 (GCD) 呼叫,並將目前的線程識別與分派的工作產生關聯。 當工作完成時,SDK 會暫時將線程識別變更為與工作相關聯的身分識別、完成工作,然後還原原始的線程身分識別。

由於 NSOperationQueue 是建置在 GCD 之上, NSOperations 會在將工作新增至 時,於線程的身分識別上執行 NSOperationQueueNSOperations 或直接透過 GCD 分派的函式也可以在執行時變更目前的線程身分識別。 此身分識別會覆寫繼承自分派線程的身分識別。

在快速中,由於 SDK 如何傳播 的身 DispatchWorkItem分識別,與 DispatchWorkItem 相關聯的身分識別是建立專案而非分派專案的線程之線程的身分識別。

檔案擁有者

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

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

共享數據

如果應用程式建立具有 Managed 和 Unmanaged 使用者數據的檔案,則應用程式會負責加密受控用戶的數據。 您可以使用 protect 中的和 unprotect API IntuneMAMDataProtectionManager來加密資料。

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

共用擴充功能

如果應用程式具有共用延伸模組,則可以透過 protectionInfoForItemProvider 中的方法 IntuneMAMDataProtectionManager來擷取所共用項目的擁有者。 如果共用專案是檔案,SDK 將會處理檔案擁有者的設定。 如果共用專案是數據,應用程式會負責在將此資料保存至檔案時設定檔案擁有者,以及在UI中顯示此資料之前呼叫 setUIPolicyAccountId API。

開啟多重身分識別

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

注意事項

啟用多重身分識別時,進程身分識別、UI 身分識別和線程身分識別會設定為 nil。 應用程式會負責適當地設定它們。

切換身分識別

  • 應用程式起始的身分識別切換

    在啟動時,多重身分識別應用程式會被視為在未知的 Unmanaged 帳戶下執行。 條件式啟動UI將不會執行,且不會在應用程式上強制執行任何原則。 應用程式會負責在每次應變更身分識別時通知 SDK。 一般而言,每當應用程式即將顯示特定用戶帳戶的數據時,就會發生這種情況。

    例如,當使用者嘗試在筆記本中開啟檔、信箱或索引標籤時。 應用程式必須先通知 SDK,才能實際開啟檔案、信箱或索引標籤。 這是透過中的 setUIPolicyAccountId API IntuneMAMPolicyManager來完成。 無論使用者是否受管理,都應該呼叫此 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 需要要求應用程式切換至特定身分識別。 多重身分識別應用程式必須實作 中的 identitySwitchRequiredForAccountIdIntuneMAMPolicyDelegate 方法,才能處理此要求。

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

    應用程式不需要呼叫 setUIPolicyAccountId 即可回應此呼叫。 如果 SDK 需要應用程式切換至 Unmanaged 使用者帳戶,則會將空字串傳遞至 identitySwitchRequiredForAccountId 呼叫。

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

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

  • 選擇性抹除

    選擇性地抹除應用程式時,SDK 會在 中IntuneMAMPolicyDelegate呼叫 wipeDataForAccountId 方法。 應用程式會負責移除指定的用戶帳戶及其相關聯的任何數據。 SDK 能夠移除使用者擁有的所有檔案,而且如果應用程式從 wipeDataForAccountId 呼叫傳回 FALSE,則會這麼做。

    請注意,這個方法是從背景線程呼叫。 在使用者的所有數據都已移除之前,應用程式不應該傳回值, (如果應用程式傳回 FALSE) ,則檔案除外。

結束準則

規劃為驗證應用程式的多重身分識別整合提供大量時間。 開始測試之前:

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

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

驗證登入和註銷案例

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

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

案例 步驟
先登入Managed - 先使用受管理的帳戶登入,並驗證帳戶的數據是否受到管理。
- 使用 Unmanaged 帳戶登入,並驗證帳戶的數據未受管理。
先登入 Unmanaged - 先使用 Unmanaged 帳戶登入,並驗證帳戶的數據未受管理。
- 使用受管理的帳戶登入,並驗證帳戶的數據是否受到管理。
登入多個Managed - 先使用受管理的帳戶登入,並驗證帳戶的數據是否受到管理。
- 使用第二個受管理帳戶登入,並驗證使用者是否遭到封鎖而無法登入,而不會先移除原始的受管理帳戶。
註銷Managed - 使用受管理的 Unmanaged 帳戶登入您的應用程式。
- 註銷Managed帳戶。
- 確認受控帳戶已從您的應用程式中移除,且該帳戶的所有數據都已移除。
- 確認 Unmanaged 帳戶仍已登入,未移除任何 Unmanaged 帳戶的數據,且仍然未套用原則。
註銷 Unmanaged - 使用受管理的 Unmanaged 帳戶登入您的應用程式。
- 註銷 Unmanaged 帳戶。
- 確認 Unmanaged 帳戶已從您的應用程式中移除,且該帳戶的所有數據都已移除。
- 確認受管理的帳戶仍已登入,未移除任何 Unmanaged 帳戶的數據,且仍會套用原則。

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

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

針對這些測試,請在測試裝置上安裝您的應用程式;開始測試之前,請先使用Managed和Unmanaged帳戶登入。

案例 步驟
單一帳戶檢視,已管理 - 切換至 Managed 帳戶。
- 瀏覽至應用程式中呈現單一帳戶數據的所有頁面。
- 確認每個頁面上都套用原則。
單一帳戶檢視,Unmanaged - 切換至 Unmanaged 帳戶。
- 瀏覽至應用程式中呈現單一帳戶數據的所有頁面。
- 確認未在任何頁面上套用原則。
多帳戶檢視 - 瀏覽至應用程式中同時呈現多個帳戶數據的所有頁面。
- 確認每個頁面上都套用原則。
Managed 暫停 - 在顯示受控數據且原則作用中的畫面上,流覽至裝置主畫面或其他應用程式來暫停應用程式。
- 繼續應用程式。
- 確認仍然套用原則。
非受控暫停 - 在顯示非受控數據且未啟用原則的畫面上,流覽至裝置主畫面或其他應用程式來暫停應用程式。
- 繼續應用程式。
- 確認未套用原則。
Managed kill - 在顯示受控數據且原則作用中的畫面上,強制終止應用程式。
- 重新啟動應用程式。
- 確認如果應用程式繼續在畫面上,且受管理帳戶的數據 (預期) ,仍會套用原則。 如果應用程式在包含 Unmanaged 帳戶數據的畫面上繼續,請確認未套用原則。
非受控終止 - 在顯示非受控數據且原則為作用中的畫面上,強制終止應用程式。
- 重新啟動應用程式。
- 確認如果應用程式在畫面上繼續執行,且未受管理帳戶的數據 (預期) ,則不會套用原則。 如果應用程式在包含受管理帳戶數據的畫面上繼續,請確認仍會套用原則。
身分識別切換臨機操作 - 實驗在帳戶之間切換,以及暫停/繼續/終止/重新啟動應用程式。
- 確認受管理帳戶的數據一律受到保護,且 Unmanaged 帳戶的數據永遠不會受到保護。

驗證數據共用案例

您的多重身分識別應用程式可能會將數據傳送至其他應用程式並接收來自其他應用程式的數據。 Intune的應用程式保護原則具有指定此行為的設定。 這些測試有助於確保您的多重身分識別整合接受這些數據共享設定。

針對這些測試,請在測試裝置上安裝您的應用程式;開始測試之前,請先使用Managed和Unmanaged帳戶登入。 此外:

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

如果您的應用程式能夠將數據傳送至其他應用程式,例如Microsoft Outlook 將檔附件傳送至 Microsoft Office:

案例 步驟
將受控識別傳送至 Unmanaged 應用程式 - 切換至 Managed 帳戶。
- 瀏覽至您的應用程式可以傳送資料的位置。
- 嘗試將數據傳送至 Unmanaged 應用程式。
- 您應該會遭到封鎖,無法將數據傳送至 Unmanaged 應用程式。
受控識別傳送至受控應用程式 - 切換至 Managed 帳戶。
- 瀏覽至您的應用程式可以傳送資料的位置。
- 嘗試使用已登入的Managed帳戶,將數據傳送至另一個Managed應用程式。
- 您應該允許將資料傳送至 Managed 應用程式。
非受控識別傳送至受控應用程式 - 切換至 Unmanaged 帳戶。
- 瀏覽至您的應用程式可以傳送資料的位置。
- 嘗試使用已登入的Managed帳戶,將數據傳送至另一個Managed應用程式。
- 您應該會遭到封鎖,無法將數據傳送至其他受控應用程式。
Unmanaged 身分識別傳送至 Unmanaged 應用程式 - 切換至 Unmanaged 帳戶。
- 瀏覽至您的應用程式可以傳送資料的位置。
- 嘗試將數據傳送至 Unmanaged 應用程式。
- 應一律允許您將 Unmanaged 帳戶的數據傳送至 Unmanaged 應用程式。

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

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

案例 步驟
從非受控應用程式匯入受控識別 - 切換至 Managed 帳戶。
- 瀏覽至您的應用程式可以從其他應用程式匯入資料的位置。
- 嘗試從 Unmanaged 應用程式匯入數據。
- 您應該會遭到封鎖,無法從 Unmanaged 應用程式匯入數據。
從受控應用程式匯入受控識別 - 切換至 Managed 帳戶。
- 瀏覽至您的應用程式可以從其他應用程式匯入資料的位置。
- 嘗試使用已登入的Managed帳戶,從其他Managed應用程式匯入數據。
- 您應該允許從其他 Managed 應用程式匯入資料。
從受控應用程式匯入非受控識別 - 切換至 Unmanaged 帳戶。
- 瀏覽至您的應用程式可以從其他應用程式匯入資料的位置。
- 嘗試使用已登入的Managed帳戶,從其他Managed應用程式匯入數據。
- 您應該會遭到封鎖,無法從其他受控應用程式匯入數據。
從 Unmanaged 應用程式匯入非受控識別 - 切換至 Unmanaged 帳戶。
- 瀏覽至您的應用程式可以從其他應用程式匯入資料的位置。
- 嘗試從 Unmanaged 應用程式匯入數據。
- 一律允許您從 Unmanaged 應用程式匯入 Unmanaged 帳戶的數據。

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

案例 步驟
從 Unmanaged 應用程式接收的受控識別 - 切換至 Managed 帳戶。
- 切換至 Unmanaged 應用程式。
- 瀏覽至可傳送資料的位置。
- 嘗試將數據從 Unmanaged 應用程式傳送至您的應用程式。
- 您應用程式的受控帳戶不應該能夠從 Unmanaged 應用程式接收資料。
受控識別從受控應用程式接收 - 切換至 Managed 帳戶。
- 切換至另一個已登入Managed帳戶的Managed應用程式。
- 瀏覽至可傳送資料的位置。
- 嘗試將數據從 Managed 應用程式傳送至您的應用程式。
- 應允許您應用程式的Managed帳戶接收來自其他Managed 應用程式的數據。
從受控應用程式接收的非受控身分識別 - 切換至 Unmanaged 帳戶。
- 切換至另一個已登入Managed帳戶的Managed應用程式。
- 瀏覽至可傳送資料的位置。
- 嘗試將數據從 Managed 應用程式傳送至您的應用程式。
- 您應用程式的 Unmanaged 帳戶應該無法從受控應用程式接收數據。
從非受控應用程式接收的非受控身分識別 - 切換至 Unmanaged 帳戶。
- 切換至 Unmanaged 應用程式。
- 瀏覽至可傳送資料的位置。
- 嘗試將數據從 Unmanaged 應用程式傳送至您的應用程式。
- 您應用程式的 Unmanaged 帳戶應一律允許從 Unmanaged 應用程式接收數據。

這些測試中的失敗可能表示您的應用程式在嘗試傳送或接收數據時,並未設定正確的作用中身分識別。 您可以在傳送/接收時利用 SDK 的取得身分識別 API 來確認作用中的身分識別已正確設定,以調查此問題。

後續步驟

完成上述所有 結束準則 之後,您的應用程式現在已成功整合為多重身分識別,並可根據每個身分識別強制執行應用程式保護原則。 後續各節 :階段 6:應用程式保護條件式存取支持階段 7:Web 檢視功能可能或可能不需要,視您應用程式所需的應用程式保護原則支援而定。