权限架构设计指南：主流模型（RBAC/ABAC）对比与开源方案选型

所谓的权限，可以总结为 “谁（主体）对什么（客体）做什么（操作）” 的核心逻辑。权限领域其实包含了许多值得深入探讨的学问。接下来，我们将逐一介绍在这个领域中常听到的一些专业名词。

权限类型

DAC（自主访问控制）

自主访问控制（DAC, Discretionary Access Control），指资源的所有者自主决定谁能访问该资源，以及具体的访问权限。例如，文件的读/写权限由文件所有者自行分配。

• 典型案例：操作系统文件权限（如 Linux 的 user/group/other 权限）、早期数据库表权限。
• 优缺点：灵活但难以管理（权限分散，易出现权限滥用），适合小规模、信任度高的场景。

ACL（访问控制列表）

访问控制列表（ACL, Access Control List）为每个资源维护一个“可访问主体 + 操作”的列表。例如，“资源A的访问列表：用户1（读）、用户2（读写）”。

• 典型案例：ZooKeeper 内部对不同节点可以控制不同的读写权限，通过不同路径的 ZNode 来控制具体的权限范围。
• 优缺点：直观易实现，但权限粒度较粗（难以批量管理，资源量/用户量增长后列表会急剧膨胀）。

RBAC（基于角色的访问控制）

RBAC 的设计思路是目前业内使用率最高的一种。它通过“角色”作为中间层，将“用户 - 角色 - 权限”进行解耦（用户关联角色，角色关联权限）。

为什么不是简单的用户直接关联权限呢？假设一个用户有100个权限，后续如果再有新用户进入系统需要授权，这样的设计会导致授权流程异常复杂（需要逐一选择100个权限）。因此，将权限集预先关联到一个角色上，授权效率会大大提升。

RBAC 本身也有不同的演进版本，大致可以分为以下几个阶段：

• RBAC0（基础版）：用户与角色多对多关联，角色与权限多对多关联。

• RBAC1（角色继承）：支持角色间的父子继承关系（例如，“管理员”角色可以继承“操作员”角色的所有权限）。

• RBAC2（约束控制）：增加角色互斥（如“出纳”和“会计”不能由同一人担任）、基数约束（如“管理员角色最多10人”）等规则。

• RBAC3（综合版）：RBAC1 与 RBAC2 的结合体。

• 典型案例：企业内部系统（OA、CRM）、云平台 IAM（如 AWS IAM 的角色权限）。

• 优缺点：兼顾了灵活性和可管理性，是目前最主流的权限模型，适合中大型系统。

ABAC（基于属性的权限控制）

基于属性的访问控制（ABAC, Attribute-Based Access Control）通过动态评估“主体属性（如用户部门、级别）、资源属性（如文件类型、创建时间）、环境属性（如登录 IP、时间）”来计算并决定权限。例如，“仅允许本部门用户在工作时间访问本部门数据”。

其大致的决策思路为：权限 = (主体属性 + 资源属性 + 环境属性) → 操作允许/拒绝。

• 典型案例：一些规则灵活的判断系统，例如：用户具备某个特定标签则放权；用户的年龄位于某个区间则放权等。
• 优缺点：灵活性极强（规则可动态调整），但设计复杂（需要定义大量属性和规则引擎），适合业务场景多变的系统。

数据权限模型（行/列）

所谓的数据权限，可以直接理解为通过定义业务数据的可见范围，来控制不同主体（如不同部门、不同租户）的数据查询域。

例如，假设是一个报表系统，不同部门的员工所看到的数据范围应该按照部门字段进行自动筛选和区分。

在了解这一业务背景后，技术实现上通常可以在数据访问层进行控制。例如，如果访问的是 MySQL，则可以通过 MyBatis 的拦截器（Interceptor）来动态添加查询条件；如果访问的是 Elasticsearch，则可以在 RestHighLevelClient 内部做一层查询参数的注入。数据权限通常在 B 端（企业级）场景中使用较多。

自研 vs 开源

权限模型类型繁多。如果你的业务场景需要快速落地一套功能丰富且强大的权限系统，其底层设计必然会涉及一系列繁琐的配置与计算。

如果你的团队拥有充足的人力和时间资源，当然可以尝试从零开始设计用户表、角色表等来实现一套自研系统，但开发周期可能会比较长。

如果你对开源社区有所了解，不难发现，在权限与认证这个体系内，业内早已有许多成熟且可用的产品，例如 Keycloak、Casbin、Authing 等。基于这些开源产品进行二次开发，效率往往会提升很多（当然，前提是需要提前吃透它们）。

下面简单介绍这几款开源产品的特征，网上详细文档很多，这里只突出重点。

Keycloak

这是一款功能非常强大的企业级 IAM 产品，支持单点登录（SSO）、身份认证、用户联合等多种能力。社区活跃度高，但学习曲线相对陡峭，需要投入一定耐心。

Casbin

Casbin 是一个强大高效的开源访问控制库，支持多种访问控制模型，用于在应用全局执行授权决策。相对于 Keycloak，Casbin 的设计更为轻量和小巧，它非常适合实现 RBAC、ABAC 这类权限控制场景。但是，Casbin 在统一身份认证（Authentication）方面的能力相对一般。

Authing

Authing 在功能的强大性和灵活性上做了许多封装。它支持各种常见的认证协议，如 OAuth、JWT、LDAP 等。在权限模型方面，Authing 能够支持 RBAC、ABAC 等常见模型，同时提供了非常丰富的技术文档与多语言 SDK，整体能力很强大。但它的缺点也很明显：它是商业产品，需要付费。

小结

最后做个总结：如果你需要进行权限架构设计，不妨先了解常用的权限模型：RBAC、ABAC、ACL、DAC、数据权限等。

如果权限模型相对简单，业务场景并不复杂，那么自研一套系统也是可行的。但是，如果你面临的场景涉及到多租户统一登录、跨组织授权、多组织兼岗等复杂需求时，不妨去研究一下开源产品是如何设计其整个模型体系的。

在下一节中，我们将深入底层设计细节，和大家一起探讨面对复杂授权场景时，如果选择自研，需要注意哪些关键事项。

如果你在技术选型或架构设计上有更多想法，欢迎到 云栈社区 与更多开发者交流探讨。