共用方式為

使用多租用戶應用程式實作跨租用戶通訊

  • 發行項

本指南提供一個解決方案，可在託管於不同 Microsoft Entra 租用戶管理之 Azure 訂用帳戶中的服務之間進行雙向、安全的通訊。

保護 Azure 中的多租用戶通訊可能會因為許多服務固有的限制而具有挑戰性。 您可以使用 Azure 受控識別直接從 Microsoft Entra ID 取得權杖，這樣就不需要直接管理認證。 不過，Azure 受控識別無法跨租使用者界限運作，而典型的替代方法是使用共用密碼，例如共用存取簽章 URL。 請記住，如果您使用共用密碼，您必須跨 Microsoft Entra 租用戶界限安全地分散和輪替密碼，。

避免此額外負擔的其中一個選項是建立多租用戶應用程式來代表工作負載的身分識別。 透過同意過程，您可以讓外部租用戶知道此工作負載身分識別，並於最終允許它在外部租用戶中驗證服務。

本文提供此模式的範例實作，其使用樣本程式碼。

此模式可以給任何具有各種服務的多租用戶情境重複使用，這些服務需要跨 Microsoft Entra 租用戶界限進行通訊。

架構

跨租用戶通訊架構的圖解。

下載此架構的 PowerPoint 檔案。

工作流程

下列工作流程會對應至上圖：

  1. 提供者端的系統管理員會建立多租用戶應用程式註冊，並為其設定用戶端密碼。

  2. 客戶端的系統管理員在其租用戶中佈建服務主體。 此服務主體是以提供者所建立的多租用戶應用程式為基礎。 您可以用多種方式進行此步驟： 在此範例中，我們選擇製作 URL 來提供客戶租用戶系統管理員，但您可以改用 Microsoft Graph API。

  3. 客戶會將角色型存取控制 (RBAC) 角色套用至這個新的服務主體，使其獲得存取 Azure 服務匯流排的授權。

  4. 提供者的函式應用程式會使用應用程式註冊的用戶端識別碼和客戶端密碼，將已驗證的訊息傳送給客戶的服務匯流排佇列。

  5. 客戶的函式應用程式會使用受控識別，透過服務匯流排觸發程序從佇列讀取提供者的訊息。

  6. 收到訊息之後，客戶的函式應用程式通常會在將狀態訊息傳回給提供者之前執行一些工作。 在此情況下，為了示範目的，函式應用程式會立即傳送一個狀態訊息給在相同服務匯流排中，個別佇列上的提供者。

  7. 此函式應用程式會透過 Azure Functions 觸發的計時器，從客戶租用戶的狀態佇列讀取。

案例詳細資料

提供者有多個客戶。 提供者和每位客戶都有自己的個別 Microsoft Entra ID 租用戶和 Azure 資源。 提供者和每位客戶都需要安全且雙向的通訊方法，以便他們可以透過服務匯流排佇列交換訊息。 解決方案應該具有吸引人的身分識別故事，且避免引入不必要的認證或密碼。

多租用戶應用程式的相關資訊

  • 應用程式物件是應用程式的全域唯一執行個體。

  • 在 Microsoft Entra 中註冊應用程式時，將在租用戶中自動建立應用程式物件和服務主體物件。

  • 在使用應用程式並引用應用程式物件的每個租戶中都會建立一個服務主體物件。 應用程式物件與其對應的服務主體物件具有一對多的關係。

  • 應用程式物件是應用程式的全域表示形式，可在所有租用戶中使用。 服務主體物件是特定租用戶中使用的本機表示形式。

  • 每一個會用到應用程式的租用戶中都必須建立服務主體物件，才能讓它建立身分識別來存取租用戶所保護的資源。 單一租用戶應用程式在其主租用戶中只有一個服務主體物件。 此服務主體物件是建立並允許在應用程式註冊期間使用。 多租用戶應用程式也具有在每一個租用戶中建立的服務主體物件，且該租用戶中的一位使用者同意其使用。

  • 若要存取受到 Microsoft Entra 租用戶保護的資源，一個安全性主體必須代表需要存取的實體。

  • 當應用程式透過註冊時或同意，擁有權限可存取租用戶中的資源時，服務主體物件就會隨即建立。 此架構是使用同意流程來實作。

