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

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

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

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

一、关于角色的继承：

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

二、关于资源和功能：

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

三、关于数据权限：

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

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

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

什么叫全部？什么叫本身的？前一个概念对于不一样的业务部门，实际的内容每每并不相同。A经理的全部订单指的是A部门的订单；而B经理的全部订单则是B部门的订单。

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

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

四、关于权限的应用：

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

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