将第三方代理与 Microsoft Entra 智能体 ID 集成

Microsoft Entra 智能体 ID使来自第三方平台的 AI 代理能够安全地进行身份验证和访问 API，而无需直接处理凭据。 本文介绍 Amazon Web Service （AWS） Bedrock 和 n8n 等平台的两种集成模式（Microsoft Entra ID身份验证 SDK（sidecar）和联合身份验证。

先决条件

在开始之前，请确保已做好以下准备：

  • 已启用代理标识功能的 Microsoft Entra tenant。
  • 某些部署选项需要Azure订阅。
  • Docker 和 Docker Compose 适用于 sidecar 模式。
  • 凭据或联合身份验证配置，具体取决于所选模式。
  • PowerShell 7.5 或更高版本与 Microsoft Graph PowerShell 模块一起使用。
  • 全局管理员 角色，仅用于初始设置。 使用 Privileged Identity Management （PIM）实时激活此角色。
  • Cloud 应用程序管理员或 应用程序管理员 角色可授予 Microsoft Graph 的委派权限，用于代理管理操作。

若要验证环境是否已准备就绪，请执行以下操作：

  1. 确认你有权在Microsoft Entra租户中创建应用程序和服务主体。
  2. 如果要部署到Azure，请确认订阅和资源组。
  3. 查看代理平台的文档，例如 AWS Bedrock 或 n8n。

为何需要第三方代理集成

组织使用来自多个平台（例如 AWS Bedrock、n8n 等）的 AI 代理。 这些代理通常需要：

  • 调用Microsoft API，例如Microsoft Graph和Azure服务。
  • 访问内部 API 和资源。
  • 无需在代码或配置中存储机密即可安全进行身份验证。

Microsoft Entra 智能体 ID提供集中式安全标识服务，第三方代理可以使用该服务按需获取令牌，而无需直接管理机密或证书。 通过使用Microsoft Entra 智能体 ID，可以：

  • 消除代理直接处理凭据的需求。
  • 对运行在 Azure 外部的代理使用工作负荷标识联合身份验证。
  • 支持多种身份验证模式，包括客户端凭据、联合标识和代理身份验证。
  • 使用 Microsoft Entra ID 身份验证 SDK（sidecar）与第三方代理平台集成。

第三方代理的集成模式

若要将第三方代理与Microsoft Entra 智能体 ID集成，请从以下模式中进行选择：

使用 Microsoft Entra ID 身份验证 SDK （sidecar）

sidecar 模式将 Microsoft Entra ID 身份验证 SDK（sidecar）作为配套容器与代理一起运行。 代理调用 sidecar 来请求 API 调用的令牌。 代理永远不会直接处理凭据；而是将令牌获取委托给 “sidecar”。

最适合：

  • Docker 或 Kubernetes 上的容器化代理。
  • 在你自己的业务流程中运行的 AWS Bedrock 代理。
  • 使用 Docker Compose 进行本地开发。
  • 已使用容器基础结构的组织。

支持的平台：

  • AWS Bedrock，包括 Claude 和其他基础模型。
  • 本地大型语言模型（LLM），如 Ollama 与 LangChain。
  • 任何容器化代理程序。

优点：

  • 无凭据代理程序代码。
  • 适用于任何容器化代理。
  • 使用 Docker Compose 轻松进行本地开发。
  • 可以部署到 Azure 容器应用、Kubernetes 或本地。

考虑：

  • 需要管理第二个容器。

下图显示了 Sidecar 体系结构。 代理容器和 sidecar 容器在同一编排环境中一起运行。 代理通过 sidecar 请求令牌，sidecar 与 Microsoft Entra 智能体 ID 通信以获取访问令牌。

此图示显示了在相同业务流程环境中运行的代理和 sidecar 容器的 sidecar 模式体系结构，其中 sidecar 从 Microsoft Entra 智能体 ID 请求令牌。

使用工作负荷标识联合身份验证（直接标识交换）

联合模式使用工作负载身份联合直接从外部标识提供者（如 AWS 安全令牌服务（STS））交换凭据，以获取 Microsoft Entra 令牌。 此模式不需要侧车。

最适合：

  • 使用 STS 和 OIDC 的 AWS 代理。
  • 已具有联合基础结构的组织。
  • 无法运行容器的代理。

支持的平台：

  • GCP 工作负荷标识→ Microsoft Entra 智能体 ID。
  • AWS STS → Microsoft Entra 智能体 ID。

优点：

  • 无需 Sidecar。
  • 使用 AWS 和其他平台中的现有基础结构。
  • 标识层上的直接令牌交换。

要求：

  • 在Microsoft Entra中预配置的联合标识凭据。
  • 支持 OIDC 或 STS 的代理平台。

下图显示了联合流。 第三方平台上的代理通过其内置工作负载身份提供者进行身份验证，使用生成的 OIDC 令牌交换 Microsoft Entra 令牌，然后调用您的 API。

图显示联合模式流程，其中第三方平台代理通过 Microsoft Entra 智能体 ID 交换 OIDC 令牌来访问你的 API 或 Microsoft 的 API。

