應用程式新增至 Microsoft Entra 識別符的方式和原因

  • 發行項

Microsoft Entra 的應用程式有兩種表示法：

  • 應用程式物件 - 雖然有 例外狀況，但應用程式物件可以視為應用程式的定義。
  • 服務主體 - 可視為應用程式的執行個體。 服務主體通常會參考應用程式物件，而跨目錄的多個服務主體可以參考一個應用程式物件。

應用程式物件是什麼？來自何處？

您可以透過 應用程式註冊 體驗來管理 Microsoft Entra 系統管理中心的應用程式物件。 應用程式物件將應用程式描述為 Microsoft Entra ID，並可視為應用程式的定義，讓服務知道如何根據其設定向應用程式發出令牌。 應用程式物件只存在於其主目錄中，即使其為在其他目錄中支援服務主體的多租用戶應用程式也是如此。 應用程式物件可能包含下列任一項 (但不限於):

  • 名稱、標誌與發行者
  • 重新導向 URI
  • 祕密 (用於驗證應用程式的對稱和/或非對稱金鑰)
  • API 相依性 (OAuth)
  • 已發佈的 API/資源/範圍 (OAuth)
  • 應用程式角色
  • 單一登入 (SSO) 中繼資料和設定
  • 使用者發佈中繼資料與設定
  • Proxy 中繼資料與設定

應用程式物件可以透過多個路徑建立，包括：

  • Microsoft Entra 系統管理中心的應用程式註冊
  • 使用 Visual Studio 建立新的應用程式，並將其設定為使用 Microsoft Entra 驗證
  • 當系統管理員從應用連結庫新增應用程式時（這也會建立服務主體）
  • 使用 Microsoft Graph API 或 PowerShell 建立新的應用程式
  • 其他許多專案，包括 Azure 中的各種開發人員體驗，以及跨開發人員中心的 API 總管體驗

服務主體是什麼，以及其來自哪裡？

您可以透過企業應用程式體驗，在 Microsoft Entra 系統管理中心管理服務主體。 服務主體是管理連線到 Microsoft Entra 識別碼的應用程式，而且可以視為您目錄中應用程式的實例。 對於任何指定的應用程式，它最多可以有一個應用程式物件（其註冊在「主目錄」中），以及一或多個服務主體物件，代表其作用中每個目錄中的應用程式實例。

服務主體可能包括：

  • 透過應用程式識別碼屬性對應用程式物件的反向參考
  • 本機使用者和群組應用程式角色指派的記錄
  • 授與應用程式的本機用戶和系統管理員許可權記錄
    • 例如：應用程式存取特定使用者電子郵件的許可權
  • 本機原則的記錄，包括條件式存取原則
  • 應用程式的替代本機設定記錄
    • 宣告轉換規則
    • 屬性對應 (使用者佈建)
    • 目錄特定的應用程式角色（如果應用程式支援自訂角色）
    • 目錄特定名稱或標誌

如同應用程式對象，服務主體也可以透過多個路徑來建立，包括：

  • 當使用者登入與 Microsoft Entra ID 整合的第三方應用程式時
    • 登入期間，會要求使用者將權限提供給應用程式，以存取該使用者的設定檔與其他權限。 第一個提供同意的人會產生服務主體，代表已將應用程式新增至目錄。
  • 當使用者登入 Microsoft 線上服務時，例如 Microsoft 365。
    • 訂閱或開始試用 Microsoft 365 時，目錄中會建立一或多個服務主體，代表用來傳遞所有 Microsoft 365 相關功能的各種服務。
    • SharePoint 等部分 Microsoft 365 服務會持續建立服務主體，以允許元件之間的安全通訊，包括工作流程。
  • 當系統管理員從應用連結庫新增應用程式時（這也會建立基礎應用程式物件）
  • 新增應用程式以使用 Microsoft Entra 應用程式 Proxy
  • 使用 SAML 或密碼 SSO 連線 SSO 的應用程式
  • 透過 Microsoft Graph API 或 PowerShell 以程式設計方式

應用程式在其主目錄中有一個應用程式物件，由其操作所在每個目錄的一或多個服務主體所參考（包括應用程式的主目錄）。

顯示應用程式對象與服務主體之間的關聯性

在前一張圖表中，Microsoft 內部維持用於發佈應用程式的兩個目錄 (顯示於左側)：

  • 一個適用於 Microsoft Apps（Microsoft 服務 目錄）
  • 用於預先整合的第三方應用程式 （應用程式庫目錄）

