六是数据范围操作权限，其实这个是可以和数据范围权限合为一个的。具体的区别在与对已经划分范围的数据再增加操作的权限控制。还是以财务管理为例，部门经理只能查看金额小于1W的数据；而总经理则没有限制，可以查看所有数据。但是请注意：他们只能对这些数据拥有查看的权限，不能修改或是删除，而财务则拥有修改的权限。在一些情况下可以用模块操作权限和数据范围权限的叠加来满足对该权限的需求，但是在权限复杂的情况下，这个权限独立出来是必须的。

权限系统基于acegi框架实现了从前端页面到后台数据全面的控制。在权限控制中，它将权限分成五类：  
  一是系统权限，主要是对模块为单位的权限划分，具体就是用户对该模块可见不可见，能不能对该模块进行再授权的操作。表现在用户界面就是用户登录系统主页面后，可以看到的顶部菜单和左侧outlookbar菜单的内容控制。作为粒度最大的权限控制，系统实现了web url的防盗链功能。举例来说，用户新开发的一个叫车辆管理的模块，配置在http://localhost/business/carmanage.action的url下，当对这个模块的权限加以控制后，直接在浏览器中键入http://localhost/business/carmanage.action同样是无法访问的，而不仅仅是界面内容的屏蔽。
  二是模块操作权限，在对整个模块的权限做出控制后，这里继续对模块的浏览、增加，修改，删除的操作权限做出控制，也可以理解为对象权限 。还是以车辆管理为例，不同的人员对这个模块的操作是不同的，有些用户可以新增，删除车辆；而有些用户则只是可以对车辆的情况查看不能修改。通过系统提供的一套web 标签，页面可以根据用户不同的操作权限屏蔽相应的功能按键。例如删除，新增按键。用户绕过页面直接操作相应业务方法同样也做到了严格的控制，没有权限的访问会被拒绝同时记入日志。 
  三是数据范围权限，又可以叫做对象实例级权限。事实上不是每个用户都可以看到所有记录的。以财务管理为例，部门经理只能查看金额小于1W的数据；而总经理则没有限制。权限系统对这部分权限也做出了全面的控制，可以根据数据类型，相应字段数值范围做出控制。
  四是单条数据ACL权限，为了满足更严格的数据权限要求，权限系统对数据实现了单条数据的ACL权限，具体说就是对每条数据都实现了权限控制，每条数据都有一到多条权限数据与其对应。以个人通讯录为例，每个用户都维护自己的一个通讯录，这些数据都只是对本人可见，其他人不可见。但用户可以对这些数据做出授权，将某条联系方式以授权的方式共享给其他人，并赋予不同的权限，包括拥有，修改，删除，浏览四种权限。

五是数据字段权限，通过xml配置，系统保证了用户的最小粒度的权限控制。每条业务数据权限可以精确控制到每一个字段。包括单个字段的可否浏览以及可否修改。保证了敏感信息的安全性。

授权，作为权限系统的重要部分，系统提供了相当方便的操作体验。以树状的方式展现权限主体（用户，角色，部门）以及资源，方便，直接，一目了然。区别与传统的RBAC模型，权限不仅仅可以分配给角色，也可以分配给部门和用户。实际的权限是这三者权限的叠加，最大限度的方便用户操作。考虑到用户的扩展，系统提供两个权限继承规则接口，用户可以自定义权限继承的规则。例如，部门A下有部门A1，部门A的权限是否由部门A1继承。

    private int mask; //权限

    public int getMask() {
        return mask;
    }

    public void setMask(int mask) {
        this.mask = mask;
    }
  }
  
  public class Contact extends BasicAclDomain
扩展二、读取列表时进行数据的过滤，原来的acegi在ACL的集合后处理会造成分页产生虎牙子
     这里采用前拦截，在acl表里增加一个className字段,里面放上PO的类名,这样可以缩小
     数据查询范围.实际在读取集合时,是先到acl表里完成分页,然后获得对Contact的real id list
     然后拦截实际DAO方法,动态改变SQL成select * from real_data where id in ( {real id list} )的形式,这样就OK了,
     分页实际是对acl表里相应记录的'分页'.比如说取第10条到20条,实际是取acl表里相应记录的第10条到20条来动态改变SQL
     这个可以写一个专门被用来拦截的类 SecurityDAO 方法findByPageACL(query, page)，ContactServiceImpl中getAllContacts
     方法强制调用该方法
