权限管理最佳实践：四，数据级查询权限管理

 

-------------------------------------------- 总大纲 ---------------------------------

Ralasafe开源有段时间了，大约有2个月了。根据社区的反馈，我打算围绕Ralasafe最佳实践，书写一系列BLOG。

 

大体内容有：

1， 登录控制： 哪些页面需要登录后才能访问，登录用户名、密码验证，登录转向页面；

2， URL权限控制：哪些页面访问需要进行角色权限验证，怎样验证最简单有效，如何处理验证失败情况；

3， 数据级权限管理方案探讨：选择中间件呢还是框架？

4， Ralasafe体系结构： 用户怎么读取，用户有哪些字段，怎样与应用基础；

5， 数据级查询权限管理： 如何给不同的人分配不同的查询数据权限，返回where条件呢，还是直接返回结果集？

6， 数据级决策权限管理： 如何给不同的人分配不同的数据操作权限，当用户不具备权限怎么办？

7， 其他细小的权限控制： 如下拉框显示内容；按钮、链接是否显示，图片是否显示等。

-------------------------------------------- ------- --------------------------------

 

 

数据级权限管理需求

数据级权限管理需求主要有：

1，支持不同用户查询到数据是不同的；

2，支持数据库行级、列级查询；

3，支持分页查询——包括2个方面：a，分页查出数据；b，能告知总数据条数是多少；

4，支持自定义条件（比如：张三在自己的查询权限范围内，查询50w以上的订单）。

理论分析

能够将数据级权限，与业务分离出来——是多年来开发人员追求的目标。一旦遇到疑难杂症，马上会让人联想到高难度的API编程，或者绚丽的XML配置。

 

不过，我今天的分析，会极其简单。不过我强烈建议大家看下去。如果对该方案有所怀疑，请使用你的应用案例进行试验。我当时不敢确认的时候，就是这么做的。

（当初，我提出该方案的时候，我们团队认为该方案过于简单，不可行。我坚持让他们实现该方案。等产品做出来后，他们略有所悟，认为该方案可行。当，我让他们做demo的时候，将该方案运用于案例的时候，他们拍腿叫道：超级太棒了！我希望你也有该感受）

 

分类思想的提出

首先，我们思考这个问题：为什么我们在程序里面使用了if/else？为什么数据级权限难以处理？

原因就是：1，有很多种情况；2，我们需要针对不同的人、不同的情况做不同的权限逻辑。比如：

if  是总公司用户？  then 查询所有订单；
else if  是分公司用户？  then 查询本分公司（${用户的公司}）及下属子公司订单；
else //  是子公司用户了
then 查询本子公司订单（${用户的公司}）

 

在RBAC模型里面有用户群组概念，也有不少开发人员将用户群组引入数据级权限管理领域。群组很好的将用户归组，但不足之处是要事先将用户归入组内。比如，在将张三指定到“总公司用户组”之前，他不属于该用户组，即便张三的机构属性显示他属于总公司。

我们对群组进行稍微改造：使用规则来定义群组，满足该规则的用户，我们则认为该用户属于该群组。传统编程里面的if/else判断条件，基本都可以使用规则或者规则表达式组来描述。此时，张三的机构属性显示是总公司，那么他就属于总公司用户组；如果他的机构属性是某个分公司，那么他就属于分公司用户组了。无需进行额外操作（指定、重新指派等，一切都是动态智能的）。

 

OK，至此，我们提出了使用规则描述的“用户分类”。该规则应该能读取用户信息、上下文信息、数据查询等，并进行相关运算（比较、集合运算等）

 

至此，我们可以基于用户要分类，为每个用户分类分配一个查询。（该查询可以接受相关参数，比如用户参数、上下文参数等）

那么上述例子，使用分类思想，可以这么解决：

用户分类：总公司用户类 —— 查询：查询所有订单

用户分类：分公司用户类 —— 查询：查询本分公司及下属子公司订单；

用户分类：子公司用户类 —— 查询：查询本子公司订单。

与功能权限结合

我认为功能权限与数据权限分开非常合适。功能权限由企业IT管理员维护；数据权限由软件开发商维护。有人会说这样不好，比如这个案例怎么处理：

