Azure Active Directory 中的应用程序对象和服务主体对象

有时在 Azure Active Directory (Azure AD) 的上下文中使用时,术语“应用程序”的含义可能会被误解。 本文澄清了 Azure AD 应用程序集成的概念和具体层面,并演示了如何注册和同意多租户应用程序

概述

已与 Azure AD 集成的应用程序具有超出软件方面的含意。 “应用程序”常作为一个概念性术语,不仅指应用程序软件,而且还指其 Azure AD 注册和运行时在身份验证/授权“对话”中的角色。

根据定义,应用程序能够使用以下角色:

  • 客户端角色(使用资源)
  • 资源服务器角色(向客户端公开 API)
  • 客户端角色和资源服务器角色

OAuth 2.0 授权流定义了对话协议,对话协议允许客户端/资源各自访问/保护资源的数据。

在下面的各部分中,你将了解 Azure AD 应用程序模型在设计时和运行时如何表示应用程序。

应用程序注册

Azure 门户中注册 Azure AD 应用程序时,会在 Azure AD 租户中创建两个对象:

  • 一个应用程序对象
  • 和一个服务主体对象。

应用程序对象

Azure AD 应用程序由其唯一一个应用程序对象来定义,该对象位于应用程序注册到的 Azure AD 租户(称为应用程序的“宿主”租户)中。 Azure AD Graph Application 实体定义应用程序对象属性的架构。

服务主体对象

若要访问受 Azure AD 租户保护的资源,需要访问的实体必须由安全主体来表示。 这同时适用于用户(用户主体)和应用程序(服务主体)。

安全主体定义 Azure AD 租户中用户/应用程序的访问策略和权限。 这样便可实现核心功能,如在登录时对用户/应用程序进行身份验证,在访问资源时进行授权。

当应用程序被授予了对租户中资源的访问权限时(根据注册或许可),将创建一个服务主体对象。 Azure AD Graph ServicePrincipal 实体定义服务主体对象属性的架构。

应用程序和服务主体的关系

可以将应用程序对象视为应用程序的全局表示形式(供所有租户使用),将服务主体视为本地表示形式(在特定租户中使用)。

应用程序对象用作模板,常见属性和默认属性从其中派生,以便在创建相应服务主体对象时使用。 因此,应用程序对象与软件应用程序存在 1 对 1 关系,而与其对应的服务主体对象存在 1 对多关系。

必须在将使用应用程序的每个租户中创建服务主体,让它能够建立用于登录和/或访问受租户保护的资源的标识。 单租户应用程序只有一个服务主体(在其宿主租户中),在应用程序注册期间创建并被允许使用。 多租户 Web 应用程序/API 还会在租户中的某个用户已同意使用它的每个租户中创建服务主体。

Note

对应用程序对象所做的任何更改也只反映在该对象在应用程序宿主租户(其注册所在的租户)的服务主体对象中。

另请注意,默认情况下本机应用程序注册为多租户应用程序。

示例

下图演示了应用程序的应用程序对象和对应的服务主体对象之间的关系,其上下文是在名为 HR 应用的示例多租户应用程序中。 此示例方案中有三个 Azure AD 租户:

  • Adatum - 开发 HR 应用的公司使用的租户
  • Contoso - Contoso 组织使用的租户,即 HR 应用的使用者
  • Fabrikam - Fabrikam 组织使用的租户,它也使用 HR 应用

应用程序对象与服务主体对象之间的关系

在此示例方案中:

步骤 说明
1 是在应用程序的宿主租户中创建应用程序对象和服务主体对象的过程。
2 当 Contoso 和 Fabrikam 的管理员完成同意并向应用程序授予访问权限时,会在其公司的 Azure AD 租户中创建服务主体对象,并向其分配管理员所授予的权限。 另请注意,HR 应用可能配置/设计为允许由用户同意以供个人使用。
3 HR 应用程序的使用者租户(例如 Contoso 和 Fabrikam)各有自己的服务主体对象。 每个对象代表其在运行时使用的应用程序实例,该实例受相关管理员同意的权限控制。

后续步骤