多维RABC权限模型

写在前面

这篇文章整理的是我大约 8 年前设计的一套权限中心方案。它并不是今天意义上最先进的权限系统，但回头看，这套设计已经不只是传统的用户、角色、菜单权限，而是在尝试解决企业内部多系统持续新增、不同业务线权限维度各异的问题。

当时我的目标并不是单纯做一个后台权限页面，而是想做一套可复用的权限基础设施，并进一步往权限中台方向演进。下面我按照当年 PPT 的顺序，一页一页把设计思路讲清楚。

---

第 1 页：目录与整体结构

这一页是整套设计的总览。我把内容分成两个部分：第一部分先说明为什么要做这套权限系统，也就是权限应用场景、用户权限来源以及抽象权限模型；第二部分再进入设计本身，包括权限中心对象设计、权限模型设计和权限中心架构设计。这样的结构其实反映了我当时的思考路径：先回答“为什么需要这套东西”，再回答“这套东西应该怎么设计”。

第 2 页：从一个普通页面开始看权限到底控制什么

这一页我拿一个后台页面举例，把权限拆成了几个最直观的层次。左侧菜单是否可见是一类权限，顶部“新增”“权限管理”“批量导出”这些按钮是否可操作是一类权限，搜索下拉框能看到哪些选项又是一类权限，最后列表每一行的“删除”“编辑”动作同样需要控制。也就是说，在一个真实系统里，权限并不只是“能不能进这个页面”，而是从菜单、按钮、可选数据集一直延伸到具体操作行为。

第 3 页：把页面上的权限拆成两大类

这一页是在上一页基础上的进一步抽象。我把权限分成两类：第一类是控制某个元素是否显示、是否可调用，这更接近菜单权限、按钮权限、操作权限；第二类是限制可用数据集，也就是典型的数据权限。比如下拉框里只能看到当前用户有权访问的部门，这不仅影响当前页面展示，也会影响后续所有依赖这个参数的查询接口返回的数据范围。这里其实已经体现出我当时一个比较明确的认识：数据权限不是“页面增强功能”，而是权限模型里独立且重要的一层。

第 4 页：前端限制不够，后端必须做二次校验

这一页强调的是安全边界。前端即使已经根据权限把页面元素隐藏了，后端也仍然必须做二次校验，否则用户可以绕过页面直接构造请求。这里我列了两个典型场景：一种是前端传入的参数本身就受数据权限约束，比如部门下拉框中的值；另一种是按钮或链接触发的操作行为，比如新增、删除、编辑等动作。这一页其实是我当时对“展示控制”和“真正的授权校验”做的一个切分：前端负责体验层，后端负责安全层。

第 5 页：用户权限的来源

这一页开始进入“用户权限来源”的问题。应该同时来自用户属性所对应的权限组，例如部门、角色等。用户属性本质上对应一个权限集合，而不是一个孤立字段。比如属于某个部门，就天然带来一组查看权限；拥有某个角色，又会再带来另一组操作权限。右侧列出的则是最终用户能执行的单条权限，例如账号管理的查看、新增、修改、删除等动作。

第 6 页：直接分配权限与属性带来的权限要合并

这一页是在上一页基础上的补充。我的思路不是完全放弃直接授权，而是把它和用户属性带来的权限结合起来。也就是说，一个用户最终拥有的权限，是“直接分配的权限”加上“通过角色、部门等属性间接获得的权限”合并后的结果。这样设计的好处是兼顾了统一管理和灵活例外：大部分权限通过属性或分组继承，个别特殊需求再通过直接分配补足。

第 7 页：从用户属性和单条权限，抽象出资源组与资源

这一页是抽象权限模型的关键。我开始不再只用“角色”“菜单”“按钮”这样的业务词，而是把左边这类权限集合抽象成 Resource Group，把右边这类具体可授权对象抽象成 Resource。在这个模型里，部门、角色等都可以被视为资源组，而菜单权限、按钮权限、其他操作权限、数据权限都可以被视为资源。这个抽象的价值在于：它不把权限模型写死在某一套业务概念里，而是给不同系统预留了扩展空间。

第 8 页：不同系统可以使用不同维度组合

这一页说明为什么要继续往“维度”去抽象。不同应用的业务语义并不相同，所以它们的资源组维度和资源维度也不应该完全一样。举例来说，有的系统资源组维度可能是角色和区部，资源维度可能是菜单、按钮、部门；另一个系统则可能多出品牌列表、区部等数据类维度。也就是说，当时想解决的并不是一个系统怎么做权限，而是一批系统怎么共用一套可扩展的权限底座。

第 9 页：进入 Part II，开始讲系统设计

这一页是第二部分的起点，意味着前面关于应用场景、权限来源和抽象模型的分析结束了，接下来要正式进入落地设计。我在这里重新列出目录，是希望读者带着前面的问题进入下面几页：既然权限需要这样抽象，那么权限中心里到底要有哪些核心对象，这些对象之间怎么组织，以及系统整体怎样接入和运行。

