RBAC（Role-Based Access Control ，基于角色的访问控制）模型是后台产品设计中常用模型。本文属于事后总结，希望对各位读者有一定的帮助，当然也有一定的局限性，欢迎留下你的评论，相互探讨。

最近西蒙折腾业务管理后台的从0到1，接到任务那刻，就开始投入资料的搜集和汇总工作。但是很多网上的资料都是基于技术层面的解释，但是很少有通俗易懂的说明，工作就开始了卡顿。

搜索出来的资料，很多都是这样的图表，后续咨询了很多伙伴，感谢他们的建议和分享，终于顺利完成了框架的梳理。撰写此文属于后续的思考沉淀，希望对各位读者有一定的帮助，当然本文也有一定的局限性，欢迎留下你的评论，相互探讨。

当框架梳理完毕的那刻，头脑中闪现的就是《结网》的一句话：“不需要再发明轮子”。

一、RBAC模型无处不在，不需要再次发明轮子,在于归类提炼

一开始搜索RBAC模型，很多都是偏技术类的说明，如用户表、角色表、用户角色关联表、权限表、权限角色表之类，没有一个概要（通俗）的说明。梳理完毕以后，发现其实RBAC模型是无处不在。

举几个例子和大家分享一下：

• 会员打折，基于会员卡，商品结账时，可以享受较低的支付价格。
• 公司的门禁卡，是分发给公司员工，只有是公司员工的身份（角色），才能领取门禁卡，才能使用打卡出入（权限），同样基于员工的角色，所以要上下班考勤打卡（权限限制）。如果离开了公司，那么不再是员工（角色），所以无法出入公司大门，也无需上下班考勤打卡。
• 公司是有组织架构，不同的岗位，有不同的管理权限，财务总监可以管理公司账户，人事总监管理公司人事，与之对应的是财务部成员和人事各自有不同的权限
• 当我们打开微博/微信，发表内容的时候，是输出者，看别人内容的时候，是浏览者，输出评论的时候，是评论者，也是基于不同的动作，触发不同的权限。如内容输出者享受的权限就是可以看到多少人点击，查看评论，回复评论，点赞数等
• 当我们打开游戏的时候，游戏也是有角色权限约束，游戏里面的角色，达到N级，可以解锁对应的技能，解锁符文镶嵌位，解锁副本，解锁其他游戏场景入口

RBAC模型无处不在，所以不需要再次发明轮子，在于归类提炼，融合贯通。

二、RBAC核心是用户-角色-权限的模型

RBAC核心是用户-角色-权限模型，但是这个模型也是一步步衍化而来，早期的是用户-权限模型。

这个模型的理念，是直接基于用户勾选权限，实现用户的赋权，但是这个模型有一个硬伤，就是无法复用，效率太低。无法批量套用，需要依次处理

以一个千人论坛为例：需要为一千个用户，手动配置权限，实现超管，超版，版主等用户的赋权。

想想为1千个用户依次配备相关权限。

现在的论坛，贴吧，已经可以实现数十万，数百万级的用户支撑，显然简单的用户-权限角色是不切实际的，事实上他们用的是改良后的用户-角色-权限的模型，也就是本次要分享的RBAC模型。

用户原本没有权限，基于角色对应的权限，获得对应的权限，用户变更角色，既可以获得对应的权限

现在还混贴吧和论坛的老鸟，应该知道在自己熟悉的板块，和自己未去过的板块，积分，头衔是不一样的，比较常见的是自己板块/贴吧，去到其他不熟悉的地方，也得从0开始熬，除非是获得对方超版调整为嘉宾，小吧主之类，那么就直接获得相关权限。这里面已经是一个用户-角色-权限的模型，这也是非常成熟的模型，所以西蒙一开始说的就是，不需要再发明轮子。

事实上，论坛的后台可以把各大板块分别设置模块，从后台层面，已经把可操作性，可见性进行区分，比方说普通用户是无法可见特殊板块，因为特殊板块可以单独设置为个别等级才可见（勾选权限），实现模块可视化的隔离。

回到论坛的角色配置，可以单独为用户的不同板块分别配置角色，用户直接基于角色获得对应的权限，用户完整的权限取全部权限的并集。基础角色就是注册用户，享受默认对应的权限即可。

如上面的图所示，甲在论坛的权限汇总之后如下：

从完整的RBAC模型会是这样的梳理实现。为了让大家更好理解模型结构，下面以人人都是产品经理的角色与权限进行详细的说明

三、人人都是产品经理角色与权限的概述

人人都是产品经理的主页面，点击各大板块的入口（红框部分），对于首页各类内容进行分类，

页面分类了很多的内容，但是涉及的板块并不多，基于板块再次细化后形成信息架构图，核心的内容为为文章、起点学院、天天问、秒聘网，个人信息。

西蒙实测对应的角色，尝试逆推相关的权限，梳理如下：

角色以及对应的权限

普通未登录用户（访客）

未登录的情况下，基于访客的身份，获得访客的权限：搜索文章，浏览文章，浏览天天问，浏览起点学院的内容，但是更深一级的操作，如文章评论，回答问题，查看视频均会弹出登录的提示

登录用户（核心角色）

用户基于手机，用户名和邮箱，微信登录之后，将获取到之前存储的账户信息，同时角色替换为已登录的用户，则权限取未登录用户和已登录用户的并集。用户登录后除了访客的之前的搜索文章，浏览文章，浏览天天问，浏览起点学院的内容外，附加了作者，评论者，天天问板块的角色，获取对应的消息提醒。

其他角色

起点学院的年费会员，红钻会员，绿钻会员以及天天问的角色，属于其他角色类型的一种，用户触发则激活该角色的权限，不触发则视为标准的用户权限。

具体为：只有在触发起点学院课程的时候，进行浏览权时判定，其中年费会员>红钻会员>绿钻会员，若课程为绿钻用户可访问时，则普通用户不可访问，返回错误。绿钻及绿钻以上的会员可以访问该视频。

同理：用户没有使用过天天问，或仅仅是浏览，没触发其他提问，回复问题等操作，则没有触发相关信息的推送提醒

运营管理角色

基于相同的逻辑，运营团队也是依据对应的角色，获取对应的权限，对于用户，内容进行管理。比如CECI的账户被勾选为天天问的管理员，则CECI可以管理天天问板块，当CECI被勾选文章的管理员，则CECI可以被临时当苦力，去加快文章的审核进度。

同理总编大人和曹大为超管角色，可以同时管理多个模块，以及对于员工的角色调整、

四、写在后面的思考

事实上，RBAC模型在很多场景都会运用上，希望本科普小文对大家有所帮助。

RBAC也可以复杂多样化，比方说游戏里面的帮派，活动，门派，跑商，任务以及对抗，都是基于角色来触发对应的内容，加入门派（门派角色），获得门派的技能树（门派权限），加入帮派（门派角色），获得对应的帮派任务和帮派福利。

RBAC的复杂程度是基于后台角色的复杂性，所以做好适当的预留空间，很重要。同样，对于RBAC模型进行改造的时候，对于整个用户-角色-权限的探索复盘也很重要，

西蒙的RBAC模型的分享到这里就差不多了，在这里感谢RAIN，小菜鸟，老王，以及很多热心伙伴的分享和建议。

本文由 @西蒙书策  原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自PEXELS，基于CC0协议