通过

如何以及为何将应用程序添加到 Microsoft Entra ID

  • 项目

Microsoft Entra ID 中的应用程序有两种表示形式：

  • 应用程序对象 - 尽管存在一些例外情况，但可将这些应用程序对象视为应用程序的定义。
  • 服务主体 - 可将其视为应用程序的实例。 服务主体通常引用应用程序对象，一个应用程序对象可由不同目录中的多个服务主体引用。

什么是应用程序对象，它们来自何处？

可以在 Microsoft Entra 管理中心通过应用注册体验来管理应用程序对象。 应用程序对象描述 Microsoft Entra ID 中的应用程序，可将其视为应用程序的定义，使服务能够知道如何根据应用程序的设置，向该应用程序颁发令牌。 应用程序对象只在其主目录中存在，即使它是支持其他目录中服务主体的多租户应用程序也是如此。 应用程序对象可以包括（但不限于）以下任何一项：

  • 名称、徽标和发布者
  • 重定向 URI
  • 机密（用于对应用程序进行身份验证的对称和/或非对称密钥）
  • API 依赖关系 (OAuth)
  • 发布的 API/资源/范围 (OAuth)
  • 应用角色
  • 用户设置元数据和配置
  • 代理元数据和配置

可通过多种途径创建应用程序对象，包括：

  • Microsoft Entra 管理中心的应用程序注册
  • 使用 Visual Studio 创建新应用程序，并将其配置为使用 Microsoft Entra 身份验证
  • 当管理员从应用库添加应用程序时（这也会创建服务主体）
  • 使用 Microsoft Graph API 或 PowerShell 创建新应用程序
  • 其他许多途径，包括 Azure 中的各种开发人员体验，以及开发人员中心的 API 资源管理器体验

什么是服务主体，它们来自何处？

可以在 Microsoft Entra 管理中心通过企业应用程序体验来管理服务主体。 服务主体是控制与 Microsoft Entra ID 相连接的应用程序的对象，可视为目录中应用程序的实例。 任意给定应用程序最多只能有一个应用程序对象（在“home”目录中注册），此外，可以有一个或多个服务主体对象，这些对象表示运行该应用程序的每个目录中的应用程序实例。

服务主体可以包括：

  • 通过应用程序 ID 属性对应用程序对象的反向引用
  • 本地用户和组应用程序角色分配的记录
  • 授予应用程序的本地用户和管理员权限的记录
    • 例如：应用程序访问特定用户电子邮件的权限
  • 本地策略（包括条件访问策略）的记录
  • 应用程序的备用本地设置的记录
    • 声明转换规则
    • 属性映射（用户设置）
    • 目录特定的应用角色（如果应用程序支持自定义角色）
    • 目录特定的名称或徽标

与应用程序对象一样，可通过多种途径创建服务主体，包括：

  • 当用户登录到与 Microsoft Entra ID 集成的第三方应用程序时
    • 在登录期间，系统要求用户向应用程序授予访问其配置文件的权限和其他权限。 第一个授权者导致生成一个服务主体，表示要添加到目录中的应用程序。
  • 当用户登录到 Microsoft 365 等 Microsoft 联机服务时。
    • 当你订阅 Microsoft 365 或开始试用时，会在目录中创建一个或多个服务主体，表示用于传递所有与 Microsoft 365 关联的功能的各种服务。
    • 某些 Microsoft 365 服务（如 SharePoint）会不断地创建服务主体，这样就可以在组件（包括工作流）之间安全地通信。
  • 当管理员从应用库添加应用程序时（这也会创建基础应用对象）
  • 通过 Microsoft Graph API 或 PowerShell 以编程方式实现

应用程序的主目录中包含一个应用程序对象，该对象由运行该应用程序的每个目录（包括该应用程序的主目录）中的一个或多个服务主体引用。

显示应用对象与服务主体之间的关系

在上面的关系图中，Microsoft 在内部维护两个用于发布应用程序的目录（左侧显示）：

  • 一个目录用于 Microsoft 应用程序（Microsoft 服务目录）
  • 一个目录用于预先集成的第三方应用程序（应用库目录）

