共用方式為

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

  • 發行項

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

  • 驗證使用者是誰（驗證）。
  • 在租使用者範圍內強制執行用戶的許可權（授權）。

您的客戶可能也想要授權外部應用程式存取其數據，或整合至您的解決方案。 使用者的身分識別會決定使用者或服務將存取哪些資訊。 請務必考慮身分識別需求，以便隔離應用程式與租使用者之間的數據。

警告

在多租使用者和 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 應用程式時，就可以使用此方法。
  • 與租用戶的識別提供者同盟。 租使用者可能有自己的IdP，除了Microsoft EntraID之外，他們可能想要讓解決方案與其同盟。 同盟可啟用單一登錄 （SSO） 體驗，並可讓租使用者管理其使用者的生命週期和安全策略，而不受您的解決方案影響。

如果您的租使用者需要支援多個識別提供者，您應該考慮。 例如，您可能需要支持本機身分識別、社交身分識別和同盟身分識別，全都在單一租用戶內。 當公司針對自己的員工和承包商使用解決方案時，這項需求很常見。 他們可能會使用同盟來存取自己的員工對解決方案的存取權，同時允許對承包商或來賓用戶進行存取，而來賓使用者則沒有同盟IdP中的帳戶。

儲存驗證和租使用者授權資訊

在多租使用者解決方案中，您必須考慮儲存數種類型的身分識別資訊的位置，包括下列類型：

  • 用戶和服務帳戶的詳細數據，包括其名稱，以及租使用者所需的其他資訊。
  • 安全地驗證使用者所需的資訊，包括提供多重要素驗證所需的資訊（MFA）。
  • 租使用者特定資訊，例如租使用者角色和許可權。 這項資訊用於授權。

警告

我們不建議您自行建置驗證程式。 新式IdP會將這些驗證服務提供給您的應用程式，也包含其他重要功能，例如MFA和條件式存取。 建置您自己的識別提供者是反模式。 不建議這樣做。

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

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

判斷使用者的身分識別數目

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

  • 您應該為每個人員建立單一使用者身分識別，或為每個租用戶用戶組合建立個別的身分識別？
    • 最好盡可能為每個人員使用單一身分識別。 您很難以解決方案廠商身分管理多個用戶帳戶，也難以管理使用者。 此外，新式IdP所提供的許多智慧型手機威脅防護都仰賴每個擁有單一用戶帳戶的人員。
    • 不過，在某些情況下，使用者可能需要擁有多個不同的身分識別。 例如，如果人員同時使用您的系統進行工作和個人用途，他們可能會想要分隔其用戶帳戶。 或者，如果您的租用戶有嚴格的法規或地理數據記憶體需求，他們可能會要求人員擁有多個身分識別，以便他們符合法規或法律。
  • 如果您使用個別租使用者身分識別，請避免多次儲存認證。 用戶應該將認證儲存在單一身分識別中，而且您應該使用來賓身分識別等功能來參考多個租使用者身分識別記錄中的相同用戶認證。

將租用戶數據的存取權授與使用者

請考慮如何將用戶對應至租使用者。 例如，在註冊程序期間，您可能會使用他們第一次存取租用戶時輸入的唯一邀請碼。 在某些解決方案中，您可以使用使用者註冊電子郵件位址的功能變數名稱來識別其所屬的租使用者。 或者，您可以使用使用者身分識別記錄的另一個屬性，將用戶對應至租使用者。 然後，您應該根據租用戶和用戶的基礎不可變唯一標識符來儲存對應。

如果您的解決方案設計成讓單一使用者只能存取單一租用戶的數據，請考慮下列決策：

  • IdP 如何偵測使用者正在存取的租使用者？
  • IdP 如何將租使用者標識碼與應用程式通訊？ 通常，租使用者標識碼宣告會新增至令牌。