扩展三、后拦截。这里AFTER_ACL_COLLECTION_READ和AFTER_ACL_READ的目的就很简单了，因为他们不再进行数据过 滤， 他们只是把用户对每条记录的mask取最大权限就OK，然后往PO里setMask。这样PO带了权限信息到页面上就非常好处理了。比如button的显示等等
扩展四、封装AclService,对单条记录的ACL权限管理。比如增加权限、修改权限、删除权限。这个acegi的最新1.0.3已经开始加入。
具体在实现中感觉acl的vote完全是鸡肋，全部不用。另外在扩展二中如果用户数据要实现数据库排序就比较困难。所以就有了还未实现的构想：
一、PO创建向ACL表里插入权限信息时可以配置不同的策略：比如通讯录创建一条新信息只能创建者可以看并管理，而你往请假表里插一条新信息后，不仅你了，你的上司也可以同时看到。（这个还是比较easy）
二、用户数据要实现数据库排序。需要在ACL_OBJECT_IDENTITY里增加几个额外的字段，把po相应的排序字段同步更新到ACL表中。什么？不好做？写配置文件啊！再对PO的update进行后拦截。
想法就这样。实现？？

1、  系统权限考虑继续采用原先实现方式，在构造功能树和树状菜单时作出权限判断；

2、  数据库操作权限考虑应用 Acegi 扩展，在业务层对相应的浏览 / 增加 / 修改 / 删除的业务方法进行拦截；

3、  行级数据权限考虑采用 AOP 的方式在用户访问相关资源时根据用户权限动态构造 SQL 注入到业务方法里，再由业务方法传递到 DAO 里；

4、  列级数据权限考虑做入页面，这里不再讨论。

5、  大集中模式下的权限管理，本质也是行级数据权限，即在每次数据访问时都需要强制判断用户所属部门 Group 。

一、 权限管理详细解决方案

用户、用户组、角色设计如下：

Principal 即为权限主体

1、  系统权限授权

web 页面：

页面上显示两棵树：左侧显示用户、用户组和角色树，右侧显示功能模块树，功能模块树的节点上跟两个复选框，分别是可见 / 可再授权。点击用户、用户组和角色树上的节点对相应权限主体进行授权。

很显然可再授权权限包含可见权限。

数据库实现：

用 ACL 实现，表设计如下：

资源 ID ，权限主体 ID ，权限主体 TYPE ，资源 TYPE ，资源操作权限，条件查询语句 queryStr 。

说明：

权限主体 TYPE  三种： user/group/role

资源 TYPE         两种： function/method  此时对系统权限来说是 function

条件查询语句 queryStr    数据范围控制   此时对系统权限该字段无效

对象：

用户保存授权信息时，先删除该权限主体 ID 的授权记录，再更新。

2、  数据库操作权限授权

这里引入一个新的对象：数据库操作资源对象   DataResource

表设计如下：

ID ， NAME ， parentId ， resStr ， resType ， desc

说明如下：

ID

NAME 资源名称 例如：新增用户

parentId

resStr  业务方法地址 例如： com.way.sevice.UserService.addUser

resType 资源类型，分两种： abstract/detail  抽象 / 具体

desc  描述说明

例子：

对用户管理进行数据库操作权限授权

新建“用户管理”做父节点，选择资源类型为“抽象”

在“用户管理”下再依次新增“新增用户”、“浏览用户”、“修改用户”、“删除用户”四个子节点，选择资源类型为“具体”

如果系统自己来判断存储就是叶子节点是“具体”，其他为“抽象”

web 页面：

页面上显示两棵树：左侧显示用户、用户组和角色树，右侧显示数据库操作资源对象树，数据库操作资源对象树的叶子节点的一级父节点上跟一个数据范围限定 button ，点击后弹出窗口输入限定条件；叶子节点上跟一个复选框。点击用户、用户组和角色树上的节点对相应权限主体进行授权

授权信息存入 ACL 表中

资源 TYPE 为 method

3、  行级数据权限授权

已在上面做了说明即数据范围限定

4、  大集中模式下的权限授权

其实所谓大集中模式控制的也不过是数据范围，考虑是所有相关表全部增加 groupId 字段，新增时添入该字段，读出时进行判断

web 页面：

“组织和用户管理”模块中，每个组织中都允许设定一个管理员，一旦设定管理员，该组织就进入大集中模式，即所有该组织的数据与其他同级组织互相隔离，仅上级组织可见。同时说明一点的是：该管理员与系统总的管理员权限一样，不同的是数据范围仅限制与该组织内部。

综述：

实际的授权部分采用了 ACL ，所以授权比较简单和直观

系统资源和数据库操作资源分开两个表存储，这样可能会给用户带来不便，也就是授权时还需要切换，但这种不便似乎不好解决，因为一个是粗粒度的一个是细粒度的。