玩转 Java 权限体系 第一篇从 ACL 到 RBAC、ABAC、ReBAC——权限模型到底在解决什么问题Java 圈里聊权限开口基本都是 Spring Security、Shiro、Sa-Token。但这三个东西解决的是同一层问题吗其实不是。它们更像执行器而真正决定你系统会不会越权、能不能审计、要不要重写一遍的是它们背后那套访问控制模型。笔者的第一个真实教训来得很早某天产品加了一句部门经理也能看本部门的数据于是PreAuthorize(hasRole(MANAGER))后面开始长出一堆if (deptId user.deptId)半年后没人说得清哪个接口是完整的权限判断。这就是典型的模型没选对框架只能拿来打补丁。这一篇不谈代码怎么写只把 ACL / DAC / MAC / RBAC / ABAC / ReBAC 这条演进线讲清楚每个模型的判定式是什么、它在什么场景会撑不住、以及这些模型在 Java 生态里分别落在哪一层。文末会给出笔者自己的选型判断。1. 先把三个词分开认证、授权、访问控制模型混用这三个词是绝大多数权限讨论吵不起来的原因。NIST 在 SP 800-162 里划得很干净认证是验证主体确实被授权使用它拿出来的那个标识而授权是对一次具体请求作出允许或拒绝的决定两者不是一回事。原文说得很直白——认证不等于访问控制或授权。来源认证 Authentication → 你是谁登录、token、Passkey、mTLS 授权 Authorization → 这一次请求能不能放行permit / deny 访问控制模型 AC Model → 能不能这件事用什么数据结构去表达和推理简单理解模型是数据模型的选型框架是这套判定式的执行位置。Spring Security 的过滤器链、Shiro 的Subject、Sa-Token 的StpUtil都是执行位置它们并不强制你用哪种模型。顺着这个划分SP 800-162 还给出了一组后来被整个行业包括零信任标准沿用的角色词组件全称干什么PEPPolicy Enforcement Point拦截请求、执行 PDP 的结论PDPPolicy Decision Point计算决策“评估适用的策略并给出结论”PIPPolicy Information Point提供决策所需的属性数据PAPPolicy Administration Point写策略、测策略、调策略的后台Context Handler—把上面几方的调用顺序编排起来来源这套词很重要因为第四、第五篇里所有网关鉴权“授权中台”把策略搬出应用的讨论本质都是在问同一件事你的 PEP 和 PDP 分别坐在哪里。2. 演进线从文件谁能读写到每次请求重新判断这条线不是编年史堆料每一步都在补上一步的表达能力缺口。1960s–70s 1992 / 1996 2004 / 2013 2013 / 2014 2019 2020 DAC · MAC → RBAC 模型 → ANSI INCITS 359 → XACML 3.0 → Zanzibar → 零信任 NIST DoD 场景 角色做中间层 2004 批准 属性四分类 关系元组 SP 800-207 术语出自 权限挂角色 2012 修订 userset 规则 2020-08 TCSEC SP 800-162 ABAC2014-01几个关键锚点都能核对时间事件出处1960s–1970sDAC / MAC 概念出现在美国国防部应用术语在 TCSEC“Orange Book”中被定义NIST SP 800-1621973机密性模型 Bell-LaPadula 的原始载体是 MITRE 技术报告 MTR-2547其 Volume II 于 1996 年被期刊重刊DOI1975 / 1977Biba 完整性模型年份存在分歧工程文档常写 1975学术引用多为 1977 的 MITRE 报告原始报告本次未取到Casbin 文档1992NIST 提出通用 RBAC 模型三条规则角色指派、角色授权、事务授权核心特征是所有访问都经由角色NIST RBAC FAQ1996RBAC 四层级模型RBAC0–RBAC3经典论文IEEE Computer29(2): 38-47DOI2004-02-11NIST RBAC 模型成为美国国家标准ANSI/INCITS 359-2004NIST 项目页2012-05-29该标准修订为INCITS 359-2012同上2013-01-22XACML 3.0成为 OASIS Standard2.0 是 2005-02-011.0 是 2003-02-18OASIS2014-01NIST SP 800-162《ABAC 定义与考量》发布Final——注意中文资料里的2018 年多为转载时间NIST2019GoogleZanzibar论文USENIX ATC 19标题为Google’s Consistent, Global Authorization SystemUSENIX PDF2020-08NIST SP 800-207《Zero Trust Architecture》发布NIST这里有个容易被忽略但很有说服力的Java 本地注脚JVM 自己就有一套代码级授权java.security.Policy/ Security Manager从 Java 1.0 就在而它正在被官方拆除——JEP 411Status: Closed/DeliveredRelease 17把它标记为待移除JEP 486Release 24永久禁用它。JEP 411 的原话相当直白它多年来不是保护客户端 Java 代码的主要手段也很少被用于服务端维护成本却很高并且官方明确不提供替代品。JVM 内置授权Policy / Security Manager → 退场Java 17 弃用Java 24 永久禁用 Java 侧权限模型剩下的三条落点应用框架Spring Security / Shiro / Sa-Token 容器规范Jakarta Authorization即 JACC 外置授权服务Casbin / OpenFGA / Cerbos / Keycloak注JEP 编号、日期与状态均为 OpenJDK 官方页面可核对的事实“最终收敛到三条路是笔者归纳不是官方表述。JACC 的定位是为授权模块定义一个低层 SPI让容器把授权决策外包给策略模块”这一点与 PEP/PDP 分离是同一个思想。来源3. 五个模型的判定式一张表看懂差异把每个模型压缩成一行判定式差异立刻就出来了。模型判定式本文归纳非原文公式权限存在哪撑不住的场景DACdecide(subject, object, ACL[object] ∪ 属主自由裁量)对象上属主可改对象海量时无法治理谁能改 ACL本身没人管MACpermit ⇔ 对象密级标签被主体许可级别覆盖用户不能改标签label业务系统没有密级这种东西变更要走中央授权RBACpermit ⇔ ∃r ∈ 会话中激活的角色 : (r, op, obj) ∈ PAuser→role→permission 三张关系表约束涉及对象属性/时间/位置时只能把约束编进角色 → 角色爆炸ABACpermit/deny ⇔ policy(attrs(subject), attrs(object), attrs(action), attrs(environment))策略布尔规则集决策前无法回答谁能看这条数据审计昂贵ReBACCheck(user#relationobject)由关系元组 userset 重写规则展开关系元组图属性类条件需额外机制可读性依赖图遍历与缓存Q1ACL 和 RBAC 到底差在哪一步差在中间层。ACL 把谁能对这个对象干什么直接写在对象上Windows 文件权限、Linux 的 owner/group/other、PostgreSQL 的GRANT、K8s 的 RoleBinding 都是这一族。它的致命问题不是不安全而是没法批量管理一百万条文档各自带一张 ACL你无法回答这个新员工多了哪些权限。RBAC 的关键设计是引入角色作为唯一的授权通道。NIST FAQ 里那句a key feature of this model is that all access is through roles就是这个意思——权限不许直接挂到用户身上。来源顺带把常被混用的两个词分清用户组是用户的集合角色是权限的集合组不携带权限角色携带。RBAC 的标准结构里还有会话中激活角色的子集这一层Core RBAC 明确包含 role activation这也是 RBAC 比权限集合打平多出来的能力。NIST RBAC 参考模型由四个组件构成前两个是主体后两个才是约束组件管什么Core RBAC最小元素集与关系用户-角色指派、权限-角色指派、会话内角色激活。标准明确Core 在任何 RBAC 系统里都是必需的其余组件互相独立Hierarchical RBAC角色继承引入角色的授权用户集 / 授权权限集Static SoD静态职责分离约束用户到角色的指派比如同一人不能同时拥有出纳和会计Dynamic SoD动态职责分离约束同一次会话里被激活的角色可以同时拥有但不能同时启用来源这张表后面会用到标准里的约束只有 SoD 这两种它们只管角色完全不涉及对象属性、行范围、时间窗、审批关系。Q2ABAC 的四类属性是哪四类先给一句最省事的对照RBAC 判定用 1 个属性角色 → 有 NIST 标准INCITS 359 ABAC 判定用 4 类属性主体/对象/操作/环境 → 标准载体是 SP 800-162 XACML这里必须说清一个措辞分歧否则容易被同行挑刺四类属性的分类法其实来自 XACMLsubject / (resource) object / action / environment conditionsOASIS 规范里对应四个属性类别 URI而 SP 800-162 正文用的是subject / object / environment / operations(activities)。两边语义一致命名不同。来源1 来源2ABAC 的定义原文值得抄进设计文档主体对对象执行操作的请求是否被批准取决于主体被赋予的属性、对象被赋予的属性、环境条件以及一组以这些属性和条件表达的策略。SP 800-162 里最有价值的一句话是它没有把 ABAC 说成 RBAC 的替代品而是反过来定位ACL 和 RBAC 在某种意义上是 ABAC 的特例ACL 工作在身份这个属性上RBAC 工作在角色这个属性上。与 ABAC 的关键差异在于用复杂布尔规则集表达策略这个概念。来源同一节还点了另一处要害ACL/RBAC 也能达成 ABAC 的目标但要证明访问控制需求被满足会变得困难而昂贵而且一旦需求变化很难找出所有需要跟着改的实现位置。这句话就是权限系统重构的立项理由。Q3ReBAC 是不是新东西思想不新工程化是新的。ReBAC这个缩写不是 Zanzibar 论文的用词——论文自称是一个存储与评估访问控制列表ACL的全球系统把 Zanzibar 归纳为 ReBAC 是后续开源实现OpenFGA、SpiceDB做的事。来源它的数据模型只有两样东西一张元组和一组展开规则元组⟨object⟩#relation⟨user⟩ object namespace:object-id user user-id | ⟨object⟩#relationuserset 展开this直接| computed userset同对象内其他关系| tuple to userset沿父对象继承 算子union / intersection / exclusion论文给的两个数字解释了为什么值得学扩展到数万亿张 ACL、每秒数百万次授权请求三年生产运行中维持95 分位延迟低于 10 毫秒、可用性高于 99.999%服务对象包括 Calendar、Drive、Photos、YouTube。一致性靠zookie协议保证 ACL 更新与内容更新之间的因果顺序。来源用 DSL 写出来是这样OpenFGA 的语法viewer from parent_folder就是 tuple-to-usersetdefine viewer: [user, domain#member] or writer or viewer from parent_folder来源ReBAC 真正的独特点是对象与对象之间的关系文件夹→文档是一等公民。RBAC 的对象只是被 permission 命中继承要靠建模ReBAC 里继承是一次查询。至于部门即父对象这类组织关系天然就该存成元组而不是存成角色。工业实现的取舍也可以核对OpenFGA 明确其 JSON 语法closely tracks the original Zanzibar paper 的语法DSL 只是编译到 JSON 的语法糖CNCF 项目2022-09-14 入选2025-10-28 升为 Incubating来源SpiceDB 则在与 Zanzibar 的官方对照页里承认简化了存储与一致性Zanzibar 只支持 SpannerSpiceDB 支持多种 datastorezookie 换成了更简单的读写一致性选项来源。纯关系模型表达不了工作时间以外不许导出这类属性条件所以两家各补了一个口子SpiceDB 叫Caveats可命名、附着到关系上的布尔表达式官方称用于建模ABAC 风格的决策OpenFGA 叫Conditions用 Google CEL 写表达式。来源1 来源24. 三个说法很流行但其实不准确的问题这一节是笔者觉得最值得单独拎出来的部分——它们直接决定选型讨论会不会跑偏。Q1角色爆炸role explosion为什么会发生这不是坊间吐槽SP 800-162 有原话RBAC 不容易支持多因子决策例如依赖物理位置、依赖专项培训的场景RBAC 的角色指派往往基于较静态的组织位置而要在这类场景里实现访问控制决策就需要创建大量临时性、成员极少的角色——这正是通常所说的角色爆炸。来源因果链是这样的角色只能挂在用户的静态组织位置上 ↓ 约束一旦涉及 对象属性 / 部门 / 时段 / 审批关系 只能把约束编码进角色本身 ↓ 角色数量 ≈ 角色 × 部门 × 数据范围 × 时段 ↓ 这些 ad hoc 角色成员极少、语义重复、无法向审计解释为什么有这个角色工业界两个低成本补丁都在这条链上打洞Casbin 的RBAC with Domains给角色加一个域/租户维度和RBAC with Conditions在规则上直接挂条件参数。来源1 来源2Q2RBAC 表达不了只看本部门数据这句话对不对过于绝对但工程语义上算半对。NIST FAQ 里专门有一节回应这类批评对方举的例子是病历权限建立在医生与病人的具体关系上官方回答有两个重点1992 年模型本身就是only if而非if的授权语义——访问只有在满足角色要求时才授予正是这样才允许在访问时追加额外约束但标准没有规定这些额外约束该怎么实现它的设计是让设计者自行添加约束来处理这些关系模型本身不会妨碍你加。来源再把第 3 节那张四组件表拿出来标准层面的约束组件只有 Static SoD 和 Dynamic SoD管的全是谁能同时/同时激活哪些角色。所以准确的表述是纯 RBACCore Hierarchical SoD无法简洁地表达行级/对象级约束硬要表达就要付出角色数量和维护成本的代价。中文社区那句RBAC 只能到菜单按钮级数据权限必须靠 ABAC/ReBAC——这是工程经验的概括不是任何标准的表述写方案时可以引但不要挂 NIST 的名义。Q3ABAC 是不是就更可控了ABAC 的代价在另一个维度决策前审计。SP 800-162 §3.1.2.3 明确要求企业需要事前审计before the fact audit能力——在请求发生之前就知道某人对哪些对象有权限、某对象被哪些人访问。原文紧接着写ABAC 系统可能不太适合高效地进行这类审计因为要算出谁能访问这条数据需要巨大的数据检索与计算量甚至可能要拿企业里每一个已知主体去模拟一次访问请求。来源同文档另一处还提醒采用分布式访问控制架构时审计访问决策与事件的能力会受到影响。结论句原文这句很适合放进立项邮件ABAC 系统更复杂因此比更简单的访问控制系统实现和维护成本更高。但同一份文档也承认ABAC 能实现既有的基于角色的策略并支持从角色化策略向更细粒度策略的迁移。NIST 自己在 RBAC 项目页上对 ABAC 的概括更口语“ABAC 是一种基于规则的访问控制方法容易搭起来但难以管理。”5. 零信任到底改变了什么、没改变什么很多方案书把零信任当成权限模型的新一代其实不是。NIST SP 800-2072020-08Final的定义是一套不断演进的网络安全范式把防御从静态的、基于网络边界的位置转向聚焦用户、资产和资源其规范性定义是在把网络视为已被攻破的前提下最小化每次请求执行精确、最小权限访问决策时的不确定性。来源七条原则里与权限框架直接相关的三条② 所有通信一律受保护与网络位置无关 ③ 对单个资源的访问按每次会话授予 —— 进了 A 资源不等于能进 B 资源 ⑥ 所有认证与授权都是动态的、访问前严格执行交易过程中持续监控可能重新认证与重新授权而且它把 PDP 又拆了一层Policy EnginePE做最终裁决“授予、拒绝或撤销”Policy AdministratorPA执行决策控制面与数据面分离。改变了什么维度传统权限框架零信任之后信任来源网络位置 / 内网身份明确不因物理或网络位置、不因资产归属而给隐含信任判定粒度一次登录长期可信per-session、per-request持续重评估PEP/PDP 位置应用外围一层拦截器往资源侧搬成为独立的、要有实时上下文和可撤销能力的决策服务决策输入角色角色 设备态势 行为 环境属性结论种类allow / denyallow / deny /revoke没改变什么判定式本身仍是policy(attributes) → permit/deny也就是 ABAC 的语义PEP/PDP 这套词汇也不是它发明的——SP 800-207 在给出 PDP/PEP 模型的段落有脚注 3明确写着概念部分定义于 OASIS XACML 2.0。微分段也不等于零信任NIST 有意把它描述成 ZTA 的一种功能能力“这些定义仍在以某种方式相对边界来定义自己比如微分段或微边界”。还有一条常被忽略的适用边界七条原则针对组织内部或与伙伴组织协作完成的工作不适用于匿名公开或面向消费者的业务流程。做 C 端产品时把 ZT 原则原样搬过来会写出很重的方案。一句话总结笔者观点零信任是部署与信任模型不是新的访问控制模型。它给权限框架出的真正考题是——你的授权决策必须能实时拿到上下文并且能被撤销。6. 这些模型在 Java 生态里分别落在哪一层把前面的谱系映射到实际选型上一张表基本够用模型Java 侧的典型落点客观状态ACL / DAC文件与数据库对象权限、Spring Security ACL 模块对象级 ACE 存 DB、Shiro 的 Wildcard Permissionsprinter:delete式通配串小众但没死ACL 模块仍是官方文档里的一章RBAC几乎所有后台的角色-菜单-按钮三件套、Keycloak 的 Role/Group Policy、Casbin 的p, sub, obj, act RBAC matcher事实上的默认起点ABACKeycloak Authorization ServicesRole/Group/User/Client/Time/Regex/JS 策略并对接 UMA、CerbosResource/Principal/Role/Scoped Policy Conditions Derived Roles、OPA/RegoCNCFGraduated2021-01-29、AWS Cedar策略语言化、可测试化ReBACOpenFGACNCF Incubating、SpiceDBZanzibar 血统元组存储数据权限行级PostgreSQL RLS9.5 引入、Oracle VPD、SQL Server RLS2016 引入应用层 MyBatis/JPA 拦截器DB 层兜底 应用层拼接并存数据权限列级PostgreSQL 列级GRANT、Oracle “Grants of Privileges on Columns”原生支持但很少被应用用上混合Casbinacl/rbac/abac/orbac/blp/biba 等一整套可运行配置Java 是官方支持语言。注2026-02 已进入 Apache 孵化器官网 casbin.org 现 301 至 casbin.apache.org单库覆盖多模型代价是模型语法要自己维护两个技术细节值得现在就记住第四篇会正面用到RLS 是会被绕过的。PostgreSQL 官方文档写明superuser 与带BYPASSRLS属性的角色总是绕过行级安全表 owner 默认也绕过可用ALTER TABLE ... FORCE ROW LEVEL SECURITY让它受约束唯一键/主键/外键这类引用完整性检查总是绕过行安全。这意味着用了 RLS 就安全是错的——应用账号一旦是表 owner策略形同虚设。来源Oracle VPD 的机制是改 SQL而不是过滤结果。官方定义是创建控制数据库行级与列级访问的安全策略做法是给命中的表/视图/同义词上的 SQL动态追加一个 WHERE 子句实现入口是DBMS_RLS包配合 application contexts。来源至于策略语言本身的语义有一个容易记错但很关键的点Cedar 是默认拒绝且显式 forbid 优先。官方规则原文是至少一条匹配策略为 Allow 且恰好零条为 Deny 时整体才是 Allow并明确两条原则——空策略集的默认结果是implicit deny任一策略给出 Deny显式 Deny 总是覆盖其它策略的 Allow。来源 同一页还顺手回答了这算 RBAC 还是 ABAC只有 scope 没有附加条件的策略可以作为 RBAC 方案的一部分带条件的策略可以作为 ABAC 方案的一部分。注Cerbos不在 CNCF 项目列表内官方项目页 404把它写成CNCF 项目是常见错误。7. 标准之外token 这一层现在走到哪了第一篇不该以代码结尾但应该给一条时间是否可信的核对结论。截至 2026-09-29事项状态出处OAuth 2.1仍不是 RFC。当前修订draft-ietf-oauth-v2-1-16Last updated2026-09-02IESG 状态仅 “I-D Exists”未进入 Last Calldatatracker草案里已经确定的口径PKCE变为必需Implicit、资源所有者密码凭证等不再被规定redirect URI严格字符串匹配目标是合并 RFC 8252 / 9700 / 浏览器应用草案并移除 RFC 9700 中被认定不安全的特性草案正文OAuth 安全 BCPRFC 9700BCP 2402025-01Updates 6749/6750/6819RFC EditorDPoPsender-constrained token 主路RFC 94492023-09。⚠️ 不是 9440——RFC 9440 是Client-Cert HTTP Header FieldInformational解决TLS 在反向代理终结、Java 应用拿不到客户端证书RFC EditormTLS 绑定 access tokenRFC 87052020-02比 OAuth 2.1 时代早得多不是新事物RFC EditorJWT 形态的 access tokenRFC 90682021-10RFC EditorOIDC Core 1.0OpenID Foundation 侧为Final含 errata set 2。⚠️ OIDC 已是 ISO/IEC 标准一说本次未核实规范正文只引用 ISO/IEC 29115别在方案里写规范这里存在一个对权限框架很锋利的张力笔者分析非标准表述OAuth 2.1 把 sender-constrained token 留在了扩展DPoP / mTLS而不是核心规范里因此 Java 框架默认发出的是不绑定的 bearer token而零信任要求可撤销、持续重评估。这两件事不靠给框架加拦截器解决只能靠短 TTL 撤销通道或把决策外置到 PDP。第三、第五篇会分别处理这两条路。最后总结先选模型再选框架。Spring Security / Shiro / Sa-Token 都是执行器它们不阻止你写出一个 ACL 系统也不保证你能写出可审计的 ABAC 系统。RBAC 是默认起点而不是终点。它带来的确定性权限只经由角色、角色只经由指派非常有价值一旦约束涉及对象属性和环境你要么走域/条件补丁要么接受角色爆炸。RBAC 表达不了数据权限这句话别原样引用。标准的态度是允许你加约束但不告诉你怎么加——真正的问题不是不能表达是表达得不可审计。ABAC 换来的细粒度要用审计成本付。上线前先确认你能回答谁能看这条数据而不是只确认这次请求被拒了。ReBAC 值得学的不是名字是关系是一等公民。组织树、文件夹、共享链、租户层级本来就该是数据而不是角色。零信任没有替代任何模型。它替代的是一次登录长期可信并把问题从权限判断放在哪变成决策能不能实时、能不能撤销。对后端/架构岗笔者个人更关注三件事权限点的唯一权威存储在哪里、需求变更时改动面能不能被枚举、以及审计能不能在事故前而不是事故后回答谁有权。下一篇测评篇会把镜头拉回到三个 Java 框架本身过滤器链、Subject、StpUtil三种架构到底在哪些地方不可互换。事实说明文中所有标准编号、发布日期、版本状态与引文均在 2026-09-29 逐条核对一手来源Biba 年份1975/1977与 ABAC四类属性措辞存在来源分歧已在正文标注DAC 的提出年份、TCSEC 确切编号、OIDC 的 ISO/IEC 状态未取到一手依据故正文未作断言。带笔者归纳/笔者观点标记的段落为分析而非标准表述。参考资料 致谢[1] NIST SP 800-162《Guide to Attribute Based Access Control (ABAC) Definition and Considerations》[2] NIST SP 800-162 发布页2014-01, Final[3] NIST RBAC 项目页标准沿革与文献清单[4] NIST RBAC FAQ四组件、RBAC0-3、约束与批评回应[5] NIST CSRC 术语表DAC MAC[6] NIST SP 800-207《Zero Trust Architecture》PDF2020-08[7] USENIX ATC 19Zanzibar — Google’s Consistent, Global Authorization System[8] OASIS XACML 3.0 Core Specification2013-01-22[9] Bell-LaPadula 原始报告重刊Journal of Computer Security, DOI 10.3233/JCS-1996-42-308 IEEE Computer 29(2):38-47 RBAC ModelsDOI 10.1109/2.485845[10] OpenJDK JEP 411弃用 Security Manager JEP 486永久禁用 Security Manager[11] Jakarta AuthorizationJACC规范页[12] Spring Security 参考文档ACL 模块 过滤器架构[13] Apache ShiroPermissions 与 News3.0.x 发版动态[14] Casbin 支持模型清单 RBAC with Domains RBAC with Conditions BLP Biba PBAC OrBAC[15] OpenFGAAuthorization Concepts Configuration Language Conceptsstore/tuple/model/Condition[16] CNCF 项目页OpenFGAIncubating, 2025-10-28 OPAGraduated, 2021-01-29[17] Authzed SpiceDB与 Zanzibar 的对照 Caveats[18] AWS Cedar 策略语言文档 Cedar Policy Syntaximplicit deny 与 forbid 优先[19] Cerbos 文档首页[20] OPA 文档首页 Data Filtering with OPA[21] PostgreSQL 文档Row Security Policies CREATE POLICY GRANT列级权限[22] Oracle Database 19c 安全指南Virtual Private Database[23] Microsoft SQL ServerRow-Level Security[24] IETF datatrackerOAuth 2.1 草案状态 draft-ietf-oauth-v2-1-16 正文[25] RFC 9700OAuth 安全 BCP RFC 9449DPoP RFC 9440Client-Cert 头 RFC 8705mTLS 与证书绑定 token RFC 9068JWT 形态 access token[26] OpenID Connect Core 1.0Final, errata set 2
玩转 Java 权限体系 第一篇从 ACL 到 RBAC、ABAC、ReBAC——权限模型到底在解决什么问题Java 圈里聊权限开口基本都是 Spring Security、Shiro、Sa-Token。但这三个东西解决的是同一层问题吗其实不是。它们更像执行器而真正决定你系统会不会越权、能不能审计、要不要重写一遍的是它们背后那套访问控制模型。笔者的第一个真实教训来得很早某天产品加了一句部门经理也能看本部门的数据于是PreAuthorize(hasRole(MANAGER))后面开始长出一堆if (deptId user.deptId)半年后没人说得清哪个接口是完整的权限判断。这就是典型的模型没选对框架只能拿来打补丁。这一篇不谈代码怎么写只把 ACL / DAC / MAC / RBAC / ABAC / ReBAC 这条演进线讲清楚每个模型的判定式是什么、它在什么场景会撑不住、以及这些模型在 Java 生态里分别落在哪一层。文末会给出笔者自己的选型判断。1. 先把三个词分开认证、授权、访问控制模型混用这三个词是绝大多数权限讨论吵不起来的原因。NIST 在 SP 800-162 里划得很干净认证是验证主体确实被授权使用它拿出来的那个标识而授权是对一次具体请求作出允许或拒绝的决定两者不是一回事。原文说得很直白——认证不等于访问控制或授权。来源认证 Authentication → 你是谁登录、token、Passkey、mTLS 授权 Authorization → 这一次请求能不能放行permit / deny 访问控制模型 AC Model → 能不能这件事用什么数据结构去表达和推理简单理解模型是数据模型的选型框架是这套判定式的执行位置。Spring Security 的过滤器链、Shiro 的Subject、Sa-Token 的StpUtil都是执行位置它们并不强制你用哪种模型。顺着这个划分SP 800-162 还给出了一组后来被整个行业包括零信任标准沿用的角色词组件全称干什么PEPPolicy Enforcement Point拦截请求、执行 PDP 的结论PDPPolicy Decision Point计算决策“评估适用的策略并给出结论”PIPPolicy Information Point提供决策所需的属性数据PAPPolicy Administration Point写策略、测策略、调策略的后台Context Handler—把上面几方的调用顺序编排起来来源这套词很重要因为第四、第五篇里所有网关鉴权“授权中台”把策略搬出应用的讨论本质都是在问同一件事你的 PEP 和 PDP 分别坐在哪里。2. 演进线从文件谁能读写到每次请求重新判断这条线不是编年史堆料每一步都在补上一步的表达能力缺口。1960s–70s 1992 / 1996 2004 / 2013 2013 / 2014 2019 2020 DAC · MAC → RBAC 模型 → ANSI INCITS 359 → XACML 3.0 → Zanzibar → 零信任 NIST DoD 场景 角色做中间层 2004 批准 属性四分类 关系元组 SP 800-207 术语出自 权限挂角色 2012 修订 userset 规则 2020-08 TCSEC SP 800-162 ABAC2014-01几个关键锚点都能核对时间事件出处1960s–1970sDAC / MAC 概念出现在美国国防部应用术语在 TCSEC“Orange Book”中被定义NIST SP 800-1621973机密性模型 Bell-LaPadula 的原始载体是 MITRE 技术报告 MTR-2547其 Volume II 于 1996 年被期刊重刊DOI1975 / 1977Biba 完整性模型年份存在分歧工程文档常写 1975学术引用多为 1977 的 MITRE 报告原始报告本次未取到Casbin 文档1992NIST 提出通用 RBAC 模型三条规则角色指派、角色授权、事务授权核心特征是所有访问都经由角色NIST RBAC FAQ1996RBAC 四层级模型RBAC0–RBAC3经典论文IEEE Computer29(2): 38-47DOI2004-02-11NIST RBAC 模型成为美国国家标准ANSI/INCITS 359-2004NIST 项目页2012-05-29该标准修订为INCITS 359-2012同上2013-01-22XACML 3.0成为 OASIS Standard2.0 是 2005-02-011.0 是 2003-02-18OASIS2014-01NIST SP 800-162《ABAC 定义与考量》发布Final——注意中文资料里的2018 年多为转载时间NIST2019GoogleZanzibar论文USENIX ATC 19标题为Google’s Consistent, Global Authorization SystemUSENIX PDF2020-08NIST SP 800-207《Zero Trust Architecture》发布NIST这里有个容易被忽略但很有说服力的Java 本地注脚JVM 自己就有一套代码级授权java.security.Policy/ Security Manager从 Java 1.0 就在而它正在被官方拆除——JEP 411Status: Closed/DeliveredRelease 17把它标记为待移除JEP 486Release 24永久禁用它。JEP 411 的原话相当直白它多年来不是保护客户端 Java 代码的主要手段也很少被用于服务端维护成本却很高并且官方明确不提供替代品。JVM 内置授权Policy / Security Manager → 退场Java 17 弃用Java 24 永久禁用 Java 侧权限模型剩下的三条落点应用框架Spring Security / Shiro / Sa-Token 容器规范Jakarta Authorization即 JACC 外置授权服务Casbin / OpenFGA / Cerbos / Keycloak注JEP 编号、日期与状态均为 OpenJDK 官方页面可核对的事实“最终收敛到三条路是笔者归纳不是官方表述。JACC 的定位是为授权模块定义一个低层 SPI让容器把授权决策外包给策略模块”这一点与 PEP/PDP 分离是同一个思想。来源3. 五个模型的判定式一张表看懂差异把每个模型压缩成一行判定式差异立刻就出来了。模型判定式本文归纳非原文公式权限存在哪撑不住的场景DACdecide(subject, object, ACL[object] ∪ 属主自由裁量)对象上属主可改对象海量时无法治理谁能改 ACL本身没人管MACpermit ⇔ 对象密级标签被主体许可级别覆盖用户不能改标签label业务系统没有密级这种东西变更要走中央授权RBACpermit ⇔ ∃r ∈ 会话中激活的角色 : (r, op, obj) ∈ PAuser→role→permission 三张关系表约束涉及对象属性/时间/位置时只能把约束编进角色 → 角色爆炸ABACpermit/deny ⇔ policy(attrs(subject), attrs(object), attrs(action), attrs(environment))策略布尔规则集决策前无法回答谁能看这条数据审计昂贵ReBACCheck(user#relationobject)由关系元组 userset 重写规则展开关系元组图属性类条件需额外机制可读性依赖图遍历与缓存Q1ACL 和 RBAC 到底差在哪一步差在中间层。ACL 把谁能对这个对象干什么直接写在对象上Windows 文件权限、Linux 的 owner/group/other、PostgreSQL 的GRANT、K8s 的 RoleBinding 都是这一族。它的致命问题不是不安全而是没法批量管理一百万条文档各自带一张 ACL你无法回答这个新员工多了哪些权限。RBAC 的关键设计是引入角色作为唯一的授权通道。NIST FAQ 里那句a key feature of this model is that all access is through roles就是这个意思——权限不许直接挂到用户身上。来源顺带把常被混用的两个词分清用户组是用户的集合角色是权限的集合组不携带权限角色携带。RBAC 的标准结构里还有会话中激活角色的子集这一层Core RBAC 明确包含 role activation这也是 RBAC 比权限集合打平多出来的能力。NIST RBAC 参考模型由四个组件构成前两个是主体后两个才是约束组件管什么Core RBAC最小元素集与关系用户-角色指派、权限-角色指派、会话内角色激活。标准明确Core 在任何 RBAC 系统里都是必需的其余组件互相独立Hierarchical RBAC角色继承引入角色的授权用户集 / 授权权限集Static SoD静态职责分离约束用户到角色的指派比如同一人不能同时拥有出纳和会计Dynamic SoD动态职责分离约束同一次会话里被激活的角色可以同时拥有但不能同时启用来源这张表后面会用到标准里的约束只有 SoD 这两种它们只管角色完全不涉及对象属性、行范围、时间窗、审批关系。Q2ABAC 的四类属性是哪四类先给一句最省事的对照RBAC 判定用 1 个属性角色 → 有 NIST 标准INCITS 359 ABAC 判定用 4 类属性主体/对象/操作/环境 → 标准载体是 SP 800-162 XACML这里必须说清一个措辞分歧否则容易被同行挑刺四类属性的分类法其实来自 XACMLsubject / (resource) object / action / environment conditionsOASIS 规范里对应四个属性类别 URI而 SP 800-162 正文用的是subject / object / environment / operations(activities)。两边语义一致命名不同。来源1 来源2ABAC 的定义原文值得抄进设计文档主体对对象执行操作的请求是否被批准取决于主体被赋予的属性、对象被赋予的属性、环境条件以及一组以这些属性和条件表达的策略。SP 800-162 里最有价值的一句话是它没有把 ABAC 说成 RBAC 的替代品而是反过来定位ACL 和 RBAC 在某种意义上是 ABAC 的特例ACL 工作在身份这个属性上RBAC 工作在角色这个属性上。与 ABAC 的关键差异在于用复杂布尔规则集表达策略这个概念。来源同一节还点了另一处要害ACL/RBAC 也能达成 ABAC 的目标但要证明访问控制需求被满足会变得困难而昂贵而且一旦需求变化很难找出所有需要跟着改的实现位置。这句话就是权限系统重构的立项理由。Q3ReBAC 是不是新东西思想不新工程化是新的。ReBAC这个缩写不是 Zanzibar 论文的用词——论文自称是一个存储与评估访问控制列表ACL的全球系统把 Zanzibar 归纳为 ReBAC 是后续开源实现OpenFGA、SpiceDB做的事。来源它的数据模型只有两样东西一张元组和一组展开规则元组⟨object⟩#relation⟨user⟩ object namespace:object-id user user-id | ⟨object⟩#relationuserset 展开this直接| computed userset同对象内其他关系| tuple to userset沿父对象继承 算子union / intersection / exclusion论文给的两个数字解释了为什么值得学扩展到数万亿张 ACL、每秒数百万次授权请求三年生产运行中维持95 分位延迟低于 10 毫秒、可用性高于 99.999%服务对象包括 Calendar、Drive、Photos、YouTube。一致性靠zookie协议保证 ACL 更新与内容更新之间的因果顺序。来源用 DSL 写出来是这样OpenFGA 的语法viewer from parent_folder就是 tuple-to-usersetdefine viewer: [user, domain#member] or writer or viewer from parent_folder来源ReBAC 真正的独特点是对象与对象之间的关系文件夹→文档是一等公民。RBAC 的对象只是被 permission 命中继承要靠建模ReBAC 里继承是一次查询。至于部门即父对象这类组织关系天然就该存成元组而不是存成角色。工业实现的取舍也可以核对OpenFGA 明确其 JSON 语法closely tracks the original Zanzibar paper 的语法DSL 只是编译到 JSON 的语法糖CNCF 项目2022-09-14 入选2025-10-28 升为 Incubating来源SpiceDB 则在与 Zanzibar 的官方对照页里承认简化了存储与一致性Zanzibar 只支持 SpannerSpiceDB 支持多种 datastorezookie 换成了更简单的读写一致性选项来源。纯关系模型表达不了工作时间以外不许导出这类属性条件所以两家各补了一个口子SpiceDB 叫Caveats可命名、附着到关系上的布尔表达式官方称用于建模ABAC 风格的决策OpenFGA 叫Conditions用 Google CEL 写表达式。来源1 来源24. 三个说法很流行但其实不准确的问题这一节是笔者觉得最值得单独拎出来的部分——它们直接决定选型讨论会不会跑偏。Q1角色爆炸role explosion为什么会发生这不是坊间吐槽SP 800-162 有原话RBAC 不容易支持多因子决策例如依赖物理位置、依赖专项培训的场景RBAC 的角色指派往往基于较静态的组织位置而要在这类场景里实现访问控制决策就需要创建大量临时性、成员极少的角色——这正是通常所说的角色爆炸。来源因果链是这样的角色只能挂在用户的静态组织位置上 ↓ 约束一旦涉及 对象属性 / 部门 / 时段 / 审批关系 只能把约束编码进角色本身 ↓ 角色数量 ≈ 角色 × 部门 × 数据范围 × 时段 ↓ 这些 ad hoc 角色成员极少、语义重复、无法向审计解释为什么有这个角色工业界两个低成本补丁都在这条链上打洞Casbin 的RBAC with Domains给角色加一个域/租户维度和RBAC with Conditions在规则上直接挂条件参数。来源1 来源2Q2RBAC 表达不了只看本部门数据这句话对不对过于绝对但工程语义上算半对。NIST FAQ 里专门有一节回应这类批评对方举的例子是病历权限建立在医生与病人的具体关系上官方回答有两个重点1992 年模型本身就是only if而非if的授权语义——访问只有在满足角色要求时才授予正是这样才允许在访问时追加额外约束但标准没有规定这些额外约束该怎么实现它的设计是让设计者自行添加约束来处理这些关系模型本身不会妨碍你加。来源再把第 3 节那张四组件表拿出来标准层面的约束组件只有 Static SoD 和 Dynamic SoD管的全是谁能同时/同时激活哪些角色。所以准确的表述是纯 RBACCore Hierarchical SoD无法简洁地表达行级/对象级约束硬要表达就要付出角色数量和维护成本的代价。中文社区那句RBAC 只能到菜单按钮级数据权限必须靠 ABAC/ReBAC——这是工程经验的概括不是任何标准的表述写方案时可以引但不要挂 NIST 的名义。Q3ABAC 是不是就更可控了ABAC 的代价在另一个维度决策前审计。SP 800-162 §3.1.2.3 明确要求企业需要事前审计before the fact audit能力——在请求发生之前就知道某人对哪些对象有权限、某对象被哪些人访问。原文紧接着写ABAC 系统可能不太适合高效地进行这类审计因为要算出谁能访问这条数据需要巨大的数据检索与计算量甚至可能要拿企业里每一个已知主体去模拟一次访问请求。来源同文档另一处还提醒采用分布式访问控制架构时审计访问决策与事件的能力会受到影响。结论句原文这句很适合放进立项邮件ABAC 系统更复杂因此比更简单的访问控制系统实现和维护成本更高。但同一份文档也承认ABAC 能实现既有的基于角色的策略并支持从角色化策略向更细粒度策略的迁移。NIST 自己在 RBAC 项目页上对 ABAC 的概括更口语“ABAC 是一种基于规则的访问控制方法容易搭起来但难以管理。”5. 零信任到底改变了什么、没改变什么很多方案书把零信任当成权限模型的新一代其实不是。NIST SP 800-2072020-08Final的定义是一套不断演进的网络安全范式把防御从静态的、基于网络边界的位置转向聚焦用户、资产和资源其规范性定义是在把网络视为已被攻破的前提下最小化每次请求执行精确、最小权限访问决策时的不确定性。来源七条原则里与权限框架直接相关的三条② 所有通信一律受保护与网络位置无关 ③ 对单个资源的访问按每次会话授予 —— 进了 A 资源不等于能进 B 资源 ⑥ 所有认证与授权都是动态的、访问前严格执行交易过程中持续监控可能重新认证与重新授权而且它把 PDP 又拆了一层Policy EnginePE做最终裁决“授予、拒绝或撤销”Policy AdministratorPA执行决策控制面与数据面分离。改变了什么维度传统权限框架零信任之后信任来源网络位置 / 内网身份明确不因物理或网络位置、不因资产归属而给隐含信任判定粒度一次登录长期可信per-session、per-request持续重评估PEP/PDP 位置应用外围一层拦截器往资源侧搬成为独立的、要有实时上下文和可撤销能力的决策服务决策输入角色角色 设备态势 行为 环境属性结论种类allow / denyallow / deny /revoke没改变什么判定式本身仍是policy(attributes) → permit/deny也就是 ABAC 的语义PEP/PDP 这套词汇也不是它发明的——SP 800-207 在给出 PDP/PEP 模型的段落有脚注 3明确写着概念部分定义于 OASIS XACML 2.0。微分段也不等于零信任NIST 有意把它描述成 ZTA 的一种功能能力“这些定义仍在以某种方式相对边界来定义自己比如微分段或微边界”。还有一条常被忽略的适用边界七条原则针对组织内部或与伙伴组织协作完成的工作不适用于匿名公开或面向消费者的业务流程。做 C 端产品时把 ZT 原则原样搬过来会写出很重的方案。一句话总结笔者观点零信任是部署与信任模型不是新的访问控制模型。它给权限框架出的真正考题是——你的授权决策必须能实时拿到上下文并且能被撤销。6. 这些模型在 Java 生态里分别落在哪一层把前面的谱系映射到实际选型上一张表基本够用模型Java 侧的典型落点客观状态ACL / DAC文件与数据库对象权限、Spring Security ACL 模块对象级 ACE 存 DB、Shiro 的 Wildcard Permissionsprinter:delete式通配串小众但没死ACL 模块仍是官方文档里的一章RBAC几乎所有后台的角色-菜单-按钮三件套、Keycloak 的 Role/Group Policy、Casbin 的p, sub, obj, act RBAC matcher事实上的默认起点ABACKeycloak Authorization ServicesRole/Group/User/Client/Time/Regex/JS 策略并对接 UMA、CerbosResource/Principal/Role/Scoped Policy Conditions Derived Roles、OPA/RegoCNCFGraduated2021-01-29、AWS Cedar策略语言化、可测试化ReBACOpenFGACNCF Incubating、SpiceDBZanzibar 血统元组存储数据权限行级PostgreSQL RLS9.5 引入、Oracle VPD、SQL Server RLS2016 引入应用层 MyBatis/JPA 拦截器DB 层兜底 应用层拼接并存数据权限列级PostgreSQL 列级GRANT、Oracle “Grants of Privileges on Columns”原生支持但很少被应用用上混合Casbinacl/rbac/abac/orbac/blp/biba 等一整套可运行配置Java 是官方支持语言。注2026-02 已进入 Apache 孵化器官网 casbin.org 现 301 至 casbin.apache.org单库覆盖多模型代价是模型语法要自己维护两个技术细节值得现在就记住第四篇会正面用到RLS 是会被绕过的。PostgreSQL 官方文档写明superuser 与带BYPASSRLS属性的角色总是绕过行级安全表 owner 默认也绕过可用ALTER TABLE ... FORCE ROW LEVEL SECURITY让它受约束唯一键/主键/外键这类引用完整性检查总是绕过行安全。这意味着用了 RLS 就安全是错的——应用账号一旦是表 owner策略形同虚设。来源Oracle VPD 的机制是改 SQL而不是过滤结果。官方定义是创建控制数据库行级与列级访问的安全策略做法是给命中的表/视图/同义词上的 SQL动态追加一个 WHERE 子句实现入口是DBMS_RLS包配合 application contexts。来源至于策略语言本身的语义有一个容易记错但很关键的点Cedar 是默认拒绝且显式 forbid 优先。官方规则原文是至少一条匹配策略为 Allow 且恰好零条为 Deny 时整体才是 Allow并明确两条原则——空策略集的默认结果是implicit deny任一策略给出 Deny显式 Deny 总是覆盖其它策略的 Allow。来源 同一页还顺手回答了这算 RBAC 还是 ABAC只有 scope 没有附加条件的策略可以作为 RBAC 方案的一部分带条件的策略可以作为 ABAC 方案的一部分。注Cerbos不在 CNCF 项目列表内官方项目页 404把它写成CNCF 项目是常见错误。7. 标准之外token 这一层现在走到哪了第一篇不该以代码结尾但应该给一条时间是否可信的核对结论。截至 2026-09-29事项状态出处OAuth 2.1仍不是 RFC。当前修订draft-ietf-oauth-v2-1-16Last updated2026-09-02IESG 状态仅 “I-D Exists”未进入 Last Calldatatracker草案里已经确定的口径PKCE变为必需Implicit、资源所有者密码凭证等不再被规定redirect URI严格字符串匹配目标是合并 RFC 8252 / 9700 / 浏览器应用草案并移除 RFC 9700 中被认定不安全的特性草案正文OAuth 安全 BCPRFC 9700BCP 2402025-01Updates 6749/6750/6819RFC EditorDPoPsender-constrained token 主路RFC 94492023-09。⚠️ 不是 9440——RFC 9440 是Client-Cert HTTP Header FieldInformational解决TLS 在反向代理终结、Java 应用拿不到客户端证书RFC EditormTLS 绑定 access tokenRFC 87052020-02比 OAuth 2.1 时代早得多不是新事物RFC EditorJWT 形态的 access tokenRFC 90682021-10RFC EditorOIDC Core 1.0OpenID Foundation 侧为Final含 errata set 2。⚠️ OIDC 已是 ISO/IEC 标准一说本次未核实规范正文只引用 ISO/IEC 29115别在方案里写规范这里存在一个对权限框架很锋利的张力笔者分析非标准表述OAuth 2.1 把 sender-constrained token 留在了扩展DPoP / mTLS而不是核心规范里因此 Java 框架默认发出的是不绑定的 bearer token而零信任要求可撤销、持续重评估。这两件事不靠给框架加拦截器解决只能靠短 TTL 撤销通道或把决策外置到 PDP。第三、第五篇会分别处理这两条路。最后总结先选模型再选框架。Spring Security / Shiro / Sa-Token 都是执行器它们不阻止你写出一个 ACL 系统也不保证你能写出可审计的 ABAC 系统。RBAC 是默认起点而不是终点。它带来的确定性权限只经由角色、角色只经由指派非常有价值一旦约束涉及对象属性和环境你要么走域/条件补丁要么接受角色爆炸。RBAC 表达不了数据权限这句话别原样引用。标准的态度是允许你加约束但不告诉你怎么加——真正的问题不是不能表达是表达得不可审计。ABAC 换来的细粒度要用审计成本付。上线前先确认你能回答谁能看这条数据而不是只确认这次请求被拒了。ReBAC 值得学的不是名字是关系是一等公民。组织树、文件夹、共享链、租户层级本来就该是数据而不是角色。零信任没有替代任何模型。它替代的是一次登录长期可信并把问题从权限判断放在哪变成决策能不能实时、能不能撤销。对后端/架构岗笔者个人更关注三件事权限点的唯一权威存储在哪里、需求变更时改动面能不能被枚举、以及审计能不能在事故前而不是事故后回答谁有权。下一篇测评篇会把镜头拉回到三个 Java 框架本身过滤器链、Subject、StpUtil三种架构到底在哪些地方不可互换。事实说明文中所有标准编号、发布日期、版本状态与引文均在 2026-09-29 逐条核对一手来源Biba 年份1975/1977与 ABAC四类属性措辞存在来源分歧已在正文标注DAC 的提出年份、TCSEC 确切编号、OIDC 的 ISO/IEC 状态未取到一手依据故正文未作断言。带笔者归纳/笔者观点标记的段落为分析而非标准表述。参考资料 致谢[1] NIST SP 800-162《Guide to Attribute Based Access Control (ABAC) Definition and Considerations》[2] NIST SP 800-162 发布页2014-01, Final[3] NIST RBAC 项目页标准沿革与文献清单[4] NIST RBAC FAQ四组件、RBAC0-3、约束与批评回应[5] NIST CSRC 术语表DAC MAC[6] NIST SP 800-207《Zero Trust Architecture》PDF2020-08[7] USENIX ATC 19Zanzibar — Google’s Consistent, Global Authorization System[8] OASIS XACML 3.0 Core Specification2013-01-22[9] Bell-LaPadula 原始报告重刊Journal of Computer Security, DOI 10.3233/JCS-1996-42-308 IEEE Computer 29(2):38-47 RBAC ModelsDOI 10.1109/2.485845[10] OpenJDK JEP 411弃用 Security Manager JEP 486永久禁用 Security Manager[11] Jakarta AuthorizationJACC规范页[12] Spring Security 参考文档ACL 模块 过滤器架构[13] Apache ShiroPermissions 与 News3.0.x 发版动态[14] Casbin 支持模型清单 RBAC with Domains RBAC with Conditions BLP Biba PBAC OrBAC[15] OpenFGAAuthorization Concepts Configuration Language Conceptsstore/tuple/model/Condition[16] CNCF 项目页OpenFGAIncubating, 2025-10-28 OPAGraduated, 2021-01-29[17] Authzed SpiceDB与 Zanzibar 的对照 Caveats[18] AWS Cedar 策略语言文档 Cedar Policy Syntaximplicit deny 与 forbid 优先[19] Cerbos 文档首页[20] OPA 文档首页 Data Filtering with OPA[21] PostgreSQL 文档Row Security Policies CREATE POLICY GRANT列级权限[22] Oracle Database 19c 安全指南Virtual Private Database[23] Microsoft SQL ServerRow-Level Security[24] IETF datatrackerOAuth 2.1 草案状态 draft-ietf-oauth-v2-1-16 正文[25] RFC 9700OAuth 安全 BCP RFC 9449DPoP RFC 9440Client-Cert 头 RFC 8705mTLS 与证书绑定 token RFC 9068JWT 形态 access token[26] OpenID Connect Core 1.0Final, errata set 2
