访问控制组件的权限粒度及它和AOP的恩恩怨怨
看得人多re的人少，究其原因大约是读者读完以后就miss the point了,不知所云,何来回馈?
so here is the point:
1 访问控制组件的开发在Action层打住还是往下到Service层?
2 是否还能往下到DAO?
3 将Action作为权限元素管控的话,它跟HTTP POST/GET是一一对应关系吗? 它跟URL是一一对应关系吗?
4 AOP是服务性功能,资源树(当然也可以是其他结构)没有初始化之前,AOP无计可施
这几天非常初略的看了一下Acegi，给出如上问题的如下答案，各位指正：
1 Acegi里面没有所谓的Action权限，要么是Web资源，用antURL来进行标识；要么就是业务方法，使用AOP验证
2 没有人这么用过
3 论坛上Robin诸人是这么用的，这里有一个如何初始化Action资源的问题，以后详细来讨论
4 本来想用AOP验证和授权web资源就是错误的想法
就我的感觉设计一个基于RABC的访问控制模型组件的难点不是User-Role-Permission等概念，而是怎样定义和管理资源。
一种说法是：
如果要做一个通用的权限控制模型，由于针对不同的应用，项目中涉及到的资源各不相同，并且每一类资源上的操作也不一样，因此需要抽象出Resource-ResourceType-Operation类出来，为应用开发提供管理资源、资源类型以及定义在资源类型上的操作的接口。这样一来灵活是灵活了,一切皆资源!!好处就是应用开发者可以自定义资源,坏处就是,应用开发者不得不自己定义资源.随时而来的还有,需要为每一类资源指定相关的一组操作,比如文件有执行/读/写/删,页面元素有显示/隐藏/,你甚至可以吧领域对象作为一个资源,或者领域对象的一个方法作为一个资源,或者领域对象所在的包作为一个资源...是不是有点灵活过头了? 而且用户真的需要知道这些吗?
第二种说法:
将资源分为功能性资源和数据性资源,页面Page,页面上的Action(也就是所谓的业务接口,针对用户可见的.它实际上就映射到了页面上的某一个或者一组元素,这个有空再讨论)作为功能性资源,是用户用来进行权限配置的接口,用户只需要了解到这一粒度的权限就可以了,那么针对这个资源,其上的操作只有访问这一种操作,要么有要么没有,管理员(比较高级的用户)给角色分配就好了,so simple.我们把这种权限分配通常叫做前台权限管控.但是往往一个业务接口是由若干个领域对象的方法(在纯OO模型下,如果是贫血的domain模型的话大约就是Service方法吧)组成的一个流程,前后分别是用AOP动态植入的权限验证啊,日志啊,连接的建立与释放啊等等.其中每一个领域对象方法对应着一些数据的操作,无外乎CURD四个.那么针对某一类数据(比如物料)或者某一个数据(料号为ABC的物料,数据实例)的操作我们叫做数据性资源上的权限.当一个业务接口由A对象的create方法+B对象的Update方法组成的话,如果某用户没有对A数据的C(新建)权限,那么此业务接口将不能得到执行,多么强大啊!!问题是,除了用人眼看代码,我怎么能知道业务接口调用了哪些领域对象的哪些方法呢? 虽然在逻辑上, page-Action-dominObject(PO)-domainObjectMethod(Service method)可以组成一个资源树,父资源的权限可以通过子资源的权限计算得到,那么如果我们将用户的权限指定到最细的粒度上,那我们就能计算出某用户针对此资源树上所有的权限了.这个可以参见我的另外一个文章:http://www.iteye.com/post/606826.我们把这叫做后台权限管控但是实际上,我们没有办法初始化这颗权限树啊!
这样的情况下,AOP失效,为什么 ? 因为AOP太早了.如果我不知道一个业务接口中到底调用了那些领域对象方法,我就不能找到这些领域对象方法资源的资源ID并传给AOP,那么AOP中的权限验证接口方法通过什么来判断呢?
坛子里面基本上所有有关RBAC的讨论我都读过了,针对Action做资源管控的或者继续往下针对数据资源进行管控的都有,但是都没有给出可行的方案或者结论.我考虑后台权限管控的原因在于怕有人绕过UI,跳过业务接口直接调用领域模型的方法,但是转念想想又可笑,那有人直接绕过应用操作数据库呢? AC系统不是万能,那么他的系统边界又应该如何定义呢?
public class Login { @Permission(des = "login into the system") public String login(Map mapRequest, Map mapSession) { System.out.println("logining..."); return FormStatics.ACTIONRETURN_REDIRECT + "Index.jsp"; }}
3 写一个ServletContextLisenter在应用启动时利用反射读出应用中所有的Action以及它对应的描述信息
4 持久化此Action表
5 提供UI界面让权限管理员来针对每个角色指定可以执行的Action元素 8 楼 Joo 2008-09-10 改进了一下，吸收Acegi的做法是用XML保存Action资源，就类似Acegi中的DefinitionSource，由开发人员自行进行配置然后再应用启动时读入内存 9 楼 popufig 2009-01-02 我的想法和你的很类似，不过遭到同事的强烈反对
http://popufig.iteye.com/admin/blogs/305872
其实你的做法相当与把resource+operation合并为一个点，也就是你的action，这种做法有个限制就是如果一个action有多个用户可以调到的方法(struts的dispatchAction)，而且要求权限不一致，就很郁闷了
我的想法是把action或者是form做为资源，里面不同的方法对应不同的操作，发布后把这种资源和操作持久化到数据库中，授权时可以用树状结构来显示，实际就两层，第一层是这些资源，第二层就是对应这些资源所能做的操作。 10 楼 Joo 2009-01-04 不知道楼上兄弟说的一个action有多个用户可调用的方法是意思，在我的模型中action是最小的权限粒度，它本身就是一个方法，哪里还会更小的组合？ 11 楼 SINCE1978 2009-06-05 干嘛要用acl这么麻烦，我们可以要求使用权限系统的客户在设计他们的业务表的时候增加录入人字段，或者录入者所属组织机构字段。使业务数据都有所属关系，然后剩下的就不用说了吧。
