共用方式為

多租用戶解決方案中身分識別的結構考量

  • 發行項

身分識別是任何多租用戶解決方案的重要方面。 您應用程式的身分識別元件負責以下兩項工作：

  • 驗證使用者的身分識別 (驗證)。
  • 在租用戶範圍內強制執行使用者的權限 (授權)。

您的客戶也可能希望授權外部應用程式存取他們的資料或整合至您的解決方案。 使用者的身分識別決定使用者或服務可以存取哪些資訊。 您必須考慮您的身分識別需求，以便在租用戶之間隔離您的應用程式和資料。

警告

多租用戶和 SaaS 應用程式中的身分識別驗證和授權服務通常由第三方身分提供商 (IdP) 提供。 身分識別提供者通常是身分識別即服務 (IDaaS) 平台不可或缺的一部分。

建立您自己的 IdP 非常複雜、昂貴，而且難以安全地建立。 建立您自己的身分識別提供者是一種反模式。 不建議這樣做。

在定義多租用戶身分識別策略之前，您應該先考慮服務的進階身分識別要求，包括下列需求：

  • 使用者或工作負載身分識別會用於存取單一應用程式或產品系列中的多個應用程式嗎？ 例如，零售產品系列可能同時擁有銷售點應用程式和庫存管理應用程式，而這兩個應用程式共用相同的身分識別解決方案。
  • 您是否打算實施現代化的驗證和授權，例如 OAuth2 和 OpenID Connect？
  • 您的解決方案是否只為您基於 UI 的應用程式提供驗證？ 或者，您是否也提供 API 存取權給您的租用戶和第三方？
  • 租用戶是否需要與自己的 IdP 建立同盟，每個租用戶是否需要支援多個不同的身分識別提供者？ 例如，您可能有使用 Microsoft Entra ID、Auth0 和 Active Directory 同盟服務 (ADFS) 的租用戶，每個租用戶都希望與您的解決方案建立同盟。 您還需要了解您將支援租用戶 IdP 的哪些同盟協定，因為這些協定會影響對您自己 IdP 的要求。
  • 他們是否需要符合特定的合規要求，例如 GDPR？
  • 您的租用戶是否要求其身分識別資訊位於特定的地理區域內？
  • 您解決方案的使用者是否需要存取應用程式內一個租用戶或多個租用戶的資料？ 他們是否需要快速切換租用戶或檢視來自多個租用戶的整合資訊？ 例如，登入 Azure 入口網站的使用者可以輕鬆地在不同的 Microsoft Entra ID 目錄和他們可以存取的訂閱之間切換。

當您建立了高層級需求後，您就可以開始規劃更具體的細節和需求，例如使用者目錄來源和註冊/登入流程。

身分識別目錄

多租用戶解決方案若要驗證和授權使用者或服務，就需要一個儲存身分識別資訊的地方。 目錄可以包含每個身分識別的權威記錄，也可以包含外部身分識別的參考，這些外部身分識別儲存在另一個身分識別提供者的目錄中。

當您為多租用戶解決方案設計身分識別系統時，您需要考慮租用戶和客戶可能需要以下哪種類型的 IdP：

  • 本機身分識別提供者。 本機身分識別提供者可讓使用者自助註冊服務。 使用者提供使用者名稱、電子郵件地址或識別碼，例如獎勵卡號。 他們還會提供一個認證，就像密碼一樣。 IdP 同時儲存使用者識別碼和認證。
  • 社交識別提供者。 社交識別提供者允許使用者使用他們在社交網路或其他公開身分識別提供者 (如 Facebook、Google 或個人 Microsoft 帳戶) 上的身分。
  • 使用租用戶的 Microsoft Entra ID 目錄。 租用戶可能已經擁有自己的 Microsoft Entra ID 目錄，他們可能希望您的解決方案使用他們的目錄作為存取您解決方案的 IdP。 當您的解決方案建立為多租用戶 Microsoft Entra 應用程式時，就可以使用此方法。
  • 與租用戶的身分識別提供者建立同盟。 除了 Microsoft Entra ID 之外，租用戶也可能有自己的 IdP，而且他們可能希望您的解決方案與之建立同盟。 聯盟可實現單一登入 (SSO) 體驗，它可讓租用戶管理其使用者的生命週期和安全原則，與您的解決方案無關。

