用户委派身份验证

用户委派是一种进阶的身份验证模式。在这种模式下，数据墙DBW 不仅验证请求来源的身份，还将终端用户的身份信息传递到数据库层，使数据库能以实际用户的身份执行查询。

概念

在标准的 JWT 身份验证模式中：

text

用户 → JWT Token → 数据墙DBW（验证 + 角色提取）→ 数据库（以数据墙DBW 服务账号执行）

数据库看到的是数据墙DBW 的连接账号（如 dab-service），不知道实际是哪个用户在请求。这在大多数场景下足够——权限控制由数据墙DBW 的 RBAC 层完成。

用户委派模式则将链条延伸到数据库：

text

用户 → JWT Token → 数据墙DBW（验证 + 转发用户身份）→ 数据库（以实际用户身份执行）

数据库不再只看到一个统一的服务账号，而是能够根据实际用户上下文执行查询。这对于需要在数据库层面实现用户级别数据隔离的场景非常关键。

适用场景

场景	说明
多租户 SaaS	每个租户的数据物理隔离，数据库需要知道是哪个租户在查询
数据库级别的精细权限	利用数据库原生的行级安全（Row-Level Security）功能，根据实际用户过滤数据
审计合规	数据库审计日志中记录实际用户身份，而不是服务账号
存储过程中的用户上下文	存储过程需要根据调用用户执行不同的逻辑或数据过滤

实现方式

用户委派的实现依赖于数据库的能力和部署环境的身份基础设施。以下是一些通用的实现思路：

会话上下文方式

通过 set-session-context 将用户身份信息注入数据库会话。这适用于 SQL Server，利用 SESSION_CONTEXT 在查询过程中传递用户信息：

json

{
  "data-source": {
    "database-type": "mssql",
    "options": {
      "set-session-context": true
    }
  }
}

启用后，数据墙DBW 在每次请求时将 JWT 声明写入 SQL Server 的 SESSION_CONTEXT。数据库中的行级安全策略、存储过程或视图可以通过 SESSION_CONTEXT(N'key') 读取调用用户的信息。

数据库代理认证

部分数据库支持中间层代理认证——数据墙DBW 使用自己的服务账号建立连接，但在查询时声明以另一个用户的身份执行。这需要数据库支持身份模拟（Impersonation）或类似机制。

连接级别切换

在多租户场景中，数据墙DBW 可以根据请求中的租户标识动态切换数据库连接字符串，连接到对应租户的数据库实例或 schema。

注意事项

注意事项	说明
不是所有数据库都支持	数据库代理认证和身份模拟是数据库特定的功能，不在数据墙DBW 的控制范围内
配置复杂性	用户委派涉及身份提供程序、数据墙DBW、数据库三方的协调配置
安全边界	确保委派的身份信息在传输过程中不被篡改——JWT 令牌的签名提供了这层保障
缓存影响	启用 `set-session-context` 后，不同用户的查询结果不能共享缓存，需要考虑缓存策略

与标准 JWT 模式的对比

维度	标准 JWT	用户委派
数据库身份	统一服务账号	实际用户身份
权限执行点	数据墙DBW	数据墙DBW + 数据库双重
审计粒度	服务账号	用户级别
配置复杂度	低	中到高
适用规模	大多数场景	多租户、合规要求高的场景

使用建议

用户委派不是数据墙DBW 的默认或推荐路径。在以下情况下考虑启用：

数据墙DBW 的 RBAC 和行级策略无法满足你的数据隔离需求。
现有数据库已经建立了基于用户的安全体系（如 Row-Level Security），你不想在应用层重复建设。
合规要求数据库审计日志必须记录实际用户身份。

如果数据墙DBW 的实体权限 + 字段控制 + 数据库策略（@claims）已经能满足需求，标准 JWT 模式是更简单、更可维护的选择。

下一步

JWT 身份验证 — 标准的 JWT 验证模式。
行级安全 — 通过数据库策略过滤数据。
安全总览 — 回到安全模型总览。

用户委派身份验证 ​

概念 ​

适用场景 ​

实现方式 ​

会话上下文方式 ​

数据库代理认证 ​

连接级别切换 ​

注意事项 ​

与标准 JWT 模式的对比 ​

使用建议 ​

下一步 ​