微盟原有新云下的权限模型是基于传统的 RBAC 模型来实现的权限控制,由于新云下的解决方案相对定制,故对于权限模型的灵活性要求并不是很高。为了适应于微盟的 WOS 体系搭建,需要寻求一个既对商户角色权限分配友好且能适应于 WOS 的高灵活特性的权限控制模型。
基于角色的权限访问控制RBAC 模型在使用的过程中演变出了 RBAC1、RBAC2 等,引入了父子角色、SSD (静态职责分离)、DSD (动态职责分离)。
优势:结构简单,利于交互。
缺陷:不够灵活,在控制要求精细化的场景下使用比较受限。
基于属性的访问控制
ABAC 可以基于访问者主体属性(如岗位、部门、年龄等)、资源对象属性(被访问文件格式、目录、标签等)、访问环境属性(如时间、地点、设备类型等)以及操作属性(如读写等)是否满足某种条件来进行授权判断(策略条件)。
PBAC 属于 ABAC 的进阶,ABAC 一般需要基于特定实现(如XACML)而 PBAC 的授权策略可以使用自然语言进行实现。
优势:灵活性很高,具有很高的扩展性。
缺陷:实现相对复杂,对性能要求也较高,对业务用户友好度不高,对产品设计要求较高。
WOS 下权限控制系统搭建前调研
期望达到的效果
商户经过账号角色的配置,可以使得账号在不同的条件下(如应用不同、节点不同、渠道不同甚至时间段不同)可以灵活地进行权限的鉴权。故其中“不同的条件”是可能会随着业务的发展不断变更或增加的。
权限配置已知的一些特殊 Case
权限模型确定
结合调研结果,在 RBAC 及 PBAC 的基础上进行了一定的变通,形了一个较适用于现下 WOS 体系诉求的权限控制模型:
主模型采用RBAC模型的特点,采用主体 -- 角色 -- 权限 的模式;在角色 -- 权限中间参考 PBAC 模型的思想引入场景规则,形成 主体(角色) -- 策略(场景规则) -- 权限 的模式。在系统实现上增加:场景规则转化器 & 规则匹配引擎 来对场景规则进行处理
为什么主体要抽象?
如果主体只针对账号,那么账号的角色固定,在进行鉴权时只需要针对账号关联的角色进行策略匹配就可以了,其优势是:可以减少计算逻辑,提高鉴权效率,但缺点也很明显:
由上图可见:这种处理方式下不利于扩展,维护成本高。
综上:希望可以通过最小调整达到权限变更的效果,故将应用、节点、账号抽象成本种不同的权限主体,通过下图的权限取交集方式进行权限范围控制;如此上边列出来的“角色权限变更场景”就可以通过调整应用主体 或 节点主体对应的权限即可满足了。
在该模型下做权限配置落地时较以往的 RBAC 模型需要额外关注环境与资源属性 到 场景规则的转换。
鉴权功能的主要逻辑点如下:
针对内部系统的统一权限拦截,考虑的方向主要有以下两种:
我们采用的是基于 SDK 的方式,主要原因:
在微盟的 WOS 体系内,该模型将角色的权限功能通过策略规则的抽象做到了高度灵活,适用于“分配简单,鉴权灵活”的场景诉求,满足 WOS 未来生态化过程中的扩展要求;在该模型下同样也继承了 PBAC 的缺点,随着场景规则的丰富将对鉴权性能也会提出更高要求,未来鉴权性能提升将是优化的方向。
webpack4 module-federation and more