第 10 页：权限中心的核心对象

这一页把权限中心中最核心的四类对象正式定义了出来：权限资源维度、权限资源、权限资源分组维度、权限资源分组。这里我刻意把“维度”和“实例”拆开了。维度定义的是某类资源或分组的类别，资源和资源组则是这个类别下的具体数据。比如“菜单”是一种资源维度，而某个菜单项是具体资源；“角色”是一种资源组维度，而某个具体角色是具体资源组。这个抽象其实是整套模型能否支撑多系统、多场景复用的基础。

第 11 页：把对象进一步落到数据模型和存储层

这一页是在上一页的对象抽象之上，进一步说明这些对象怎样和实际数据表对应起来。这里可以看到，资源维度里既包括操作类对象，比如菜单、按钮、链接，也包括数据类对象，比如公司、品牌、自定义资源；资源组维度则包括角色、部门以及自定义分组。也就是说，我当时已经在尝试把统一抽象模型和具体数据库结构打通，让系统既能表达权限语义，又能真正落表、落数据、落管理后台。

第 12 页：权限中心并不只是一个后台，而是一套接入式能力

这一页其实是我当时比较“平台化”的一个思路。左边是业务应用，右边权限中心，中间通过 SDK、Spring Boot 自动配置、数据库初始化等机制把权限能力植入到业务系统中。我的目标并不是每个系统都重新开发权限模块，而是让新系统引入 SDK 之后，就默认拥有一套权限相关接口、菜单、表结构和基础能力。这样一来，权限中心就不只是一个单独系统，而更像一套可以嵌入各业务系统的基础设施。

• 前端框架内置权限管理相关UI
• 后端框架内置相关Rest api定义配合前端UI使用
• 后端应用第一次启动时会自动创建PSM开头，以及PCA开头的数据库表
• 后端通过PCA提供的SDK与PCA Server进行通信，SDK中内置Job定义，定期与Server端同步基础数据，并将应用的权限信息同步给PCA Server，用于Server端统计

一般情况下管理员可以在应用内进行权限管理，在Server端进行权限集中时实际上是利用了SSO，跳转到对应应用的权限管理页面进行管理，在Server端可以进行跨应用的权限信息查询和审计，在一个员工离职时也方便进行一键权限回收

第 13 页：权限中心应该具备的功能模块

这一页从产品结构上说明权限中心应该长什么样。按照我的设想，至少要包括用户管理、数据维度管理、分组维度管理、应用管理、资源管理、权限管理以及统计查询几个模块。部分截图如下：

第 14 页：应用管理与用户管理的职责边界

这一页我把应用管理和用户管理的功能拆得比较细。应用管理除了应用本身的增删改查，还包含应用分类管理、基础信息管理以及权限模型配置；用户管理则不仅包含 AD 用户和本地用户的查询，还包括新增本地用户、修改本地用户、删除本地用户、同步 AD、以及用户分组管理。这里的核心思路是：应用是权限的承载边界，用户是授权的主体来源，两者都必须在权限中心中成为一等对象。

第 15 页：权限管理模块关注的是“看见全局”和“配置全局”

这一页描述的是权限管理模块本身应该支持什么操作。对于应用，可以查看应用下的用户信息、权限配置信息、资源组和资源的使用情况，也可以跳转回应用管理界面做进一步配置；对于用户，则可以查看用户所使用的应用信息列表，并进入某个应用查看该用户在其中被分配的分组和资源列表。右侧的“权限模型维度管理”则说明，权限中心除了管授权结果，还要负责资源维度和资源分组维度本身的定义与维护。

第 16 页：落地到具体功能，就是一套完整的权限中心后台

这一页更像一个最终的功能清单，把前面抽象的内容进一步落实到了页面和操作上。应用管理下要有基础信息管理、权限模型管理和同步任务信息；用户列表下要能分配属性、分配资源、手动触发同步；资源组列表和资源列表则要支持按维度和名称查询，并支持新增、修改、删除以及批量分配给人或资源组。从这一页能看出来，我当时设计的已经不是一个“理论上的权限模型”，而是已经往具体管理后台和日常运营流程上落了。

最后总结

现在回头看，这套设计不是单纯的 RBAC 页面堆叠，而是一套试图解决多系统权限复用、多维数据权限建模以及统一治理问题的权限中心雏形。它的核心价值在于它试图用统一对象模型、统一接入方式和统一管理后台去承接不同系统的权限差异。

如果今天重做这套系统，我会在此基础上进一步补强动态规则、策略表达、审计与治理能力；但即使放在现在，我依然认为这套设计很适合作为一篇关于“企业权限系统如何从单系统模块走向平台化能力”的真实复盘。