RBAC权限模型及数据权限扩展的实践

话说大家对RBAC权限模型应该是耳熟能详了。但真正用的好的并不多。并且原始的RBAC模型并不包括数据权限的管理，网上也差点儿没有相关的文章可以參考。本人经过几个项目的实战，在其基础上扩展出一套可行的、简单的数据权限模型，希望可以帮助大家解决数据权限管理上的老大难问题。

至于什么是数据权限，请移步我的其它文章，这里不再敷述。

1、关于角色的继承：

在上图描写叙述的模型中，并没有实现角色的继承。既然一个用户能够分配多个角色，那么角色是否能继承还有什么必要呢？实现这个毫无必要的功能须要大大添加应用的复杂度，可谓是得不偿失。

2、关于资源和功能：

大家能够从图中看到仅仅有一张表的一个字段用来描写叙述资源或功能的授权。在大多数场景中，资源和功能实际上无法进行严格的区分。有所差别的仅仅是颗粒度的不同而已。一个业务组能够算是一种颗粒度最粗的资源。一个页面或窗口相对就精细一些了；到页面内菜单、工具栏button，就更精细了。假设控制的颗粒度达到页面元素或界面控件的程度，就是最细颗粒度的权限控制了。所以不管你叫资源还是功能、操作。都没有差别。你要控制的就是那些东西，仅仅须要你描写叙述出来，就能够被控制。

3、关于数据权限：

数据权限的授权相对功能权限来说，是全然不同的两种类型。怎样为数据授权，这必须从数据权限的本质出发，从怎样鉴别数据出发，仅仅有可以像鉴别资源一样对数据加以鉴别，我们才干对数据进行正确的授权。

假设我们抛开数据值的不同（值的不同不是本质的不同）来分析数据，就会发如今一般场景中，数据的不同首先是业务类型的不同。譬如：订单数据、结算数据、生产计划数据等等。

对于同一类型数据，还能够以产生数据的对象：业务部门、业务人员加以区分。这也是常常遇到的需求：经理能够看到所有的订单，业务员仅仅能看自己的。

什么叫所有？什么叫自己的？前一个概念对于不同的业务部门，实际的内容往往并不相同。A经理的所有订单指的是A部门的订单；而B经理的所有订单则是B部门的订单。

至于所谓的“自己的”。就更加明显是一个相对概念了。张三的和李四的一般来说是不存在交集的。但有时候。也有一些绝对性的需求。譬如要求C部门的张三要管A部门订单的审核，相同C部门的王五则负责B部门。

这样，数据权限的授权必需要从相对和绝对两个维度进行定义，才干做到逻辑完备。所以模型中也通过两张表来描写叙述数据权限，在相对模式中，用Mode字段来描写叙述不同的颗粒度，而在绝对模式中用户能够直接指定部门或用户的ID。此外，用ModuleId字段来定义数据的类型，也就是产生业务的模块。这个字段所包括的逻辑不仅是差别数据的业务类型，更重要的是为应用数据权限提供根据。

4、关于权限的应用：

本人在项目中，功能权限和数据权限都应用在数据訪问层。利用数据库函数返回给应用程序被授权的资源或功能的ID集合。

应用程序依据ID集合通过反射载入资源或功能，达到用户不能訪问非授权资源的目的。数据权限的应用方法也差点儿相同，将数据库函数join到业务表上去，未授权的业务数据就会被过滤掉。通过join添加的Permission列，则描写叙述了该行数据的读写权限为仅仅读还是读写。