平台身份验证

平台身份验证是一种部署模式——身份验证工作不在数据墙DBW 内部完成，而是委托给外部的反向代理、API 网关或服务网格。网关认证通过后将用户身份信息通过 HTTP 请求头注入到后端请求中，数据墙DBW 信任这些标头。

架构

客户端 → 网关（认证 + 注入身份头） → 数据墙DBW（Unauthenticated 模式）

数据墙DBW 配置为 Unauthenticated 模式，不自行验证令牌。身份信息已由网关注入到请求头中，引擎直接使用这些信息进行角色判定和权限评估。

适用场景

• 企业已部署统一的 API 网关（Kong、APISIX、AWS API Gateway 等），不希望在每个后端服务中重复配置认证。
• 使用服务网格（Istio、Linkerd）进行东西向流量管理，网格层面已处理身份。
• 内部系统间调用，认证由企业 SSO 统一处理，数据墙DBW 只需关心授权。

配置方式

数据墙DBW 侧配置为匿名模式：

{
  "runtime": {
    "host": {
      "authentication": {
        "provider": "Unauthenticated"
      }
    }
  }
}

网关负责：

1. 验证用户身份（JWT、API Key、Session Cookie 等）。
2. 从认证结果中提取用户角色。
3. 将角色通过 X-MS-API-ROLE 请求头注入到转发给数据墙DBW 的请求中。
4. （可选）注入额外的身份标头供数据库策略的 @claims 引用。

Nginx 示例

server {
    listen 443 ssl;

    # SSL 配置略...

    location /api/ {
        # 由 auth_request 模块验证
        auth_request /auth;

        # 将认证服务返回的角色注入到后端请求
        auth_request_set $user_role $upstream_http_x_user_role;
        proxy_set_header X-MS-API-ROLE $user_role;

        # 注入用户 ID 等 claims
        auth_request_set $user_id $upstream_http_x_user_id;
        proxy_set_header X-User-Id $user_id;

        proxy_pass http://dab-api:5000;
    }

    location /auth {
        # 内部认证检查端点
        internal;
        proxy_pass http://auth-service:8080/verify;
    }
}

安全注意事项

注意事项	说明
网络隔离	数据墙DBW 服务端口（如 5000）只允许网关内网访问，不得对外暴露
标头可信	确保只有网关能够向数据墙DBW 发送请求——外部请求无法绕过网关直接注入身份头
网关认证可靠	网关层面的认证机制需要足够安全（令牌验证、超时、吊销检查）
角色映射	网关需要正确地将认证用户映射到数据墙DBW 的 permissions 中配置的角色名

网关提供的能力

平台身份验证的优势在于网关可以提供数据墙DBW 本身不具备的能力：

能力	说明
多种认证方式	API Key、Session Cookie、mTLS、OAuth2 等
速率限制	按用户或 IP 限制请求频率
请求/响应转换	修改请求路径、添加/删除请求头
统一日志和审计	在网关层集中记录所有 API 调用
IP 白名单/黑名单	基于来源 IP 的访问控制

限制

• @claims 引用需要额外的网关配置：如果数据库策略使用了 @claims.userId，网关需要将用户 ID 作为声明标头注入，且数据墙DBW 需要相应的机制来读取这些非 JWT 声明。匿名模式下 @claims 的支持有限。
• 角色切换依赖网关注入：客户端不能通过 X-MS-API-ROLE 自主切换角色——只能使用网关注入的角色。
• 不适合直接暴露：如果你的架构中没有网关层，平台认证模式不适用。请使用 JWT 身份验证。

下一步

• JWT 身份验证 — 引擎自行验证令牌的独立方案。
• 匿名访问 — Unauthenticated 模式的基础配置。