一个额后台的用户角色权限系统总是可以大概划分为三个大的模块的：用户管理、角色管理、权限管理。下面，我们就此三个模块展开叙述一下。
一、用户角色权限系统说明
1、RBAC权限设计模型
（1）RBAC
（Role-Based-Access Control，基于角色的访问控制），就是用户通过角色与权限进行关联，从而获得某些功能的使用权限。权限被赋予给角色，而不是用户，但是一个用户可以拥有若干个角色，当一个角色被赋予某个用户时，此用户就拥有了该角色所包含的功能权限。简单地说，一个用户拥有若干角色，每一个角色拥有若干功能权限，这样，就构造成“用户-角色-权限”的授权模型。在这种模型中，用户与角色之间，角色与权限之间，一般是多对多的关系，如图：
2、三大模块搭建后台用户角色权限系统
如上所述，一个后台的用户角色权限系统总是可以大概划分为三个大的模块的：用户管理、角色管理、权限管理。用户管理往往随着行政部门划分或者随着业务线部门划分，对应部门或者小组内的用户有着基本相似的功能需求和权限等级；角色管理相对来讲更加固定，它往往是基于业务管理需求而预先在系统中设定好的橘色标签，一般不会随意更改，更像是一个用户分组标签，权限管理内容相对更加庞杂和蜂虎，主要包含了目标、操作、和许可权三个部分，当某一功能权限授权给用户时，也就相当于为该用户开通了可以操作某个目标功能的许可权。
角色权限系统属于策略设计的范畴，它的设计非常考验一个PM对业务的理解力以及对自己后台所有功能的熟悉程度。做角色权限系统之前一定要先深度了解业务流程以及后台的所有功能模块，在不了解的请胯下，多向相关同事请教，避免角色权限系统设计过程中出现差错和逻辑漏洞。
二、用户角色权限系统建设的三大模块
1、用户管理
用户管理中的用户主要是功能系统的使用者，这些用户是一个一个的员工个体，这些个体往往从两个维度来进行划分：行政关系（部门架构）、业务部门（业务架构）。用户管理就是在此两个维度来给员工个体进行关联性的初步分群或者分组。按照行政部门或者按照业务线部门划分后，对于部门或者小组内的用户有着基本相似的系统功能使用需求和权限等级。
注：上图例为按照行政关系划分的用户管理模式。
注：上图为按照业务线关系划分的用户管理模式
2、角色管理
（1）角色管理
角色往往是基于业务管理需求而预先在系统中设定好的固定标签，每个角色对应明确的系统权限，其所拥有的系统权限一般不会随意更改，并且角色也不会随着用户的被添加和被移除而进行改变，相较于用户管理而言更加稳定
（2）自动赋权：用户自动进入角色
如果角色与行政关系下的组织部门存在绑定关系，那么如果一个用户进入到该组织部门后，该用户会自动被加入到对应的角色中，并且拥有该角色所有的系统权限，如一个财务人员【小张】入职财务部后，那么该用户无需进行额外的授权即可在对应财务报表系统查看该部门员工可查看的财务数据报表和对应的操作权限（比如操作财务审批等）；
（3）角色赋权：用户被添加进角色
业务是不断创新和发展的，随着业务的发展，会有越来越多的新的角色被设置和创建，比如公司新启动了一个企业团餐项目，项目部横向的从各个部门找了多个员工组件项目团队，并且该项目的业务权限也只是授权给这批员工可查看和操作，那么，在此项目中，会产生一个新的角色“财务1”，系统高级管理员会把从财务部门选中的财务【小张】添加到“财务1”这个角色中，那么【小张】即可获得查看企业团餐项目业务数据报表和操作的权限。这种权限的授予无法通过用户行政关系的自动绑定来实现；
（4）角色继承：角色权限的继承
权限可以是独有的，也可以是继承的。每个角色都有自己的权限集，角色继承其实也就是继承父系角色的权限，一般角色在继承其父系角色的全部权限的基础上增加拥有一些自己的权限。而系统角色继承往往存在于用户分级管理比较明确的团队或者公司；
（5）角色互斥：角色包含的权限互斥
角色互斥的业务背景：当一个业务流程由于风控的原因，需要将其操作给划分成分开的几个步骤时，需要给这几个不同的步骤授权不同的角色，并且这些角色之间需要进行互斥。比如大额财务报销审批流程，财务人员【小张】拥有了审批人权限后，就无法将审批确认的权限再授予小张，以此来规避一个人完成大额报销而带来的财务风险；
（6）临时角色
临时角色往往是针对特殊群体设置的，比如公司有特殊访问队莅临，需要给这些特殊的客户一些临时的身份来体验某些功能操作。那么把这些人添加到部门的组织架构中显然是不合适的。因为这些人只是临时的摆放者，不是企业员工；其次，这些客户需要体验的功能操作往往是横跨多个业务模块的产品线的（比较复杂），一般公司并没有现成的固定角色符合拥有客户所需的全部操作权限，因此，需要给这些客户开设临时角色，并且支持给临时角色最大的权限选择空间；
（7）黑白名单
3、权限管理
（1）权限管理
权限管理更多是从功能菜单、功能权限、数据参数三个不同颗粒度登记来考量的。具体颗粒度的大小视公司结构和团队规模而定，如果不是业务属性一定要求将权限控制到非常精细的级别，其实就没必要将权限的颗粒度才分到具体某一项操作或者某一项按钮，毕竟后台产品的核心是业务管理平台，主要目标是辅助业务的管理和推进。
注：如图为某一后台产品的部分截图，其中可见功能菜单页、功能操作按钮和数据字段。
（2）功能菜单权限
对于后台产品来讲，针对功能菜单来划分用户权限其实是比较粗颗粒度的一种管理方式，这种模式下用户一旦获得授权即可使用该菜单下的全部数据查看权限和功能操作权限；
（3）功能操作权限
功能操作层级的权限相对于功能菜单会更为深入，这种情况下，不同角色的用户可以进入同一菜单页面后，查看相同的数据字段信息，但是他们可执行的功能操作不同；
（4）数据字段权限
数据字段层面是比较细颗粒度的拆分，他会实现不同角色用户在进入同一菜单页面后台时，可见的数据字段都有差异，比如销售人员进入某销售业绩管理后台时，可以看到自己的业绩提升数据，但是财务人员看到的是业务工单的费用字段，这些字段共存在一个菜单中，只是受限于不同的角色权限而已。