转载至：http://www.sohu.com/a/340431910_695183
产品经理在思考产品架构的过程中，必须要有业务流程的参与。通过业务流，常常会抽象出对产品有诉求的多个角色，再依据角色的特性去梳理使用场景并设计需求。
当角色之间的使用场景不冲突，不需要隔离时，我们会综合考虑这些角色的使用场景来设计解决方案。比如QQ音乐同时需要为听歌和听电台的用户提供所有的功能需求。
当这些角色的使用场景完全不重叠、流程对立时，我们会设计完全独立的两套系统，如微店卖家端和买家端；
除了上面两种情况，在toB产品中，基于产品流程和信息安全等多符合因素考虑， 各个角色的使用场景是部分通用，部分隔离的，这时候就需要引入“权限系统”了。
涉及到权限的问题往往是都是复杂的问题，在系统权限控制方面，我们经常会参照现成的案例来设计自己的权限控制，以下就是John所总结最常见的四种权限控制的方法。
一、控制系统的帐号及登录
1. 帐号的定义
基本上所有的互联网产品，无论是移动端、PC端、C端或B端产品，登录都需要一个账号。只是对于C端的产品，都是用户自己注册即可。
而对于后台产品而言，是需要公司内部人员去创建账号的。而这个账号就是一把钥匙，我们通过控制账号所具备的权限，进而控制这个员工的所操作区域。
2. 帐号的层级：企业（管理员）帐号、普通帐号
公司的实际运营人，他应该掌握最核心、权限最大的企业帐号，所以也可以称为“管理员帐号”俗称admin账号，其他都为普通帐号。
在实际系统中的核心业务步骤如下：
-
企业搭建系统时，默认会用admin作为系统账号的最高权限。下级可以创建企业账号（依托于权限）。
-
在部署培训阶段，可指导企业账号持有人创建一个或多个普通账号（可是给其帐号授权管理员角色），后续配置即由管理员账号进行。
（魅族的小伙伴可以说下，魅族论坛账号为“J.Wong”是不是admin的权限。哈哈哈哈）
在用户状态上加状态控制，可用的用户就可以登录系统，禁用、停用的就无法登录。
二、角色管理角色
往往是基于业务管理需求而预先在系统中设定好的固定标签，每个角色对应明确的系统权限，他是一个集合的概念，是众多最小权限颗粒的组成。我们通过把权限给这个角色，再把角色给账号，从而实现账号的权限，因此它承担了一个桥梁的作用。引入角色这个概念，可以帮助我们灵活的扩展，使一个账号可以具备多种角色。
其所拥有的系统权限一般不会随意更改，并且角色也不会随着用户的被添加和被移除而进行改变，相较于用户管理而言更加稳定。
而引入“角色”概念后，用户与角色之间的关系链是怎么样的？这儿引用一个模型：RBAC模型（已经被大家写文章用坏了，可能有些小伙伴还是懵逼），John这边贴上百度百科解释下：
基于角色的权限访问控制（Role-Based Access Control）作为传统访问控制（自主访问，强制访问）的有前景的代替受到广泛的关注。在RBAC中，权限与角色相关联，用户通过成为适当角色的成员而得到这些角色的权限。这就极大地简化了权限的管理。在一个组织中，角色是为了完成各种工作而创造，用户则依据它的责任和资格来被指派相应的角色，用户可以很容易地从一个角色被指派到另一个角色。角色可依新的需求和系统的合并而赋予新的权限，而权限也可根据需要而从某角色中回收。角色与角色的关系可以建立起来以囊括更广泛的客观情况。
简单点一句话说下：Who（权限的拥有者或主体）对What/Which（权限针对的对象或资源）进行How（权限针对的对象或资源）操作。
上图示意为：用户与角色可为多对一或多对多的关系，当一个用户的角色为多对多时，当前用户的权限是多个角色的并集。
此时只需要为角色赋予权限，能够大大减轻管理负担，同时将用户与权限解耦，提供更大的灵活性。
由于随着公司扩大角色的增多，试想如果用户量上万，新增一个角色时，可能需要为大量用户都分配一遍新的角色，工程量仍然巨大，此时即可以引入用户组的概念：如果部分用户的使用场景是相对一致和基础的，我们可以把这些用户打包成一个组，基于这个组的对象进行角色和权限的赋予。
同理如果权限较多时也会存在一样的问题，处理方式是引入权限组的概念，将使用场景相对固定的一组功能或权限打包成组赋予角色。但是一般来讲一个系统中权限功能的体量是相对有限和可控的，所以实际应用中对权限组的使用较少。
用一个页面例子来解释下：
（用户组）
（用户管理）
（用户权限&权限组）
三、控制功能权限（案例）
功能权限定义：为可见、可以操作的功能范围。例如：某一部分目录，或者某个页面里的各种操作。
1. 目录管理模块
类型分为2种：目录、操作。
在目录上加权限控制，有权限的就可以访问对应模块。
在业务模块的功能按钮上加权限控制，最小粒度的控制用户行为。例如：上级有录入商品的权限，就能看到商品录入的操作，点击录入就可以进行商品的录入操作；反之没有该权限的下级就无法进行商品录入的操作。
（红色的代表目录，蓝色的代表操作）
2. 控制功能权限管理
底层目录管理配置一般为开发人员一早就配置好，现在由用户进行分配使用这些功能权限。
功能权限：以角色为基础，通过划分不同角色的不同功能权限，并将员工添加到对应的角色中，实现员工功能权限的区分和隔离，包括：
-
对象级功能：比如功能的入口是否可见，如角色为“人事HR”，对“人员管理”的“查看列表”权限点取消，则此角色下员工不可见人员管理的功能入口。
-
操作点权限：比如新建、编辑等业务操作；
字段权限：在展示信息时加权限控制，保证敏感信息的安全性。可为角色配置对象字段的读写、只读或不可见。比如：为角色“服务人员”配置销售订单的【销售订单金额】字段不可见。
（字段权限细节）
-
【读写】权限：员工将具备该字段的最大权限，【新建】【编辑】时可编辑，列表和详情页可见该字段。
-
【只读】权限：员工在【新建】【编辑】时不可编辑，列表和详情页可见该字段。
-
【不可见】权限：员工在【新建】【编辑】【列表】【详情】界面对该字段（或该字段值）不可见。
功能权限对于前端界面的影响点：
-
如果员工没有某对象“查看列表”的权限，则该对象的功能入口会被隐藏。
-
如果员工没有某对象的操作点权限，则在对象页面上隐藏相应操作按钮。
-
如果员工没有某对象的指定字段的可见权限，则在对象页面上隐藏相应字段。
总结下：在权限管理中，需要遵循的一个重要的点：用户移动要匹配对应的操作。
四、配置权限注意点
产品设计支持后，配置权限需要注意以下几个要点：
1. 确定是否支持前端配置
如果角色和权限相对固定，则一般将角色与权限的关系可以写在后台，改动时需要后端变更且重新上线；这种情况适用于公司内部系统等只有一个使用主体的系统。
如果需要自定义角色、或者每个角色在不同使用者的场景下有不同的权限，则需要将角色的定义、角色与权限之间的配置体现在“前端用户配置页面”；这种情况适用于有频繁变动的自定义角色权限，和有租户体系的系统。
2. 以基本单元拆分，以业务逻辑配置
一般可将每个对象的“增、删、改、查”各自作为一个基本的权限单元。打个比方，在“人员管理”中，查看人员列表、添加人员、删除人员、编辑人员信息最好拆分为4个权限单元。在技术和设计上，我们希望能尽量做到解耦和模块化。
但是在业务层面有些操作却是一体的。这些不能拆开的权限在“前端用户配置页面”中建议打包成一个整体提供配置。例如，如果我们确定在系统的现有和未来业务中，仅分为普通成员有“人员管理”的查看权限，管理员有操作权限，则可将“增、删、改”三个基本权限单位合并为“操作”权限进行配置。
3. 页面权限优先于操作和数据权限
必须配置了页面模块权限后，才能配置当前页面模块下具体的操作权限，以及页面模块的数据展示权限；
4. 查看权限优先于增删改权限
正常情况下，一定要先能查看某个模块或操作，其它的增删改操作才有意义。因此在设计时，应在获取查看权限前限制其它权限的配置；或者配置其它权限时默认赋予查看权限。
5. 角色与权限的多种关系
角色与权限的关系不仅是单纯“是/否关系”，还包括以某种限制进行操作，和以某种程度访问数据。例如在“人员管理”中：
-
数据范围：用户拥有查看人员列表的权限，但仅能查看自己所在的团队；
-
数据边界限制（上限等）：添加人员时不能超过20个等。
-
数据字段：HR能查看人员列表中包括职级、薪资等字段；其它角色仅能查看姓名邮箱等字段；
6. 角色与权限的设计表达
在传达一个系统的权限设计规则时，设计师常常习惯用主观最直接的方式表达想法，如用“当……时，就……”的句式来表达。但一个平台中涉及的权限规则是非常多的，当通篇以这样的形式描述时，表达对象将很难理解。
正确的描述方式：更清晰的是基于开发的语言，和技术模型的结果进行表达：将各角色与权限单元绘制成网格，每个交叉点网格中描述该角色与权限的数据关系和限制。
五、后台产品逻辑自查表
后台产品逻辑遵循的就是八个字：“增（增加）”、“删（删除）”、“改（修改）”、“查（查询）”、“显（显示）”“算（算法）”、“传（传递）”和“异（异常）”。用一张表来整体看下自查表：
后台权限不复杂，用户角色和权限一一对应匹配就好了。同样前端后台都不复杂，只要真实清楚的去了解业务就好了。
