权限管理系统，还缺少什么？里面有要求，也有我已经做过的项目的描述！

项目目标：设计并开发与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、通过“级--功能--角色--用户”来进行管理。
功能： 系统的一些操作。  例如：添加员工
•角色：角色是一个或多个功能的集合。例如总经理：人员调整，添加部分信息。。。。。。。。
•用户：用户可以扮演一个或多个角色。
级: 一般权限就是一个功能树的结构，添加‘级‘，主要是用来设置显示的时候加载。。


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

这种权限系统的设计比较普通，个人感觉效率较低，如果项目稍大，权限这一块会是个瓶颈。
而且本文并没有做更细的划分，是想做成粗粒度的还是细粒度的？
希望看到解答。

"资源"+"角色"+"用户"这三者构成的权限系统,功能上没问题.但操作上有问题.看看下面的问题:
考虑实际情况，假如在一个学校里。
属于一般教师的特有权限为p1、p2
而属于主任的特有权限为p3、p4.
而主任要求同时具有教师的权限.那主任这个角色有的权限是p3+p4还是p1+p2+p3+p4?
而主任这个人只具有"主任"这个角色还是具有"主任"+"教师"的角色?
无论你选择上面的哪个实现,在系统增加一个人和增加一个角色两个操作中,最少会有一个很麻烦.

另外你提到系统需要"灵活"+"方便".这是个陷阱.系统越灵活方便,后果就是系统复杂.
设计和编码复杂就不说了,重点是逻辑复杂了.培训难度很大,你培训半天,用户还是不了解的话,
那系统还是失败.
引用一句话就是"设计就是折中"

谢谢，楼上的2位，本来还想写很多的，但是，离职拉，现在忙于找工作中呀。。。这个月，忙完了，我一定吧我则个模块写好。。