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

  • 發行項

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

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

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

警告

在多租使用者和 SaaS 應用程式中，驗證和授權服務通常是由協力廠商識別提供者 （IdP） 提供。 識別提供者通常是身分識別即服務 （IDaaS） 平臺不可或缺的一部分。

建置您自己的 IdP 相當複雜、昂貴且難以安全地建置。 建置您自己的識別提供者是 反模式 。 我們不建議這麼做。

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

  • 使用者或 工作負載身分 識別是否會用來存取產品系列內的單一應用程式或多個應用程式？ 例如，零售產品系列可能有銷售點應用程式和庫存管理應用程式，其共用相同的身分識別解決方案。
  • 您是否打算實作新式驗證和授權，例如 OAuth2 和 OpenID 連線？
  • 您的解決方案是否只提供 UI 型應用程式的驗證？ 或者，您也提供對租使用者和協力廠商的 API 存取權嗎？
  • 租使用者是否需要與自己的 IdP 同盟，而且每個租使用者是否需要支援多個不同的識別提供者？ 例如，您可能有具有 Microsoft Entra ID、Auth0 和 Active Directory 同盟服務 （ADFS） 的租使用者，其中每個租使用者都希望與您的解決方案建立同盟。 您也需要瞭解您將會支援的租使用者 IdP 的同盟通訊協定，因為通訊協定會影響您自己的 IdP 需求。
  • 是否需要符合特定的合規性需求，例如 GDPR ？
  • 您的租使用者是否需要其身分識別資訊位於特定地理區域內？
  • 解決方案的使用者是否需要從一個租使用者或應用程式內的多個租使用者存取資料？ 他們需要在租使用者之間快速切換或檢視來自多個租使用者的合併資訊的能力嗎？ 例如，已登入Azure 入口網站的使用者可以輕鬆地在不同的 Azure Active Directory 和他們可存取的訂用帳戶之間切換。

當您建立高階需求時，可以開始規劃更具體的詳細資料和需求，例如使用者目錄來源和註冊/登入流程。

身分識別目錄

若要讓多租使用者解決方案驗證及授權使用者或服務，它需要一個儲存身分識別資訊的位置。 目錄 可以包含每個身分識別的權威記錄，或可能包含儲存在另一個識別提供者目錄中之外部身分識別的參考。

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

  • 本機識別提供者。 本機身分識別提供者可讓使用者自行註冊服務。 使用者提供使用者名稱、電子郵件地址或識別碼，例如獎勵卡號碼。 它們也會提供認證，例如密碼。 IdP 會同時儲存使用者識別碼和認證。
  • 社交識別提供者。 社交識別提供者可讓使用者使用他們在社交網路或其他公用身分識別提供者上擁有的身分識別，例如 Facebook、Google 或個人 Microsoft 帳戶。
  • 使用租使用者的 Microsoft Entra 識別碼或 Microsoft 365 目錄。 租使用者可能已經有自己的 Microsoft Entra ID 或 Microsoft 365 目錄，而且他們可能會希望您的解決方案使用其目錄作為 IdP 來存取您的解決方案。 當您的解決方案建置為 多租使用者 Microsoft Entra 應用程式 時，就可以使用這種方法。
  • 與租使用者的識別提供者同盟。 租使用者可能有自己的 IdP，而不是 Microsoft Entra ID 或 Microsoft 365，他們可能會希望您的解決方案與其同盟。 同盟可啟用單一登入 （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 維護。 原始投稿人如下。

主要作者：

其他投稿人：

下一步

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