身份认证与访问控制

数据墙DBW 提供了从身份识别到数据过滤的完整安全链路。通过身份验证确认"谁在调用"，通过基于角色的授权控制"能做什么"，通过数据库策略和字段控制精确到"能看到哪些行、哪些列"。

安全模型概览

数据墙DBW 采用分层安全模型，每一层都可以独立配置：

层次	控制内容	配置位置
身份验证	确认调用方身份	runtime.host.authentication
实体授权	角色可执行的操作	entities.{name}.permissions
字段控制	角色可访问的列	permissions.actions.fields
行级过滤	角色可看到的数据行	permissions.actions.policy

四层安全共同构成纵深防御，未配置权限的请求默认被拒绝。

身份验证

数据墙DBW 支持多种身份验证方式：

方式	适用场景
匿名访问	服务位于可信网关之后，由网关负责身份验证
JWT 验证	第三方身份提供程序（Okta、Auth0、Keycloak 等）签发令牌
本地模拟	开发测试环境，跳过外部验证

对于 JWT 方式，引擎会验证令牌的 issuer、audience 和签名，并从令牌的 roles 声明中提取用户角色信息。

基于角色的授权

每个实体都通过 permissions 配置定义角色与操作的映射：

{
  "Book": {
    "source": "dbo.books",
    "permissions": [
      { "role": "anonymous",   "actions": ["read"] },
      { "role": "authenticated","actions": ["read", "create"] },
      { "role": "editor",      "actions": ["read", "create", "update"] },
      { "role": "admin",       "actions": ["*"] }
    ]
  }
}

角色分为两种：

• 系统角色：Anonymous（未认证用户）和 Authenticated（已认证用户），引擎自动分配。
• 用户角色：来自令牌声明的自定义角色，通过请求头 X-MS-API-ROLE 显式选择。

每个请求只在一个角色上下文中评估。引擎根据请求的身份信息和 X-MS-API-ROLE 头决定最终生效角色。

角色继承

数据墙DBW 支持角色权限继承，减少重复配置。继承链为：

自定义角色 → authenticated → anonymous

如果某个角色未在实体上显式配置，它会自动沿用下一级角色的权限。配置一次 anonymous 的读权限，所有更宽泛的角色都能直接获得相同的读取能力，无需为每个角色重复声明。

字段级访问控制

你可以按角色精确控制每个操作可访问的字段：

{
  "role": "auditor",
  "actions": [
    {
      "action": "read",
      "fields": {
        "include": ["*"],
        "exclude": ["salary", "last_login"]
      }
    }
  ]
}

无论请求来自 REST 还是 GraphQL，引擎都会自动过滤掉被排除的字段。客户端引用被禁字段时会收到拒绝响应。

行级安全

数据库策略允许你用 OData 风格表达式过滤查询结果。策略会在数据库查询中追加 WHERE 条件，确保用户只能看到被授权的行：

{
  "action": "read",
  "policy": {
    "database": "@item.ownerId eq @claims.userId"
  }
}

策略支持 @item.{field} 引用实体字段，@claims.{claim} 引用用户令牌中的声明。策略适用于 read、update、delete 操作。

默认安全原则

数据墙DBW 从设计上贯彻"默认拒绝"原则：

• 未在配置中引用的数据库对象不会暴露在 API 中。
• 未配置 permissions 的实体拒绝所有访问。
• 未显式授予的字段和行不被返回。

配置越简单，安全越牢靠。你只需要声明"谁可以做什么"，其他一律拒绝。

下一步

• 阅读安全总览 了解完整的安全架构。
• 阅读授权概述 深入了解角色与权限机制。