共用方式為

多租用戶解決方案中身分識別的架構方法

  • 發行項

幾乎所有的多租用戶解決方案都需要身分識別系統。 在本文中，我們會討論身分識別的常見元件，包括驗證和授權，並討論如何在多租用戶解決方案中套用這些元件。

注意

在開始為多租用戶解決方案建置身分識別系統之前，請檢閱多租用戶解決方案中身分識別的架構注意事項，以深入了解您需要做出的重要需求和決策。

驗證

驗證是建立使用者身分識別的程序。 當您建置多租用戶解決方案時，驗證程序的多個層面都有需要留意的特殊注意事項和方法。

同盟

您可能需要與其他識別提供者 (IdP) 建立同盟。 同盟可用來支援下列案例：

  • 社群登入，例如讓使用者使用其 Google、Facebook、GitHub 或個人 Microsoft 帳戶。
  • 租用戶特定的目錄，例如讓租用戶能夠將應用程式與自己的身分識別提供者建立同盟，這樣就不需要在多個位置管理帳戶。

如需同盟的一般資訊，請參閱同盟身分識別模式。

如果您選擇支援租用戶專屬的身分識別提供者，請確定您已釐清您需要支援哪些服務和通訊協定。 例如，您是否支援 OpenID Connect 通訊協定和安全性聲明標記語言 (SAML) 通訊協定？ 或者，您只支援與 Microsoft Entra 執行個體建立同盟嗎？

當您實作任何身分識別提供者時，請考慮任何可能適用的規模和限制。 例如，如果您使用 Azure Active Directory (Azure AD) B2C 作為您自己的身分識別提供者，您可能需要部署自訂原則，以與特定類型的租用戶身分識別提供者建立同盟。 Azure AD B2C 會限制您可以部署的自訂原則數目，這可能會限制您可以建立同盟的租用戶專屬身分識別提供者數目。

您也可以考慮提供同盟作為功能，僅適用於較高產品層的客戶。

單一登入

單一登入體驗可讓使用者順暢地在應用程式之間切換，而不會在每個時間點提示重新驗證。

當使用者瀏覽應用程式時，應用程式會將他們導向 IdP。 如果 IdP 看到他們有現有的工作階段，它會發出新的權杖，而不需要使用者與登入程序互動。 同盟身分識別模型支援單一登入體驗，可讓使用者跨多個應用程式使用單一身分識別。

在多租用戶解決方案中，您也可以啟用另一種形式的單一登入。 如果使用者獲授權可使用多個租用戶的資料，當使用者將內容從某個租用戶變更為另一個租用戶時，您可能需要提供順暢的體驗。 請考慮您是否需要支援租用戶之間的順暢轉換，如果是的話，您的身分識別提供者是否需要重新發出具有特定租用戶宣告的權杖。 例如，登入 Azure 入口網站的使用者可以在不同 Microsoft Entra 目錄之間切換，這會導致重新驗證，並重新發出來自新選取 Microsoft Entra 執行個體的權杖。

登入風險評估

新式身分識別平台支援登入程序期間的風險評估。 例如，如果使用者從不尋常的位置或裝置登入，驗證系統可能需要額外的身分識別檢查，例如多重要素驗證 (MFA)，才能允許登入要求繼續進行。

請考慮您的租用戶是否可能有需要在驗證程序期間套用的不同風險原則。 例如，如果您在高度管制的產業中有一些租用戶，則其風險設定檔和需求可能會與在較不受管制的環境中工作的租用戶有不同的風險設定檔和需求。 或者，您可以選擇允許定價層較高的租用戶指定比購買較低層級服務的租用戶更嚴格的登入原則。

如果您需要針對每個租用戶支援不同的風險原則，您的驗證系統必須知道使用者登入的是哪個租用戶，才能套用正確的原則。

如果您的 IdP 包含這些功能，請考慮使用 IdP 的原生登入風險評估功能。 這些功能可能相當複雜且容易發生錯誤，無法自行實作。

或者，如果您與租用戶自己的身分識別提供者建立同盟，則可以套用自己的風險性登入風險降低原則，並控制應強制執行的原則和控制項。 不過，請務必避免不小心對使用者增加不必要的負擔，例如需要兩個 MFA 挑戰 - 一個來自使用者的家庭身分識別提供者，另一個來自您自己的身分識別提供者。 請確定您了解同盟如何與每個租用戶的身分識別提供者及其套用的原則互動。

模擬

模擬可讓使用者假設其他使用者的身分識別，而不使用該使用者的認證。