提供者如何向客戶發出訊息？

在理想情況下，提供者能夠將受控識別指派給負責將訊息傳送至客戶佇列的 Azure 計算資源。 客戶的租用戶已設定為信任提供者租用戶的受控識別。 不過，目前要在兩個 Microsoft Entra 租用戶之間建立真正的同盟 (基本上是允許一個租用戶與另一個租用戶「共用」身分識別)，是不可能的。 因此，提供者必須使用客戶認可的身分識別進行驗證。 提供者必須向客戶的 Microsoft Entra 租用戶進行驗證，做為客戶知道的服務主體。

我們建議提供者在其自己的租用戶中註冊多租用戶應用程式，然後讓每個客戶在其租用戶中佈建相關服務主體。 提供者接著可以使用此服務主體驗證客戶的租用戶和客戶託管的 API。 提供者永遠不需要在此方法中共用客戶端密碼。 提供者獨立負責認證管理

客戶如何傳訊給提供者？

我們建議客戶建立或託管提供者可從中讀取的佇列。 客戶將訊息寫入佇列。 提供者會使用服務主體物件重複輪詢每個客戶佇列中的訊息。 此方法的缺點是，當提供者收到訊息時，它會產生輪詢延遲。 程式碼也需要更頻繁地在提供者中執行，因為它必須喚醒並執行輪詢邏輯，而不是等待事件觸發它。 不過，提供者仍然獨立負責可增強安全性的認證管理。

另一個可能的解決方案是讓提供者為每個客戶建立或託管佇列。 每位客戶建立自己的多租用戶應用程式，並要求提供者將其佈建在其租用戶中做為服務主體物件。 然後，客戶會使用此服務主體物件，將訊息傳送至提供者端的客戶特定佇列。 客戶仍然獨立負責認證管理。 這種方法的一個缺點是提供者必須將與客戶應用程式相關的服務主體佈建到其租用戶中。 此過程是手動的，提供者可能不希望手動步驟成為新客戶上線流程的一部分。

樣本代碼設定

下列步驟會引導您完成設定提供者與客戶之間跨租用戶通訊的流程。

提供者設定

提供者設定包含產生和佈建多租用戶應用程式服務主體的步驟，以及佈建客戶租用戶的步驟。

  1. 建立 HTTP 觸發的函式應用程式，以傳送訊息，來寫入客戶租用戶內的客戶服務匯流排命令佇列。

  2. 建立時間觸發的函式應用程式，以定期檢查客戶租用戶內客戶服務匯流排內的狀態佇列。

在提供者的租用戶內建立多租用戶應用程式

首先，在提供者的租用戶中建立多租用戶應用程式，並在客戶的租用戶內佈建該身分識別。 在此情境中，身分識別是服務主體。 本文稍早的架構說明如何將提供者租用戶的服務主體設定及佈建至客戶的租用戶。 此架構也會概述如何使用多個 Microsoft Entra 租用戶進行佈建。

  1. 選擇多租用戶組織選項。

  2. 將下列網站新增為重新導向 URI：https://entra.microsoft.com。 您可以變更此 URI 以符合您的業務需求。

  3. 登記並記下應用程式 (用戶端) 識別碼值。

建立新的用戶端密碼

  1. 建立多租用戶應用程式之後，請為此服務主體建立客戶端密碼。

  2. 將產生的金鑰儲存在安全位置。 密碼和用戶端識別碼是您在下一個步驟中交換程式碼、在授權碼流程中和識別碼權杖所需的用戶端認證。

Azure 函式 - HTTP 觸發的

使用 HTTP 函式，將訊息傳送至客戶的服務匯流排部署佇列，以啟動提供者租用戶的部署。 我們選擇 HTTP 觸發的函式作為傳遞方法，以啟動此概念驗證。 您稍早產生的服務主體會做為認證來存取客戶租用戶，並寫入服務匯流排內的特定佇列。 您也需要完成此步驟的客戶設定 ，才能正常運作。

Azure 函式 - 計時器觸發的

