管理向应用程序分配代理标识

本文将介绍如何在 Microsoft Entra ID 中为计划与应用程序交互的代理分配标识，以便这些代理能够使用企业应用程序。 Microsoft Entra 配置步骤取决于代理和企业应用程序的功能。

组织可以通过将每个应用程序配置为依赖于 Microsoft Entra 进行单一登录或预配，并要求将这些用户分配到应用程序，从而控制其Microsoft Entra 租户中的哪些员工和业务来宾用户可以与组织的企业应用程序进行交互。 如果应用程序公开多个应用角色，还可以向每个用户分配特定的应用角色。 有关详细信息，请参阅 管理应用程序的用户和组分配。

当 AI 代理有一个工具（或者可能在其平台中称为技能或连接器）来与租户中的企业应用程序通信时，可以将该工具的标识分配给应用程序。 该工具可能使用服务主体、代理标识或代理用户进行身份验证。 通过将这些标识分配给企业应用程序的角色和权限，可以允许代理支持的应用程序识别代理标识，并使代理能够从Microsoft Entra ID 获取适当的令牌，以便应用程序访问。

本文概述了如何根据应用程序的功能选择三个选项。

同意应用程序权限范围

使用 Microsoft Entra 标识平台的应用程序可以 公开要调用的其他客户端应用程序的 API。 使用 API 的应用程序可以公开这些 API 调用的 OAuth 范围。 工具的服务主体可以同意对这些范围的权限，从而允许它调用 API。

有关同意代理标识或服务主体的详细信息，请参阅 管理员同意应用程序权限。

将代理标识分配给应用程序角色

对于识别服务主体上的角色声明的应用程序，可以将代理的服务主体或代理标识分配给应用程序的应用角色。 在您分配应用角色时，会赋予应用程序权限。 应用程序权限通常由守护程序应用、后端服务或自治代理使用，这些代理需要自行进行身份验证和进行授权的 API 调用，而无需用户交互。 有关详细信息，请参阅 向应用程序添加应用角色并在令牌中接收它们。

首先，确认应用程序的清单中的应用角色具有allowedMemberTypesApplication，表明该角色可被其他应用程序使用。 如果该角色仅允许用户，则应用程序不支持代理标识和服务主体。该角色的应用程序不支持代理标识和服务主体。 然后，可以使用 Microsoft Entra 管理中心、Microsoft Graph 或 Microsoft Graph PowerShell 将应用角色分配给代理标识或服务主体。

• 如果使用 Microsoft Entra 管理中心，请按照有关如何 分配给应用程序应用角色的说明进行操作。

• 如果使用 Microsoft Graph 或 Microsoft Graph PowerShell，则向应用程序角色分配代理标识或服务主体类似于将 用户和组分配到应用程序。 可以使用 列表应用角色分配 来检查代理标识或服务主体是否已具有角色分配，并使用 添加应用角色分配 来创建新的应用角色分配。 例如，若要使用 PowerShell 为代理标识创建应用程序角色分配，请设置$PrincipalId为代理标识的id，设置$ResourceId为目标应用程序服务主体的id，以及设置$AppRoleId为目标应用程序应用角色的 ID。 然后，构造用于添加应用角色分配的负载：

  
  $Body = @{
    principalId = $PrincipalId
    resourceId = $ResourceId
    appRoleId = $AppRoleId
  } | ConvertTo-Json
  
  Invoke-MgGraphRequest -Method POST -Uri "https://graph.microsoft.com/v1.0/servicePrincipals/$ResourceId/appRoleAssignedTo" -Body $Body
  

分配给使用 SAML 的应用程序

如果您拥有的应用程序仅支持通过 SAML 让用户获取令牌，并且希望您的代理能够自主地使用代理身份与该应用程序进行交互，则可以通过代理用户扩充代理的身份。 然后，向代理添加对 SAML 和代理用户的支持后，代理可以获取应用程序的令牌。 与代理标识不同，还可以根据需要通过 SCIM 将代理用户预配到这些应用程序中（如果需要）。

使代理能够与接受 SAML 断言的应用程序交互，要求额外注册一个应用程序，以便于Microsoft Entra ID在代理流中提供 SAML 断言作为响应。 除了代理和应用程序本身，你还需要为租户中任何基于 SAML 的应用程序创建一个 SAML 帮助程序应用注册。 如果在内部开发代理程序，该辅助组件可能是代理的一部分。

在 Microsoft Entra 租户中，需要存在以下组件：

• 代理标识蓝图和代理标识蓝图主体
• SAML 辅助应用程序注册
• 作为目标资源的企业应用程序
• 一个 OAuth2PermissionGrant，带有
  • SAML 辅助应用注册为客户端
  • 企业应用程序作为资源
  • 企业应用程序的实体 ID 与 /.default 连接后的作用域值

然后，为每个代理身份创建：

• 代理用户
• 为代理用户将应用程序角色分配给企业应用程序的某个角色之一。
• 一个 OAuth2PermissionGrant，用于代理的身份，
  • 作为客户端的代理标识
  • SAML 辅助程序应用程序注册为资源
  • 由api://'、SAML 帮助程序应用程序的应用程序 ID 和/.default连接而成的范围值

如果代理拥有多个代理身份，您可以使用权限继承，在代理身份蓝图上一次性授予许可，然后将其继承给多个代理身份。

在这些应用程序、用户、角色分配和授权在租户中就位后，需要 SAML 断言以进行企业应用程序身份验证的代理可以：

• 获取作为代理标识蓝图的令牌。

• 使用该令牌向 https://login.microsoftonline.com/<tenantid>/oauth2/v2.0/token 终结点发出令牌请求，并获取联合标识凭据（FIC）令牌作为代理标识。

  在该请求中，client_id 是代理标识 ID，scope 是 api://AzureADTokenExchange/.default，grant_type 是 client_credentials，client_assertion_type 是 urn:ietf:params:oauth:client-assertion-type:jwt-bearer，client_assertion 是步骤 1 中的代理标识蓝图令牌。

• 使用这两个令牌，作为代理用户，使用帮助应用的范围，发起一个令牌请求以获取令牌。

  在此请求中，client_id是代理标识 ID，scope是api://'与 SAML 帮助程序应用的应用 ID 的连接，/.default、grant_type是user_fic，client_assertion_type是urn:ietf:params:oauth:client-assertion-type:jwt-bearer，client_assertion是代理标识蓝图令牌，user_id是代理用户对象 ID，user_federated_identity_credential是代理标识令牌。

• 发出代表调用令牌请求以获取 https://login.microsoftonline.com/<tenantid>/oauth2/v2.0/tokenSAML 令牌。

  在此请求中，提供 SAML 帮助程序应用程序注册的凭据、作为 user_fic 断言返回的令牌、授权类型 urn:ietf:params:oauth:grant-type:jwt-bearer、带有 /.default 的企业应用程序 ID 的范围、requested_token_use 和 on_behalf_of 的 requested_token_type 及 urn:ietf:params:oauth:token-type:saml2 的 。 响应包含以 Base64URL 编码的 SAML 断言。

相关内容

• 将用户和组分配到应用程序角色