发现每次设计权限体系都很痛苦，归根结底就是没有沉淀出一套方法论。看了下网上的文章大多是讲RBAC权限管理模型RBAC0介绍到RBAC3，看的吐血了，还是自己总结点实际点的东西。
设计B端产品，无可避免会涉及权限管理的问题。
为什么呢？
因为B端产品生来就是带着组织结构属性的，它辅助我们分工、协调和合作。所以我们的产品必须紧紧切合职、责、权这三个主题。
简介
权限管理，一般指根据系统设置的安全规则或者安全策略，用户可以访问而且只能访问自己被授权的资源，不多不少。
原因
为什么要做权限管理呢？
权利不同可以了解的数据内容不同，保证数据隐私，避免数据泄密；
职责不同所需要页面不同，保证操作效率，避免页面干扰；
技术水平不同可以操作的功能不同，保证系统安全，避免操作风险。
还有其他要素，都注定了要独立出一个权限管理模块来规范操作和数据权限。
原则
权责明晰：
权：专人做专事，既可以防止误操作，又避免干扰。比如自身才可以编辑和删除。
责：能将错误行为定位到人，落实责任。比如操作作业和表都带上责任人的信息。
界限分明：
功能：将功能按不同层级或者属性进行划分；
数据：将数据按业务类型或者组织架构特性进行划分。
流程规范：
依赖：允许用户依赖别人作业和查看作业信息，保证组织的流畅性；
继承：根据实际情况要考虑流程的容错性，比如是否可以跨节点确认。
原理
所以每个用户都需要权限限定，但是直接给用户赋上权限，会有很多问题：
灵活度低，如果某个操作权限关掉了，需要一个个找出用户依次修改权限。
所以基于传统的权限模型进行改建，RBAC模型是一个成熟的权限模型，虽然被讲烂了，但是还是假装不知道重新介绍下。
RBAC（Role-Based Access Control）基于角色的访问控制，不同于传统的权限模型直接赋予使用者权限，而是将权限赋予角色。
用户与角色相关联，是多对多关系；
角色与权限相关联，是多对多关系。
项目管理
项目是用来隔离数据和用户的，用户加入当前项目才可以享受该项目下的资源。你可以把项目当做部门就明白了，A部门的用户不可以查看B部门的数据。
注意：删除项目，需要提示是否删除项目下的数据，如果删除有很多风险，那就禁用删除吧。还有一种折中的方法，就是删除时允许将项目下的资源迁移到其他项目。
用户管理
管理用户信息，以及对用户进行增删改查，包括用户名称、所属部门、联系电话等信息，至于密码，一般只能重置密码，而不是显示密码允许修改。
注意：
源：一般我们可以和OA关联拿取账号，而不需要在产品里添加，保证内部系统信息一致性。
交接：如果用户的信息被产品某些功能所引用，必须考虑用户离职后，其创建的资源管理的问题，这时候被赋予所有权限的管理员是个很好的接盘侠。
用户组管理
用户组其实就是批量给用户赋予角色，将多个用户绑定为一个小组，再给这个小组赋予一个角色。
注意：如果内部组织架构不复杂的话，最好不要加入用户组，不然增加了权限体系的复杂性，毕竟杀鸡焉用牛刀。
角色管理
管理角色信息，对角色进行增删改查，包括角色名称、角色描述和角色状态等。
可以将角色理解为将权限打包成一个小组，那个小组就是一个角色。
页面权限：页面权限指用户可以看到的页面。如果你的产品比较复杂，可能你需要从模块权限到菜单权限最后到页面权限。
操作权限：操作权限指用户可以操作的内容，即按钮权限，是否有增删改查的权限。
思考
衔接自然：比如根据项目区分数据权限，根据岗位区分角色，将现实的角色与产品角色相关联，显得更自然。
轻装上阵：很多人一讲到权限管理，就希望把它设计的非常全面严谨，但是逻辑上的全面严谨和功能上的全面严谨完全是两回事。如果前期不需要，完全没必要多抽象出几个概念，需要考虑的反而越多。所以在能满足权限的需求下，就不要多设概念，比如抽象出用户组这种，很可能基本用不到，而且还增加了系统复杂度。
随机应变难道一定要遵从RBAC模型吗？等你真正参与项目，就会发现，RBAC模型仅仅只是个开始，它只是帮你打好基础，之后还会有各种各样个性化的需求，绝对不仅仅现在说的这么简单······
参考
大数据开发平台权限管理
后台经验分享：如何做权限管理系统设计
后台系统：账号权限系统设计
以RBAC模型为基础，分析B端权限系统的设计思路（业务技能）
一个案例，三个角色，简单说下B端产品的权限设计
