话说大家对RBAC权限模型应该是耳熟能详了，但真正用的好的并不多。而且原始的RBAC模型并不包含数据权限的管理，网上也几乎没有相关的文章可以参考。本人经过几个项目的实战，在其基础上扩展出一套可行的、简单的数据权限模型，希望能够帮助大家解决数据权限管理上的老大难问题。至于什么是数据权限，请移步我的其他文章，这里不再敷述。

1、关于角色的继承：

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

2、关于资源和功能：

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

3、关于数据权限：

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

如果我们抛开数据值的不同（值的不同不是本质的不同）来分析数据，就会发现在一般场景中，数据的不同首先是业务类型的不同。譬如：订单数据、结算数据、生产计划数据等等。对于同一类型数据，还可以以产生数据的对象：业务部门、业务人员加以区分，这也是经常遇到的需求：经理可以看到所有的订单，业务员只能看自己的。什么叫全部？什么叫自己的？前一个概念对于不同的业务部门，实际的内容往往并不相同，A经理的全部订单指的是A部门的订单；而B经理的全部订单则是B部门的订单。至于所谓的“自己的”，就更加明显是一个相对概念了。张三的和李四的一般来说是不存在交集的。但有时候，也有一些绝对性的需求，譬如要求C部门的张三要管A部门订单的审核，同样C部门的王五则负责B部门。

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

4、关于权限的应用：

本人在项目中，功能权限和数据权限都应用在数据访问层，利用数据库函数返回给应用程序被授权的资源或功能的ID集合。应用程序根据ID集合通过反射加载资源或功能，达到用户不能访问非授权资源的目的。数据权限的应用方法也差不多，将数据库函数join到业务表上去，未授权的业务数据就会被过滤掉，通过join增加的Permission列，则描述了该行数据的读写权限为只读还是读写。

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