MCP 工具防御式授权实现：Entra ID + JWT + RBAC/ABAC

在 Amazon QuickSight 上为 MCP 工具实施纵深防御授权

Amazon QuickSight 上的每次 Model Context Protocol（MCP）工具调用都是一次访问事件，可能需要在工具级别和参数级别实施纵深防御授权。这是在有效令牌之上的额外一层控制。如果没有细粒度控制，一个配置错误的权限就能绕过组织为满足合规性要求而设置的访问要求。在这篇文章中，你将实现一种多门授权模式，按顺序评估 OpenID Connect（OIDC）JSON Web Token（JWT）声明。该模式在每次调用时强制执行基于角色的访问控制和基于属性的访问控制。你可以根据合规性要求配置要激活哪些授权控制，从基于组的权限到参数级属性检查。Microsoft Entra ID 作为本演练的身份提供商（IdP）。

当你将 MCP 工具连接到 Amazon QuickSight 时，有效的单点登录（SSO）确认了调用者是谁，但并不能确认他们应该被允许做什么。授权填补了这一空白，将已验证的身份转换为关于每个调用者可访问范围的一组可强制执行的规则。Model Context Protocol（MCP）是一种开放协议，将应用程序连接到内部工具、数据库和 API，减少了对自定义集成的需求。然而，一旦这些工具触及敏感数据，有效的 SSO 令牌就不够了。没有分层的、纵深防御的授权，一个范围过宽的令牌就能让调用者访问超出其角色的工具和数据，这可能导致数据泄露并使合规审计复杂化。

当组织通过 MCP 将敏感数据源连接到 Amazon QuickSight 时，"已认证"不再等于"已授权"。授权决定调用者可以从哪些位置、以什么特权级别调用哪些工具。例如，受监管的组织要求在登录时进行多因素身份验证（MFA），并限制从未批准的国家访问。身份提供商强制执行第一个要求，授权层强制执行第二个要求。标准的 OAuth 2.0 身份验证不会强制执行调用者在工具和参数级别可以做什么。

这篇文章解释了多门授权模式如何工作，并引导你完成驱动它的身份层配置。拦截器通过四个门按顺序处理 OpenID Connect（OIDC）JSON Web Token（JWT）声明：MFA、地理限制、组到角色映射和工具级权限检查。在本演练中，你配置了各个门所依赖的 Microsoft Entra ID 应用程序、声明和策略。然后，你将 Amazon QuickSight 连接到现有的 Amazon Bedrock AgentCore Gateway，这是 Amazon Bedrock AgentCore 的一项功能。该网关在客户端和 MCP 工具之间提供 HTTP 端点和 JWT 验证层。你通过以不同角色登录来验证允许和受限路径。本演练假设你已经部署了 AWS 组件，包括网关、拦截器 AWS Lambda 函数、工具 Lambda 函数及其使用的 Amazon DynamoDB 表。你将获得一个可审计的、可组合的安全层，它位于用户的自然语言请求和你的业务逻辑之间。

这篇博文使用了一个虚构示例：AnyCompany Global Services，这是一家企业，在 Amazon DynamoDB 上维护一个多租户风险登记簿，通过 Amazon QuickSight 上的 MCP 工具访问。对于可能需要细粒度访问控制以进行合规审计的金融服务、医疗保健和政府组织，这种模式非常相关。

AnyCompany 要求每次工具调用都来自已完成 MFA 的已认证调用者。来自未批准国家的调用者被拒绝访问。基于角色的权限强制执行严格的读/写边界：读者可以查询风险，但不能创建、更新或删除风险，而管理员可以绕过条件门以获得运营灵活性。最后，每次变更必须产生不可变的审计记录，以满足合规性和取证要求。

图 1 所示的多门授权用户流满足了上述每个要求。你通过附加到 Amazon Bedrock AgentCore Gateway 的单个 AWS Lambda REQUEST 拦截器来实现它。拦截器按固定顺序评估 JWT 声明，每个门独立运作。

图 1：多门授权用户流

授权门按以下顺序处理请求：

每个门都通过环境变量独立配置。门 3 和门 4（基于组的 RBAC 和工具权限）构成核心授权层，始终处于活跃状态。其余两个门是条件性的，可以通过将环境变量设置为 false 或完全省略来禁用。这意味着只需要 RBAC 和地理围栏的部署会激活三个门。需要更细粒度和控制的部署可以激活全部四项检查。

