Apache Calcite基于角色的认证授权实现方案咨询

核心结论 #

Apache Calcite本身并未内置完整的认证授权模块，它作为SQL解析、优化与执行引擎，权限控制属于需要上层扩展的能力，所以你找不到官方文档参考是正常情况，并非搜索问题。

推荐的底层扩展实现方案 #

以下方案可实现底层权限控制，让Avatica JDBC连接复用同一授权流程，替代多角色多服务器的低效方案：

1. 扩展Schema/Table接口实现权限拦截 #

这是最直接的底层扩展方式，通过自定义Schema和Table，在元数据访问阶段校验权限：

• 自定义Schema实现，重写getSubSchema、getTable方法，在返回子Schema或表之前，校验当前用户角色是否具备访问权限，无权限则抛出AccessDeniedException或返回null
• 针对列级权限，自定义Table实现，重写getRowType方法，根据用户角色过滤掉无权限的列；或者在scan方法中直接忽略无权限列的数据
• 关键：将用户角色信息传递到Calcite上下文——Avatica连接时可将用户/角色信息放入JDBC连接属性，在创建CalciteConnection时提取并存储（比如通过CalciteConnection.getConfig()或自定义上下文对象）

示例代码片段：

public class SecuredSchema extends AbstractSchema {
    private final String currentUser;
    private final Map<String, Set<String>> rolePermissions;

    public SecuredSchema(String currentUser, Map<String, Set<String>> rolePermissions) {
        this.currentUser = currentUser;
        this.rolePermissions = rolePermissions;
    }

    @Override
    protected Table getTable(String name) {
        String requiredPermission = "table:" + this.getName() + "." + name;
        if (!hasPermission(currentUser, requiredPermission)) {
            throw new AccessDeniedException("No access to table: " + this.getName() + "." + name);
        }
        // 返回实际的Table实现
        return super.getTable(name);
    }

    private boolean hasPermission(String user, String permission) {
        // 从rolePermissions中校验用户角色对应的权限
        Set<String> userRoles = getRolesForUser(user);
        for (String role : userRoles) {
            if (rolePermissions.getOrDefault(role, Collections.emptySet()).contains(permission)) {
                return true;
            }
        }
        return false;
    }

    private Set<String> getRolesForUser(String user) {
        // 从用户-角色映射中获取当前用户角色
        return Collections.emptySet();
    }
}

2. 利用Planner规则在逻辑计划阶段校验 #

在SQL解析后的逻辑计划生成阶段，添加自定义优化规则，遍历计划中的表/列节点进行权限校验：

• 自定义RelOptRule，在规则匹配时检查当前用户对计划中涉及的Schema/Table/Column是否有权限
• 通过RelOptCluster.getContext()获取存储的用户角色信息，无权限则抛出异常，终止计划优化
• 这种方式能拦截所有通过SQL提交的访问请求，避免元数据层面的绕过

3. 集成Avatica认证扩展，打通用户上下文 #

Avatica支持自定义认证逻辑，可先在网关层完成身份认证，再将用户信息传递给后端Calcite：

• 实现Avatica的Authenticator接口，在authenticate方法中校验用户凭证（比如用户名密码、Token），获取用户角色
• 自定义AvaticaHandler，在处理JDBC请求时，将用户角色信息注入到Calcite连接的上下文（比如通过ThreadLocal或Connection属性）
• 这样所有通过Avatica连接的请求都会自动带上用户上下文，Calcite端的权限逻辑可直接复用

方案优势对比 #

相对于你当前的“多角色多模型多服务器”方案，上述扩展方式具备以下优势：

• 无需维护多个Calcite模型和Avatica实例，扩展性强
• 权限逻辑集中管理，便于统一更新和审计
• 所有Avatica JDBC连接复用同一授权流程，无需客户端适配

列级权限扩展补充 #

如果需要实现列级权限，除了在Table的getRowType中过滤列，还可以：

• 自定义EnumerableTable，在scan方法中生成只包含有权限列的结果集
• 利用Calcite的Project规则，自动添加投影节点过滤无权限列

注意事项 #

• 确保权限校验覆盖所有入口：包括SQL查询、直接调用Schema API等，避免出现权限绕过漏洞
• 异常处理要符合SQL标准，返回清晰的权限错误信息（比如SQLState 42501：权限不足）
• 可缓存角色-权限映射关系，减少每次查询的权限校验开销，提升性能

内容的提问来源于stack exchange，提问作者SailingSRJ