产品学习笔记-后台权限控制-20181023
时隔1个月，学习笔记启动。
理论
权限控制有一套很成熟的体系：RBAC(Role-based access control)基于角色的访问控制。
1.RBAC认为权限的过程可以抽象概括为：判断【Who是否可以对What进行How的访问操作（Operator）】这个逻辑表达式的值是否为True的求解过程。即通过who、what、how构成了访问权限三元组。
2.RBAC支持公认的安全原则：最小特权原则、责任分离原则和数据抽象原则。
- 最小特权原则*，是在RBAC模型中可以通过限制分配给角色权限的多少和大小来实现，分配给与某用户对应的角色的权限只要不超过该用户完成其任务的需要就可以了。
- 责任分离原则的实现，是因为在RBAC模型中可以通过在完成敏感任务过程中分配两个责任上互相约束的两个角色来实现，例如在清查账目时，只需要设置财务管理员和会计两个角色参加就可以了。
- 数据抽象是借助于抽象许可权这样的概念实现的，如在账目管理活动中，可以使用信用、借方等抽象许可权，而不是使用操作系统提供的读、写、执行等具体的许可权。但RBAC并不强迫实现这些原则，安全管理员可以允许配置RBAC模型使它不支持这些原则。因此，RBAC支持数据抽象的程度与RBAC模型的实现细节有关。
3.基本模型RBAC0定义了完全支持RBAC概念的任何系统的最低需求。
RBAC0的模型核心：用户User、角色Role、许可权Permission、会话Session实体集合。
- RABC0权限管理的核心部分，其他的版本都是建立在0的基础上的。
- 用户users(USERS)、角色roles(ROLES)、目标objects(OBS)、操作operations(OPS)、许可权permissions(PRMS)五个基本数据元素，此模型指明用户、角色、访问权限和会话之间的关系。
- 有如下规则
- [ ] 每个角色至少具备一个权限，每个用户至少扮演一个角色；
- [ ] 可以对两个完全不同的角色分配完全相同的访问权限；
- [ ] 会话由用户控制，一个用户可以创建会话并激活多个用户角色，从而获取相应的访问权限;
- [ ] 用户可以在会话中更改激活角色，并且用户可以主动结束一个会话。
- [ ] 用户和角色是多对多的关系，表示一个用户在不同的场景下可以拥有不同的角色。
- [ ] 将用户和许可进行分离，是彼此相互独立，使权限的授权认证更加灵活
- [ ] 角色和许可（权限）是多对多的关系，表示角色可以拥有多分权利
实例
RBAC（Role-Based Access Control，基于角色的访问控制）就是用户通过角色与权限进行关联
1.当用户的数量非常大时，要给系统每个用户逐一授权（授角色），是件非常烦琐的事情。这时，就需要给用户分组，每个用户组内有多个用户。除了可给用户授权外，还可以给用户组授权。这样一来，用户拥有的所有权限，就是用户个人拥有的权限与该用户所在用户组拥有的权限之和。
-
角色是什么？可以理解为一定数量的权限的集合，权限的载体。
eg,要给某个用户授予这些权限，不需要直接将权限授予用户，可将“版主”这个角色赋予该用户。
（上述两点下图用户组、用户与角色三者的关联关系表）
用户组、用户与角色三者的关联关系
2.在应用系统中，权限表现成什么？有些权限设计，会把功能操作作为一类，而把文件、菜单、页面元素等作为另一类，这样构成“用户-角色-权限-资源”的授权模型。注意，
- [ ] 请留意权限表中有一列“权限类型”，我们根据它的取值来区分是哪一类权限，如“MENU”表示菜单的访问权限、“OPERATION”表示功能模块的操作权限、“FILE”表示文件的修改权限、“ELEMENT”表示页面元素的可见性控制等。
- [ ] 这样设计的好处有二。其一，不需要区分哪些是权限操作，哪些是资源，（实际上，有时候也不好区分，如菜单，把它理解为资源呢还是功能模块权限呢？）。其二，方便扩展，当系统要对新的东西进行权限控制时，我只需要建立一个新的关联表“权限XX关联表”，并确定这类权限的权限类型字符串。
- [ ] 权限表与权限菜单关联表、权限菜单关联表与菜单表都是一对一的关系。（文件、页面权限点、功能操作等同理）。也就是每添加一个菜单，就得同时往这三个表中各插入一条记录。
- [ ] 数据表建模时,可把功能操作和资源统一管理，也就是都直接与权限表进行关联，这样可能更具便捷性和易扩展性。
权限分类表
而在做数据表建模时，RBAC权限模型的扩展模型的完整设计图如下：
RBAC权限模型的扩展模型的完整设计图
设计
可参考文章
[1] 一款后台产品的用户管理系统，哪些功能点不可或缺？
[2] 后台经验分享：如何做权限管理系统设计
[3]电商后台系统：管理后台之账号管理（一）
[4]三个模块，搭建后台用户角色权限管理系统
1、常见的常规管理功能
- 用户管理用户按架构新建在对应的组织上。一般挂到机构→部门（一级部门–二级部门）下。对于公司内部管理系统，管理用户的前提，是需要合理的组织架构，只有支持组织架构的灵活配置，才能进一步支持组织内人员的增删调整。
- 角色管理所有角色的管理功能。新建角色时，可将角色建立在某级机构或机构及以下，代表此角色只能适用此级别或此级别以下级别。
- 菜单管理（有的后台叫栏目管理）支持自主配置菜单一级二级，支持新增菜单、修改菜单、删除菜单，更改菜单（修改菜单名、菜单顺序等），每个菜单对应一个权限。
- 组管理用户所属组，用于配置统一组同一部门用户。有了用户组，在新建角色时，可直接将角色赋予某个组，则进入此组的人员自动获得对应角色。
2.密切相关的工作流
- 一个业务流程包含多个环节的审批确认关系，按照业务流程，将各个节点串接起来，即时工作流。系统实现各个节点的自动流转，解决手工处理工作流程的低效和失误，提高工作效率的同时，还可通过线上直接流程状况进行实时跟踪，实现业务流程流转的自动化。
- 常见节点动作：
提交：每个节点的人将流程提交至下手岗位。
回退：可退回到某个节点继续流转，退回到发起岗，或退回到前手岗。
撤回：节点执行完后、下一节点执行前，可以收回进行修改然后再提交。
取消/撤销：流程发起人执行取消流程。
中止：流程提前结束，当前节点之后的其它节点不再执行。
审批：表单中的某个字段，用于填写审批意见。
会签：通常用于审批后给相关的人签字确认，需要签字确认。
知会：指定的人知道有这个流程这么回事，并能查看流程，不需要签字确认。
加签：审批时，可以征求另一人或多人的意见，然后再回到原审批人。
跳签：跳过接下来的一个或连续的多个节点，直接到指定的节点执行。
...... - 上报关系
每个节点提交后，下一节点将有谁审批？一般会为对应岗位的人员配置对应的节点。但若涉及到分公司或分地区审批，则需要设计上报关系。
上报关系支持灵活配置前一岗与后一岗的对应关系。 - BRAC和流程节点，在设计过程中，还需考虑其灵活性。
如操作员入职流程完毕后，自动赋予其岗位对应角色权限，当然这可通过对用户组分配角色实现。当操作员调岗时，根据调岗的跨度大小，自主确定是否更改权限或删除权限。流程节点在系统中可根据对应业务，后台预备支撑性较强的节点变量，支持前台配置，由管理员自主根据对应业务流程，配置相应的流转节点。
【摘自】
[1] 权限系统与RBAC模型概述(绝对经典)
[2]后台设计的基石：用户权限管理（RBAC）及工作流（workflow）模型
[3]参考文献1
[4]参考文献2
[5]如何设计出色的网站后台原型？
前段时间做后台实在是无从下手，在网上搜，也没什么系统的课程或者书籍，咨询了同事，推荐如下书籍，希望读完能帮助提升自己对后台的一定认知。
【推荐书单】
《淘宝十年产品事》
[《电商产品经理宝典》]
[《大象UML》]
[《产品设计思维电商·全攻略》]
