增强你的业务:通过访问控制将 AI 工具连接到你现有的服务
了解如何通过使用个人访问令牌(Personal Access Tokens)和模型上下文协议(Model Context Protocol,MCP)安全地将 AI 工具连接到你的现有服务,获取完整的源代码和实用示例。
欢迎来到通过访问控制将 AI 工具连接到你现有服务的指南!
我们将探讨如何使你的现有服务为 AI 工具做好准备,特别是通过与 LLM(使用 模型上下文协议)和各种 AI 代理的集成,同时解决访问控制挑战。
通过本指南,你将获得:
- 无缝的 AI 集成:了解如何将 AI 工具连接到你的服务,使你的数据和功能在 AI 环境中可用
- 增强的 API 安全性:通过有效的访问控制改善你的 API 界面,以保护数据和用户隐私
- 为用户提供个性化的 AI 体验:通过个人访问令牌为每个用户创建独特的 AI 辅助体验
我们提供完整的教程资源,完整演示项目 源代码(包括前端、后端和 MCP 服务器),甚至包括实用指南,帮助你从头开始构建 AI 准备好的服务。
以下是本指南如何改善你的业务:
- 竞争优势:提升你服务的技术能力和用户体验,在竞争激烈的市场中脱颖而出
- 用户价值提升:通过 AI 工具使用户在产品中发现更深层次的价值,增加留存率和满意度
- 面向未来的服务:无缝地将你的服务与 AI 生态系统集成,为即将到来的 AI 驱动的商业环境做好准备,打开创新的增长路径
让我们开始吧!
什么是 MCP 以及它如何将 AI 工具连接到你的服务
MCP(模型上下文协议)是一种开放的、通用的协议,用于标准化应用程序向大型语言模型(LLMs)提供上下文信息的方式。
MCP 由多个关键组件共同工作,使 AI 工具能够访问你的服务:
在本指南中,你只需知道 MCP 服务器是你的服务与 AI 工具之间的关键连接点。它负责为 LLM 提供一系列工具,这些工具将与你自己的服务进行交互。有关 MCP 的更多详细信息,你可以参考 什么是 MCP(模型上下文协议)及其工作原理。在这里,我们将专注于 MCP 服务器。
我们将使用已集成基于角色的访问控制(RBAC)策略的内容管理系统(CMS)作为示例。我们将为其创建一个 MCP 服务器,并定义一个 get-available-article-count
工具,允许 LLM 获取当前用户在 CMS 中可用的文章数量:
这是将 MCP 服务器连接到你的服务的关键代码。在此工具实现中,它向服务的 api/articles
端点发送请求并返回结果。
但是,这远远不够,因为你的服务的 API 可能不是公共的。每个端点都需要访问控制,不同的用户可以访问不同的资源和数据。
接下来,我们将讨论如何为你的服务添加访问控制。
如何为 MCP 服务器实现访问控制
理解通过 AI 工具访问你的系统的用户与直接使用你的系统的用户是相同的非常重要——MCP 服务器在他们通过 AI 工具交互时充当他们的代表。
因此,当用户通过 AI 工具访问你的服务时,会出现两个实际的访问控制挑战:
- MCP 服务器如何像用户一样登录到你的系统?
- 你的系统是否应该重新设计其整个访问控制机制 来适应 MCP 服务器?这将是一个显著的成本和努力,特别是当你的原始系统已经有其自己的身份验证机制时
解决这些问题的关键是:
用户如何可以让 MCP 服务器授予访问服务的权限而不使用他们的凭据和交互式登录?
如果你能解决这个问题,你可以通过 MCP 服务器直接与你的服务进行交互,而你的服务可以继续使用先前为用户设计的访问控制机制,而不需要仅仅为 MCP 服务器重新设计一个新系统!
但这可能吗?
当然可以!我们可以通过使用 个人访问令牌 完美地解决这个问题!
个人访问令牌(PATs)为用户提供了一种安全的方法来授权访问令牌,而不使用他们的凭据和交互式登录。这对于需要以程序化方式访问资源的 CI/CD、脚本或应用程序很有用。
工作流如下所示:
因此,只要你的系统支持个人访问令牌(PAT),你就可以在不重新设计身份验证机制的情况下完美解决 AI 工具与现有服务之间的访问控制挑战,同时确保用户的数据安全和隐私保护。
现在,让我们看看如何在实践中实现这一点。
MCP 服务器访问控制实现
在本节中,我们将使用现有的 CMS 系统作为基础为 MCP 服务器实现访问控制。
你可以查看完整的 CMS 示例教程和源代码 RBAC 原则实践:为你的应用程序实现安全授权,但这不是必需的,我们将在这里介绍所有的基本原则。
CMS 示例基于 Logto,一个流行的开源身份平台,提供全面的身份验证和授权解决方案,但技术实现不是本文的重点。
为你的服务设计权限和访问控制策略
实施访问控制的第一步是为你的系统设计权限和访问控制策略。
在我们的 CMS 示例中,我们根据 RBAC(基于角色的访问控制) 设计了以下 API 端点,并指定了访问每个端点所需的权限:
端点 | 访问控制逻辑 |
---|---|
GET /api/articles | - 任何具有 list:articles 权限的人,或作者可以查看自己的文章 |
GET /api/articles/:id | - 任何具有 read:articles 权限的人,或文章的作者 |
POST /api/articles | - 任何具有 create:articles 权限的人 |
PATCH /api/articles/:id | - 任何具有 update:articles 权限的人,或文章的作者 |
DELETE /api/articles/:id | - 任何具有 delete:articles 权限的人,或文章的作者 |
PATCH /api/articles/:id/published | - 仅具有 publish:articles 权限的用户 |
系统的权限设计如下:
权限 | 描述 |
---|---|
list:articles | 查看系统中所有文章的列表 |
read:articles | 阅读任何文章的完整内容 |
create:articles | 创建新文章 |
update:articles | 修改任何文章 |
delete:articles | 删除任何文章 |
publish:articles | 更改发布状态 |
基于这些权限,我们为我们的 CMS 系统定义了以下角色:
权限/角色 | 👑 管理员 | 📝 发布者 | ✍️ 作者 |
---|---|---|---|
描述 | 全系统访问权限,用于完成内容管理 | 可以查看所有文章并控制发布状态 | 可以在系统中创建新文章 |
list:articles | ✅ | ✅ |