了解令牌流动

这两种模式都遵循相同的核心令牌流：

  1. 代理请求令牌。 代理或代替代理进行操作的 sidecar 使用身份验证凭据调用 Microsoft Entra 智能体 ID。
  2. Microsoft Entra验证标识。 Microsoft Entra通过客户端凭据、联合凭据或其他受支持的方法验证代理的标识。
  3. Microsoft Entra返回令牌。 代理接收Microsoft Entra访问令牌。
  4. 代理调用 API。 代理使用令牌对Microsoft或自定义 API 进行身份验证。
  5. API 验证令牌。 API 检查令牌签名和声明，然后授予访问权限。

常见集成方案

AWS Bedrock 代理调用Microsoft Graph

AWS Bedrock 代理（如 Claude）需要通过Microsoft Graph查询Microsoft 365数据或管理资源。 侧车模式非常适合此方案。 将 AWS Bedrock 代理与 sidecar 模式集成：

  1. 将代理和 sidecar 部署到 AWS 或你自己的基础结构。
  2. 在具有Microsoft Graph权限的Microsoft Entra中配置代理标识。
  3. 代理向 sidecar 请求以获取令牌。
  4. sidecar 从 Microsoft Entra 智能体 ID 获取令牌。
  5. 代理使用令牌调用Microsoft Graph。

有关分步说明，请参阅使用 Microsoft Entra 智能体 ID 保护 Amazon Bedrock 代理。

n8n 代理调用 Microsoft Graph 和 MCP Server for Enterprise

n8n 代理需要通过 Microsoft Graph 或 Microsoft Graph MCP Server for Enterprise 访问Microsoft 365数据。 此方案使用 n8n-nodes-entraagentid 社区节点直接在 n8n 工作流中管理令牌获取。 要集成 n8n 智能体，请执行以下操作：

  1. 使用 Azure 开发人员 CLI（azd）将 n8n 部署到Azure 容器应用。
  2. 在具有Microsoft Graph权限的Microsoft Entra中配置代理标识。
  3. n8n 工作流使用社区节点从 Microsoft Entra 智能体 ID 获取令牌。
  4. 代理使用令牌调用 Microsoft Graph 或 MCP Server for Enterprise。

有关分步说明，请参阅 使用 Microsoft Entra 智能体 ID 保护 n8n 代理。

使用 Ollama 进行本地开发

你正在使用本地 LLM（如 Ollama）进行开发，并且想要在部署之前测试身份验证。 将 sidecar 模式与 Docker Compose 配合使用。 在本地测试：

  1. 在 Docker Compose 中运行代理程序和“sidecar”。
  2. 代理调用 localhost:7000/token 以向 Sidecar 请求令牌。
  3. sidecar 从 Microsoft Entra 智能体 ID 获取令牌。
  4. 在部署之前在本地测试代理行为。

有关分步说明，请参阅 为本地开发运行 Sidecar 组件。

高级路线图

使用下表确定所选模式的步骤：

Step 图案 任务
1 两者都有 在 Microsoft Entra 中设置代理标识和权限。
2 两者都有 选择集成模式：sidecar 或联盟。
3 Sidecar 部署 Agent 和 Sidecar 容器，然后在本地测试。
4 Sidecar 部署至 Azure 容器应用、Kubernetes 或其他平台的生产环境上。
5 联邦 在 Microsoft Entra 中配置联合标识凭据。
6 联邦 将代理部署到目标平台。

安全最佳做法

集成第三方代理时，请遵循以下安全原则：

  • 切勿在代理代码中嵌入凭据。 使用Microsoft Entra 智能体 ID动态获取令牌。
  • 使用最低权限。 通过角色或作用域仅授予代理标识所需的权限。
  • 验证令牌受众和颁发者。 请始终验证令牌是否来自你的 Microsoft Entra 租户。
  • 定期轮换凭据。 如果使用客户端机密，请按计划轮换它们。 请考虑改用联合凭据。
  • 监视令牌使用情况。 使用Microsoft Entra日志跟踪哪些代理访问哪些 API。
  • 请保持 Microsoft Entra ID 身份验证 SDK（sidecar）为最新版本。 安全和兼容性更新会定期发布。

排查常见问题

如果在集成过程中遇到问题，请使用以下指南确定原因和解决方法：

问题 原因 解决方案
代理无法访问 sidecar 网络配置问题或 Sidecar 未运行 验证 sidecar 是否正在运行、检查 DNS 和网络，并确认端口绑定。 默认端口为 7000。
Sidecar 无法获取令牌 Microsoft Entra身份验证失败 验证代理标识凭据、检查Microsoft Entra权限，并查看租户 ID 和客户端 ID。
令牌请求返回 HTTP 错误代码 401 Microsoft Entra凭据无效或未配置联合凭据 确认凭据是否正确，并验证是否设置了联合标识凭据（如果使用联合模式）。
API 拒绝令牌 令牌缺少所需的范围或权限 将所需的 API 权限添加到代理标识，并请求具有正确范围的令牌。

相关内容

  • Last updated on