匿名访问

Unauthenticated 提供程序告诉数据墙DBW 不要验证任何 JWT 令牌。所有请求都按 anonymous 系统角色处理。这是数据墙DBW 的默认认证方式。

适用场景

场景	说明
网关后部署	数据墙DBW 位于 Nginx、Traefik、API 网关等反向代理之后，网关已完成用户认证
内网服务	服务仅在私有网络内部访问，不面向公网
快速原型	本地开发阶段不想搭建身份系统，先跑通数据 API

场景	原因
直接暴露公网	任何人都可以无限制访问 API
需要角色区分	所有请求都是 `anonymous`，无法区分不同用户
需要 claims 注入	没有 JWT 令牌，数据库策略中的 `@claims` 引用无法工作

如果数据墙DBW 部署在网关之后，网关已完成认证，建议让网关将用户身份通过 X-MS-API-ROLE 头注入，这样可以结合网关的认证能力和数据墙DBW 的授权体系。

bash

dab configure --runtime.host.authentication.provider Unauthenticated

生成的配置：

json

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

因为所有请求都按 anonymous 角色评估，必须在每个实体的 permissions 中显式授予 anonymous 角色所需的操作：

json

{
  "Book": {
    "source": "dbo.Books",
    "permissions": [
      { "role": "anonymous", "actions": ["read"] }
    ]
  }
}

未配置 anonymous 的实体对所有请求返回 403。

虽然引擎不验证令牌，但可以通过 X-MS-API-ROLE 请求头实现基本的角色切换——由网关在认证后注入该头。

nginx

# Nginx 示例：认证通过后注入角色头
location /api/ {
    proxy_set_header X-MS-API-ROLE $user_role;
    proxy_pass http://dab-api:5000;
}

这种方式在 Unauthenticated 模式下也可以实现角色区分，前提是网关能够可靠地识别用户并分配角色。

WARNING

确保数据墙DBW 服务端口不被外部直接访问——只允许网关的内网通信。如果外部可以直接访问服务端口，攻击者可以随意伪造 X-MS-API-ROLE 头。