权限管理系统，还缺少什么？里面有要求，也有我已经做过的项目的描述！
项目目标：设计并开发与JBOSS集成的J2EE权限系统（类似JBOSS的权限管理系统，其实我对JBOSS没什么了解）


总体要求：

1、灵活、通用、方便；

2、高度安全并可靠；

3、易于扩展；

4、结构完整，代码清晰，易于阅读。


技术要求：

1、需要提供详细设计文档，阐述基本思路与实现方法；

2、资源控制（对象资源和数据资源的控制方法）；

3、权限关系建模；

4、访问控制方法；

5、业务逻辑层的访问接口；




===========================下面是我的权限系统的分析资料==============================
权限Demo
　　B/S系统中的权限比C/S中的更显的重要，C/S系统因为具有明确的客户端，所以访问用户的权限检测可以通过客户端实现或通过客户端+服务器检测实现，而B/S中，浏览器是每一台计算机都已具备的，面向的用户对象不确定，如果不建立一个完整的权限检测，那么一个“非法用户”很可能就能通过浏览器轻易访问到B/S系统中的所有功能（例如:SQL注入等）。因此B/S业务系统都需要有一个或多个权限系统来实现访问权限检测，让经过授权的用户可以正常合法的使用已授权功能，而对那些未经授权的“非法用户”将会将他们彻底的“拒之门外”。
需求陈述
• 不同职责的人员，对于系统操作的权限应该是不同的。
• 可以对“角色”进行权限分配。在公司里面，每一个人都扮演这不同的角色，不同的角色，他的权限操作又是不同的。所以，系统中就提出了对“角色”进行操作的概念，将权限一致的人员编入同一角色，然后对该角色进行权限分配。
• 权限管理系统应该是可扩展的。它应该可以加入到任何带有权限管理功能的系统中。就像是组件一样的可以被不断的重用，而不是每开发一套管理系统，就要针对权限管理部分进行重新开发。当一个用户的角色，发生变化，那么他所拥有的权限，也会因此发生改变。
• 关于设计
　　为了实现需求，数据库的设计可谓及其重要，无论是“组”操作的概念，还是整套权限管理系统的重用性，都在于数据库的设计。
下面，我们先来分析一下数据库结构，使用 MySql：
首先，proinfo表（以下简称为“权限表”），roleinfo表（以下简称为“角色表”），以及userinfo表（以下简称为“人员表”），是三张实体表，它们依次记录着“权限”的信息，“角色”的信息和“人员”的信息。如下图：
Userinfo：用户信息表 roleinfo:角色信息表

Proinfo:权限信息表

　　这三个表之间的关系是多对多的，一个权限可能同时属于多个角色，一个角色中也可能同时包含多个权限。同样的道理，一个人员可能同时属于多个角色，而一个角色中也可能同时包含多个人员。

由于这三张表之间存在着多对多的关系，那么它们之间的交互，可以使用2张中间表来实现，一张用来映射权限表与管理组表之间的交互，一张用来映射人员表与角色表之间的交互。由于时间的关系，当然，在数据库设计的时候，角色表和权限表之间没有创建中间表，角色不多（角色类型基本很少发生改变），通过在权限表中创建一个字段来关联实现，对扩展性，肯定是有一定的影响。　
Appinfo:角色表和权限表的映射表

　　通过这种关联，才查询到权限映射表之中那些权限的详细信息。综合起来，我们就知道了一个管理组可以执行的权限有哪些，以及这些权限的详细信息是什么。
或许大家要问，为什么不把角色表和用户表也通过一个字段来关联？
因为：在添加一个用户的时候，就要为该用户分配角色，在角色表中用一个字段来关联，想一下，我有N个用户，角色表中就会有>N条记录，查询出来也很麻烦！
　　为什么使用这种数据库设计方式搭建起来的系统可以重用呢？
• 三张实体表中记录着系统中的三个决定性元素。“权限”，“角色”和“用户”。而这三种元素可以任意添加，彼此之间不受影响。无论是那种类型的业务系统，这三个决定性元素是不会变的，也就意味着结构上不会变，而变的仅仅是数据。
• 映射表中记录着三个元素之间的关系。但这些关系是人为创建的，需要变化的时候，只是对数据库中的记录进行操作，无需改动表的结构。
　　综上所述，这样设计数据库，系统是基本可以重用的，并且经受得住“变更”考验的。
系统不足地方（个人见解）
1. 将所有的权限放在一张表中，如果每一个用户都具有相同的一部分权限？
将相同的权限找出来，划分为一个权限管理组，在用户登陆的时候，直接查询加载。
2. 权限功能的动态显示，应该在数据库中在添加一张表目录表（比较麻烦），设置权限组显示目录分配，当然你也可以在程序来完成该功能！



关于“级别-功能-角色-用户-组”的权限管理设计
思路：
1、通过“级--功能--角色--用户”来进行管理。
功能： 系统的一些操作。 例如：添加员工
•角色：角色是一个或多个功能的集合。例如总经理：人员调整，添加部分信息。。。。。。。。
•用户：用户可以扮演一个或多个角色。
级: 一般权限就是一个功能树的结构，添加‘级‘，主要是用来设置显示的时候加载。。


希望有时间的朋友，拿出你的意见！！！！！！

级别，level，是对角色的级别划分，不同级别的角色可分配的权限一般是不同的。个人理解：）

seam的s:hasrole

我刚做完一个权限管理模块，和你的设计基本一致。不过有2 个关联表，并且在每一个表中都有 “有效日期”，“终止日期”。“级”的概念是通过权限表有个parentId 字段来表达权限的树型结构。

用 Seam 的 hasRole 很容易实现。
page 中的树型结构用 Richfaces 实现不算太难。

好在没有用户组，否则更加搞，感觉权限系统不能过度设计，适用就好。

我的设计，跟你相似，呵呵

qiujy 24 小时前   rolePermission  这个类可以不要的   把role 与 permission 之间建立一对多的关系 

谢谢楼上的各位，我现在是基本确定啦，在设计上，有一定的出入，满足BoSS的需求，用5张表，就能很好的解决。肯能，是我还在想在这方面做扩展，如果有什么好的建议，我还是会采取的！

  很经典的权限管理模式，看不到有什么特别之处。