与 Microsoft Entra ID 集成的应用程序发布者/供应商需有一个发布目录（在右侧显示为“某个软件即服务 (SaaS) 目录”）。

自行添加的应用程序（在关系图中显示为你的应用）包括：

  • 开发的应用（与 Microsoft Entra ID 集成）
  • 使用 Microsoft Entra 应用程序代理发布的应用

备注和例外情况

  • 并非所有服务主体都会往后指向应用程序对象。 最初生成 Microsoft Entra ID 时，提供给应用程序的服务存在更多的限制，使用服务主体便足以建立应用程序标识。 原始服务主体在形式上更接近于 Windows Server Active Directory 服务帐户。 出于此原因，仍可以通过不同的途径创建服务主体（例如使用 Microsoft Graph PowerShell），而无需首先创建应用程序对象。 Microsoft Graph API 在创建服务主体之前需要一个应用程序对象。
  • 上述信息当前并非全部都是以编程方式公开的。 只能在 UI 中使用以下功能：
    • 声明转换规则
    • 属性映射（用户设置）
  • 有关服务主体和应用程序对象的详细信息，请参阅 Microsoft Graph API 参考文档：

应用程序为何要与 Microsoft Entra ID 集成？

应用程序将添加到 Microsoft Entra ID，以使用它提供的一个或多个服务，包括：

  • 应用程序身份验证和授权
  • 用户身份验证和授权
  • 用户预配和同步
  • 基于角色的访问控制 (RBAC) - 使用目录定义应用程序角色，以便在应用程序中执行基于角色的授权检查
  • OAuth 授权服务 - 供 Microsoft 365 和其他 Microsoft 应用程序用来授予对 API/资源的访问权限
  • 应用程序发布和代理 - 将应用程序从专用网络发布到 Internet
  • 目录架构扩展属性 - 扩展服务主体和用户对象的架构以在 Microsoft Entra ID 中存储其他数据

谁有权向我的 Microsoft Entra 实例添加应用程序？

默认情况下，目录中的所有用户都有权注册正在开发的应用程序对象，并通过同意来决定要共享哪些应用程序/授予对其组织数据的访问权限。 当目录中的第一个用户登录到应用程序并授予许可时，会在租户中创建一个服务主体。 否则，同意授予信息将存储在现有的服务主体中。

允许用户注册和许可应用程序最初听上去可能令人担忧，但请记住以下原因：

  • 多年以来，应用程序一直可以使用 Windows Server Active Directory 进行用户身份验证，而无需在目录中注册或记录应用程序。 现在，组织提高了可见性，完全知道有多少应用程序正在使用目录以及为何使用目录。
  • 将这些责任委托给用户消除了管理员驱动的应用程序发布和注册过程。 过去，在使用 Active Directory 联合身份验证服务 (ADFS) 时，管理员可能必须代表开发人员添加一个应用程序作为信赖方。 现在，开发人员可以自行解决问题。
  • 用户为了业务目的使用其组织帐户登录到应用程序是一个好现象。 如果他们以后离开了组织，便会自动失去他们所用应用程序中帐户的访问权限。
  • 记录与哪个应用程序共享了哪些数据是一个很好的做法。 数据的可流动性比以往更好，因此，明确记录哪个用户与哪些应用程序共享了哪些数据会很有用。
  • 为 OAuth 使用 Microsoft Entra ID 的 API 所有者将明确决定用户可向应用程序授予哪些权限，以及哪些权限需要管理员的许可。 只有管理员才能许可较大范围的且更重要的权限，而用户许可范围限制为用户自己的数据和功能。
  • 当用户添加应用程序或允许应用程序访问其数据时，可以审核事件，使你能够在 Microsoft Entra 管理中心查看“审核报告”，以确定应用程序是如何添加到目录中的。

如果仍然想要阻止目录中的用户在未经管理员批准的情况下注册和登录应用程序，可以更改两项设置来关闭这些功能：

  • 若要更改你的组织中的用户同意设置，请参阅配置用户对应用程序表示同意的方式。

  • 阻止用户注册其自己的应用程序：

    1. 在 Microsoft Entra 管理中心，浏览到“标识”>“用户”>“用户设置”。
    2. 将用户可以注册应用程序更改为否。