途牛原创｜途牛无线权限系统的架构设计与实践

序

以前写过一篇大话权限中心的PHP架构之道，主要是从软件工程角度介绍，如何经过编码规范、依赖管理、数据源架构、事务处理、单元测试等技术，来保障权限系统的高可用，并未真正的涉及这套系统的架构。

今天准备从设计细节上分享一二。

望各位看官，心有“空杯”，带着“问题”一探究竟。

0. RBAC3

这里仍是尤其的重要，由于他是整套系统设计的根基。

因此残忍的从上一篇中复制了一遍。。。

RBAC认为权限受权其实是Who、What、How的问题。在RBAC模型中，who、what、how构成了访问权限三元组，也就是“Who对What(Which)进行How的操做”。

• Who：权限的拥用者或主体（如Principal、User、Group、Role、Actor等等）

• What：权限针对的对象或资源（Resource、Class）。

• How：具体的权限（Privilege，正向受权与负向受权）。

• Operator：操做。代表对What的How操做。也就是Privilege+Resource

• Role：角色，必定数量的权限的集合。权限分配的单位与载体,目的是隔离User与Privilege的逻辑关系.

权限系统的本质就是这个模型（我的观点勿喷）。咱们在此核心思想上，抽象了两个新概念。

应用建模、权限自治

下面将从如下4个层面展开介绍。

• 应用建模

• 业务场景

• 权限管理

• 鉴权设计

1. 应用建模

系统架构上支撑权限系统灵活配置，不僵硬字段，不僵硬行为，基于各类业务权限管控的特征灵活设计。

公式一枚：应用＝资源＋行为＋角色

1.1 字段定义

简单点说，就是要管控资源的属性和行为。

好比要管控菜单，属性就包括菜单ID、菜单名称、菜单URL、菜单ICON、上级菜单ID等，行为就包括访问、受权等。（菜单权限）

好比要管控城市，属性就包括区域ID、区域名称、区域代码、所属区域ID等，行为就包括访问、受权等。（区域权限）

好比要管控CMS，字段就包含页面ID、页面名称等，行为就包括访问、受权、编辑、重置等。（CMS数据权限）

按照惯性的思惟，这里就是3张资源表对应角色表，同时还有3张资源角色关系表，换而言之，就是有多少资源须要管控就有多少张表（又是我的观点，勿喷）。

惯性的思惟，两个痛点。

1. 每一种资源都要独立存储。

2. 每一种资源都要有一套Form排版&交互&存储实现。

为了解决这个问题，咱们作了如下的设计。

字段建模

任意资源的字段，均可以抽象成以下几类。

• 资源映射字段（mapField）

• 资源节点字段（treeFiled）

• 资源系统字段（systemFields）

• 资源表单字段（columns）

• 资源行为字段（privileges）

举个栗子：菜单资源。

class menu extends app { public static $appMapField = 'url'; public static $appTreeField = 'name'; public static $columns = array( array( 'id' => 'id', 'label' => '菜单ID', 'type' => 'input', 'format' => 'int', 'option' => array() ), array( 'id' => 'name', 'label' => '菜单名称', 'type' => 'input', 'format' => 'string', 'option' => array() ) ); public static $privileges = array( array( 'id' => 'access', 'name' => '访问' ) ); public static $systemFields = array('id', 'parent_id'); } 

动态表单

表单在网页中主要负责数据采集功能。一个表单有三个基本组成部分：

1. 表单标签；

2. 表单域，包含了文本框、密码框、隐藏域、多行文本框、复选框、单选框、下拉选择框和文件上传框等；

3. 表单按钮。

常规工做是静态表单。

设计动态表单模型，基本的思路应该是数据和表现显示的分离。抛开表现层，一个表单包含的若干个字段和填写的数据。所谓动态，就是这些字段名称可能改变，数量可能有增减。

• 经过资源的columns字段控制表现层。

• 经过资源的数据字段控制数据层。

经过这种模式，任意资源的Form排版&交互&存储都动态实现了。