一般而言，模擬很危險，而且很難實作和控制。 不過，在某些情況下，模擬是必要條件。 例如，如果您操作軟體即服務 (SaaS)，技術服務人員可能需要假設使用者的身分識別，以便他們以使用者身分登入，並針對問題進行疑難排解。

如果您選擇實作模擬，請考慮如何稽核其使用方式。 請確定您的記錄包含執行動作的實際使用者，以及他們模擬之使用者的識別碼。

某些身分識別平台支援模擬，無論是內建功能，還是使用自訂程式碼。 例如，在 Azure AD B2C 中，您可以新增模擬使用者識別碼的自訂宣告，也可以取代所發行權杖中的主體識別碼宣告。

授權

授權是確定允許使用者執行哪些操作的程序。

授權資料可以儲存在多個位置，包括下列位置：

  • 在您的身分識別提供者中。 例如，如果您使用 Microsoft Entra ID 作為識別提供者，您可以使用應用程式角色 和群組等功能來儲存授權資訊。 然後，您的應用程式可以使用相關聯的權杖宣告來強制執行您的授權規則。
  • 在您的應用程式中。 您可以建置自己的授權邏輯，然後儲存每個使用者可以在資料庫或類似儲存系統中執行之動作的相關資訊。 然後，您可以針對角色型或資源層級授權設計更精細的控制項。

在大部分的多租用戶解決方案中，角色和權限指派是由租用戶或客戶所管理，而不是由您以多租用戶系統廠商的身分來進行管理。

如需詳細資訊，請參閱應用程式角色。

將租用戶身分識別和角色資訊新增至權杖

請考慮解決方案的哪個部分或元件應該執行授權要求，包括判斷使用者是否允許使用來自特定租用戶的資料。

常見的方法是讓身分識別系統將租用戶識別碼宣告內嵌至權杖。 此方法可讓應用程式檢查宣告，並確認使用者正在使用其允許存取的租用戶。 如果您使用以角色為基礎的安全性模型，您可以選擇使用使用者內擁有的角色相關資訊來擴充權杖。

不過，如果允許單一使用者存取多個租用戶，您可能需要讓使用者在登入程序期間通知他們打算使用哪個租用戶。 選取其作用中租用戶之後，IdP 可以在它所簽發的權杖中包含該租用戶的正確租用戶識別碼宣告和角色。 您也需要考慮使用者在租用戶之間切換的方式，這需要發行新的權杖。

以應用程式為基礎的授權

替代方法是讓身分識別系統與租用戶識別碼和角色無關。 使用者會使用其認證或同盟關聯性來進行識別，且權杖不包含租用戶識別碼宣告。 個別的清單或資料庫包含哪些使用者已獲授與每個租用戶的存取權。 然後，應用程式層可以根據查閱該清單，確認是否應該允許指定的使用者存取特定租用戶的資料。

使用 Microsoft Entra ID 或 Azure AD B2C

Microsoft 提供 Microsoft Entra ID、Microsoft Entra 外部 ID 和 Azure AD B2C，這是您可以在自己的多租用戶解決方案中使用的受控識別平台。

許多多租用戶解決方案都是軟體即服務 (SaaS)。 選擇是否要使用 Microsoft Entra ID、Microsoft Entra 外部 ID 或 Azure AD B2C，部分取決於您定義租用戶或客戶群的方式。

  • 如果您的租用戶或客戶是組織，他們可能已經針對 Office 365、Microsoft Teams 或自己的 Azure 環境等服務使用 Microsoft Entra 識別碼。 您可以在自己的 Microsoft Entra 目錄中建立 多租用戶應用程式，讓您的解決方案可供其他 Microsoft Entra 目錄使用。 您甚至可以在 Azure Marketplace 中列出您的解決方案，並讓使用 Microsoft Entra ID 的組織輕鬆存取。
  • 如果您的租用戶或客戶未使用 Microsoft Entra 識別碼，或他們是個人，而不是組織，請考慮使用 Microsoft Entra 外部 ID 或 Azure AD B2C。 Microsoft Entra 外部 ID 和 Azure AD B2C 都提供一組功能來控制使用者註冊和登入的方式。 例如，您可以將解決方案的存取限制為已邀請的使用者，或允許自助式註冊。 使用 Azure AD B2C 中的自訂原則，完全控制使用者與身分識別平台的互動方式。 您可以使用自訂品牌，並將 Azure AD B2C 與您自己的 Microsoft Entra 租用戶建立同盟，讓您自己的員工能夠登入。 Azure AD B2C 也支援與其他身分識別提供者建立同盟。
  • 某些多租用戶解決方案適用於上述兩種情況。 有些租用戶可能有自己的 Microsoft Entra 租用戶，而其他租用戶則不一定。 您也可以針對此案例使用 Azure AD B2C，並使用自訂原則來允許使用者從租用戶的 Microsoft Entra 目錄登入。 不過，如果您使用自訂原則在租用戶之間建立同盟，請確定您已考慮單一 Azure AD B2C 目錄可以使用的自訂原則數目限制。