與 Microsoft Entra ID 整合的應用程式發行者/廠商必須有發佈目錄（如「某些軟體即服務（SaaS）目錄」右側所示。

您自行新增的應用程式（在 圖表中以應用程式表示） 包括：

  • 您開發的應用程式（與 Microsoft Entra ID 整合）
  • 您為 SSO 連線的應用程式
  • 您使用 Microsoft Entra 應用程式 Proxy 發佈的應用程式

附注和例外狀況

  • 不是所有服務主體都能指回某個應用程式物件。 當 Microsoft Entra ID 最初建置時，提供給應用程式的服務會比較有限，而且服務主體就足以建立應用程式身分識別。 原始服務主體的圖形接近 Windows Server Active Directory 服務帳戶。 基於這個理由，您仍然可以透過不同的路徑建立服務主體，例如使用 Microsoft Graph PowerShell，而不需要先建立應用程式物件。 Microsoft Graph API 需要應用程式物件才能建立服務主體。
  • 不是上述所有資訊目前都以程式設計方式公開。 下列專案僅適用於 UI：
    • 宣告轉換規則
    • 屬性對應 (使用者佈建)
  • 如需服務主體和應用程式對象的詳細資訊，請參閱 Microsoft Graph API 參考檔：

為什麼應用程式會與 Microsoft Entra 識別元整合？

應用程式會新增至 Microsoft Entra ID，以使用其提供的一或多個服務，包括：

  • 應用程式驗證和授權
  • 使用者驗證和授權
  • 使用同盟或密碼的 SSO
  • 使用者布建和同步處理
  • 角色型存取控制 （RBAC） - 使用 目錄來定義應用程式角色，以在應用程式中執行角色型授權檢查
  • OAuth 授權服務 - Microsoft 365 和其他 Microsoft 應用程式用來授權存取 API/資源
  • 應用程式發佈和 Proxy - 將應用程式從專用網發佈至因特網
  • 目錄架構延伸屬性 - 擴充服務主體和用戶對象的 架構，以在 Microsoft Entra ID 中儲存其他數據

誰有權限可將應用程式新增至我的 Microsoft Entra 執行個體？

雖然有些工作只有 Global 管理員 istrators 可以執行（例如從應用連結庫新增應用程式，以及設定應用程式以使用 應用程式 Proxy），但目錄中的所有使用者都有權註冊他們正在開發的應用程式物件，並決定他們透過同意共用/授與組織數據存取權的應用程式。 如果某個人是您目錄中第一個登入應用程式並授與同意的使用者，這會在您的租使用者中建立服務主體。 否則，同意授與資訊會儲存於現有服務主體上。

允許用戶註冊和同意應用程式一開始可能很令人擔心，但請記住下列原因：

  • 應用程式多年來一直能夠使用 Windows Server Active Directory 進行用戶驗證，而不需要在目錄中註冊或記錄應用程式。 現在組織將改善可見度，以確實了解有多少應用程式正在使用目錄，以及其用途。
  • 委派這些責任給使用者會取消管理員驅動之應用程式註冊與發佈處理序的需求。 使用 Active Directory 同盟服務 （ADFS） 時，系統管理員可能必須代表開發人員將應用程式新增為信賴憑證者。 現在開發人員可以自助。
  • 使用者使用其組織帳戶登入應用程式對於商務程序來說是件好事。 如果他們隨後離開組織，他們會自動失去他們在所使用應用程式中帳戶的存取權。
  • 擁有與哪些應用程式共用什麼資料的記錄是件好事。 資料比以往更容易傳送，擁有誰與哪些應用程式共用什麼資料的清楚記錄很實用。
  • 針對 OAuth 使用 Microsoft Entra ID 的 API 擁有者會確實決定使用者能夠授與應用程式什麼權限，以及哪些權限需要管理員同意。 只有管理員可以同意更大範圍且較重要的權限，而使用者同意則限定在使用者自身資料與功能的範圍內。
  • 當使用者新增或允許應用程式存取其數據時，可以稽核事件，以便檢視 Microsoft Entra 系統管理中心內的稽核報告，以判斷如何將應用程式新增至目錄。

如果您仍然想要防止目錄中的使用者註冊應用程式，以及在未經系統管理員核准的情況下登入應用程式，您可以變更兩個設定來關閉這些功能：

  • 若要變更組織中的使用者同意設定，請參閱 設定使用者同意應用程式的方式。

  • 若要防止使用者註冊自己的應用程式：

    1. 在 Microsoft Entra 系統管理中心，流覽至 [身分>識別使用者使用者>設定]。
    2. 將 [使用者可以註冊應用程式] 變更為 [否]。