如果單一使用者需要授與多個租使用者的存取權，則必須考慮下列決策：

  • 您的解決方案如何識別並授與具有多個租用戶存取權的用戶的許可權？ 例如，使用者是否可以是定型租用戶的系統管理員，並且具有生產租使用者的唯讀存取權？ 或者，您可以為組織中的不同部門擁有個別的租使用者，但您需要在所有租用戶之間維護一致的使用者身分識別？
  • 使用者如何在租用戶之間切換？
  • 如果您使用工作負載身分識別，工作負載身分識別如何指定它需要存取的租使用者？
  • 是否有租使用者特定資訊儲存在使用者的身分識別記錄中，可能會洩漏租使用者之間的資訊？ 例如，假設使用者已使用社交身分識別註冊，然後獲得兩個租使用者的存取權。 租使用者 A 以詳細資訊擴充使用者的身分識別。 租使用者 B 是否應該能夠存取擴充的資訊？

本機身分識別或社交身分識別的用戶註冊程式

某些租使用者可能需要允許使用者自行註冊解決方案中的身分識別。 如果您不需要與租使用者的身分識別提供者同盟，可能需要自助式註冊。 如果需要自我註冊程式，您應該考慮下列問題：

  • 用戶允許從哪個身分識別來源註冊？ 例如，使用者可以建立本機身分識別，以及使用社交識別提供者嗎？
  • 如果只允許本機身分識別，則只允許特定電子郵件網域嗎？ 例如，租使用者是否可以指定只有擁有 @contoso.com 電子郵件地址的用戶可以註冊？
  • 在登入程式期間，應該用來唯一識別每個本機身分識別的用戶主體名稱 （UPN） 為何？ 例如，電子郵件地址、使用者名稱、電話號碼和獎勵卡號碼都是UPN的常見選擇。 不過，UPN 可能會隨著時間而變更。 當您在應用程式的授權規則或稽核記錄中參考身分識別時，最好使用身分識別的基礎不可變唯一標識符。 Microsoft Entra ID 提供物件識別碼 （OID），這是不可變的標識碼。
  • 使用者是否需要驗證其UPN？ 例如，如果使用者的電子郵件地址或電話號碼作為 UPN 使用，您如何確認資訊是否正確？
  • 租用戶系統管理員是否需要核准註冊？
  • 租使用者是否需要租使用者特定的註冊體驗或URL？ 例如，當用戶註冊時，您的租使用者是否需要品牌註冊體驗？ 您的租使用者是否需要能夠攔截註冊要求，並在繼續之前執行額外的驗證？

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

允許使用者自行註冊身分識別時，通常需要有一個程式，才能授與租使用者的存取權。 註冊流程可能包含存取權授與程式，或根據使用者的相關信息進行自動化，例如其電子郵件位址。 請務必規劃此程式，並考慮下列問題：

  • 註冊流程會如何判斷用戶應獲授與特定租使用者的存取權？
  • 如果使用者不應該再存取租使用者，您的解決方案是否會自動撤銷其存取權？ 例如，當使用者離開組織時，必須有手動或自動化的程式，才能從租使用者中移除其存取權。
  • 您是否需要為租使用者提供一種方式，以稽核可存取其租使用者及其許可權的使用者？

自動化帳戶生命週期管理

解決方案之公司或企業客戶的常見需求是一組功能，可讓他們將帳戶上線和下線自動化。 開放式通訊協定，例如 System for Cross-domain Identity Management （SCIM），可提供業界標準的自動化方法。 此自動化程式通常不僅包含建立和移除身分識別記錄，也包括管理租用戶許可權。 當您在多租使用者解決方案中實作自動化帳戶生命週期管理時，請考慮下列問題：

  • 您的客戶是否需要為每個租用戶設定和管理自動化生命週期程式？ 例如，當用戶上線時，您可能需要在應用程式中的多個租用戶內建立身分識別，其中每個租使用者都有一組不同的許可權。
  • 您需要實作 SCIM，或是否改為提供租使用者同盟，以保留租使用者控制下的真相來源，而不是管理本機使用者？