如需詳細資訊，請參閱在多租用戶架構中使用 Azure Active Directory B2C 的注意事項。

應避免的反模式

建置或執行您自己的身分識別系統

建置現代化身分識別平台是很複雜的程序。 有一系列通訊協定和標準可提供支援，而且很容易不正確地實作通訊協定並公開安全性弱點。 標準和通訊協定會有所變更，您也需要持續更新身分識別系統，以減輕攻擊和支援最新的安全性功能。 請務必確保身分識別系統具有復原性，因為任何停機時間都可能會對您的解決方案的其餘部分造成嚴重後果。 此外，在大部分情況下，實作身分識別提供者並不會為企業新增權益，而這只是實作多租用戶服務的必要部分。 最好改用由專家建置、操作及保護的特殊身分識別系統。

當您執行自己的身分識別系統時，您必須儲存密碼雜湊或其他形式的認證，這會成為攻擊者的誘人目標。 即使雜湊和經過 Salt 處理的密碼通常保護不足，因為攻擊者可用的運算能力可能會危害這些形式的認證。

當您執行身分識別系統時，您也會負責產生和散發 MFA 或一次性密碼 (OTP) 代碼。 然後，這些需求表示您需要一種機制，才能使用 SMS 或電子郵件來散發這些代碼。 此外，您負責偵測目標與暴力密碼破解攻擊、節流登入嘗試、稽核等等。

使用現成的服務或元件，而不是建置或執行您自己的身分識別系統，是很好的作法。 例如，請考慮使用 Microsoft Entra ID 或 Azure AD B2C，這是受控識別平台。 受控身分識別平台廠商負責為其平台操作基礎結構，通常支援目前的身分識別和驗證標準。

無法考慮租用戶的需求

租用戶通常對於身分識別應該如何針對其使用的解決方案進行管理，有很強的意見。 例如，許多企業客戶需要與自己的身分識別提供者同盟，才能支援單一登入體驗，並避免管理多個認證集。 其他租用戶可能需要多重要素驗證，或登入程序的其他保護形式。 如果您尚未針對這些需求進行設計，稍後進行改造可能會很困難。

在您完成身分識別系統的設計之前，請確定您了解租用戶的身分識別需求。 檢閱多租用戶解決方案中身分識別的架構注意事項，以了解經常出現的一些特定需求。

將使用者和租用戶混為一體

請務必清楚考慮您的解決方案如何定義使用者和租用戶。 在許多情況下，關聯性可能相當複雜。 例如，租用戶可能包含多個使用者，而單一使用者可能會加入多個租用戶。

請確定您有一個清楚的程序，可在您的應用程式和要求內追蹤租用戶內容。 在某些情況下，此程序可能會要求您在每個存取權杖中包含租用戶識別碼，並讓您在每個要求上驗證租用戶識別碼。 在其他情況下，您會將租用戶授權資訊與使用者身分識別分開儲存，並使用更複雜的授權系統來管理哪些使用者可以針對哪些租用戶執行哪些作業。

追蹤使用者或權杖的租用戶內容適用於任何 租用模型，因為使用者身分識別一律在多租用戶解決方案中具有租用戶內容。 當您為單一租用戶部署獨立戳記時，甚至是追蹤租用戶內容的良好作法，這會證明您的程式碼基底適用於其他形式的多租用戶。

將角色和資源授權混為一體

請務必為解決方案選取適當的授權模型。 以角色為基礎的安全性方法可以簡單實作，但以資源為基礎的授權可提供更精細的控制。 請考慮租用戶的需求，以及您的租用戶是否需要授權某些使用者存取解決方案的特定部分，而不是其他部分。

無法寫入稽核記錄

稽核記錄是了解您的環境及使用者如何實作系統的重要工具。 藉由稽核每個身分識別相關事件，您通常可以判斷您的身分識別系統是否受到攻擊，而且您可以檢閱系統的使用方式。 請確定您在身分識別系統中寫入和儲存稽核記錄。 請考慮解決方案的身分識別稽核記錄是否應提供給租用戶檢閱。

參與者

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

主要作者：

其他投稿人：

下一步

檢閱多租用戶解決方案中身分識別的架構注意事項。