门 1 是唯一在拦截器外部强制执行的门。Entra ID 在颁发令牌之前应用条件访问策略，因此到达网关的每个令牌都已经满足 MFA。设置 REQUIRE_MFA 会开启拦截器内部对 amr 声明的额外检查，适用于在令牌中记录 MFA 证据的身份提供商。这两种机制协同工作：策略将未验证的调用者拒之门外，声明检查在请求路径中确认令牌携带了该证据。

拦截器在业务逻辑运行之前评估所有四个授权门。未通过某个门的请求会被拒绝并返回 403，不会到达工具或其数据。每条通过的变更都会写入一条不可变的审计记录，为你提供完整的、可查询的谁做了什么的事件追踪。

在部署解决方案之前，先设置你的身份提供商。

本演练假设你熟悉 AWS Lambda、OAuth 2.0 授权流程和 Microsoft Entra 身份提供商配置。你还需要访问以下章节中描述的一些 AWS 服务和 OIDC 身份提供商。

本演练假设该模式的 AWS 端已部署在你的账户中。该端包括配置了 CUSTOM_JWT 授权方的 Amazon Bedrock AgentCore Gateway、AWS Lambda REQUEST 拦截器、工具 Lambda 函数及其使用的 Amazon DynamoDB 表。这些资源的部署不在本文范围内，本文重点介绍身份和授权配置。

身份提供商设置

本演练使用 Microsoft Entra ID 作为身份提供商。授权模式适用于符合 OIDC 条件的身份提供商。但是，配置步骤因你选择的身份提供商而异。你需要在 Entra ID 租户中满足以下条件：拥有创建应用注册、安全组和强制执行 MFA 的条件访问策略的全局管理员或应用程序管理员角色。条件访问策略需要 Microsoft Entra ID P1 或 P2 许可证。为了进行验证，准备至少三个具有不同组成员的测试用户。

部署 Entra ID 应用程序

以下章节引导你完成注册两个应用注册、公开 API 以及连接权限的步骤。你还需要配置 AWS Lambda 拦截器读取的声明，以控制 MCP 工具上的权限。在整个过程中，将占位符标识符（{TENANT_ID}、{RESOURCE_APP_ID}、{GATEWAY_URL} 等）替换为你自己租户中的值。

Amazon QuickSight 使用 Proof Key for Code Exchange（PKCE）和 RFC 8707 资源指标，这是一种将令牌绑定到特定 API 端点的标准。它们共同将每个访问令牌限定到特定的 MCP 服务器。在令牌交换期间，Amazon QuickSight 将 AgentCore Gateway URL 作为资源参数发送。当资源由 URL 标识时，Entra ID 要求客户端和资源由单独的应用注册表示。

配置资源应用程序

步骤 1 到 3 注册资源应用程序、设置其应用程序 ID URI 并公开 Amazon QuickSight 请求的 API 范围。

步骤 1：注册资源应用程序（AnyCompany-MCP-Authorization）

资源应用程序代表受保护的 MCP API。它的访问令牌是 AgentCore Gateway 验证的令牌。

在 Microsoft Entra 管理中心，转到 Entra ID > 应用注册，然后选择新建注册。

对于名称，输入 AnyCompany-MCP-Authorization。

在支持的账户类型下，选择仅此组织目录中的账户（单租户）。

保留重定向 URI 为空（资源应用不处理登录重定向）。选择注册。

图 2 显示了资源应用程序的已完成注册表单，其中已输入名称并选择了单租户。

图 2：资源应用程序注册

在应用程序概述页面上，记下并复制应用程序（客户端）ID、对象 ID 和目录（租户）ID。你稍后需要这些值。

图 3 显示了概述页面，其中包含应用程序（客户端）ID、对象 ID 和目录（租户）ID。

图 3：Microsoft Entra ID 中的资源应用程序概述

步骤 2：使用 Microsoft Graph API 设置应用程序 ID URI 和令牌版本

资源应用程序上的以下两个设置通过 Microsoft Graph API 应用：

Application ID URI：标识符是一个完整 URL（AgentCore Gateway URL），因此通过 Graph API 设置 identifierUris。

Access token version：此模式需要 v2.0 访问令牌，因此更新 api.requestedAccessTokenVersion 下的 Microsoft Graph api 属性。

你可以在对应用程序对象的一次 PATCH 请求中同时应用这两个设置。使用应用程序的对象 ID（不同于客户端 ID），即你在步骤 1 中记录的那个。

选项 A：Microsoft Graph Explorer

打开 Microsoft Graph Explorer 并以管理员身份登录。出现提示时同意 Application.ReadWrite.All 范围。