普通审查员可以审查50w财务数据；中级审查员审查50w～500w的财务数据。这个50w、500w，企业需要自行维护。

 

OK，我认为这50w、500w应该称为“权限策略数据”，可以保存到数据库里面，做为基础数据或者数据字典由企业通过界面自行维护。而软件开发商，开发的“数据级权限”策略读取这些数据。（当然，你可以缓存。。。。）

Ralasafe方案

怎样实现数据级查询权限

为了理解本节内容，建议下载ralasafe demo应用，对照图形界面，更容易理解些。

Ralasafe使用管理界面来定制用户分类、定制数据查询。为了确保定制无误，Ralasafe支持在线测试。比如定制用户分类后，可以选择一个用户进行测试。数据查询等都是可以在线测试的。

 

定制完毕后，将用户分类和数据查询配对，赋给特点权限。一个权限，可以赋多个（用户分类——数据查询）配对。和前面的理论分析一样。

 

具体定制，怎样配对，可以参考文档，配有图片，在此不做多说。定制用户分类，定制数据查询，给权限授权策略（即配对）。

怎样与应用结合

Ralasafe提供org.ralasafe.Ralasafe和org.ralasafe.WebRalasafe两个接口类。里面的query方法对应数据级查询权限。在应用系统相应的地方，调用该方法即可。我建议在系统的控制层调用，即：servlet或者action。

 

ralasafe demo例子，EmployeServlet就是这么调用的：（demo演示员工查询，不是订单查询）

// 通过Ralasafe接口获取当前用户被授权查看的员工
Collection employees = WebRalasafe.query(req, Privilege.QUERY_EMPLOYEE);
// 将数据放入request，供前台展示
req.setAttribute("employees", employees);

OK，就这么简单。需要编程的工作量非常非常少，达到了极致。世界从此清净了。

 

（WebRalasafe.query方法接受req<HttpRequest>参数，从这里读取User。Ralasafe.query方法则直接传入User，可供非web类应用调用） 

系统结构

Ralasafe由权限引擎和管理界面组成。权限引擎解析权限策略；管理界面生成、维护权限策略。如图示：

 

 

注：ralasafe团队博客在javaeye/baidu/blogjava等空间，同步发布。ralasafe官方网站：http://www.ralasafe.org/zh

 

 

 

 

 

评论

22 楼 hpjucy 2010-12-24  

*终于把分页查询给研究出来了，不过，怎么对集合的结果排序呢，有排序的类吗？没看到文档里有写啊，还是，只能在数据查询里面自己写SQL语句？？？

21 楼 hpjucy 2010-12-14  

*看到你们网站上的分页这样写的

//分页查询
public static QueryResult query(int privilegeId, User user, java.util.Map context, int first, int max);

但取数据集不是这样么

Collection employees = WebRalasafe.query(request, MyPrivilege.CUST_BASIC_VIEW); 

不太理解哦~~

20 楼 hpjucy 2010-12-14  

*发现个问题，如果要对查询出来的数据集进行分页要怎么做，不会拿一整个数据集去分吧，那太杯具了

Collection employees = WebRalasafe.query(request, MyPrivilege.CUST_BASIC_VIEW);   
request.setAttribute("custList", employees); 

19 楼 hda 2010-09-20  

由于不返回WHERE条件，而是JDBC直接查询，导致无法和HIBERATE，IBATIS等集成。这样也导致很多应用不能与ralasafe集成了。

18 楼 lai555 2010-09-15  

细粒度控制,有好的例子参考么?

17 楼 metadmin 2010-09-12  

我相信他们的产品。而且他们产品是经受过市场考验的，并不是吹的。

16 楼 downpour 2010-09-12  

metadmin 写道

downpour 写道

所以任何所谓的权限管理，只能做到框架级别，而不能深入业务。楼主的解决方案，我不是很看好。

使用中间件控制权限管理的，还有IBM Tivoli Access Manager for e-business 和Oracle Entitlements Server。他们在巨型跨国企业有应用案例。

连这种公司的产品你都信？

我现在就在用你说的这个IBM的方案，从头到尾就是垃圾。

