身份验证概述

身份验证用于确认请求发起方的身份。数据墙DBW 支持多种身份验证方式，覆盖从本地开发到生产部署的完整链路。选择哪种方式取决于你的部署架构——服务放在哪里、前面有没有网关、用户身份如何管理。

五种身份验证方式

方式	Provider 值	核心原理	适用阶段
匿名访问	Unauthenticated	引擎不做身份验证，所有请求使用默认角色	网关后部署、内网服务
JWT 验证	Custom	引擎自行验证 JWT 令牌的 issuer、audience 和签名	对接第三方身份系统
平台身份注入	Unauthenticated	反向代理或网关完成认证后注入身份头，引擎信任这些标头	API 网关架构
本地模拟	Simulator	跳过所有验证，所有请求视为已认证，可切换角色	本地开发和测试
用户委派	见具体配置	将终端用户的身份传递到数据库层，由数据库执行最终权限判断	需要数据库级别的用户隔离

身份验证流程

无论哪种方式，请求到达数据墙DBW 后都经过统一的处理管道：

1. 提取身份信息
   ├── JWT 模式：从 Authorization: Bearer <token> 中提取令牌
   ├── 网关注入模式：从平台标头（X-MS-CLIENT-PRINCIPAL 等）提取身份
   └── Simulator 模式：跳过提取，直接分配默认角色

2. 验证身份信息
   ├── JWT 模式：验证签名、issuer、audience、过期时间
   └── 其他模式：信任或跳过验证

3. 确定最终角色
   ├── 无身份信息 → Anonymous
   ├── 有身份信息但未指定角色 → Authenticated
   └── 通过 X-MS-API-ROLE 头指定 → 指定角色

4. 传递给授权层 → 根据角色评估实体权限

角色判定矩阵

Bearer Token	X-MS-API-ROLE 头	最终角色	HTTP 状态
无（Unauthenticated 模式）	无	Anonymous	200
无（Unauthenticated 模式）	有指定	Anonymous（头被忽略）	200
有效（Custom 模式）	无	Authenticated	200
有效（Custom 模式）	有，且令牌 roles 包含该值	指定角色	200
有效（Custom 模式）	有，但令牌 roles 不包含该值	—	403
无效或过期	—	—	401

配置位置

所有身份验证配置集中在 runtime.host.authentication 下：

{
  "runtime": {
    "host": {
      "authentication": {
        "provider": "Custom",
        "jwt": {
          "issuer": "https://identity.example.com/",
          "audience": "api://dab-api"
        }
      }
    }
  }
}

字段	说明	适用 Provider
provider	身份验证提供程序	全部
jwt.issuer	JWT 签发方 URL，用作验证 Authority	Custom
jwt.audience	预期的 JWT audience 声明	Custom

jwt.issuer 同时也是 OpenID Connect 元数据发现地址。引擎根据 issuer 构造 /.well-known/openid-configuration URL 自动获取签名密钥。

roles 声明

数据墙DBW 固定使用 roles 作为 JWT 中的角色声明名，不可配置。如果你的身份提供程序使用其他声明名（如 groups、permissions），需要配置提供程序额外输出一个 roles 声明，或在令牌中把角色信息映射到 roles 字段。

roles 声明可以是字符串或字符串数组。引擎将数组中的所有值视为该用户拥有的角色列表。

选择指引

你的部署情况	推荐方式
服务在 Nginx/Traefik 后面，网关负责认证	匿名访问（配合网关注入角色头）
服务直接暴露，需要自身验证	JWT 验证
对接 Okta / Auth0 / Keycloak	JWT 验证
本地开发测试，快速验证权限	本地模拟（Simulator）
需要把终端用户身份传到数据库	用户委派（特定场景）

下一步

• 匿名访问 — Unauthenticated 提供程序的完整配置。
• JWT 身份验证 — 对接 Okta、Auth0 等身份系统。
• 授权概述 — 认证通过后的权限体系。