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

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

 

大体内容有：

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

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

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

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

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

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

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

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

 

数据级权限

数据级权限，无外乎这些类型：

1，数据库行列级：比如领导查询数据范围和普通员工查询的数据范围不同，客户经理能够查询客户联系方式字段，而其他人不能查看客户联系方式字段。

2，字段内容控制：比如普通审查员审查50w以下财务数据，刚入职客户经理只能将客户级别调整不能超过3级。

 

从用户与数据的交互方向可以分为2大类：

1，从系统获取数据（查询）；

2，向系统提交数据之前的判断。

现实困惑

这种权限与业务紧密耦合，很难找到通用方法。绝大部分系统仍然采用if/else来编程，而且这种逻辑分散到系统的各个环节，甚至还会在系统多处出现重复判断。

也有不少网友尝试5表模型等，试图通过数据模型构造好的ACCESS CONTROL LIST来控制。这种构造ENTRY模式，当数据量小的时候，是可行的，维护工作量也不大。当数据量大的时候，显然不能奏效。甚至无法运行，维护工作量非常大。

主要表现在：

1，where 语句里面的in(..., ..., ..., ..., ...) 子条件过长，或者使用in (select ... from ACL_ENTRY where ... )性能也是非常低下的；

2，当删除某用户的时候，需要在ACL_ENTRY表里面，删除相关记录；

3，当删除某业务数据的时候，也需要在ACL_ENTRY表里面，删除掉相关记录；

4，数据量大，ACL_ENTRY数据量承几何级增长。

 

也有企业尝试使用规则引擎来解决。这是非常好的尝试，提升了系统开发效率、组件复用率。

主要表现在：

1，首先，主动的实践了一项最佳项目实践：权限与业务松耦合。

2，通过松耦合，大幅优化了系统结构。

3，进一步提高了组件复用率。

只是，规则引擎毕竟不是专业于权限管理领域，对于复杂需求，或者有些需求实现起来还是很别扭。看起来像if/else的规则表达罢了。

 

Ralasafe和IBM、Oracle商业产品一样，都使用规则进行描述。大家的区别在于：谁满足需求更多、更容易了。

框架or中间件

框架的好处，显然是有个体系结构，团队遵循该方式进行开发、组装即可。提供了一种标准和开发模式。

中间件的好处，显然是提供了自由，而且易于结合、易于分工。提供了一种服务方式。

 

我本人希望自由，所以讨厌框架，偏爱中间件。但我对选用中间件、框架的选择标准是非常中肯的，供大家参考。

 那么具体到权限管理领域，显然是功能分离，中间件更合适。这么做，还将不给原有系统、新开发系统的既定框架造成冲突。一个系统里面使用多个框架，是非常痛苦的事情。殊不知在SSH的海洋里面，有多少人将N多时间“Kill”在沙滩上？！

Ralasafe体系结构及应用集成

Ralasafe是中间件，采用服务模型。在业务需要的地方，调用Ralasafe接口，或者将Ralasafe接口向LOG4J那样wrap到你的aspect里面去。

 

Ralasafe按照权限的方向，提供2种数据级权限管理服务，也正好对应2个接口：

1，从系统获取数据， Ralasafe.query( int privilegeId, User user, CustomizedWhere where, int fromIndex, int size );

2，向系统提交数据之前的判断，Ralasafe.permit( int privilegeId, User user, Object businessData);

Ralasafe还针对web应用，提供了WebRalasafe。

 

接口非常简单，在接口层只要告知Ralasafe：当前这个是谁，他/她想干什么。

权限逻辑，全部在Ralasafe图形化管理界面，点击鼠标完成配置，并进行在线测试。无需编程。

所以，使用Ralasafe编程工作量非常少。也给不少开发人员造成“不知道怎样与应用集成”的错觉。

Ralasafe的用户怎么来

Ralasafe并不会给你的应用系统“假定”有哪些字段。你的应用系统用户可以由任意字段，通过XML文件安装到Ralasafe即可。该XML文件，主要指明：用户存在那张表（也可以是视图，这样可以从多张表关联读取数据。比如ralasafe-demo，就关联到company表读取了companyLevel和companyName字段）； 哪些字段是唯一字段； 哪些字段是主键；各字段对应类型。

 

然后，在所有权限规则里面，可以读取这些用户字段。比如ralasafe-demo应用（下载地址：

http://www.ralasafe.org/zh/download/download.jsp ) 用户含有companyLevel字段，在定制“总公司”用户分类的时候，就将该用户companyLevel字段与总公司级别“1”进行比较。

 

（下期真正开始探讨数据级权限管理实现了）

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

 

 

 

最近我在搞权限这一块！

看了楼主的文章，使我受益匪浅！

真的很期待！

现在JavaEye的朋友怎么这样眼高手低了，人家辛辛苦苦写出来的连载，你不愿看也就罢了，居然投了5个隐藏帖，实在看不过去。

这里[高手]众多，很多人想投精华也因为发的隐藏帖多了，积分扣到0无法再投

好帖子，一直对权限控制没更好的想法，我差点陷入5表中。

讨论基于url角色权限控制，与数据级的权限控制主题,就值得一看.

我就是属于那无法再投的，所以说LZ比较杯具，或者又说明【高手们】认为我们认为属于“精华”的都不值一哂

分析得不错。期待下一篇

从你们的API 看，似乎是直接侵入到SQL一级，好的数据级权限控制系统绝不会要求别人用特定的函数或者API来访问数据源的。说的不对地方请指正！

讨论基于url角色权限控制，与数据级的权限控制主题,就值得一看