1.2 数据存储

资源表对应的Schema以下：

字段名称	字段备注
应用ID	/
资源ID	/
资源父ID	/
资源Data	JSON

经过反射API，获取当前应用的资源存储插件（资源Data字段）。

app::find($params['app_id'])->getResoucePlugin()->save($params['data']); 

经过资源基类作数据存储的统一封装。

public function save() { $this->beforeSave($this->attributes); } protected function beforeSave() { //check attributes } 

很显然资源Data字段，不能很好的完成单资源行为鉴权的任务。

设计上引入了资源映射字段，每当资源变动时，触发addMap，会同步字段信息到资源映射关系表中（资源的语义化索引）。

举几个栗子，方便你们理解这个字段：

• 好比菜单类应用，映射字段就是菜单连接。

• 好比数据类应用，映射字段就是数据ID。

public function addMap() { if ($this->map) { //sync map field } else { //create map field } } 

应用建模，相对来讲是一个较技术的话题，换个方向，下面来和你们聊一聊系统的业务场景。

2. 业务场景

系统架构上支撑多种业务形态的权限管控。

2.1 菜单类业务

说到权限，大多数应用场景都会想到菜单权限，然而咱们也不例外，菜单类的应用，就是生产的第一个实例。

举个栗子：A系统/菜单权限应用

• 字段

  • 菜单ID、菜单名称、菜单连接、菜单上级ID

• 行为

  • 访问、受权

2.2 数据类业务

数据类应用，相对于菜单类型来讲，更关注的是，对某一行数据的行为控制，行为是多样的。

举个栗子：A数据/数据权限应用

• 字段

  • 数据ID、数据名称

• 行为

  • 访问、受权、编辑、删除、新增、重置、导出、导入

2.3 表单类业务

表单类应用，在2B的系统中，权限设计尤其重要。

举个栗子：A确认单/表单权限应用

• 字段

  • 模块ID、模块名称（行程模块、供应商模块、订单模块、财务模块）

• 行为

  • 访问、受权、只读、可写、隐藏

总结一下权限的业务场景：

• 菜单类：单资源的单行为（可否”行为“当前“资源”）

• 数据类：单资源的多行为

• 表单类：多资源的多行为

小伙伴们，大家的业务场景能实现吗？（留言吧）

3 权限管理

接下来讲说权限管理中的一些设计之道。

3.1 自治

设计上参考JIRA，当前应用的管理者主导当前应用的权限生态。

• 资源的增删改查

• 角色的增删改查

• 资源字段定义

• 资源行为定义

• 资源行为的角色赋予

3.2 自举

系统中给每一种资源都天生赋予一种系统行为叫作“受权”。

任意资源节点的角色行为赋予，都由拥有该资源节点受权行为的角色去分配。

3.3 双向受权

两个维度受权，方便检索，也方便配置。

基于角色＋行为，选择资源。

基于资源＋行为，选择角色。

^^^^^^^^

下一个阶段将会支持默认权限的配置，非应用内的角色，也一样能够享有应用内的部分资源的部分行为的权限。

4 鉴权设计

最后简单说下，鉴权接口的设计。

U、R、P、S分别表示用户集合、角色集合、许可权集合和会话集合。

PA P×R表示许可权与角色之间多对多的指派关系。

UA U×R表示用户与角色之间多对多的指派关系。

公式一枚：S＝UA ∩ PA

4.1 单应用＋单行为

统称为资源树接口。

举个栗子：R角色在A应用中拥有P行为的资源。

4.2 单应用＋单资源＋单行为

统称为行为鉴权接口。

举个栗子：R角色在A应用中是否拥有R资源的P行为。

结束语

权限系统一直以来是咱们应用系统不可缺乏的一个部分，若每一个应用系统都从新对系统的权限进行设计，以知足不一样系统用户的需求，将会浪费咱们很多宝贵时间，因此花时间来设计一个相对通用的权限系统是颇有意义的。

设计一个相对通用的系统是颇有意义的。(不只仅是权限)