Share via

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

  • 發行項

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

注意

在開始為多租使用者解決方案建置身分識別系統之前，請檢 閱多租使用者解決方案 中身分識別的架構考慮，以深入瞭解您需要做出的重要需求和決策。

驗證

驗證是建立使用者身分識別的程式。 當您建置多租使用者解決方案時，驗證程式的數個層面都有特殊考慮和方法。

同盟

您可能需要與其他識別提供者 （IdP） 同盟。 同盟可用來啟用下列案例：

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

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

如果您選擇支援租使用者特定的識別提供者，請確定您厘清您需要支援哪些服務和通訊協定。 例如，您是否支援 OpenID 連線 通訊協定和安全性判斷提示標記語言 （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 和 Azure AD B2C，這是您可以在自己的多租使用者解決方案中使用的受控識別平臺。

許多多租使用者解決方案都是軟體即服務（SaaS）。 您可以選擇要使用 Microsoft Entra ID 或 Azure AD B2C，部分取決於您如何定義租使用者或客戶群。

如需詳細資訊，請參閱 在多租使用者架構 中使用 Azure Active Directory B2C 的考慮。

要避免的反模式

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

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

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

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

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

無法考慮租使用者的需求

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

在您完成身分識別系統的設計之前，請確定您瞭解租使用者的身分識別需求。 檢閱 多租使用者解決方案 中身分識別的架構考慮，以瞭解經常出現的一些特定需求。

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

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

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

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

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

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

無法寫入稽核記錄

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

參與者

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

主要作者：

其他投稿人：

下一步

檢閱 多租使用者解決方案 中身分識別的架構考慮。