一、问题场景
授权（Authorization）回答的是"已认证的主体能否对资源执行某操作"。与认证（Authentication）不同，授权的复杂度随业务增长呈指数级上升。
1.1 典型业务需求
在企业级系统中，授权需求通常包含以下维度：
- 功能权限：用户是否能访问某个菜单或 API 端点；
- 数据权限：用户是否能看到某条记录（行级）或某个字段（列级）；
- 操作权限：用户是否能对资源执行特定动作（读、写、删除、审批）；
- 上下文约束：操作是否在允许的时间窗口、网络环境、设备条件下发生。
1.2 授权决策的四个参与方
XACML（eXtensible Access Control Markup Language）标准定义了授权决策的四个核心组件：
| 组件 | 全称 | 职责 |
|---|---|---|
| PEP | 策略执行点（Policy Enforcement Point） | 拦截请求，向 PDP 发起授权查询，执行决策结果 |
| PDP | 策略决策点（Policy Decision Point） | 评估策略，返回允许/拒绝/不确定 |
| PIP | 策略信息点（Policy Information Point） | 提供决策所需的属性数据（用户属性、资源属性、环境属性） |
| PAP | 策略管理点（Policy Administration Point） | 管理和存储策略规则 |
请求 --> [PEP] --查询--> [PDP] --获取属性--> [PIP]
|
[PAP: 策略存储]这一架构模型贯穿后续所有授权方案的讨论。
1.3 从单体到微服务的授权挑战
在单体架构中，授权逻辑通常内嵌在业务代码里，通过 if-else 或注解完成。微服务架构下，挑战显著增加：
- 每个服务都需要独立做授权决策，但策略必须全局一致；
- 服务间调用的身份传递需要可信的令牌机制；
- 权限变更需要在所有服务间快速生效；
- 授权决策的延迟直接影响 API 响应时间。
二、RBAC 模型与角色爆炸
2.1 RBAC 核心概念
RBAC 由 NIST（National Institute of Standards and Technology）标准化，其核心思想是通过角色（Role）间接地将权限（Permission）赋予用户（User）。
用户 --分配--> 角色 --关联--> 权限NIST RBAC 模型定义了四个层级：
- RBAC0（Core）：用户-角色-权限的基本映射；
- RBAC1（Hierarchical）：角色继承，高级角色自动拥有低级角色的权限；
- RBAC2（Constrained）：静态和动态职责分离（SoD，Separation of Duties）；
- RBAC3（Symmetric）：RBAC1 + RBAC2 的完整组合。
2.2 角色爆炸问题
假设一个系统有以下维度：
- 3 个基础角色：管理员、编辑者、查看者；
- 10 个部门；
- 5 个项目；
- 4 个数据密级。
如果用纯 RBAC 表达"某用户在某部门的某项目中以某密级角色操作"，需要的角色数量为：
3 x 10 x 5 x 4 = 600 个角色这还只是四个维度。实际业务中维度更多，角色数量轻松突破数千甚至数万。角色爆炸带来的问题：
-
管理成本剧增：管理员无法理解上千个角色的含义；
-
分配错误频繁：角色命名混乱导致误授权；
-
审计困难：无法快速回答"某用户为什么能访问这个资源"；
-
变更风险高 ：修改一个角色可能影响大量用户。
更多文章