一个产品经理小白，渴望快速成长，希望大牛多多指点。

对于权限管理系统的个人理解，希望对你有所帮助

有没有发现，我们使用任何一个产品，或多或少都会涉及权限管理系统，比如使用微信，我们设置【查看朋友圈的范围】，直接影响我们的好友能查看我们的朋友圈动态的范围；又如我们日常使用的企业类软件，不用部门可能使用的功能不一样；产品的收费用户与免费用户能使用的功能是不一样；在社区里，版主和普通社员的权限也是不一样的。没错，这些就是权限带来的好处，让使用用同一个产品的用户看到、使用的功能不同，甚至实现专人定制化的权限设置。

今天我要介绍的就是基于RBAC的权限管理模型，来搭建个性化的权限管理系统。

首先我来介绍一下用户、角色、权限

用户：其实就是相当于账号，我们登录一个网站、一个平台都需要有账号，账号是登录进行操作的前提。

角色：角色有点类似于职位，每一个职位都有一定范围内的工作内容，就像你是前台接待员，那你的工作就是接待，不可能让你去做财务的工作，除非说你是前台接待员又是财务部门的人员。

权限：第一层面是控制我们网站、平台、应用需要控制的页面的显示或者说是菜单是否显示；第二个层面是控制页面按钮的显示，即操作的权限控制，第三个层面是更为精准化数据控制，比如一些人可以看到页面列表的所有数据，而一些人只能看到部分数据。

现在开始步入正题，先介绍一下传统的权限管理系统，在传统的权限管理系统中，是直接把权限赋值给用户，使用传统权限管理系统，在初期使用人员比较少的时候还是很方便的，但是当使用人员增多，系统功能也日益复杂，就会发现对每个人的权限进行管理维护真的需要花很长时间。由此也产生了RBAC权限模型，这是一套完整成熟的系统，他在“用户”和“权限”中间增加了”角色“的概念，把权限赋值给角色，再把角色赋值给用户，这样做的好处就是授权更加灵活，支持批量化修改用户的权限。同时根据权限系统的复杂程度，RBAC又分为RBAC0、RBAC1、RBAC2、RBAC3。

一、RBAC0——基础模型

RBAC0是基础模型，可以满足大多数的权限管理系统，在这个模型中，我们把权限赋值给角色，再把角色赋值给用户，其中用户与角色的分配方式有两种，一种是用户与角色是一对一的关系，即一个用户对应一种角色；另一种就是用户与角色是多对多的关系，即一个用户可有多个角色。

一般而言我们用的都是用户与角色是多对多的关系，一个用户被赋值为多个角色，同时一个角色可以赋值给多个用户。就拿我做的第一个权限管理来说，这是一个为原创内容中心量身制作的系统，有总编，统稿，责编，编辑，美编等角色，比如张三他是责编，同时他又兼顾了统稿的角色，那这就是一个用户拥有两个角色；同时因为公司人员原创内容中心部门人数有好几十人，多个统稿负责人是每天轮流值班的。那就是统稿的角色被多个用户拥有了。

二、RBAC1——角色分层模型

这个模型是在RBAC0的升级，在角色中引入了子角色的概念，就相当于给一个角色分了多个拥有不同权限的子角色，从而实现更细粒度的权限控制。

这种情况我用部门来举例吧，比如销售部门，部门有负责人：销售总监，管理整个部门，也就是销售部门所有的权限都有，像分配任务，统计部门KPI，有时候遇到非常重要的客户需要自己来跟进，招聘部门人员等等；销售部门还有销售经理：主要是负责销售总监分配的任务，统计部分销售的KPI；还有普通的销售人员，主要就是负责接待客户。那这样就是销售总监拥有整个部门所有的权限，而销售经理，普通销售则拥有销售总监的部分权限，但是销售总监、销售经理、普通销售其实都是销售角色。所以就产生了角色分组模型。

三、RBAC2——角色限制模型

该模型也是在RBAC0的基础上演变而来的，但是新增了对用户、角色以及权限的限制控制。

这些限制可以分成两类，即静态职责分离SSD(Static Separation of Duty)和动态职责分离DSD(Dynamic Separation of Duty)。具体限制如下图：

角色限制模型更为严谨，对逻辑性要求更高，同时对业务也需要有深入的了解。

静态职责分离，我就拿互斥角色的限制来说，比如财务部，负责提交财务报销的人员不能同时拥有报销审核的权限，如果报销的人同时拥有审核的权限，那会产生非常大的风险；再比如编辑人员不能同时具有发稿的权限，一篇文章最终呈现在我们用户面前其实经过了编辑、美编、责编、统稿等多个步骤，如果编辑拥有发稿的权限，那编辑写完稿直接发出去了，一方面没有美编的排版、样式等的优化，也没有责编的复查，最终很有可能就会产生出质量不高的内容。

动态职责分离：如用户拥有多个角色，当用户登录时，是采用激活其中一个角色？还是说采用所有角色拥有的权限中和？一般而言是采用激活其中一个角色，分工更为清晰。但具体采用哪种方案，那需要根据系统复杂性以及产品的思维来确定。

三、RBAC3——统一模型

统一模型是RBAC1以及RBAC2的结合

四、实战案例

案例一：我设计的第一个权限管理系统用的就是RBAC0基础模型，因为这个系统是对公司内部部门使用的，使用人数在50-100人，相应的功能也不算很复杂，权限的控制在页面+操作及按钮的层面上，因为这是一个针对我们编辑部门以及运营部门使用，而且功能结构不复杂，所以不需要对角色进行分组，因为当时是第一次做权限系统，考虑不周，没有加角色互斥的限制，但因为使用人数不多，人工维护所需花的时间也不多。

案例二：不久公司另一个系统由于功能随着迭代越来越复杂，之前的权限管理都是后台自己控制，没有可视化管理，发现人工运营维护需要耗费大量的时间，由此权限管理系统提上日程，也由于我之前有搭建权限管理系统的经验，这个任务自然安排给了我。首先简要说一个要设计的大概吧，因为这个权限系统涉及了两个后台平台简称后台A、后台B。使用后台A的主要是部门负责人，使用后台B的主要是部门员工；所以你也看出来了，这里就需要对角色进行分组，对于使用后台A的是部门负责人拥有该部门所有的权限，而使用后台B的是部门人员，所拥有的权限是负责人权限的子集。而且部门负责人可以创建新的角色用于管理部门权限，并把相应角色赋值给部门的员工。所以这就是权限系统中又有一个子权限系统。这样权限管理系统就搭建起来了。其次就要进行角色的限制了，这个我主要的针对的是在数据层面上的控制，就拿销售线索来举例吧，销售总监可查看并分配销售线索给销售，也就是销售总监可以查看所有的销售线索；而对于普通销售就只能查看并根据自己负责的销售线索，这就是根据角色来控制数据的下发显示。

五、总结

基于两次的权限系统的搭建，积累了一下有关权限管理的知识，还记得第一次做权限管理系统时，有很多都不知道，对于用户管理，角色管理入手很快，但对于权限管理，对于具体要控制到什么程度，其中的逻辑关系，限制条件的制定，这些涉及边缘化的东西想得越清楚，会更好的推进产品开发实现。所以在做产品前，需要了解产品背后的业务逻辑，熟悉使用场景，了解这些对于任何一个产品经理，都是必修的课程。而我自知现在能力尚弱，仍需不断努力。路漫漫其修远兮，吾将上下而求索。