对权限系统设计的再思考

什么是权限系统，权限系统究竟在整个系统中起到什么作用，或者说权限系统必须提供哪些功能？
谈谈个人的看法，我认为授权和验证是一个权限系统最基本的功能，而一个更完善的权限系统会增加上如何验证和验证后如何处理这两种功能。
对于一个权限系统的基本元素，我觉得只有两个：Principal(权限主体)，权限。用户，用户组，角色等都可以抽象为权限主体这个概念；而权限则是资源+操作的抽象。权限可分为两种，一种纯粹就是资源，没有操作，也可以认为是默认操作；另外一种就是带操作的资源。授权本身没有什么说的，赋予权限主体权限；验证简单的说就是传入权限主体和当前操作需要的权限，然后验证返回说可以操作或是不可以操作yes/no。同时要注意的是验证的时候需要一个类（接口）来返回用户当前所拥有的权限，然后与当前操作需要的权限进行比对，最后返回比对结果。
以acegi为例，下面分开来说明：
首先，acegi是没有授权功能的，它简单把权限主体与资源配置在了xml里，当然这也带来了可扩展性，可以看一个配置：
/index.jsp，/hello.htm这些URL都是资源，因为它默认的操作就是访问，所以访问特定URL就成了一个权限，ROLE_ANONYMOUS,ROLE_USER无疑就是权限主体。
Acegi对方法访问权限的配置也是和上面一样的。
然后，看看acegi的验证，其实它的验证就是一个个的Voter，当你访问一个方法时，由它获得当前用户和需要的权限（就是该
方法），然后返回yes/no。
OK，这就是一个完整的权限系统了。当然acegi如果仅仅提供上面两个基本功能，它是不会向现在这样成功的，它最大的亮点就是提供了如何验证和验证后如何处理这两种功能。对url它提供了filter，方法也一样提供了Interceptor，这就是如何验证，和我们在action里验证没有任何区别，只是换了一种方式而已。然后它验证后的处理方式：yes就继续往下执行,no就抛出异常最后再处理这个异常。我们在执行每个action前同样也可以做到这一点。
这里着重要提到的是数据权限。比如说A只能对部门A下的数据有查看权限，B可以对部门A的数据有修改权限和对部门B的数据的查看权限。
看起来这个需求是比较麻烦的，但是我们可以按上面说的拆分以下：
资源1：部门A下的数据  ；资源2：部门B下的数据
操作1：查看；    操作2：修改
产生四种权限：
权限1：资源1+操作1 ；权限2：资源1+操作2；权限3：资源2+操作1；权限4：资源2+操作2
权限主体A拥有权限：1 ； 权限主体B拥有权限：2，3
这样就非常清晰了。
总结：我始终认为拥有授权和验证功能就完成了一个完整的权限系统。至于如何去校验权限，不管你是filter还是aop那是具体实现时的细节，采取的不同策略。而验证后的处理则是和不同策略相对应的。在你考虑设计一个权限系统时首先考虑的是如何实现授权和验证，而不是一开始就考虑我是采取filter，还是aop，还是动态改变sql。
谢谢wolfsquare，它的blog相关www.blogjava.net/wolfsquare/archive/2006/07/04/56606.html

个人认为数据权限不应该纳入到权限系统范围之内，这样会使权限系统的扩展性比较差，因为每个系统它的数据权限的规则都是不一样的，现在我在做一个通用的权限系统（至少可以满足大部分的需求），我的做法是把数据权限放置到业务逻辑，这样既会使权限系统通用，另外一个方面是数据权限放到业务逻辑本身实现就很简单，何必要增加难度放置到权限系统呢！

我开始也是这样处理和认为的，但是当我使用了acegi的acl部分后，我开始改变了一些想法，我认为是可以有一个通用的抽象的。当然，实现方式参考了acegi的acl。有时间我整理一下

业务和权限要分清楚
  两码事
  权限系统是很单纯，纯洁的，
    如果把业务扯进来就复杂罗

我以前都是把数据权限处理放到业务里，很期待ａｃｌ方式的权限处理，什么时候给讲讲？

习惯把权限系统物理独立出来！

比如新的schema,新的db,新的模块,然后在植入原先的系统。