使用計時器觸發的函式，從客戶的租用戶內輪詢部署狀態佇列。 我們會每隔 10 秒輪詢部署狀態佇列，以取得此概念驗證的示範用途。 這種方法讓客戶無需擁有服務主體就能存取提供者的租用戶。

客戶設定

  1. 藉由修改及使用提供的 URL 來佈建服務主體。

  2. 將提供者服務主體的範圍設定為使用適當的 RBAC 控制項。

  3. 建立服務匯流排觸發函式，從服務匯流排訊息佇列讀取訊息，並將訊息放入另一個佇列。 為了示範目的，此流程最適合用來測試功能。

  4. 為服務匯流排觸發的函式建立系統指派的受控識別。

  5. 指派系統指派的受控識別服務匯流排範圍。

將服務主體從提供者的租用戶佈建至客戶的租用戶

  1. 將client_id查詢字串參數取代為您自己的用戶端識別碼之後，請瀏覽下列URL：https://login.microsoftonline.com/organizations/oauth2/v2.0/authorize?response_type=code&response_mode=query&scope=openid&client_id=<your_client_ID>。

    您也可以使用系統管理員 Microsoft Graph API 呼叫、Azure PowerShell 命令，或 Azure CLI 命令，將服務主體佈建至另一個 Microsoft Entra 租用戶。

  2. 使用客戶的租用戶帳戶登入。

  3. 在同意畫面上，選取接受，以在客戶租用戶中佈建提供者的應用程式。 URL 最終會重新導向至microsoft.com，該 URL 仍具有將身分識別佈建至客戶租用戶所需的效果。

  4. 移至企業應用程式以查看新佈建的服務主體，以確認客戶 Microsoft Entra 租用戶內的身分識別。

設定已佈建服務主體的 RBAC

將提供者服務主體的範圍設定為從提供者服務主體設定到在服務匯流排上具有「服務匯流排資料擁有者」角色。 此服務主體是用來使用 HTTP 觸發的函式寫入佇列，以及從計時器觸發的函式讀取佇列。 請務必將「Azure 服務匯流排資料擁有者」角色新增至服務主體。

Azure 函式 - 服務匯流排觸發程序

請遵循身分識別型函式教學課程中的步驟，從服務匯流排佇列定義函式觸發程序，並了解如何設定受控識別。 本指引可協助您在新增訊息至佇列時，從服務匯流排佇列觸發函式應用程式。 當您將訊息放入不同的佇列時，也會使用受控識別。 為了示範目的，我們會使用相同的函式來推播訊息。

在新建立的服務匯流排命名空間中，選取存取控制 (IAM)。 您可以檢視及設定誰可以存取控制平面中的資源。

使用受控識別授予函式應用程式對服務匯流排命名空間的存取權

  1. 請務必將「Azure 服務匯流排資料接收者」角色新增至受控識別。

  2. 在受控識別選取器中，從系統指派的受控識別類別中選擇函式應用程式 。 標籤函式應用程式旁邊可能有一個數字。 該數字指出訂用帳戶中有多少應用程式具有系統指派的身分識別。

在函數應用程式中連線服務匯流排

  1. 在入口網站中，搜索函式應用程式或移至函式應用程式 頁面上它所在的位置。

  2. 在應用程式設定中，選取 + 新 以在表格中建立新的應用程式設置。 Service BusConnection__fullyQualifiedNamespace <SERVICE_BUS_NAMESPACE>.Service Bus.windows.net.

服務主體用戶端密碼生命週期管理

如果您將密碼引入跨租用戶架構，則必須管理這些產生的客戶端密碼的生命週期。 請參閱密碼管理的最佳做法，以了解如何安全地儲存、輪替及監視用戶端密碼。

本機設定

每個子目錄都包含local.settings.json檔案的 stubbed 版本，可修改為在本機執行 Azure 函式。 若要在 Azure 中設定組態，請更新應用程式設定。

DefaultAzureCredential命令會在觸達 Azure CLI 認證之前列舉多個設定。 若要避免混淆，建議您在開發本機函式時執行az login -t <tenant ID>命令來選取正確的認證。

參與者

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

主要作者：

下一步