一、             考虑实现

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 ，所以授权比较简单和直观

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

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