一、前言
微盟原有新云下的权限模型是基于传统的 RBAC 模型来实现的权限控制，由于新云下的解决方案相对定制，故对于权限模型的灵活性要求并不是很高。为了适应于微盟的 WOS 体系搭建，需要寻求一个既对商户角色权限分配友好且能适应于 WOS 的高灵活特性的权限控制模型。
二、常用的权限模型
2.1 RBAC
基于角色的权限访问控制RBAC 模型在使用的过程中演变出了 RBAC1、RBAC2 等，引入了父子角色、SSD (静态职责分离)、DSD (动态职责分离)。
优势：结构简单，利于交互。
缺陷：不够灵活，在控制要求精细化的场景下使用比较受限。
2.2 ABAC&PBAC
基于属性的访问控制
ABAC 可以基于访问者主体属性（如岗位、部门、年龄等）、资源对象属性（被访问文件格式、目录、标签等）、访问环境属性（如时间、地点、设备类型等）以及操作属性（如读写等）是否满足某种条件来进行授权判断（策略条件）。
PBAC 属于 ABAC 的进阶，ABAC 一般需要基于特定实现（如XACML）而 PBAC 的授权策略可以使用自然语言进行实现。
优势：灵活性很高，具有很高的扩展性。
缺陷：实现相对复杂，对性能要求也较高，对业务用户友好度不高，对产品设计要求较高。
三、微盟权限系统模型介绍
3.1 模型选择
WOS 下权限控制系统搭建前调研
- 尽可能保持原有的交互方式，降低商户的切换学习成本
- 微盟体系统下虽然大商户账号数量也很多，但账号关联的角色相对统一，差异性不高
- WOS 下各类应用可灵活组合，菜单权限控制需要相对灵活，有一定的可扩展性
期望达到的效果
商户经过账号角色的配置，可以使得账号在不同的条件下（如应用不同、节点不同、渠道不同甚至时间段不同）可以灵活地进行权限的鉴权。故其中“不同的条件”是可能会随着业务的发展不断变更或增加的。
权限配置已知的一些特殊 Case
- 在不同应用、不同节点下权限不一样 角色在商城应用品牌节点下的菜单与在门店节点下的菜单功能是不一样的
- 菜单随着店铺购买应用或节点开通应用情况的不同而不一样 数据应用的菜单，当节点开通的商城会额外露出一些菜单功能
- 同一个角色在不同的端/渠道露出的权限不一样 角色在PC端所具备的权限点与在移动端所具备的权限点不一样
权限模型确定
结合调研结果，在 RBAC 及 PBAC 的基础上进行了一定的变通，形了一个较适用于现下 WOS 体系诉求的权限控制模型：
主模型采用RBAC模型的特点，采用主体 -- 角色 -- 权限 的模式；在角色 -- 权限中间参考 PBAC 模型的思想引入场景规则，形成 主体(角色) -- 策略(场景规则) -- 权限 的模式。在系统实现上增加：场景规则转化器 & 规则匹配引擎 来对场景规则进行处理
为什么主体要抽象？
如果主体只针对账号，那么账号的角色固定，在进行鉴权时只需要针对账号关联的角色进行策略匹配就可以了，其优势是：可以减少计算逻辑，提高鉴权效率，但缺点也很明显：
由上图可见：这种处理方式下不利于扩展，维护成本高。
综上：希望可以通过最小调整达到权限变更的效果，故将应用、节点、账号抽象成本种不同的权限主体，通过下图的权限取交集方式进行权限范围控制；如此上边列出来的“角色权限变更场景”就可以通过调整应用主体 或 节点主体对应的权限即可满足了。
3.2 流程简介
四、功能实现
4.1 赋权
在该模型下做权限配置落地时较以往的 RBAC 模型需要额外关注环境与资源属性 到 场景规则的转换。
4.2 鉴权
鉴权功能的主要逻辑点如下：
- 收集环境数据与属性数据进行上下文初始化供后续的规则匹配。
- 按业务场景 init 权限过滤链路。
- 使用规则引擎进行场景规则统一校验。
4.3 鉴权SDK
针对内部系统的统一权限拦截，考虑的方向主要有以下两种：
我们采用的是基于 SDK 的方式，主要原因：
- 将控制权交给接入方，可以高度自治；网关层无需做鉴权与否的判断
- 减少映射关系集中管理带来的更新迭代不便
- 可以覆盖应用之间直接 dubbo 交互的场景（不经过网关）
五、结语
在微盟的 WOS 体系内，该模型将角色的权限功能通过策略规则的抽象做到了高度灵活，适用于“分配简单，鉴权灵活”的场景诉求，满足 WOS 未来生态化过程中的扩展要求；在该模型下同样也继承了 PBAC 的缺点，随着场景规则的丰富将对鉴权性能也会提出更高要求，未来鉴权性能提升将是优化的方向。
