一、问题场景

授权（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 个角色

这还只是四个维度。实际业务中维度更多，角色数量轻松突破数千甚至数万。角色爆炸带来的问题：

• 管理成本剧增：管理员无法理解上千个角色的含义；
• 分配错误频繁：角色命名混乱导致误授权；
• 审计困难：无法快速回答”某用户为什么能访问这个资源”；
• 变更风险高：修改一个角色可能影响大量用户。

  ---

  更多文章

研发体系最佳实践-本地开发流水线-CSDN博客

如何设计微服务统一认证中心_微服务4.0认证中心接入oauth2-CSDN博客