也来乱弹权限系统

也来乱弹权限系统

最近在设计权限方面的内容，有些想法，乱弹一下。个人觉得实现权限系统主要是三个方面：
1、授权。主要是授权模型的维护，如资源、角色、用户、部门的对应关系等。
2、认证。主要是用户身份的认证，以及取出用户的权限。
3、校验权限。当用户对某一资源进行操作时，将用户的权限与操作该资源所应有的权限进行比对校验。
在对这三个方面进行说明前，也想说说对数据权限的看法。什么是数据权限，很简单，
考虑一种场景 （javaeye里的例子）
看看销售数据
A销售员可以看到自己的销售情况和每一笔具体销售业务，但是看不到B的
B销售员可以看到自己的销售情况和每一笔具体销售业务，但是看不到A的
分公司销售经理则可以看到本部门的A和B的销售情况，但是看不到其他分公司的销售业务
集团销售Boss可以看到集团内所有分公司的销售业务数据
共同点：他们都可以看到“销售数据”这一模块
不同点：他们读取数据的范围是不一样的
这个也可以叫做实例级权限控制。有人认为这种权限一般是放在业务里做的, 如果非要用一个固定的模型实现,可以参考 ACL, 不过也是要在业务里写 ACL 相关代码的。确实，以前自己也都是放在业务里做的，但一直认为这也应该是权限系统的一部分，通过用户的权限来构造不同的sql语句。具体通过AOP实现，好象已经有个开源的东西还没看（lllyq的 http://bba96.dev.java.net）。ACL对实例级权限控制感觉效率会有问题，个人看法。
具体来说：
1、授权
   具体开发里简便的授权方式已经成了用户必提的要求，很明显，仅仅基于role和权限交互是远远不够的。现实中你必须把角色、用户、部门三者全部与权限挂钩。而这三者毫无疑问地就会存在权限继承的问题。考虑一下，在部门A增加一个用户，很显然该用户会继承部门A的权限；同时如果在部门A下增加一个部门角色，该角色应不应该也继承部门A的权限呢？也许需要一个规则接口，具体规则实现看客户需求。
   再说说资源，这里仅讨论系统资源不考虑数据资源。考虑一个“业务管理”的模块，该模块下面还有“项目管理”，“物品管理”，“采购管理”三个模块，当对用户赋予了“业务管理”模块的查看权限，用户是否同时对“项目管理”，“物品管理”，“采购管理”具有查看权限呢？这里同样存在资源权限继承的问题。客户的需求是不同的，所以同样需要一个资源权限继承的规则接口。
   最后说说授权信息的保存。考虑ACL。表设计：资源ID，权限主体ID，权限主体TYPE，资源操作权限。一开始考虑权限主体ID就是UserID，这样会在认证的时候效率很高，但考虑到部门A下有100个用户，当对部门A增加一个权限时，实际上会往ACL表里插入100条记录，这就让人不能接受了。
2、认证
   其实就两个方面，一是检查是否存在这个用户，二是取出用户的权限。呵呵，这里有些绝对了，取出用户的权限完全可以放到校验权限里来做，不必这里一次性全读出来。用户的权限放在一个List里，对象可以构造一个，两个属性：资源ID和资源操作权限。取出用户的权限时候要用到上面定义的规则接口来组装用户实际的所有权限。
2、校验权限
   这个就比较简单了，个人倾向于在Action里完成这个工作，需要进行权限检查的Action实现一个接口，接口里有一个 public boolean hasPermission() ，写个拦截器拦截即可。这里的关键还是通过资源权限继承的规则接口来校验用户操作该资源的权限。
完全是个人乱弹，欢迎拍砖：）

http://www.blogjava.net/ronghao 荣浩原创，转载请注明出处：）