文章从权限模型出发，结合具体案例分享了To B 的权限体系设计关键环节和需要注意的问题，与大家分享。

背景

之前在另一篇文章里介绍了权限体系的基础概念如RBCA和ACL，网友反馈说不够深入，需要来点见真章的东东，最好是能够看完后，就可以直接拿到工作中投入使用的。联想到工作中遇到的几个都属于ToB领域里，但面向不同业务方向和类型的实际项目，拿来具体讨论一下，如何为平台设计一个比较通用的权限系统。

原型图

我这里用的是xiaopiu，在线绘图。不用额外安装程序。如果专业点的，一般会用axure，有一定的学习门槛。

从这张原型图里，可以看到这是一个体现了权限体系核心功能的简单系统。

• 当王经理登录的时候，不仅能管理系统概况，也能管理具体的实用功能也就是围栏和视频系统。
• 当巡逻员小李和巡逻员小明登录的时候，他们只能管理围栏和视频系统。
• 通过账户和角色的组合，就能够实现上面的要求

实现的原理是什么呐？首先来了解下资源的概念

背后的事儿

什么是资源

如果没有【账户】和【角色】，这就变成了一个最纯粹的功能系统了。这个系统由系统概览和实用功能两个一级菜单，以及下层的各个细分功能组成。

第一步需要用标识，来标记这些功能。通俗的，可以将这些功能命名为资源，后台数据库中就是通过资源ID来识别某一个具体的功能的。

页面上的每个元素都要有对应的资源ID，这是为了在前端展示的时候，能够做到让不同用户登录后，有的用户可以查看，有的可以编辑，有的可以删除。

所以第二步，需要定义对各个资源ID能够进行的操作，也就是资源和操作之间会产生一个映射关系。

资源和操作

操作的含义，可以理解为CRUD(创建Create/读取Read/更新Upate/删除Delete)四种类型。一般实际实现过程中，为了不这么麻烦，可以将这四种操作简化为全有或者全无。用映射关系来表示就是

resourceId -> CRUD

实际实现的效果就是，当用户能够看到这个资源，那他就可以操作这个资源。如果真的遇到了有特定的需求，就是对于同一个资源，这一种类型的用户必须有而且只能有查看的权限，同时必须没有编辑的权限，那么就需要将这个映射关系打散为如下格式

resourceId -> R

resourceId -> CUD

接下来，准备工作都做好了。铛铛铛，将进入重头戏，账户和角色。

角色

从业务流程上来讲，是先有角色，再有账户。所以需要先创建一个角色。

王经理是一个账户，他有一个叫做“经理”的角色。系统中新增一个角色的时候，一般至少有3个字段，分别是角色的名称（必填），角色拥有的资源的权限（必填），对于该角色的描述（可选）。对于各项的要求如下：

• 角色的名称不允许重复，如果有多个同样名称的角色，被赋予的权限还不一样，系统就乱套了。
• 对应的资源权限。也就是上面提到的resourceId+CRUD的组合。当然支持多选。也就是同一个角色，可以拥有对多个资源的权限

根据上述描述，在系统中创建两个角色

• 经理角色。具有对资源【系统概览】和【实用功能】【围栏】【视频】的权限。这里要特别提一下，虽然将实用功能和围栏分成两个资源提了，但是实际操作时，当选择了围栏功能时，由于它是实用功能的子节点，默认直接将实用功能的权限也给这个角色就可以了，既简单又不会造成更复杂的情况
• 巡逻员角色。具有对【实用功能】【围栏】【视频】的权限

账户

万事俱备，只欠东风。最后一步就是新建3个帐户。账户新建的时候，需要填写的字段，除了账户名称（当然账户名称也是不允许的重复的）和本身这个系统要求的一些信息（例如照片，手机号，电话号码等）以外，就只需要一个字段【角色】了。

这里的角色字段的取值，来自于上一小节里提到的【角色】。一个账户，可以绑定多个角色。不同的账户，也可以绑定同一个角色。

为了让王经理，小李，小明能够正常服务于自己的岗位，实际上就是：

• 新建一个账户，王经理，绑定的是之前创建好的 经理角色。
• 新建一个账户，小李，绑定的之前创建好的 巡逻员角色
• 新建一个账户，小明，绑定的之前创建好的 巡逻员角色

然后这三个人，用自己的帐号密码登录就可以了

总结

在一个真实的系统中，进行权限操作步骤是：

• 第一步定义自己系统的资源权限映射关系，权限是由资源+操作组成的
• 第二步创建角色，这个过程会将角色和对应的资源权限绑定
• 第三步创建帐号，这个过程会将角色和帐号进行绑定

另外，映射关系为

• 资源和操作：多对多
• 角色和权限：多对多
• 帐号和角色：多对多

本文由 @花生草 原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议。