使用多組織用戶共享伺服器對伺服器驗證
發行︰ 2017年1月
適用於： Dynamics 365 (online)
這是最常見的案例，也用於透過 Microsoft AppSource 發行的應用程式，但是您也可以使用多組織用戶共享，而不使用 Microsoft AppSource 列出應用程式。
每個 Dynamics 365 (線上) 組織都與 Azure Active Directory (Azure AD) 組織用戶相關聯。 您的 Web 應用程式或服務已使用自己的 Azure AD 用戶註冊。
在此案例中，任何 Dynamics 365 (線上) 用戶都可能使用您的多組織用戶共享應用程式，在他們授權應用程式存取資料後。
本主題內容
需求
概觀：開發和測試您的應用程式
建立與 Dynamics 365 中已註冊應用程式相關聯的應用程式使用者
使用您的 Dynamics 365 用戶測試應用程式
使用另外的 Dynamics 365 用戶測試應用程式
準備部署應用程式使用者的方法
需求
若要建立和測試使用伺服器對伺服器驗證的多組織用戶共享應用程式 (S2S)，您將需要：
Azure AD 用戶，用來發行應用程式或服務。
2 個 Dynamics 365 (線上) 訂閱
一個要與用來發行應用程式或服務 Azure AD 用戶相關聯。
另一個可以是試用訂閱，用於測試訂閱者存取應用程式的方式。
概觀：開發和測試您的應用程式
您將建立的應用程式必須透過將用來發行應用程式的 Azure AD 用戶註冊。
從高階角度來看，此程序包括：
建立多組織用戶共享 Web 應用程式並透過您的 Azure AD 用戶註冊。
建立與您的 Dynamics 365 (線上) 用戶中已註冊應用程式相關聯的應用程式使用者。
建立自訂資訊安全角色並將它指派給 Dynamics 365 (線上) 用戶中的應用程式使用者。
使用您的 Dynamics 365 (線上) 用戶測試應用程式
使用另外的 Dynamics 365 (線上) 用戶測試應用程式
如需此程序的完整範例，請參閱逐步解說：多組織用戶共享伺服器對伺服器驗證。
建立多組織用戶共享 Web 應用程式並透過您的 Azure AD 用戶註冊
您可以建立多組織用戶共享 Web 應用程式或服務，使用 Azure AD 做為驗證提供者。
本主題的焦點不是確切說明如何這樣做。 有多種方法可了解做法，請選擇符合您需求或偏好的方法。 如需詳細資訊和範例，請參閱下列連結：
Azure AD 需要下列值才能登錄您的應用程式：
值 |
描述 |
|---|---|
應用程式識別碼 URI |
應用程式的識別碼。 此值會在驗證時傳送至 Azure AD，指出呼叫端想要其 Token 的應用程式。 此外，此值會包含在 Token 內，讓應用程式得知它就是所要的目標。 |
回覆 URL 和重新導向 URI |
若是 Web API 或 Web 應用程式，回覆 URL 是 Azure AD 傳送驗證回應的目標位置，包括驗證成功時的 Token。 |
用戶端識別碼 |
應用程式的識別碼，由 Azure AD 在應用程式註冊時產生。 當要求授權碼或 Token 時，用戶端識別碼和金鑰就會在驗證時傳送至 Azure AD。 |
金鑰 |
驗證時與用戶端識別碼一併傳送至 Azure AD，用來呼叫 Web API 的金鑰。 |
應用程式註冊時，會為其指派 [Azure Active Directory 物件識別碼]，這是已註冊應用程式的唯一識別碼。
如果您使用 Visual Studio 2015 建立新的 ASP.NET MVC 應用程式，則可以選擇將指定應用程式將支援多組織用戶共享功能。 MVC 應用程式的範本提供指定要採用的驗證類型的選項。 當您建立專案時，可藉由設定其屬性選擇驗證方法。 下圖顯示可用的選項：
.jpeg "ASP.NET MVC Change Authentication Dialog")
當您在專案中設定這些選項時，專案會設定為使用 OWIN 中介軟體，並且為支援此案例的基本應用程式建立結構。 進行一些基本修改後，就可以調整為搭配 Dynamics 365 (線上) 使用。 這是逐步解說：多組織用戶共享伺服器對伺服器驗證中示範的方法。
在建立和註冊應用程式進行開發的過程中，您通常會使用 https://localhost 做為 [登入 URL] 和 [回覆 URL] 值，因此可以在發行前，直接在本機上測試應用程式並進行偵錯。 您需要在發行應用程式前變更這些值。
當您註冊應用程式時，必須產生金鑰，也稱為 ClientSecret。 這些金鑰可以設定 1 或 2 年的有效期間。 做為應用程式的主機，您必須將此值視為密碼，並且在到期前負責管理金鑰更新。 您可能會想要使用 Azure 金鑰保存庫。其他資訊：https://azure.microsoft.com/en-us/services/key-vault/
授與應用程式存取 Dynamics 365 (線上) 資料的權限
這就是您的 Dynamics 365 (線上) 執行個體必須與您的 Azure AD 用戶建立關聯的原因。 如果您的 Azure AD 用戶未與 Dynamics 365 (線上) 用戶相關聯，您就無法執行下列步驟。
前往 https://portal.azure.com 並選取 [Azure Active Directory]。
按一下 [應用程式註冊] 並尋找您使用 Visual Studio 建立的應用程式。
您需要授與應用程式存取 Dynamics 365 (線上) 資料的權限。 在 [API 存取] 區域中，按一下 [必要權限]。 您會看見它已有 Windows Azure Active Directory 的權限。
按一下 [新增]，然後 [選取 API]。 在清單中選取 [Dynamics 365]，然後按一下 [選取] 按鈕。
在 [選取權限] 中，選取 [以組織使用者身分存取 Dynamics 365]。 然後按一下 [選取] 按鈕。
按一下 [完成]，新增這些權限。 完成時，您應該會看到權限已套用。
.jpeg "Grant Dynamics 365-Permissions to application")
建立與 Dynamics 365 中已註冊應用程式相關聯的應用程式使用者
當您的應用程式存取其中一個應用程式訂閱者的 Dynamics 365 資料時，它將需要在訂閱者的 Dynamics 365 組織中的應用程式使用者。 就像任何 Dynamics 365 使用者，此應用使用者必須至少與一個定義使用者能夠存取的資料的資訊安全角色相關聯。
systemuser 實體有三個新屬性可儲存此資料。
結構描述名稱 |
顯示名稱 |
Type |
描述 |
|---|---|---|---|
ApplicationId |
應用程式識別碼 |
UniqueidentifierType |
應用程式的識別碼。 這是用來存取其他應用程式的資料。 |
ApplicationIdUri |
應用程式識別碼 URI |
StringType |
URI 用來做為外部應用程式的唯一邏輯識別碼。 這可用來驗證應用程式 |
AzureActiveDirectoryObjectId |
Azure AD 物件識別碼 |
UniqueidentifierType |
這是應用程式目錄物件識別碼。 |
此 systemuserAzureActiveDirectoryObjectId 屬性值必須是已註冊應用程式的 Azure Active Directory 物件識別碼的參考。 此參考將在 Dynamics 365 中設定，根據 ApplicationId 值建立應用程式使用者時。
注意
如果您一開始使用自己的 Dynamics 365 用戶及與其相關聯的 Azure AD 用戶開發您的應用程式，只要建立應用程式使用者即可，因為已註冊的應用程式已經是 Azure AD 用戶的一部分。
不過，若要在不同組織內建立應用程式使用者進行測試，或是只要在訂閱者使用您的應用程式時，他們就必須先對應用程式授與同意，因此程序中的步驟不同。 如需詳細資訊，請參閱使用另外的 Dynamics 365 用戶測試應用程式。
為應用程式使用者建立資訊安全角色
在下一個步驟中，您將建立 Dynamics 365 應用程式使用者。 此使用者的權限和存取權限將由您設定的自訂資訊安全角色定義。 在您建立應用程式使用者之前，必須先建立自訂資訊安全角色，才能將使用者與該角色建立關聯。 其他資訊：TechNet：建立或編輯資訊安全角色
注意
應用程式使用者無法與其中一個預設的 Dynamics 365 資訊安全角色產生關聯。 您必須建立自訂資訊安全角色，才能與應用程式使用者建立關聯。
手動建立 Dynamics 365 應用程式使用者
建立這個使用者的程序與建立授權使用者不同。 使用下列步驟：
瀏覽至 [設定] > [安全性] > [使用者]
在檢視表下拉式清單中，選取 [應用程式使用者]。
按一下 [新增]。 然後確認您使用的是 [應用程式使用者] 表單。
如果您未在表單中看見 [應用程式識別碼]、[應用程式識別碼 URI] 及 [Azure AD 物件識別碼] 欄位，則必須從清單中選取 [應用程式使用者] 表單：
.jpeg "Select Application User Form")
新增適當的值至欄位：
欄位
值
應用程式識別碼
已在 Azure AD 註冊的應用程式的應用程式識別碼值。
Full Name
應用程式的名稱。
主要電子郵件
要讓訂閱者連絡您時使用的電子郵件地址。
[使用者名稱]、[應用程式識別碼 URI] 和 [Azure AD 物件識別碼] 欄位會鎖定，您無法設定這些欄位的值。
當您建立這個使用者時，這些欄位的值會在您儲存使用者時從 Azure AD 擷取，依據 [應用程式識別碼] 值。
將應用程式使用者與您在為應用程式使用者建立資訊安全角色建立的自訂資訊安全角色建立關聯。 其他資訊：TechNet：指派資訊安全角色給使用者
使用您的 Dynamics 365 用戶測試應用程式
由於應用程式已透過您的 Azure AD 用戶註冊，而且開發組織中的應用程式使用者已設定，因此您可以繼續對自己的 Dynamics 365 用戶開發應用程式。 但是，這並非多組織用戶共享功能的有效測試。 您需要在另外的 Dynamics 365 用戶上測試您的應用程式。
使用另外的 Dynamics 365 用戶測試應用程式
在另外的 Dynamics 365 用戶上測試您的應用程式之前，Azure AD 用戶的系統管理員必須對應用程式授與同意。 系統管理員可使用瀏覽器瀏覽至應用程式授與同意。 他們第一次存取應用程式時，會看見類似下方的對話方塊：
.jpeg "Grant consent to access Dynamics 365 data")
當他們授與同意時，已註冊的應用程式將會新增至 Azure AD 企業應用程式清單中，並提供給 Azure AD 用戶的使用者。
系統管理員授與同意之後，您才能在訂閱者的 Dynamics 365 用戶中建立應用程式使用者。 您可以手動建立應用程式使用者，使用手動建立 Dynamics 365 應用程式使用者中所述的步驟。
若是初始測試，您可能想要手動執行這些步驟。 當您準備好將應用程式或服務提供給訂閱者時，會希望採取更有效率的程序。 下一節將說明這個主題。
準備部署應用程式使用者的方法
訂閱者對您的應用程式或服務授與同意後，您會需要簡單、可靠的方式讓他們將應用程式使用者和任何其他必要的元件新增至他們的 Dynamics 365 組織。
您必須包括自訂資訊安全角色，用來定義應用程式需要的權限，然後確認應用程式使用者與該自訂資訊安全角色相關聯。 由於自訂資訊安全角色可包含在解決方案中，因此您應準備受管理的解決方案，當中包含自訂資訊安全角色的定義，以及您的應用程式需要的任何其他解決方案元件。
如需建立自訂資訊安全角色的詳細資訊，請參閱
如需建立 Dynamics 365 解決方案的詳細資訊，請參閱下列主題：
不過，應用程式使用者不可包含在解決方案中，因此您需要提供另一種方式來建立此應用程式使用者，並將它與自訂資訊安全角色建立關聯。
有許多方法可以達成此目的，包括使用 Microsoft Dynamics 365 SDK 撰寫自己的程式並讓訂閱者執行程式。
Microsoft Dynamics 365 SDK 提供 CRM 套件部署器 應用程式，可用來準備套件，將傳輸解決方案與資料至不同的 Dynamics 365 組織的程序自動化。其他資訊：建立 Dynamics 365 Package Deployer 的套件
另請參閱
逐步解說：多組織用戶共享伺服器對伺服器驗證
使用單一組織用戶伺服器對伺服器驗證
使用伺服器對伺服器 (S2S) 驗證建立 Web 應用程式
連線至 Microsoft Dynamics 365
Microsoft Dynamics 365
© 2017 Microsoft. 著作權所有，並保留一切權利。 著作權