将方法设置为 PATCH，URL 设置为 https://graph.microsoft.com/v1.0/applications/{OBJECT_ID}。

将请求正文设置为以下内容，将 {GATEWAY_URL} 替换为你的网关 URL（例如 api://{RESOURCE_APP_ID} 或完整网关端点，取决于你的租户策略）：

{
  "identifierUris": ["{GATEWAY_URL}"],
  "api": {
    "requestedAccessTokenVersion": 2
  }
}

选择 Run query。204 No Content 响应表示成功。

图 4 显示了 Microsoft Graph Explorer 中的 PATCH 请求以及确认成功的 204 No Content 响应。

图 4：Microsoft Graph Explorer PATCH 请求

使用步骤 1 中的租户 ID 登录租户。

az login --tenant "{TENANT_ID}" --scope "https://graph.microsoft.com//.default"

使用对象 ID 在一次调用中 PATCH identifierUris 和请求的访问令牌版本。

az rest --method PATCH \
  --uri "https://graph.microsoft.com/v1.0/applications/${OBJECT_ID}" \
  --headers "Content-Type=application/json" \
  --body '{
    "identifierUris": ["{GATEWAY_URL}"],
    "api": { "requestedAccessTokenVersion": 2 }
  }'

通过重新读取应用程序来确认更改。

az rest --method GET \
  --uri "https://graph.microsoft.com/v1.0/applications/${OBJECT_ID}?\$select=identifierUris,api" \
  -o json

响应应列出你的 identifierUris 并显示 "requestedAccessTokenVersion": 2。

步骤 3：公开 API 范围

设置了 Application ID URI 后，添加网关和 Amazon Quick 请求的委托范围。

在资源应用程序中，转到 Expose an API。

选择 Add a scope。在 Add a scope 面板中，为第一个范围填写表单：

Who can consent?：选择 Admins and users（或者如果你的租户要求所有范围都需要管理员同意，则选择 Admins only）

Admin consent display name：一个短标签，例如 Access MCP tools。

Admin consent description：例如，允许应用程序代表已登录用户调用 MCP 工具。

User consent display name 和 User consent description：可选。如果允许用户同意，则提供面向用户的等效内容。

State：保留设置为 Enabled。

对每个剩余的委托范围重复 Add a scope，使用相同的同意和状态设置：mcp:stream、stream、invoke。

完成后，Scopes defined by this API 列表显示所有四个范围，每个范围都有其完整的 Application ID URI（例如 api://<gateway-id>.../mcp）和 Enabled 状态。

如果 Add a scope 报告 Application ID URI 未设置，请确认步骤 2 已成功完成，因为门户读取的是通过 Graph 设置的 identifierUris。

配置客户端应用程序

步骤 4 和 5 注册客户端应用程序并授予其调用资源 API 的权限。

步骤 4：注册客户端应用程序（AnyCompany-Quick-MCP-Client）

客户端应用程序是 Amazon Quick 进行身份验证的 OAuth 客户端。

在 App registrations 中，选择 New registration。

对于 Name，输入 AnyCompany-Quick-MCP-Client。

在 Supported account types 下，选择 Accounts in this organizational directory only（单租户）。

在 Redirect URI 下，选择平台 Web 并输入 https://us-east-1.quicksight.aws.amazon.com/sn/oauthcallback。选择 Register。

转到 Certificates & secrets > Client secrets > New client secret。添加描述和过期时间，选择 Add，然后复制密钥 Value（它只显示一次）。

在概述页面上，复制应用程序（客户端）ID。你现在有了 Amazon Quick 所需的客户端 ID 和客户端密钥。

步骤 5：授予客户端对资源 API 的权限

在客户端应用程序（AnyCompany-Quick-MCP-Client）中，转到 API permissions > Add a permission。

选择 My APIs 并选择 AnyCompany-MCP-Authorization。

选择 Delegated permissions，选中 invoke 范围，然后选择 Add permissions。

对于此流程，资源应用程序上的 invoke 委托权限已足够。Amazon Quick 是 OAuth 客户端，并在内部管理 PKCE、刷新令牌和用户会话。因此，你不需要在资源应用上请求 offline_access 或 Microsoft Graph openid/profile 范围。AgentCore Gateway 验证的令牌是资源应用程序的访问令牌（audience = 你的资源应用）。拦截器读取的身份声明（oid、sub、groups、ctry、email、amr）来自你在步骤 6 和 7 中在该令牌上配置的声明。

选择 Grant admin consent for {your tenant} 并确认。

图 5 显示了管理员同意后的客户端应用程序 API 权限，其中在资源应用程序上授予了 invoke 范围。

