admin 的权限设计方案
当前权限系统设计（RBAC）
Admin 系统采用了一套 Role Based Access Control（RBAC）设计方案，其中 Access 是代码中实际进行权限判断的信息，Role 是为了便捷的分配一组权限而设置的。
当前问题：
权限定义
- 权限用于控制页面和功能的交互，但粒度标准不一致，且权限之间关系没有考虑在内
角色分配
- 角色描述不清晰，难以被理解
申请
- 申请流程不标准
- 申请人不清楚该申请的角色
- 申请人申请的角色缺少审批&管控
- 只有 Camila 可以进行账户管理，工作量大
新功能权限/角色创建
- 权限和角色定义模糊，创建的思路不统一
- 新功能权限的创建比较随意，没有规范流程
- 权限和角色的创建人(开发)和使用人(需求方)分割，导致创建后难以分配和管理
权限系统理解
- admin 权限系统没有在公司内形成一致的理解，权限/角色概念不清晰
其他
- 新用户/离职权限管理
ref: 需求列表
主要改动
- 规范权限/角色概念， 添加
用户组概念， 添加权限管理人 角色 - 规范申请权限，人事变动，上线新功能的权限管理流程
- 整理现有权限/角色，规范 开发/用户/PM/管理人 责任划分
- 建立
权限管理人白名单 - 完善 admin 权限管理功能， 添加几个新的功能页面
未来期望场景
权限申请流程：
除了 Camila 之外建立代理机制，可以让每个模块/业务团队单独分配角色
在新的申请流程里面， 申请人只需要找到对应权限管理人申请既可
添加新权限/角色流程：
- 由 PM 在设计需求的时候同时设计，然后同步给需求方以及开发， 开发按照 PM 设计的需求开发对应的权限
- 需求上线时，新角色分配给权限管理员，然后由权限管理员分配角色给用户组或用于
新责任划分
- 权限代理人： 拥有
团队的权限，拥有一些权限可以自己分配，可以拥有用户组的管理能力，负责在团队有新的人员/权限的时候进行分配，权限管理人的权限变动可以其他管理人或者 PM - PM：对应业务部分相关权限的负责人，上线新需求的时候按标准设计新的角色和权限并给到对应业务组和开发，对已有权限进行维护和整理。
- admin 开发： 开发负责角色的对应权限的开发，以及在角色制定的时候进行 review
- 业务团队/用户： 业务团队在人事变动和业务改动的情况下寻求权限管理人去管理对应权限
- 用户组管理人： 用户组管理人可以管理用户组，这个角色可能是权限管理员，也可以是管理员分配
权限相关设计方案
权限（Access）
- 权限的作用
权限是代码中实质的管控目标。用户在 Admin 页面中是否有查看和操作权限，完全由权限来控制。但是对于用户而言权限是透明的，通常用户知道自己拥有什么角色，不必知道自己有什么权限。
- 创建职责
对于新开发的功能或模块，PM 提交权限设计，Admin 团队评审。
- 设计标准
通常页面访问和页面内需要做访问控制的最小粒度功能，可以被设计为一个权限。例如一个页面中含有一张表格，可以对表格中的记录进行增删改查，则对应的潜在权限为：页面访问权限（控制展示页面入口）、表格查看权限、表格中记录的操作权限：删除、添加、修改。如果需要针对表格中的内容进行进一步的限制，用户根据自己的权限只能访问符合特定条件的记录，例如只能访问特定国家地区的记录，则这一类权限控制不在这一部分，我们将另辟章节讨论。
1. 权限类型：Admin系统权限是前端权限，既按前端使用思维设计
1. 命名规范
1. 采取类似目录层级形式的命名方式，属于同一模块、同一页面的权限，阅读名字可知
1. 通过名称能看出去权限的大致类型（页面、操作、内容等），用词多用xxx_page, manage, view, cancel, delete 等。
1. 权限分类：页面（目录）访问权限 和 页面内权限（例如功能权限）& 内容权限
1. 权限关系：页面内权限继承页面访问权限，例如页面中某个功能提交权限自动继承页面访问权限
1. 权限粒度
- 权限不跨页面
- 设计时页面访问和页面内操作尽量分开，避免权限过大需要拆分
订单模块的权限示例：
| 权限名 | 描述 |
|---|---|
| booking/booking_tasks_page | booking 模块 booking tasks 页面的访问权限 |
| booking/booking_tasks_page/manage | booking 模块 booking tasks 页面内 tasks 管理权限 |
| booking/order_summary_page/fraud_recovery/manage | booking 模块 order summary 页面里 fraud 恢复的管理权限 |
- 审计和维护
维护职责：Admin 系统开发人员
权限相对变动少，需要定期评估的有：
1. 定期报告检查和清理未使用权限
1. 收集反馈拆分过大权限、或添加缺失的权限控制
1. 根据内审团队提供的权限关系表，审核是有账号同时有用有冲突的两个权限（有些权限因为业务原则，不能被同一账户同时拥有）
角色（Role）
- 角色的作用
角色是向账户分配权限的最小单位，角色是一组权限的集合。我们不直接向账户分配权限，而是向其分配角色。通常权限多且散碎，角色一组相关权限整理到一起，需求方只需理解到角色的含义。
- 创建职责
PM 根据产品交互流程/操作流创建角色，Admin 系统开发人员 review
- 设计标准
在我们设计中，角色与用例（Use Case）直接相关，包含一个用例中所有步骤涉及的一组权限。
1. 角色类型：是功能角色，而不是用户职位。例如角色是财务对账单审核者，而不是财务总监
1. 命名规范
- 与Access的目录式名称不同，权限名称字符串中词语用下划线'_'连接
- 能看出所属模块（模块命名空间）
- 避免使用用户职位名称（如LOC PM），应该用系统角色名称（LOC Request Manager)
- 名称中建议使用manager/editor/viewer/operator等尾缀
1. 角色粒度
- 角色不跨模块
- 角色是按照用例的交互流程来设定，完成一个用例中所有操作需要的权限可以设为一个角色（完备性）
- 多数情况下用例的设置比较自然且显而易见，但也有写情况下，用例可大可小，是否进一步拆分用例原则为，如果理论上一个用例中有部分操作与整体操作需要进行不同的权限控制，则应该拆分用例，并设置不同角色。例如，有些数据表的相关用例只有两个，即view和manage。但有些业务场景需要对manage部分进行进一步拆分，例如需要拆出一个create用例仅仅负责插入记录，然后manage进行所有的管理操作。
订单模块的角色示例：
| 角色名称 | 对应权限 |
|---|---|
| booking_booking_tasks_viewer | booking/booking_tasks_page |
| booking_booking_tasks_manager | booking/booking_tasks_page booking/booking_tasks_page/manage |
| booking_fraud_recovery_viewer | booking/order_summary_page booking/order_summary_page/fraud_recovery/view |
| booking_fraud_recovery_manager | booking/order_summary_page booking/order_summary_page/fraud_recovery/view booking/order_summary_page/fraud_recovery/manage |
- 审计和维护
- 维护职责：相关模块的 PM
- 角色作为权限和用户中间一层抽象，变化会比较多，尤其是考虑到设计的标准本身很难严格细致：
- 定期报告检查和清理未使用角色
- 定期检查过大过小角色，看是否有拆分和合并的可能
- 定级检查角色查看是否其中含有互相冲突的权限（有些权限因为业务原则，不能被同一账户同时拥有）
账户相关设计方案
账户（User Account）
- 账户的作用
- 用来登录 Admin 系统，最终所有角色分配的对象，以及权限管控对象。
- 创建职责
- klk 员工：员工自行创建。使用 klk 账户初次登录 Admin 系统，会自动创建 Admin 系统账户。
- 非 klk 员工：Camila 和账户所有者。Camila 加白名单，账户所有者初次登录 Admin 系统创建账户。
- 设计标准
- 难点是能否约束尽可能多的账户都有所属部门信息。对于有所属部门信息的账户，就可以由部门的权限管理员对其进行部分权限管理（分配用户组）。
- 审计和维护
- 账户的审计和维护主要是指关闭账户操作。
- 维护职责：Camila 和各部门权限管理人员
- 主要工作内容：
- 按部门定期出报告或者有页面可以查询到 部门内账户情况，审查是否所有账户需要关闭
- 关闭时需要清除所有的权限
- 非 LOOK 员工账户关闭时需要移出白名单
- ？关闭账户操作最终由各部门权限管理员执行，还是 Camila 执行？
用户组（User Group)
- 用户组的作用
- 按岗位职责，定义一组常用的角色，便捷的分配给账户
- 部门权限管理员有权限将部门内用户，加入到部门里的所拥有的用户组
- 创建职责
各部门权限管理员，根据团队内岗位和职责定义用户组。
- 设计标准
- 用户组类型：是用户职位，而不是系统角色。例如职位是翻译项目经理，而不是翻译请求管理者
- 命名规范：尽量使用职位进行命名
- 用户组关系：用户组属于部门（部门信息不完善的过渡期内，用户组属于部门权限管理员），部门有层级关系，上级部门拥有下属部门的所有用户组；以职位常用为标准，将一组角色分配给用户组，这些角色可以跨功能模块。
- 用户组粒度：用户组不能跨部门，例如两个部门都需要项目经理，但是需要两个不同用户组
- 审计和维护
- 维护职责：各部门权限管理人员
- 维护内容分为三块：
- 定期报告，将不再需要相关权限的用户，移除相应用户组
- 定期报告，检查是否需要拆分、合并、新建、删除用户组
- 定期报告，检查是否需要调整用户组的角色，调整用户组角色时可能也要相应调整对应用户的角色。例如某个角色并非用户组通用，只有少数用户需要，从中移除后需要为少数用户单独加上这些角色
部门（Department/Division)
- 部门的作用
- 约束部门权限管理员能管理的用户组，所有的用户组都归属于某个部门
- 约束用户组可被分配给的用户，所有用户（或有特例）都有部门信息，所有部门都有权限管理员，后者可为前者分配用户组
- 创建职责
- 从 workday 中传入，从 workday 的部门层级中挑选某一级或者某几级作为 Admin 权限系统的部门。
- 初期通过 RaaS，每日更新
- 后期通过 API 实时获取
- 设计标准
- 部门类型：用户从 HR 角度的部门信息，部门权限管理员类似于 BLM
- 部门关系：
- 部门有指定的权限管理员（可多值）
- 用户组属于部门
- 用户属于部门，部门有层级关系
- 部门有权限管理员有权分配本部门的用户组给本部门的用户
- 通过审批流程，Camila 有权限分配任意用户组给任意用户
- 审计和维护
- 维护职责：各部门权限管理人员
- 有了部门之后可以做一些相关审计：
- 本部门用户拥有的非本部门用户组报告
- 非本部门用户拥有的本部门用户组报告
分阶段计划
Step 1 - 项目开展的前提——整理现有权限和角色（订单模块）
在这一步，制定权限和角色的设计标准，按这个标准清理现有权限和角色，并加上合理的描述。
主要变化有：
- 订单模块将会使用新的权限&角色定义
- 有了一套新的标准 ，后续 PM 和 Admin 系统开发都要按规范设计角色和权限
- 有一套 guideline , 以后权限申请请求都有统一的格式，Camila 也知道判断哪些人有权提交申请表。更重要的是有了部门权限管理员这个角色，后面很多事情可以由这个角色完成。
- 初步整理权限管理人名单
Step 2 - 增加模块
这一步逐渐完成 admin 系统已有权限角色的整理&迁移
Step3 - 新增用户组
部门权限管理员基于部门内的职位/职责来整理出用户组，用户组包含职位/职责的常用的一组角色。
部门权限管理员可以替组内成员申向 Camila 请加入属于本部门的用户组。
新建用户组页面, 各部门权限管理员有查看权限, Camila 有管理权限。
主要变化有：
这样部门权限管理员就可以根据员工的职位/职责申请一个或者多个用户组，如果用户组覆盖不到的角色再单独申请。虽然还是要经过 Camila，但是有了用户组，可以更高效的给用户申请权限。
Step4 - 自助在线分配用户组
部门权限管理员可以自助将用户加入/移除自己所拥有的用户组。同时为员工申请权限也可以通过页面提交，审批也在页面中进行。
主要变化有：
大部分的权限开通请求到不了 Camila 这边，部门权限管理员通过将用户加入/移出其管理的用户组就可以实现。
Step5 - 在线提交权限申请、和用户组变更申请
之前虽然部门权限管理员可以为员工提交权限申请，但是申请是通过申请表发送。审批也是 Camila 线下进行，然后手动在 Admin 系统中操作。
另外Step3 - 新增用户组中，如果部门权限管理员需要修改用户组（增删用户组、增删用户组中角色），都需要通过线下申请流程。
这一阶段支持两种申请通过线上提交和审核，审核后自动生效。
主要变化：
除非特殊情况，Camila 不再收到线下的申请。大部分工作转为线上。
Step6 - 强化部门概念，建立部门实体
截至目前，部门只是账户的一个可选属性。根据设计，用户归属于部门、用户组归属于部门，权限管理员对部门行使管理权限而不是用户组。
一个缺点是，无法根据部门进行控制，例如一个部门权限管理员，可以将其拥有的用户组分配给其他部门的人，或者可以为非本部门员工提交申请。
这里通过联通 Workday，引入员工部门信息，并将用户组纳入部门。
主要变化：
角色申请和用户组内成员管理更可控，所有跨部门的申请都需要经过 Camila。
Camila 可以更高效的在线审核申请。