2019/3/10
什么是RBAC
权限系统通常基于RBAC（Role-Based Access Control）的思想设计，拥有4个关键元素：
用户 – 角色 – 权限 – 资源。
λ 资源
被安全管理的对象（Resources页面、菜单、按钮、订单等）
λ 权限
访问和操作资源的许可（Permit删除、编辑、审批等）
λ 角色
我们通过业务流程确定一个角色，实际是确定角色并角色具备的那些权限的过程，角色所以是权限的集合，是众多权限颗粒组成；
我们通过把权限给这个角色，再把角色给用户，从而实现用户的权限，因此它承担了一个桥梁的作用。
引入角色这个概念，可以帮助我们灵活的扩展，使一个用户可以具备多种角色。
λ 用户
系统实际的操作员（User）
【用户(user：谁)】被赋予【角色(role：具有1-n个权限)】，通过角色关联的【权限(permit：许可)】去访问/操作【资源(resource)】
场景：
张三（user）是人事主管（role），可以看到李四的请假申请（resource），并批复同意（permit）
为什么需要RBAC
传统权限模型
传统模型中无角色概念，用户直接被赋予权限；
1、 导致配置权限相当麻烦
2、 无法快速为多个用户批量删除/编辑权限
3、 用户多身份下权限配置维护麻烦
用户—角色—权限多对多的关系，解决了这些问题，权限修改只需对角色的关联权限进行修改。
若多身份，只需多用户进行多角色赋予即可。
权限通过角色来赋予至用户，使得用户即使发生变更、离职也不会影响权限本身的稳定性。
RBAC Types
RBAC模型可以分为4种类型：
RBAC0/ RBAC1/ RBAC2/ RBAC3
1、2、3种衍生类型均给予RBAC0衍化。
RBAC0
场景：
公司运营时段时间了，形成了不同的部门，每个部门专注于自身的工作内容和客户，不同身份的员工应当杜绝互相看到或具备干预其他部门的业务情况出现，所以需要对每个员工进行权限的控制。
此场景处理时引入RBAC处理如下：
前提：资源已经被抽象出来，资源关联的权限已经清晰。
抽象定义阶段
1、抽取资源及相关权限
员工管理
查看员工、新增员工、修改员工、删除员工… else
客户管理
查看客户、新增客户、修改客户、删除客户… else
… else
2、定义角色及关联相关权限
角色定义，一般从岗位进行抽取，或者通过业务流程进行定义。
是指在组织内需要承担特定的动作或活动，并且可能与其他业务角色有互动的角色。
角色 权限
人事专员 查看员工、新增员工、修改员工、删除员工… else
销售专员 查看客户、新增客户、修改客户、删除客户… else
… else
功能落地阶段
1、构建角色
2、赋予员工对应角色
RBAC0是RBAC权限模型基础。
权限设计时将权限赋予给角色，而不是用户，一个用户可以拥有若干角色，从而使用户可以获得更广泛的权限。
就此构造成“用户- 角色- 权限”的授权模型。
在这种模型中，用户与角色之间，角色与权限之间，一般者是多对多的关系。
角色和权限绑定，用户被赋予相应的角色，通过多对多的关系来实现授权和授权的快速变更，从而控制用户对系统的功能使用和数据访问权限。
在RBAC模型下，我们只需要将组织中的角色进行抽象，例如销售经理、财务经理、市场经理、市场专员...
然后把权限分配给这些角色，再把角色赋予用户。
这样无论是分配权限还是后期进行权限的修改，只需要修改用户和角色的关系（分配），或角色和权限的关系即可（维护），更加灵活方便。
此外，如果一个用户有多个角色。
譬如王先生既负责销售部也负责市场部，那么可以给王先生赋予两个角色，即销售经理和市场经理，这样他就拥有这两个角色的所有权限。
RBAC1
场景：
A公司新招很多员工，其中包括很多管理岗位，it部门在位新员工开通账号时发现，给管理岗位员工进行角色赋予时遇到一个很麻烦的问题，管理岗位不能直接拥有下属的权限，
比如给销售经理角色进行分配时，下面的销售专员，销售助理等她们的权限销售经理是不能直接获得的。
怎样才能让销售经理直接拥有下属员工的权限呢？
这种情况就适合RBAC1模型，对角色进行继承。
基于RBAC0模型，引入角色间的继承关系，即角色上有了上下级的区别；
角色间的继承关系可分为一般继承（General）和受限继承（Limited）。
λ 一般继承关系：
要求角色继承关系是一个绝对偏序关系，允许角色间的多继承。
λ 受限继承关系：
进一步要求角色继承关系是一个树结构，实现角色间的单继承。
受限继承则增强了职责关系的分离
一般继承和受限继承的区别，一般继承是图；
受限继承可以有多个父节点，但子节点只能有一个，是一个反向树结构。
概念图解：
λ 一般继承关系
行政主管
|
|--------------------|--------------------|
| | |
v v v
行政管理员 行政秘书 行政专员
xx权限 xx权限 xx权限
行政主管权限继承自行政管理员、行政秘书、行政专员
λ 受限继承关系
角色继承用来解决组织机构之间的权限关系。
角色继承的方向和用户关系的方向时相反的，举例：
用户继承关系–>
业务员 -> 部门经理->总经理
角色继承关系->
总经理-> 部门经理->业务员
举例：所有role_Sales（业务员）的权限role_Mgr（部门经理）都具有，那么即role_Mgr）继承自role_Sales。
了解基本概念后，以上场景解决方案如下：
1、抽取业务角色
行政主管、行政专员、行政助理 … else
销售主管、销售专员、销售助理 … else
产品主管、产品专员、产品助理 … else
人力主管、人力专员、人力助理 … else
市场主管、市场专员、市场助理 … else
… else
2、确定角色层级关系
行政主管
|--------------------|--------------------|
v v v
行政专员 行政助理 行政…
… else
3、确定角色与用户赋予关系
哪些用户，需要被赋予那些角色。
功能落地阶段
1、角色创建/维护
2、用户创建/角色分配
角色管理
角色名称 继承角色 生效 操作 更新时间
行政专员 无 是 修改/删除 Date
行政助理 无 否
行政主管 行政专员、行政助理
xx专员 无 是 修改/删除 Date
xx助理 无 否
xx主管 xx专员、xx助理
… else
RBAC2
场景：
最近公司议论纷纷，因为一个叫张玛丽的同事，他是老板的小姨子，但在公司却即是会计，还同时是审计，这钱怎么支出的，合规不合规大家都不知道，财务总监也犯怵，万一真在钱上出了叉子可怎么办？
这种情况就适合RBAC2模型，对角色进行限制。
RBAC2同样建立在RBAC0基础之上，仅是对用户、角色和权限三者之间增加了一些限制，实现了责任分离。
RBAC2约束当角色被赋予给用户时，或用户在某一个时刻激活了一个角色时，需要遵循一些强制性的规则。
这些限制可以分成两类，
即静态职责分离SSD(Static Separation of Duty)和动态职责分离DSD(Dynamic Separation of Duty)。
约束（Constraining）和 用户– 角色– 权限一起决定了RBAC2模型下用户的访问许可。
λ 静态职责分离（SSD）
当角色授权给用户时，需要判断当前用户是否被赋予了一个与新角色冲突的角色，冲突的角色位一个二元关系，任何一个用户在此场景下只能拥有其中一个角色。
λ 动态职责分离（DSD）
在角色分配时可以将冲突的角色赋予给同一个用户，但是在用户使用系统时，一次会话中不能同时激活两个角色。
举例（引用）：
在超市POS系统中，杨翠花可以即是收银员（role_staff），也是收银主管（role_dire）。
收银员必须要经过主管才能打开收银机的抽屉修改某次结算错误。
在此场景下，DSD要求用户必须先放弃收银员的角色；
即，当发生结算错误时，收银员需要先关闭抽屉，然后再以收银主管的身份打开抽屉，才可以进行结算纠正相关的处理。
RBAC2对角色的限制有此类：
角色互斥、基数约束、先决条件角色约束、运行时互斥等。
1. 角色互斥（SSD）：用户不能分配到互斥角色集合中的多个，在互斥的角色中只能选择一个
如：财务当中的会计和审计不能同时被赋予给同一个用户
2. 基数约束（SSD）：一个用户能够拥有的角色是有限的，一个角色拥有的权限也是有限的
如：某个角色是为CEO准备的，那就不能有多个
3. 先决条件角色（SSD）：用户想要获得较高的权限，受限需要获得低一级的权限
如：有副经理的权限才能有总经理的权限
4. 运行时互斥（DSD）：如果用户同时拥有多个互斥角色，但运行时只能激活其中一个角色
如：想要给自己发工资就需要先放弃自己员工的角色
针对本次场景，解决方案如下：
采用动态责任分离处理互斥角色处理
抽象定义阶段
1、抽取业务角色
行政主管、行政专员、行政助理 … else
销售主管、销售专员、销售助理… else
产品主管、产品专员、产品助理 … else
人力主管、人力专员、人力助理 … else
市场主管、市场专员、市场助理 … else
… else
2、确定角色互斥关系
角色名称 互斥角色集合
会计 审计、出纳 … else
3、确定角色与用户赋予关系
哪些用户，需要被赋予那些角色。
功能落地阶段
1、构建角色
2、角色赋予
RBAC3
RBAC3时RBAC1和RBAC2的合集，这种模式即要维护好角色间的继承关系处理好分层，又要处理角色间的责任分离。
统一模型：
RBAC3 = RBAC1 + RBAC2
权限设计基本的模块划分
权限设计基本围绕权限本身相关资源展开，核心包含用户、权限、角色等
（简单作为演示说明，实际根据业务丰富）
用户管理
用户为系统使用者，对应实际环境的员工。
用户的管理包括用户的构建，删除，信息修改，激活，禁用，角色授权等。
用户构建（示意）
如果授权动作叫复杂，内容项较多，用户构建、用户角色授权可以分开，上图仅做示意
No 名称 工号部门 职位 账号 角色 状态 操作
1 杨翠花 10 xx 收银柜台 cuihuayang 收银员，xxx 激活 xxx/xxx
…
用户列表（示意）
角色管理
角色创建（示意）
编号 角色名称 状态 权限 对应用户 操作
xxx/xxx/xxx xxx/xxx/xxx
角色列表（示意）
权限管理
权限管理从功能操作（页面+功能）、数据管理两个不同颗粒度等级来考量的。
权限的抽取可以是开发层面随着项目的迭代同时进行权限的控制，也可以做成后台进行统一管理
构建权限（示意）
权限名称 权限类型 权限地址 管理操作
查看付款申请 功能权限 abc/def 编辑/删除
… else
权限颗粒– 功能菜单权限
粗力度权限控制，获得当前权限后页面所有数据可查看或操作
权限颗粒– 功能操作权限
比菜单权限更细化，具象到不同角色即使看到相同数据，所具备的操作管理权限也不一样
权限颗粒– 数据字段权限
最细颗粒的权限控制，实现了不同角色进入后，看到的数据字段都会不同。
