企业级应用系统中数据的安全性格外重要，必须很好的解决系统管理权限问题，让应用系统的不同用户，拥有与其角色相对应的特定几个应用子系统（或
2 应用系统权限管理的设计
现实的企业往往分成多个职能部门进行管理。在较大的企业中，各个职能部门下面还有多个子部门，这些子部门可能还有自己的下级部门。企业中某个业务的完成需要具体分配到某个部门，甚至某个子部门。要满足这种多部门、多层次管理的需要，企业级Web应用系统的权限管理必须采取多级授权。
在具体的权限管理中，为了方便权限的授予和回收，需要设置角色或者用户组，来进行权限的批量维护。同时为了使授权更加灵活，还可以对用户授予附加权限。附加权限如果和角色或者用户组权限不重复，权限维护功能的实现效率不会受到太大的影响。
2.1 解决方案
2.1.1 系统用户的设置
在此多级授权的权限管理中，首先要确定一个超级管理员账户，该账户在系统初始化前就设置好，具有唯一性，主要职能是进行系统初始化，以及进行系统模块的管理。超级管理员在完成系统初始化之后，在企业下一级各部门中建立管理员账户，管理员账户在部门中具有唯一性，主要职能是建立下级管理员账户，以及针对该部门进行用户和权限的管理。企业中的所有员工都可以成为普通用户，已经有管理员账户的员工还可以建立普通用户账户。管理员职能进行系统管理，而普通用户的职能主要是完成业务系统的管理。
2.1.2 用户权限的设置
用户权限主要包括两种：第一种是功能模块级的，在具体应用时往往对应的是一个浏览器窗口；第二种是操作权限，对应于一个功能窗口中的“添加”、“删除”、“查询”等数据操作，在页面中往往是一个超级链接或者按钮。要注意的是，并不是每个功能模块都有对应的操作，子系统级模块就不能有具体的操作，只有最底层的功能模块才能有操作。
2.1.3 用户权限的来源
系统用户的权限有三个来源，分别是角色权限、用户组权限以及附加权限。角色的设置主要针对一组在管理功能上相同的用户，用户隶属于某个角色便拥有了该角色的所有权限，管理员可以将可转授角色授予下属用户。用户组的设置组要针对相同部门的用户，用户隶属于某个用户组便拥有了该用户组的所有权限，管理员可以将可转授用户组授予下属用户。附加权限的出现有两种情况，一种是先设置了用户的角色（用户组）后，授予用户的零星权限，这种权限往往不存在重复；另外一种情况是先给用户分配了零星权限，然后再设置用户的角色（用户组），这样附加权限和角色（用户组）权限可能存在重复。对附加权限的处理在回收权限的时候要特别注意。
2.2 数据库设计
权限管理主要涉及到的数据表如下图：
1) 用户表用于记录系统用户信息。
2) 用户组表用于记录系统中定义的用户组信息。
3) 角色表用于记录系统中定义的角色信息。
4) 用户所属用户组表用于记录用户所属的用户组，以及该用户是否能将用户组权限转授给下属用户。
5) 用户所属角色表用于记录用户所属的角色，以及该用户是否能将角色权限转授给下属用户。
6) 模块列表用于记录系统中功能模块信息，其中所属模块ID用来记录其父模块编号；类别用来区分其是子系统、普通功能模块还是最底层功能模块；链接用来记录功能模块对应的功能页面的URL。
7) 操作列表用于分模块记录所有底层功能模块所拥有的操作。
8) 模块权限表用于记录系统的功能模块权限分配信息，其中被授权对象ID记录的是用户编号或者用户组编号或者角色编号；权限分类用来区分授权对象是用户、用户组还是角色；能否转授用来表示该模块及其操作能否被转授。
9) 操作权限表用于记录底层功能的具体操作权限的分配信息。
3 权限管理的实现
3.1 浏览器端的实现
3.1.1
在权限管理中涉及到的页面窗口主要包含两个，一个是在创建系统用户时给用户分配角色或者用户组，另一个是给用户、角色和用户组对象授予具体权限。前者仅仅是通过指定用户所属的角色名称和用户组名称将该角色或者是用户组的权限授予了用户，界面设计相对简单。后者需要同时体现授权对象、模块权限信息、操作权限信息，界面设计比较复杂，下图是针对该功能的一种界面实现：
首先是使用框架将几种数据元素进行分隔显示。用户、角色和用户组这三种授权对象均采用列表显示，使用TAB页特效来实现三种列表间的切换。
在授权对象列表中选中一个对象后，在功能模块树中显示该对象的模块权限信息。功能模块树中的每一个节点对应于一个当前管理员所拥有的并且能够转授的模块权限，管理员拥有的那不能转授的模块权限不会出现在模块树中。已经授予对象的功能模块在树中表现为选中状态；如果授权对象为用户，其来自角色或者用户组的权限将显示为不可取消的选中状态，只有附加权限显示为可取消得选中状态。
点击最底层功能模块后，会在右下方的框架中显示该模块操作。只有当前管理员拥有的操作权限才会显示，而授予对象的操作权限显示为选中状态。在此页面中还可以设置对象是否能对当前选中的功能模块权限进行转授，当然此选项只对用户有效。
3.1.2 数据结构
构建功能模块树需要获取当前管理员拥有的可转授的模块权限，以及被选中对象所拥有的模块权限。将这些数据构造成JavaScript脚本中的数组，再利用JavaScript特效就能够造成模块权限树。最后构造JavaScript方法来保持模块选中的一致性，即保证取消一个节点同时取消其所有字节点，选中一个节点的同时选中其所有的父节点。
通过页面中JavaScript脚本的处理可以将最后提交的权限维护信息整理成格式如下的字符串数据：
模块标识;模块权限操作（添加/删除/增删操作<—>1/2/3）;能否转授（0/1）;发生更改action数目;action1标识;[action操作1（添加/删除<—>1/2）....
如：“23;1;0;3;450;451; 452”表示添加标志号为23的模块权限，此模块权限不能转授，添加标志号为450、451、452的三个操作权限。
“23;3;0;2;450;2;453;1”表示修改标志号为23的模块的操作权限，删除其标志号为450的操作权限，同时添加标志号为453的操作权限。
“23;2;0;3;451;452;453”表示删除标志号为23的模块权限，同时删除标志号为451、452、453的操作权限。
3.2 权限维护处理
根据客户端提交的权限维护信息格式可知，对权限的维护主要包括三个功能：添加功能模块权限、删除功能模块权限、修改功能模块的操作权限。从具体实现来分又可分为权限的授予和权限的回收。
权限的授予比较简单，只对当前接受权限的对象进行处理。
权限的回收则比较复杂，因为在回收一个对象的权限时，必须对由此转授出去的权限进行回收。在这个多级授权，并采用角色（用户组）权限加附加权限的权限管理方案中，必须谨慎的构造权限回收算法。
1) 删除用户的模块权限的算法流程图：
删除用户的操作权限的算法流程与此类似。
2) 删除角色（用户组）的模块权限
假设管理员A将角色Role授予管理员B，管理员B又将角色Role拥有的模块权限M授予用户C。在A取消B的角色Role的时候，如果不回收C拥有的模块权限M，那么对C来说M是没有正常来源的。因此，在删除角色（用户组）的模块权限后，还需要删除系统用户由此获得的附加权限。
删除用户由此获得的附加权限的SQl语句如下：
delete from 模块权限表
where 授权对象类型是用户
and 模块权限是M
and 对象用户是有Role角色（用户组）
and Role角色（用户组）没有其他与M相同并且可以转授的模块权限
删除角色（用户组）的操作权限算法流程与此类似。
4 结论
本文所设计的权限管理已经在笔者所完成的几个基于J2EE技术的企业级应用系统中得到应用。通过实践证明，此多级授权权限管理能够很好的满足企业级应用系统中多部门、多层次管理的需要。
你可以通过这个链接引用该篇文章:http://langhua983.bokee.com/tb.b?diaryId=15859615