15 楼 metadmin 2010-09-12  

有点是让我莫名的伤感。

文中举例非常常见，不算复杂，但不代表该方案就只能满足该类需求。其实这是一个好的解决方案，应用到其他需求也是非常好的。

只是，怎样设计权限策略，怎样匹配，需要思考一下。

14 楼 fight_bird 2010-09-12  

理想的权限方案：粗粒度的权限框架 + 充分的权限定制空间 + 若干具有通用性的已定制策略

这个方案基本做到了，不错。

13 楼 完全菜鸟 2010-09-10  

还是新手啊，没怎么看懂。不过我以前做过简单的权限，也不是很难理解啊

12 楼 metadmin 2010-09-10  

ltian 写道

Ralasafe提供org.ralasafe.Ralasafe和org.ralasafe.WebRalasafe两个接口类。里面的query方法对应数据级查询权限。在应用系统相应的地方，调用该方法即可。我建议在系统的控制层调用，即：servlet或者action。

如果按照分层的理论，访问数据库的层次都是在业务逻辑层之下，业务逻辑层是在服务层之下。servlet或者action都已经是展现层了，更在服务层之上，为了权限难道要打破良好的分层设计吗？

建议在控制层接入Ralasafe，是因为我们平常的系统，也是在控制层接入数据访问层或者业务service层的。所以，我觉得对于查询，没有必要在service里面再次封装。DAO层一般无权限逻辑，所以不用关系。

ltian 写道

另外，访问数据都要通过WebRalasafe.query来进行，我不知道性能如何？把所有的数据访问层都交给权限去做，是不是去权限部分做的太多了，侵入的太多了？

你说的是否侵入太多，确实不少人有这么反映。很多人是这样的观点，不知道你是否一样。 很多人认为我们返回WHERE条件就可以了，而不是应该返回数据结果集。由业务service或者dao来根据where条件，查询数据。
我们的思路是：
1，大家的共同目标是：使用最有效率（或者说开发最有效率、或者性价比）查询出数据。
2，要能够控制列级，比如张三请求查询返回数据列有10列，李四请求查询却返回数据列5列。
所以，Ralasafe就不愿意分开了，而且使用JDBC访问，无废话高效查询，返回数据级是开发人员指定的映射类。

ltian 写道

楼主说遵循NIST的RBAC，不知道楼主是否真正了解RBAC Model，这里未体现出任何RBAC模型方面的优秀概念。如果我没记错的话，在2004年出来的NIST RBAC模型中里面没有用户群组的概念，而且，RBAC就是针对传统的用在操作系统中的GBAC（group based acess control）做的改进。可能楼主的权限系统确实非常棒，但是希望写文章的时候严谨一些。

Ralasafe模型与RBAC模型的关系是：

11 楼 metadmin 2010-09-10  

lgcpeter 写道

同意metadmin的功能权限和数据权限分开。
数据权限通过拼SQL语句也没有问题。
但，这样的框架侵入到项目中是不是项目必须得先花力气学习Ralasafe，并且要从项目设计阶段就有按照Ralasafe的规则走？

我们开发Ralasafe，其中有个目的就是为了容易使用，最好是只有少量IT知识的人就能使用。
Ralasafe的图形化界面，目前反馈还是很友好的、很容易使用的。不仅没有新概念，而且每步都有在线测试。确保无误。

强烈建议你尝试做1～3个功能。

10 楼 metadmin 2010-09-10  

downpour 写道

所以任何所谓的权限管理，只能做到框架级别，而不能深入业务。楼主的解决方案，我不是很看好。

使用中间件控制权限管理的，还有IBM Tivoli Access Manager for e-business 和Oracle Entitlements Server。他们在巨型跨国企业有应用案例。

9 楼 sunliao_first 2010-09-10  

有时候是业务去决定技术吧，不同方面不同的方案。关键是要适合的。

8 楼 lgcpeter 2010-09-10  

还是感觉规则不够简单清楚。如果能一句话或几句话说明白最好了。

7 楼 lgcpeter 2010-09-10  