您應該考慮您的租用戶是否需要支援多個身分識別提供者。 例如，您可能需要在單一租用戶內支援本機身分、社群身分和同盟身分。 當公司使用的解決方案既適用於自己的員工，也適用於承包商時，這項要求很常見。 他們可能會對自己的員工使用同盟存取解決方案，同時也允許承包商或訪客使用者存取，因為他們在同盟 IdP 中沒有帳號。

儲存驗證及租用戶授權資訊

在多租用戶解決方案中，您需要考慮在何處儲存數種身分識別資訊，包括下列類型：

  • 有關使用者和服務帳戶的詳細資訊，包括他們的姓名和其他租用戶需要的資訊。
  • 安全驗證使用者所需的資訊，包括提供多重要素驗證 (MFA) 所需的資訊。
  • 租用戶特定資訊，例如租用戶角色和權限。 此資訊用於授權。

警告

我們不建議您自行建立驗證程序。 現代的 IdP 為您的應用程式提供這些驗證服務，它們也包含其他重要功能，例如 MFA 和條件存取。 建立您自己的身分識別提供者是一種反模式。 不建議這樣做。

請考慮下列儲存身分識別資訊的選項：

  • 在 IdP 目錄中儲存所有身分識別和授權資訊，並在多個租用戶之間共用。
  • 將使用者認證儲存在 IdP 目錄中，並將授權資訊與租用戶資訊一起儲存在應用程式階層中。

確定使用者的身分識別數

多租用戶解決方案通常允許一個使用者或工作負載身分識別存取多個租用戶的應用程式和資料。 考慮您的解決方案是否需要此方法。 如果是，那麼您應該考慮以下問題：

  • 您應該為每個人建立單一的使用者身分，還是為每個租用戶-使用者組合建立獨立的身分識別？
    • 在可能的情況下，每個人最好使用單一身分識別。 要管理多個使用者帳戶會變得很困難，不論是身為解決方案廠商的您，還是您的使用者，都是如此。 此外，現代 IdP 所提供的許多智慧型威脅防護都仰賴每個人擁有單一使用者帳戶。
    • 不過，在某些情況下，使用者可能需要擁有多重不同的身分識別。 例如，如果人們同時為工作和個人目的使用您的系統，他們可能希望將使用者帳戶分開。 或者，如果您的租用戶有嚴格的法規或地理資料儲存要求，他們可能會要求一個人擁有多重身分識別，以便遵守法規或法律。
  • 如果您使用每租用戶身分識別，請避免多次儲存認證。 使用者的認證應該針對單一身分儲存，您應該使用訪客身分等功能，從多個租用戶的身分識別記錄中參考相同的使用者認證。

授權使用者存取租用戶資料

考慮如何將使用者對應到租用戶。 例如，在註冊程序中，您可能會使用一個獨特的邀請代碼，讓他們在第一次存取租用戶時輸入。 在某些解決方案中，您可能會使用使用者註冊電子郵件地址的網域名稱，作為識別他們所屬租用戶的方法。 或者，您可以使用使用者身分識別記錄的其他屬性，將使用者對應到租用戶。 然後，您應該根據租用戶和使用者的底層不可變唯一識別碼儲存對應。

如果您的解決方案在設計上只讓單一使用者存取單一租用戶的資料，那麼請考慮下列決定：

  • IdP 如何偵測使用者正在存取的租用戶？
  • IdP 如何將租用戶識別碼傳達給應用程式？ 一般而言，租用戶識別碼的索賠會被加入到權杖中。

如果需要授予單一使用者對多個租用戶的存取權，則需要考慮以下決策：

  • 您的解決方案如何識別並授予可存取多個租用戶的使用者權限？ 例如，使用者可以是訓練租用戶的管理員，但對生產租用戶只有唯讀存取權嗎？ 或者，您是否可以為組織中的不同部門設定獨立的租用戶，但需要在所有租用戶之間維持一致的身分識別？
  • 使用者如何在租用戶之間切換？
  • 如果使用工作負載身分識別，工作負載身分識別如何指定需要存取的租用戶？
  • 使用者身分識別記錄中是否儲存了租用戶的特定資訊，而這些資訊可能會在租用戶之間洩露？ 舉例來說，假設使用者以社交身分識別註冊，然後獲得兩個租用戶的存取權。 租用戶 A 用更多資訊豐富了使用者的身分識別。 租用戶 B 是否應該存取豐富後的資訊？

本機身分或社交身分的使用者註冊程序

