2. 身份与权限核心模型

在认证授权系统中，所有工程问题最终都会落到一组核心概念上：用户、角色、权限、资源、策略。它们不是抽象名词，而是决定系统能否正确回答“谁，在什么条件下，能对哪个对象做什么”的建模基石。理解这些概念之间的关系，比记住某个框架的 API 更重要。

先看五个核心对象。用户（Subject）是请求的发起者，可以是自然人、服务账号、设备或外部系统。资源（Resource）是被访问的对象，例如订单、文件、API 端点、数据库行。权限（Permission）描述“能做什么”，通常由操作（Action）和资源类型组合而成，如 order:read、file:delete。角色（Role）是权限的集合，用于批量授予。策略（Policy）则是把主体、资源、操作和条件绑定在一起的规则，是授权决策的直接依据。

这五个对象的关系可以用一张结构图清晰表达：用户通过角色或直接绑定获得权限，权限作用于资源，策略决定绑定是否生效以及生效条件。下图展示了这一核心关系，并标注了 RBAC、ABAC、ReBAC 三种模型各自的作用位置。

RBAC：以角色为中心的经典模型

RBAC（基于角色的访问控制）的核心思想是：不直接给用户授权，而是先定义角色，再把角色分配给用户。用户通过角色间接获得权限。RBAC 的典型结构是三层：用户—角色—权限。一个用户可以拥有多个角色，一个角色可以包含多个权限，权限最终指向资源。

RBAC 的优势在于管理成本低、语义直观。当组织有 500 名员工、20 个岗位时，只需维护 20 个角色，而不是 500 份独立授权。但 RBAC 的局限也很明显：它只能表达“用户是否有某个角色”，无法表达“用户只能访问自己所属部门的订单”这类细粒度条件。一旦出现“同角色但不同数据范围”的需求，RBAC 就会被迫膨胀出大量角色变体，例如 order_reader_dept_a、order_reader_dept_b，角色数量爆炸。

ABAC：以属性为核心的动态决策

ABAC（基于属性的访问控制）把决策依据从“角色”扩展到“属性”。属性可以来自四个维度：主体属性（部门、职级、安全等级）、资源属性（所有者、密级、创建时间）、操作属性（读、写、删除）、环境属性（时间、IP、设备可信度）。策略以条件表达式形式描述，例如：

允许 当:
  主体.部门 == 资源.所属部门
  且 主体.职级 >= 3
  且 环境.时间 在 09:00-18:00
  且 操作 == "read"

ABAC 的表达能力远强于 RBAC，适合数据权限复杂、条件多变的场景。但它的代价是策略数量增长快、调试困难、性能开销高。生产系统中，ABAC 通常不会全量替代 RBAC，而是作为 RBAC 的补充层：角色决定“能不能进这个功能”，ABAC 策略决定“能看哪些数据”。

ReBAC：以关系为核心的图模型

ReBAC（基于关系的访问控制）把权限判断转化为图上的可达性问题。典型场景是文档协作：用户 A 是文档 D 的编辑者，用户 B 是 A 所在团队的成员，那么 B 是否对 D 有读权限？ReBAC 通过定义关系元组（如 document:D#editor@user:A）和关系推导规则来回答。Google Zanzibar 是 ReBAC 的代表性系统，其核心是关系元组存储和一致性快照。

ReBAC 适合层级嵌套深、共享关系复杂的场景，如网盘、项目管理工具、社交平台。它的难点在于关系图规模大时的查询性能，以及关系变更后的一致性保障。

选型依据：从业务问题出发

三种模型不是互斥的，生产系统往往是组合使用。选型时先问三个问题：第一，权限判断是否主要依赖“岗位/职能”？如果是，RBAC 足够。第二，是否存在大量“同角色不同数据范围”的需求？如果是，需要 ABAC 补充。第三，资源之间是否存在复杂的共享、继承、嵌套关系？如果是，ReBAC 更合适。

生产系统建模常见误区

误区一：把角色当用户组用。角色应该是权限的集合，而不是人的集合。如果创建“张三的角色”“李四的角色”，角色就退化成用户别名，失去批量管理价值。正确做法是角色对应岗位或职能，用户通过分配关系获得角色。

误区二：权限粒度过粗或过细。粒度过粗会导致“要么全给要么全不给”，被迫用角色变体补丁；粒度过细会导致权限数量爆炸，管理成本超过收益。建议以“资源类型 + 操作”为基本粒度，数据范围交给策略层处理。

误区三：忽略资源层级与继承。很多系统资源天然有层级，如“项目 → 文件夹 → 文件”。如果建模时把每层资源独立授权，就会出现大量重复授权和遗漏。应在模型层面支持继承，例如子资源默认继承父资源的权限，再通过显式拒绝覆盖。

误区四：策略与代码耦合。把授权判断硬编码在业务逻辑中，短期快，长期不可维护。策略应集中管理、可版本化、可测试。即使使用 RBAC，也应把角色-权限映射放在配置或策略层，而不是散落在 if-else 中。

总结来说，用户、角色、权限、资源、策略是权限系统的五个基本构件。RBAC 解决“职能授权”，ABAC 解决“条件授权”，ReBAC 解决“关系授权”。生产系统很少只用一种模型，而是根据业务场景组合使用。建模时避开角色用户化、粒度失控、忽略层级、策略耦合四个常见误区，才能让权限系统在业务增长时仍然可控、可查、可扩展。