图 5：显示资源应用程序上 invoke 范围的客户端应用程序 API 权限

配置声明、组和 MFA

步骤 6–9 添加 AWS Lambda 拦截器读取的声明、支撑 RBAC 策略的安全组，并要求在登录时进行 MFA。

步骤 6：配置组声明

在资源应用程序（AnyCompany-MCP-Authorization）中，转到 Token configuration。

选择 Add groups claim。

选择 Security groups，并在 Access token type 的 ID 下，选择 Group ID 格式。选择 Add。

图 6 显示了为访问令牌添加了组声明的 Token configuration 页面。

图 6：组和可选声明的令牌配置

步骤 7：添加可选声明

在资源应用程序的 Token configuration 页面上，保持打开状态，选择 Add optional claim。

将令牌类型设置为 Access 并添加 ctry 和 email 声明。选择 Add。

如果提示你打开声明所需的 Microsoft Graph 权限，请接受。

图 7 显示了已为声明授予管理员同意的 Microsoft Graph API 权限。

图 7：已授予管理员同意的 Microsoft Graph API 权限

步骤 8：创建安全组

在 Identity > Groups > All groups > New group（组类型 Security）中创建三个安全组：

图 8 显示了在 Microsoft Entra ID 中创建的这三个安全组。

图 8：Microsoft Entra ID 中用于 RBAC 的安全组

创建每个组后，打开它并从概述页面复制其对象 ID，拦截器将这些 ID 映射到 RBAC 策略。然后将你的测试用户分配到适当的组。当用户登录 Amazon Quick 时，生成的访问令牌会使用组声明包含他们的组对象 ID。拦截器从令牌中读取这些 ID。然后将它们映射到相应的 RBAC 策略。

步骤 9：使用条件访问策略要求 MFA

门 1（MFA 验证）由 Entra ID 在颁发令牌之前强制执行。

转到 Protection > Conditional Access > Policies > New policy。

命名策略（例如 Require MFA for MCP Authorization）。

在 Assignments > Users 下，选择你的测试用户或包含他们的组。

在 Target resources > Cloud apps 下，选择资源应用程序（AnyCompany-MCP-Authorization）。

在 Access controls > Grant 下，选择 Grant access 并选择 Require multifactor authentication。

将 Enable policy 设置为 On，然后选择 Create。

从上述步骤中，收集拦截器强制授权所需的值。这是租户 ID、应用程序客户端 ID 以及你创建的两个安全组的对象 ID。拦截器将这些作为环境变量读取，以及激活每个条件门的切换设置。

配置好身份提供者后，下一节将引导你了解连接这些组件的架构。

架构

该架构遵循从用户身份验证到授权、再到工具执行和数据存储的线性请求流程。

图 9 展示了端到端架构，从 Amazon QuickSight 中的用户请求开始，经过网关和拦截器，最终到达工具函数和数据存储。

图 9：端到端架构概览

架构中的编号步骤如下：

1. Amazon QuickSight 在 Entra ID 中对客户端应用（AnyCompany-Quick-MCP-Client）进行身份验证。Entra ID 将调用方重定向到其授权端点，调用方在该端点进行身份验证，并根据条件访问策略的要求完成 MFA。

2. Entra ID 颁发一个作用域为资源应用（AnyCompany-MCP-Authorization）的令牌。Amazon QuickSight 在令牌端点交换授权码，并将网关 URL 作为资源参数包含在内。生成的 JWT 包含组成员身份和国家/地区声明。

3. Amazon QuickSight 在每次调用 Amazon Bedrock AgentCore 网关端点时，将 JWT 作为 bearer 令牌附加到请求上。

4. Amazon Bedrock AgentCore 网关使用 Entra ID JSON Web 密钥集（JWKS）端点验证 JWT 签名、签发者、受众和过期时间。

5. AWS Lambda REQUEST 拦截器接收已验证的 JWT 声明，并按顺序处理活动的授权门。

6. 工具 AWS Lambda 函数执行请求的操作，并使用租户作用域的分区键和条件表达式将风险数据写入 Amazon DynamoDB 中的 fgac-risks 表。

7. 工具 AWS Lambda 函数向审计表追加一条不可变的审计记录，记录执行者身份、操作、时间戳和结果。响应通过 Amazon Bedrock AgentCore 网关返回到 Amazon QuickSight。当您授予访问权限时，授权层对用户不可见。当您拒绝访问时，会显示清晰的消息。Amazon Bedrock AgentCore 网关提供了 HTTP 端点和 JWT 验证层，将 Amazon QuickSight 连接到您的 MCP 工具。

