关于数据权限设计的一些想法
Posted Franson
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了关于数据权限设计的一些想法相关的知识,希望对你有一定的参考价值。
序言
在各种系统中,要保证数据对象的安全性以及易操作性,使企业的各业务部门、职能部门能够方便而且高效的协同工作,那么一个好的数据权限管理设计就成为一个关键的问题。虽然企业中各个单元的工作流程有所不同,处理的数据对象也有所不同,但是在组织结构、信息的处理方式上具有很多相同的地方,这就为设计数据对象的权限控制提供了一个抽象基础。数据权限的控制不同于一般的功能权限的控制,一般的功能权限指的是某个用户、角色或者是某个用户组能不能操作某种功能。而数据权限指的是某个用户、角色或者是某个用户组对某个数据对象的操作边界的问题,比如说用户A可以对数据对象进行完全控制,而用户B则只能对数据对象进行浏览的权限,部门主管可以查看隶属该部门所有同事的信息,某个同事只能查看他自己的信息等等。
同时数据权限控制隶属于动态权限控制的范畴。
数据权限设计
在当前的许多应用程序中都会涉及到权限管理,权限主要分为功能权限和数据权限,至于功能权限相对简单些,网上也有不少的实现方案,这里不再介绍,下边主要探讨下数据权限的设计方案。
数据权限跟功能权限有很大的不同,颗粒度很小,贯穿于整个项目的开发周期中,无法像功能权限一样在项目要结尾的时候追加,也有一些公司有自己的权限组件(功能权限),给已完成的项目配上权限组件就生效了。数据权限做不到组件级别,必须在项目设计阶段就已经规划好。之前看网上同样有人想基于spring切面的原理去实现数据权限,这样就可以做到了低侵入、低耦合,想法很好,可是现实很骨感,这样做使整个应用系统效率大减折扣,同样对数据权限的控制策略也很不灵活。
下边提出自己的设计方案,在系统中独立一个数据权限模块,该模块可以根据当前业务模块的SQL、当前操作人信息、当前权限的策略来自动生成对应的带数据权限的SQL语句给业务模块继续处理,如下图所示:
数据权限设计分析
SQL语句可扩展
数据权限往往作为功能权限的高级行为,可以从数据对象的幅度方面进行控制,比如用户只能看自己的订单、普通会员看不到某数据对象的高级属性(字段)等等。颗粒度这么细的情况下对结果集处理显然是不可能了,这时只能介入到SQL语句中了,此时又不想在开发阶段让开发人员过多的考虑数据权限的问题,这时最好把SQL语句给提到一个配置文件中,或者数据库中,开发阶段只需开发人员通过数据权限模块的接口调用得到已实现数据权限控制的SQL语句,这样也算做到的代码的低侵入。
SQL语句高效解析处理
数据权限模块的核心之一就有SQL语句的高效解析处理,SQL处理指根据当前登录人信息及数据权限策略生成一个带有数据权限处理结果的SQL语句,所以这里对SQL语句的解析处理必须要求精确、准确。在开发阶段由开发人员把SQL写入到配置文件中,在运行阶段由数据权限取得该SQL进行分析处理(加上数据权限),这样就完成了SQL的组装处理。
数据权限策略设计
最核心的地方就是数据权限策略的设计了,这里先引入几个概念:
1、资源:数据权限的控制对象,业务系统中的各种资源。比如订单单据、销售单等
2、主体:用户、部门(用户组)、角色等
3、规则:用于【数据权限】的条件规则
4、权限:功能权限(如菜单权限),数据权限,字段权限
这里侧重分析下主体及规则,主体有层级关系,可以为不同主体设置不同规则,比如:当前数据仅对创建人(或者某个人)有效、下级主体的权限对于上级主体同样有效(可配置,如可勾选)、非当前主体只能看到部分数据(部分数据可选)。这里只提供部分规则示例,现实环境中需要根据企业环境或者项目环境去完善这些规则。
数据权限策略优化
数据权限同样属于权限范畴,每次访问都会去请求验证权限,所以权限的认证必须要高效,这时可以写算法或者是用MEMCACHE等来提高响应速度。
以上是关于关于数据权限设计的一些想法的主要内容,如果未能解决你的问题,请参考以下文章