有些租用戶可能需要允許使用者在您的解決方案中自行註冊身分識別。 如果您不需要與租用戶的身分識別提供者聯盟，可能需要自助服務註冊。 如果需要自助註冊程序，那麼您應該考慮下列問題：

  • 允許使用者從哪些身分識別來源註冊？ 例如，使用者可以建立本機身分識別，同時使用社交身分提供者嗎？
  • 如果只允許本機身分識別，那麼是否只允許特定的電子郵件網域？ 例如，租用戶是否可以指定只允許擁有 @contoso.com 電子郵件地址的使用者註冊？
  • 在登入程序中，使用者本尊名稱 (UPN) 應該用於唯一識別每個本機身分？ 例如，電子郵件地址、使用者名稱、電話號碼和獎勵卡號碼都是 UPN 的常見選擇。 但是，UPN 會隨時間改變。 當您在應用程式的授權規則或稽核記錄中提及身分時，使用身分的底層不可變唯一識別碼是個好的做法。 Microsoft Entra ID 提供物件 ID (OID)，這是一個不可變的識別碼。
  • 使用者是否需要驗證其 UPN？ 例如，如果使用使用者的電子郵件地址或電話號碼作為 UPN，您將如何驗證資訊的正確性？
  • 租用戶管理員需要核准簽約嗎？
  • 租用戶是否需要特定的註冊體驗或 URL？ 例如，當使用者註冊時，您的租用戶是否需要品牌註冊體驗？ 您的租用戶是否要求能夠攔截註冊要求，並在繼續之前執行額外的驗證？

自助註冊使用者的租用戶存取權

當允許使用者自助註冊身分識別時，通常需要有一個程序讓使用者獲得租用戶的存取權。 註冊程序可能包括存取權授予程序，也可能是根據使用者的相關資訊 (如電子郵件地址) 自動進行的。 重要的是要為這個程序做好規劃，並考慮以下問題：

  • 註冊程序將如何判斷使用者應獲授特定租用戶的存取權限？
  • 如果使用者不應該再擁有租用戶的存取權，您的解決方案會自動取消他們的存取權嗎？ 舉例來說，當使用者離開組織時，需要有一個手動或自動的程序來移除他們對租用戶的存取權。
  • 您是否需要提供一種方式，讓租用戶可以稽核可存取其租用戶的使用者及其權限？

自動化帳戶生命週期管理

公司或企業客戶對於解決方案的共同需求，就是要有一套功能，讓他們可以自動化開啟和關閉帳戶。 開放式通訊協定，例如跨網域身分識別管理系統 (SCIM)，提供了一種業界標準的自動化方法。 這個自動化流程通常不僅包括身分識別記錄的建立和移除，還包括租用戶權限的管理。 在多租用戶解決方案中實施自動化帳戶生命週期管理時，請考慮下列問題：

  • 您的客戶是否需要為每個租用戶設定和管理自動化生命週期流程？ 例如，當使用者入職時，您可能需要在應用程式的多個租用戶中建立身分識別，而每個租用戶都有不同的權限。
  • 您是否需要實施 SCIM，或者您是否可以提供租用戶聯合，讓使用者的真實來源由租用戶控制，而不是管理本機使用者？

使用者驗證程序

當使用者登入多租用戶應用程式時，您的身分識別系統就會驗證使用者的身分。 當您規劃認證程序時，您應該考慮下列問題：

  • 您的租用戶是否需要設定自己的多重要素驗證 (MFA) 原則？ 例如，如果您的租用戶是金融服務業，他們需要實施嚴格的 MFA 原則，而小型線上零售商可能沒有相同的要求。
  • 您的租用戶是否需要設定自己的條件存取規則？ 例如，不同的租用戶可能需要封鎖來自特定地理區域的登入嘗試。
  • 您的租用戶是否需要自訂每個租用戶的登入程序？ 例如，是否需要顯示客戶的標誌？ 或者，是否需要從其他系統中擷取每個使用者的資訊，例如獎勵號碼，並傳回身分識別提供者以加入使用者個人資料？
  • 您的使用者是否需要冒充其他使用者？ 例如，支援團隊成員可能希望透過冒充其他使用者的使用者帳戶來調查其他使用者的問題，而不需要以該使用者的身分進行驗證。
  • 您的使用者是否需要存取解決方案的 API？ 例如，使用者或第三方應用程式可能需要直接呼叫您的 API 來擴充您的解決方案，而不需要使用者介面來提供驗證流程。

工作負載身分識別