Amazon Bedrock AgentCore 网关提供了 HTTP 端点和 JWT 验证层，将 Amazon QuickSight 连接到您的 MCP 工具。

Entra ID 配置到 AWS 强制执行的映射

在架构映射完成后，您可以检查授权层如何读取声明。

理解授权模式

Amazon Bedrock AgentCore 网关使用 CUSTOM_JWT 授权人进行配置，需要从您的 Entra ID 租户中获取三个值：签发者、受众（您的客户端 ID）和 JWKS URI：

gateway:
  authentication:
    type: JWT
    jwt:
      issuer: "https://login.microsoftonline.com/{TENANT_ID}/v2.0"
      audience: "{CLIENT_ID}"
      jwks_uri: "https://login.microsoftonline.com/{TENANT_ID}/discovery/v2.0/keys"

网关在拦截器运行之前验证令牌签名、签发者、受众和过期时间。然后拦截器解码 JWT payload 并按顺序评估活动的门。失败的门返回 403，且不会调用工具 Lambda：

门 1：MFA 验证。 由条件访问策略在颁发令牌之前强制执行，因此到达拦截器的令牌已经过 MFA 验证。对于在令牌中嵌入 MFA 证据的 IdP，提供可选的 amr 声明检查（REQUIRE_MFA）。

门 2：国家/地区地理围栏。 当 REQUIRE_COUNTRY=true 时，如果 ctry 声明不在 ALLOWED_COUNTRIES 中，则拒绝请求。

门 3：组 RBAC。 将 groups 声明中的每个 UUID 映射到 readers、authors 或 admins 策略。如果没有匹配项，则拒绝所有访问。

门 4：工具权限。 确认请求的工具名称在匹配策略的允许列表中。

策略定义和组到策略的映射提供了单一可信来源，由您在步骤 8 中收集的安全组 Object ID 构建，并作为环境变量提供：

READ_TOOLS = {'list_risks', 'get_risk', 'search_risks'}
WRITE_TOOLS = {'create_risk', 'update_risk', 'delete_risk'}
POLICIES = {
    'readers': READ_TOOLS,
    'authors': READ_TOOLS | WRITE_TOOLS,
    'admins': READ_TOOLS | WRITE_TOOLS,
}
GROUP_TO_POLICY = {
    READERS_GROUP_ID: 'readers',
    AUTHORS_GROUP_ID: 'authors',
    ADMINS_GROUP_ID: 'admins',
}

MCP 工具 Lambdas。 该模式使用六个工具 Lambda，每个 MCP 工具一个：

每个工具 Lambda 都会在服务器端重新检查调用者的权限，因此即使拦截器配置错误或被绕过，授权仍然有效。每次变更都会向 Amazon DynamoDB 审计表追加一条不可变的审计记录，包含执行者、操作、时间戳、工具名称和结果。

在 Entra 应用部署完成且模式理解之后，将 AgentCore 网关连接到 Amazon QuickSight 并验证每个门。

连接到 Amazon QuickSight 并验证

在连接网关之前，确认您的测试用户有权访问 Amazon QuickSight 实例。通过 AWS IAM Identity Center 配置用户，可以通过从 Entra ID 配置 SAML 和 SCIM 自动配置。或者，您可以在 IAM Identity Center 控制台中手动将用户分配到 Amazon QuickSight 应用。然后您可以使用内置的 MCP 客户端将 Amazon QuickSight 连接到远程 MCP 服务器。

图 10：Amazon QuickSight 中的连接器页面

通过为服务到服务身份验证提供四个值，将 Amazon QuickSight 连接到 Amazon Bedrock AgentCore 网关端点。在 Amazon QuickSight 中，导航到 Home > Connectors > Create for your team > MCP，并使用以下配置添加一个新的 MCP 服务器：

图 11 显示了 MCP 服务器连接配置，您可以在其中输入 AgentCore 网关端点。

图 11：MCP 服务器连接配置

图 12 显示了该连接的服务到服务身份验证设置。

图 12：MCP 服务身份验证配置

在下一步中，Amazon QuickSight 验证 OAuth 令牌并从网关发现可用的工具。

连接 MCP Connector 后，六个风险注册表工具在 Amazon QuickSight 中显示为可用操作。您可以通过自然语言与它们交互。当您授予访问权限时，授权层对用户不可见。当您拒绝访问时，会显示清晰的消息。

图 13 显示了已连接的 MCP 服务器，包含六个风险注册表工具（原文截断）