使用者驗證程式

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

  • 您的租使用者是否需要設定自己的多重要素驗證 （MFA） 原則？ 例如，如果您的租用戶位於金融服務產業，則需要實作嚴格的 MFA 原則，而小型在線零售商可能沒有相同的需求。
  • 您的租使用者是否需要設定自己的條件式存取規則？ 例如，不同的租使用者可能需要封鎖來自特定地理區域的登入嘗試。
  • 您的租使用者是否需要自定義每個租使用者的登入程式？ 例如，您需要顯示客戶的標誌嗎？ 或者，是否需要從另一個系統擷取每個使用者的相關信息，例如獎勵號碼，並傳回給識別提供者以新增至使用者配置檔？
  • 您的使用者是否需要模擬其他使用者？ 例如，支援小組成員可能想要藉由模擬其用戶帳戶而不需要以使用者身分進行驗證，來調查其他使用者擁有的問題。
  • 您的使用者是否需要取得解決方案 API 的存取權？ 例如，使用者或第三方應用程式可能需要直接呼叫 API 來擴充您的解決方案，而不需要使用者介面來提供驗證流程。

工作負載身分識別

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

工作負載身分識別類似於使用者身分識別，但通常需要不同的驗證方法，例如密鑰或憑證。 工作負載身分識別不會使用 MFA。 相反地，工作負載身分識別通常需要其他安全性控制，例如一般密鑰輪流和憑證到期。

如果您的租使用者預期能夠對多租使用者解決方案啟用工作負載身分識別存取，則您應該考慮下列問題：

  • 如何在每個租使用者中建立和管理工作負載身分識別？
  • 工作負載身分識別要求的範圍如何設定為租使用者？
  • 您是否需要限制每個租使用者所建立的工作負載身分識別數目？
  • 您需要為每個租使用者提供工作負載身分識別的條件式訪問控制嗎？ 例如，租使用者可能會想要限制工作負載身分識別，使其無法從特定區域外部進行驗證。
  • 您會提供哪些安全性控制給租使用者，以確保工作負載身分識別保持安全？ 例如，自動化金鑰輪替、金鑰到期、憑證到期和登入風險監視都是降低風險的方法，其中可能會誤用工作負載身分識別。

與單一登錄的識別提供者同盟 （SSO）

已經有自己的用戶目錄的租使用者可能會希望您的解決方案 與其 目錄同盟。 同盟可讓您的解決方案在其目錄中使用身分識別，而不是使用不同的身分識別來管理另一個目錄。

當某些租使用者想要指定自己的身分識別原則，或啟用單一登錄 （SSO） 體驗時，同盟特別重要。

如果您預期租使用者與解決方案同盟，您應該考慮下列問題：

  • 為租用戶設定同盟的程序為何？ 租使用者是否可以自行設定同盟，或程式是否需要小組手動設定和維護？
  • 您將支援哪些同盟通訊協定？
  • 哪些程式已就緒，以確保同盟無法設定錯誤，以授與另一個租使用者的存取權？
  • 單一租使用者的身分識別提供者是否需要與解決方案中的多個租使用者同盟？ 例如，如果客戶同時擁有訓練和生產租用戶，他們可能需要將相同的識別提供者與這兩個租使用者同盟。

授權模型

決定最適合您解決方案的授權模型。 兩種常見的授權方法如下：

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

這些模型是不同的，您選取的方法會影響您的實作，以及您可以實作的授權原則複雜度。

如需詳細資訊，請參閱 角色型和資源型授權。

權利和授權

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

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

身分識別調整和驗證磁碟區

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

  • 用戶目錄是否會調整為所需的用戶數目？
  • 驗證程式會處理預期的登入和註冊數目嗎？
  • 驗證系統是否會有無法處理的尖峰？ 例如，在上午 9 點 PST 時，西部 美國 區域的每個人都可能會開始工作並登入您的解決方案，而導致登入要求激增。 這些情況有時稱為 登入風暴。
  • 解決方案其他部分的高負載會影響驗證程式的效能嗎？ 例如，如果您的驗證程式需要呼叫應用層 API，大量驗證要求是否會對解決方案的其餘部分造成問題？
  • 如果您的IdP變成無法使用，會發生什麼事？ 是否有備份驗證服務可以接管以提供商務持續性，而IdP無法使用？

參與者

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

主要作者：

其他投稿人：

下一步

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