Dubbo

Authorization Flow 授权流程 1. 背景(Background) 随着模型上下文协议 (Model Context Protocol, MCP) 的应用场景从本地环境扩展到开放的互联网，对服务进行访问控制和身份验证变得至关重要。这直接关系到 MCP Server 的核心安全性。当前，Pixiu 网关已经具备将后端 API 包装为 MCP Server 的能力，下一步的核心任务是利用网关的现有能力，集成一套标准的鉴权机制，以完整实现 MCP 规范中的授权 (Authorization) 要求。 MCP 规范明确指出： Implementations using an HTTP-based transport **SHOULD** conform to this specification. （基于 HTTP 的传输应该实现此规范。） 本方案旨在设计一个健壮、可扩展且符合行业最佳实践的授权流程。 2. 核心原则与角色定位 (Core Principles & Role) 2.1 Pixiu 的角色抉择：资源服务器 A protected MCP server acts as an OAuth 2.1 resource server, capable of accepting and responding to protected resource requests using access tokens. ...

Pixiu AI 演进 AI 应用架构新范式 AI 应用架构图 调用链路说明 用户向AI应用发起请求，请求流量进入流量网关（云原生API网关）。 云原生API网关侧维护管理了不同类型的AI Agent的API或路由规则，将用户请求转发至对应的AI Agent。（可以考虑接入 A2A 协议） AI Agent无论以哪种方式实现，只要其中的节点需要获取数据，便向MCP网关（云原生API网关）请求获取可用的MCP Server及MCP Tool的信息。 因为MCP网关处可能维护了很多MCP信息，可以借助LLM缩小MCP范围，减少Token消耗，所以向AI网关（云原生API网关）发请求和LLM交互。（这一步可选） MCP网关将确定好范围的MCPServer及MCP Tool的信息List返回给AIAgent。 AI Agent将用户的请求信息及从MCP网关拿到的所有MCP信息通过AI网关发送给LLM。 经过LLM推理后，返回解决问题的唯一MCP Server和MCP Tool信息。 AI Agent拿到确定的MCP Server和MCP Tool信息后通过MCP网关对该MCP Tool做请求。 实际生产中 ③-⑧ 步会多次循环交互 云原生 API 网关 [!注释] 南北走向流量为 client-server 的流量 东西走向流量为 server-sever 流量 Web Application Firewall，Web应用防火墙，简称WAF 传统的流量网关和 API 网关集成的微服务网关（SpringCloud Gateway）注重于同 k8s 中的 Pod 进行交互，有东西走向流量和南北走向流量。 而新一代网关 增加了AI 流程的同时，有如下特点 流量网关、API网关，微服务网关、AI网关、MCP网关多合一 统一东西南北向流量 集成 WAF ，内容安全数据面 集成 AI 领域 LLM，MCP 差异化竞争力：服务治理、API管理、LLM管理、MCP管理 + 基本竞争力：高性能、高可用、零信任、易扩展 ...

issue 关联 Environment Server: Java-server, dubbo version v3.0.14 Client: Dubbo-go, v3.1.1 Protocol: Dubbo Registry: Nacos, v2.1.2 Problem dubbo-go 的 client 端无法调用 dubbo 的 server 端的代码。 问题分析 在调试并复现代码问题后，我发现问题出在 QueryDataSource 方法中： 1 QueryDataSource func(ctx context.Context, id int) (*DataSource, error) dubbo:"queryDataSource" 根本原因是类型不匹配：在 Go 中，int 和 int64 通常都是 8 字节，而在 Java 中，int 类型只有 4 字节。 这种差异导致 Java 无法正确识别要调用的方法。 解决方案： 将 Go 方法中的 int 参数更改为 int32。 1 QueryDataSource func(ctx context.Context, id int32) (*DataSource, error) dubbo:"queryDataSource" 这个修改应该能解决类型兼容性问题。 Go 中的枚举表示 我注意到您定义的 Java 枚举类型在 Go 中表示为字符串： 1 Type string hessian:"type" // Mapped from Java enum 为了解决这个问题并确保在 Go 中正确处理枚举，我建议使用 dubbo-go-hessian2 仓库中提供的枚举生成工具。 ...

issue 关联 client: dubbo-go: v3.2.0-rc2 server: dubbo v3.3.0 registry: zookeeper 问题 1：biStream 客户端没有关闭长连接的接口；如果服务端不调用 onCompleted，那么 Receive 会永久 block 客户端应当具有主动 Close 能力才对，底层使用的是 grpc，而 grpc 客户端是能够主动关闭连接的。 问题 2：Java 服务端调用 onCompleted() 后，biStream.Receive 返回 EOF 但是和服务端的 TCP 连接仍然存在；我知道 dubbo client 内部是连接池，但是我测试了一下，TCP 连接似乎并没有被复用 源码分析 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 func TestBiDiStream2(svc greet.GreetService) error { fmt.Printf("start to test triple bidi stream 2\n") stream, err := svc.GreetStream(context.Background()) if err != nil { return err } if sendErr := stream.Send(&greet.GreetStreamRequest{Name: "stream client!"}); sendErr != nil { return err } resp, err := stream.Recv() if err != nil { return err } fmt.Printf("triple bidi stream2 resp: %s\n", resp.Greeting) if err := stream.CloseRequest(); err != nil { return err } if err := stream.CloseResponse(); err != nil { return err } fmt.Printf("========>TestBiDiStream end, close stream...\n") return nil } 在其中 ...