同意metadmin的功能权限和数据权限分开。
数据权限通过拼SQL语句也没有问题。
但，这样的框架侵入到项目中是不是项目必须得先花力气学习Ralasafe，并且要从项目设计阶段就有按照Ralasafe的规则走？

6 楼 ltian 2010-09-10  

Ralasafe提供org.ralasafe.Ralasafe和org.ralasafe.WebRalasafe两个接口类。里面的query方法对应数据级查询权限。在应用系统相应的地方，调用该方法即可。我建议在系统的控制层调用，即：servlet或者action。

如果按照分层的理论，访问数据库的层次都是在业务逻辑层之下，业务逻辑层是在服务层之下。servlet或者action都已经是展现层了，更在服务层之上，为了权限难道要打破良好的分层设计吗？

另外，访问数据都要通过WebRalasafe.query来进行，我不知道性能如何？把所有的数据访问层都交给权限去做，是不是去权限部分做的太多了，侵入的太多了？

楼主说遵循NIST的RBAC，不知道楼主是否真正了解RBAC Model，这里未体现出任何RBAC模型方面的优秀概念。如果我没记错的话，在2004年出来的NIST RBAC模型中里面没有用户群组的概念，而且，RBAC就是针对传统的用在操作系统中的GBAC（group based acess control）做的改进。可能楼主的权限系统确实非常棒，但是希望写文章的时候严谨一些。

5 楼 鱼言风语 2010-09-10  

"最佳实践"请慎用

4 楼 metadmin 2010-09-09  

balaschen 写道

这个适用面太简单了，举个例子，在OA类的文档管理系统中，每个文档（记录）的查看权限是由该文档定义的（类似操作系统的文件夹的安全性设置），每个文档可以设置哪些人，哪些部门，哪些群组可以看（群组和部门又可以嵌套），这样的场景下，用户是无需分类的，数据查询要如何定义？

楼主的方案有一个潜在的假设，这个假设就是你的业务数据的查询，是可以通过简单定义来实现的，如果业务数据查询的复杂度超出“数据查询定义”的范围，就无能为力了。

我一贯的观点，数据权限是没有万能胶的，只有在特定的业务领域，才有存在的可能。

你说的这种模式，应该是典型的基于ACCESS CONTROL LIST控制的模式了，可以by user, or by group, even inherit。
这种模式，如果完全没有规则可选，那么使用我提出的基于分类的思想，并不算合适。

但，这种完全基于ACL ENTRY LIST的模式，当数据量大的时候，系统运行和维护压力都非常大。

所以，对此场景，我更愿意尝试对业务进行重新分析。方向1：
1，是否从用户查询界面处进行构造，比如查询分配到本人的数据；查询分配到本人所在组的数据；（这样的查询就简单很多了，都是可以使用SQL语句完成的）
2，用户界面（或者叫接口）维持不变，不进行改造。在实现代码部分，将上述方案进行拼加。

因为，我对你的意思，还并不完全了解。所以就我个人项目经验，做出一些预测。


对于很多系统来说，这种分类模式是足够使用的。因为场景基本都能使用规则进行描述。再不行的话，复杂到了极点的话，Ralasafe也是支持存储过程，支持自定义查询，支持直接输入业务代码的。

我个人非常坚信该方法，在我们做的项目里面都能充分使用。不过，对于复杂场景怎样定制策略，是有学问的。

3 楼 downpour 2010-09-09  

balaschen 写道

这个适用面太简单了，举个例子，在OA类的文档管理系统中，每个文档（记录）的查看权限是由该文档定义的（类似操作系统的文件夹的安全性设置），每个文档可以设置哪些人，哪些部门，哪些群组可以看（群组和部门又可以嵌套），这样的场景下，用户是无需分类的，数据查询要如何定义？

楼主的方案有一个潜在的假设，这个假设就是你的业务数据的查询，是可以通过简单定义来实现的，如果业务数据查询的复杂度超出“数据查询定义”的范围，就无能为力了。

我一贯的观点，数据权限是没有万能胶的，只有在特定的业务领域，才有存在的可能。

所以任何所谓的权限管理，只能做到框架级别，而不能深入业务。楼主的解决方案，我不是很看好。