在大多數解決方案中，身分通常代表使用者。 有些多租用戶系統也允許服務和應用程式使用工作負載身分識別，以存取您的應用程式資源。 例如，您的租用戶可能需要存取您的解決方案所提供的 API，以便自動執行某些管理工作。

工作負載身分識別與使用者身分類似，但通常需要不同的驗證方法，例如金鑰或證書。 工作負載身分識別不使用 MFA。 相反，工作負載身分識別通常需要其他安全控制，例如定期滾動金鑰和證書到期。

如果您的租用戶希望能夠啟用工作負載身分識別存取您的多租用戶解決方案，那麼您應該考慮以下問題：

  • 工作負載身分識別將如何在每個租用戶中建立和管理？
  • 如何將工作負載身分識別要求的範圍設定為租用戶？
  • 您是否需要限制每個租用戶所建立的工作負載身分識別的數量？
  • 是否需要為每個租用戶的工作負載身分識別提供條件存取控制？ 例如，租用戶可能希望限制工作負載身分識別從特定區域之外驗證。
  • 您將向租用戶提供哪些安全控制，以確保工作負載身分識別的安全？ 例如，自動金鑰滾動、金鑰過期、證書過期和登入風險監控都是降低工作負載身分識別可能遭濫用風險的方法。

與單一登入 (SSO) 的身分識別提供者建立同盟

租用戶已經擁有自己的使用者目錄，他們可能希望您的解決方案能與到他們的目錄建立同盟。 同盟允許您的解決方案使用其目錄中的身分，而不是管理另一個具有不同身分的目錄。

當某些租用戶想要指定自己的身分識別原則，或啟用單一登入 (SSO) 體驗時，同盟就顯得特別重要。

如果您希望租用戶與您的解決方案結合，您應該考慮以下問題：

  • 為租用戶設定同盟的程序是什麼？ 租用戶可以自行設定同盟運作，還是需要您的團隊手動設定和維護？
  • 您會支援哪些同盟協定？
  • 有哪些程序可確保不會錯誤設定同盟系統，以授予其他租用戶存取權限？
  • 在您的解決方案中，單一租用戶的身分識別提供者是否需要與多個租用戶建立同盟？ 例如，如果客戶同時擁有訓練租用戶和生產租用戶，他們可能需要將相同的身分識別提供者與兩個租用戶同盟。

授權模型

決定對您的解決方案最有意義的授權模式。 兩種常見的授權方式為：

  • 角色型授權。 將使用者指派給角色。 該應用程式的某些功能只限特定角色使用。 例如，管理員角色的使用者可以執行任何動作，而較低角色的使用者則可能擁有整個系統的子集權限。
  • 資源型授權。 您的解決方案提供一組不同的資源，每個資源都有自己的權限集。 特定使用者可能是某項資源的管理員，卻無法存取另一項資源。

這些模式截然不同，您所選擇的方式會影響您的實施以及您可以實施的授權原則的複雜性。

權利和授權

在某些解決方案中，您可能會使用按使用者授權作為商業定價模式的一部分。 您可以提供具有不同功能的不同級別使用者授權。 例如，擁有一個授權的使用者可能被允許使用應用程式功能的子集。 特定使用者根據其授權所允許存取的功能，有時稱為權利。

雖然追蹤和執行權利與授權類似，但通常是由應用程式程式碼或專用的權利系統處理，而不是由身分識別系統管理。

身分識別擴展和驗證量

隨著多租用戶解決方案的成長，需要由解決方案處理的使用者和登入要求的數量也會增加。 您應該考慮下列問題：

  • 使用者目錄是否能擴展至所需的使用者數量？
  • 驗證程序能否處理預期的登入和登入數量？
  • 會不會出現認證系統無法處理的高峰？ 例如，在太平洋標準時間上午 9 點，美國西部地區的每個人都可能開始工作並登入您的解決方案，造成登入要求的尖峰。 這些情況有時稱為登入風暴。
  • 您解決方案其他部分的高負載是否會影響驗證程序的效能？ 例如，如果您的驗證程序需要呼叫應用程式層 API，那麼大量的驗證要求會否對解決方案的其他部分造成問題？
  • 如果您無法使用您的 IdP，會發生什麼情況？ 當 IdP 無法使用時，是否有後備驗證服務可以接手提供業務連續性？

參與者

本文由 Microsoft 維護。 原始投稿人如下。

主要作者：

其他投稿人：

下一步

檢閱多租用戶解決方案中身分識別的結構方法。