定义与基本概念 Spring Security 是一个基于 Spring 框架的安全框架，为 Java 企业级应用提供了全面的安全解决方案，涵盖了身份验证（用户登录）、授权（访问控制）、加密和防止常见的安全漏洞等功能。它可以集成到各种类型的 Spring 应用中，包括 Web 应用（如 Spring MVC、Spring Boot）和非 Web 应用。 OAuth2（开放授权 2.0）是一个开放标准的授权框架，旨在解决不同应用之间的授权问题，允许用户在不向第三方应用透露自己的用户名和密码的情况下，授权第三方应用访问他们存储在另一个服务提供商上的资源。它通过使用令牌Token来代表用户的授权，使得资源服务器能够验证请求是否被授权。 核心角色与流程 资源所有者：通常是用户，拥有受保护的资源。 资源服务器：存储资源的服务器，需要对请求进行授权验证。 客户端：请求访问资源的应用程序。 授权服务器：负责验证资源所有者的身份，并发放令牌给客户端 客户端请求资源所有者授权，资源所有者同意后，授权服务器向客户端发放令牌，客户端携带令牌访问资源服务器，资源服务器验证令牌的有效性后提供资源。 与 Dubbo 的协同 同时低版本 javax 和高版本 jakarta servlet API ，jakarta API 优先级更高，只需要引入jar即可使用HttpServletRequest和HttpServletResponse作为参数 使用 Filter 扩展: 实现 Filter 接口和 org.apache.dubbo.rpc.protocol.tri.rest.filter.RestExtension 接口，然后注册SPI 主要流程 由于 OAuth2 需要授权服务器，资源服务器，客户端，为了简化案例，就写授权服务器和资源服务器。 AuthorizationServer 采用默认配置 1 2 3 4 5 6 @Bean public SecurityFilterChain authorizationServerSecurityFilterChain(HttpSecurity http) throws Exception { OAuth2AuthorizationServerConfiguration.applyDefaultSecurity(http); return http.build(); } 1. 端点访问控制 授权端点（/authorize）： 要求进行身份验证，只有已认证的用户才能发起授权请求。默认情况下，通常会使用 Spring Security 的标准身份验证机制，如基于表单的登录或 HTTP Basic 认证。 限制对该端点的请求方法，一般只允许 GET 和 POST 方法，以防止恶意的请求操作。 令牌端点（/token）： 此端点用于发放访问令牌和刷新令牌，安全要求更高。默认配置会要求客户端进行身份验证，通常通过客户端 ID 和客户端密钥进行认证。 同样限制请求方法，一般只允许 POST 方法，以确保只有合法的请求才能获取令牌。 2. 防止跨站请求伪造（CSRF） 启用 CSRF 保护机制，CSRF 是一种常见的网络攻击手段，攻击者通过在用户已登录的情况下，利用用户的浏览器自动发送恶意请求。默认配置会在授权服务器的相关请求中添加 CSRF 防护措施，例如在表单提交时要求包含 CSRF 令牌。 对于一些与 OAuth2 流程紧密相关的请求，可能会根据具体情况对 CSRF 保护进行特殊配置，例如在某些情况下允许特定的请求绕过 CSRF 检查，但这需要谨慎处理以确保安全性。 3. 安全头信息设置 添加各种安全相关的 HTTP 头信息，以增强安全性。例如： Content-Security-Policy：用于限制网页可以加载的资源来源，防止跨站脚本攻击（XSS）。 X-Frame-Options：防止页面被嵌入到其他页面的框架中，避免点击劫持攻击。 X-XSS-Protection：启用浏览器的 XSS 过滤机制，帮助检测和阻止 XSS 攻击。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 private static final String HOST = System.getProperty("authorization.address", "localhost"); String issuer = "http://" + HOST + ":9000"; @Bean public RegisteredClientRepository registeredClientRepository() { RegisteredClient registeredClient = RegisteredClient.withId(UUID.randomUUID().toString()) .clientId("49fd8518-12eb-422b-9264-2bae0ab89f66") //configure the client id .clientSecret("{noop}H3DTtm2fR3GRAdr4ls1mcg") // configure the client secret .authorizationGrantType(AuthorizationGrantType.AUTHORIZATION_CODE) .authorizationGrantType(AuthorizationGrantType.CLIENT_CREDENTIALS) .authorizationGrantType(AuthorizationGrantType.REFRESH_TOKEN) .redirectUri("http://localhost:9000/oauth2/token") // configure the redirect uri .scope("openid") .scope("read") .scope("write") .build(); return new InMemoryRegisteredClientRepository(registeredClient); } @Bean public AuthorizationServerSettings authorizationServerSettings() { return AuthorizationServerSettings.builder() .issuer(issuer) // set the address of the authorization server .build(); } 配置相关授权信息，并进行相关接口的暴露 ...