角色与权限

角色与权限是数据墙DBW 安全模型的核心。每个请求都会被分配到一个角色，引擎根据角色在实体上配置的权限决定是否允许当前操作。默认情况下，未配置权限的实体拒绝所有访问。

角色类型

数据墙DBW 使用两种角色：

类型	角色	分配方式
内置角色	Anonymous	未认证用户自动分配
内置角色	Authenticated	已认证用户自动分配
自定义角色	自定义名称	来自 JWT 令牌的 roles 声明，通过 X-MS-API-ROLE 头选择

一个请求的已认证主体可能关联多个角色，但引擎每次只在一个最终生效角色的上下文中评估权限。

角色判定逻辑

是否有 Bearer Token	是否有 X-MS-API-ROLE	最终角色
无	—	Anonymous
有效	无	Authenticated
有效	有，且令牌包含该角色	该用户角色
有效	有，但令牌不包含该角色	拒绝（403）
无效	—	拒绝（401）

权限定义

每个实体通过 permissions 数组定义角色与操作的映射：

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

* 通配符代表该实体类型支持的全部操作。对于表和视图，* = create + read + update + delete；对于存储过程，* = execute。

字段访问控制

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

{
  "action": "read",
  "fields": {
    "include": ["*"],
    "exclude": ["salary", "password"]
  }
}

被排除的字段无论从 REST 还是 GraphQL 请求，都会被引擎过滤掉。

数据库策略

策略允许在行级别过滤数据。策略被转换为数据库查询的 WHERE 条件，使用 @item.{field} 引用实体字段，@claims.{claim} 引用用户身份：

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

策略适用于 read、update、delete 操作。

角色继承

未在实体上显式配置的角色会自动从更宽泛的角色继承权限，继承链为：

自定义角色 → authenticated → anonymous

配置一次 anonymous 的 read 权限，authenticated 和所有未显式配置的命名角色自动获得相同的读取能力。

分层安全模型

数据墙DBW 的安全控制分为多个层次，逐层叠加：

层级	控制内容	示例
实体级	哪些实体可访问、允许哪些操作	角色 A 只能读 Book，不能写
字段级	哪些字段可见	普通用户看不到 salary 字段
策略级	行级数据过滤	用户只能看到自己创建的记录
数据库级	数据库自身的行级安全（RLS）	SQL Server RLS 策略配合 @claims 使用

这种分层设计让安全边界可以精确到"谁能访问什么实体、能做什么操作、能看到哪些字段、能查到哪些行"。