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