通用权限管理系统java权限处理及其实现思路

1、窗体顶端关键字: 用户权限管理 B/S系统中的权限比C/S中的更显的重要，C/S系统因为具有特殊的客户端，所以访问用户的权限检测可以通过客户端实现或通过客户端+服务器检测实现，而B/S中，浏览器是每一台计算机都已具备的，如果不建立一个完整的权限检测，那么一个“非法用户”很可能就能通过浏览器轻易访问到B/S系统中的所有功能。因此B/S业务系统都需要有一个或多个权限系统来实现访问权限检测，让经过授权的用户可以正常合法的使用已授权功能，而对那些未经授权的“非法用户”将会将他们彻底的“拒之门外”。下面就让我们一起了解一下如何设计可以满足大部分B/S系统中对用户功能权限控制的权限系统。 需求陈述 不同职

2、责的人员，对于系统操作的权限应该是不同的。优秀的业务系统，这是最基本的功能。 可以对“组”进行权限分配。对于一个大企业的业务系统来说，如果要求管理员为其下员工逐一分配系统操作权限的话，是件耗时且不够方便的事情。所以，系统中就提出了对“组”进行操作的概念，将权限一致的人员编入同一组，然后对该组进行权限分配。 权限管理系统应该是可扩展的。它应该可以加入到任何带有权限管理功能的系统中。就像是组件一样的可以被不断的重用，而不是每开发一套管理系统，就要针对权限管理部分进行重新开发。 满足业务系统中的功能权限。传统业务系统中，存在着两种权限管理，其一是功能权限的管理，而另外一种则是资源权限的管理，在不同系

3、统之间，功能权限是可以重用的，而资源权限则不能。关于设计借助NoahWeb的动作编程理念，在设计阶段，系统设计人员无须考虑程序结构的设计，而是从程序流程以及数据库结构开始入手。为了实现需求，数据库的设计可谓及其重要，无论是“组”操作的概念，还是整套权限管理系统的重用性，都在于数据库的设计。我们先来分析一下数据库结构：首先，action表（以下简称为“权限表”），gorupmanager表（以下简称为“管理组表”），以及master表（以下简称为“人员表”），是三张实体表，它们依次记录着“权限”的信息，“管理组”的信息和“人员”的信息。如下图：这三个表之间的关系是多对多的，一个权限可能同时属于多

4、个管理组，一个管理组中也可能同时包含多个权限。同样的道理，一个人员可能同时属于多个管理组，而一个管理组中也可能同时包含多个人员。如下图：由于这三张表之间存在着多对多的关系，那么它们之间的交互，最好使用另外两张表来完成。而这两张表起着映射的作用，分别是“actiongroup”表（以下简称“权限映射表”）和“mastergroup”表（以下简称“人员映射表”），前者映射了权限表与管理组表之间的交互。后者映射了人员表与管理组表之间的交互。如下图：另外，还需要一张表来控制系统运行时左侧菜单中的权限分栏，也就是“权限分栏表”，如下图：根据上面的分析，我们进行数据库结构设计，如下图：点击这里查看权限管理

5、系统数据表字段设计为了能够进行良好的分析，我们将数据库结构图拆分开来，三张实体表的作用已经很清晰，现在我们来看一下两张映射表的作用。一 权限映射表 如下图：首先，我们来了解一下权限映射表与管理组表以及权限表之间的字段关联。看图中的红圈，先看gorupid字段相关联，这种关联方式在实际数据库中的表现如下图：如图中所示，管理组表中“超级管理员”的groupid为1，那么权限映射表中groupid为1的权限也就是“超级管理员”所拥有的权限。使用groupid字段关联，是为了查到一个管理组能够执行的权限有哪些。但这些权限的详细信息却是action字段关联所查询到的。action字段相关联在数据库中的表

6、现如下图：通过这种关联，才查询到权限映射表之中那些权限的详细信息。综合起来，我们就知道了一个管理组可以执行的权限有哪些，以及这些权限的详细信息是什么。或许你会问，为什么不使用actionid字段相关联呢？因为： 权限表中的id字段在经过多次的数据库操作之后可能会发生更改。 权限映射表中仅仅记录着一个管理组可以执行的权限。 一旦权限表中的id更改，那么权限映射表中的记录也就更改了。 一个管理组可以执行的权限势必将出错，这是非常不希望的。考虑到上面的情况，所以应该使用action字段相关联，因为： 在权限表中，id可能发生变化，而action字段却是在任何情况下也不可能发生变化的。 权限映射表中记

7、录的action字段也就不会变。 一个管理组可以执行的权限就不会出错了。二 人员映射表 如下图：我们来了解一下人员映射表与管理组表以及人员表之间的字段关联，如下图：看图中的红圈部分，先看groupid字段关联，这种关联方式在数据库中的表现如下图：如图，“超级管理员”组的groupid为1，我们再看人员映射表，admin属于超级管理员组，而administrator属于超级管理员组，同时也属于管理员组。使用这种关联方式，是为了查到一个管理组中的人员有谁。和上面一样，人员的详细信息是靠id字段（人员映射表中是masterid字段）关联查询到的。id字段（人员映射表中是masterid字段）关联表现

8、在数据库中的形式如下图：一个人员可能同时属于多个“管理组”，如图中，administrator就同时属于两个“管理组”。所以，在人员映射表中关于administrator的记录就会是两条。这种关联方式才查询到管理组中人员的详细信息有哪些。综合起来，才可以知道一个管理组中的人员有谁，以及这个人员的详细信息。再结合上面谈到的权限表和权限映射表，就实现了需求中的“组”操作，如下图：其实，管理组表中仅仅记录着组的基本信息，如名称，组id等等。至于一个组中人员的详细信息，以及该组能够执行的权限的详细信息，都记录在人员表和权限表中。两张映射表才真正记录着一个组有哪些人员，能够执行哪些权限。通过两张映射表的

9、衔接，三张实体表之间的交互才得以实现，从而完成了需求中提到的“组”操作。我们再来看一下权限分栏表与权限表之间的交互。这两张表之间的字段关联如下图：两张表使用了actioncolumnid字段相关联，这种关联方式在数据库中的表现如下图：如图所示，通过这种关联方式，我们可以非常清晰的看到权限表中的权限属于哪个分栏。现在，数据库结构已经很清晰了，分配权限的功能以及“组”操作都已经实现。下面我们再来分析一下需求中提到的关于权限管理系统的重用性问题。为什么使用这种数据库设计方式搭建起来的系统可以重用呢？ 三张实体表中记录着系统中的三个决定性元素。“权限”，“组”和“人”。而这三种元素可以任意添加，彼此之

10、间不受影响。无论是那种类型的业务系统，这三个决定性元素是不会变的，也就意味着结构上不会变，而变的仅仅是数据。 两张映射表中记录着三个元素之间的关系。但这些关系完全是人为创建的，需要变化的时候，只是对数据库中的记录进行操作，无需改动结构。 权限分栏表中记录着系统使用时显示的分栏。无论是要添加分栏，修改分栏还是减少分栏，也只不过是操作记录而已。综上所述，这样设计数据库，系统是完全可以重用的，并且经受得住“变更”考验的。总结：此套系统的重点在于，三张实体表牢牢地抓住了系统的核心成分，而两张映射表完美地映射出三张实体表之间的交互。其难点在于，理解映射表的工作，它记录着关系，并且实现了“组”操作的概念。

11、而系统总体的设计是本着可以在不同的MIS系统中“重用”来满足不同系统的功能权限设置。附录：权限管理系统数据表的字段设计下面我们来看看权限管理系统的数据库表设计，共分为六张表，如下图：action表：action表中记录着系统中所有的动作，以及动作相关描述。actioncolumn表：actioncolumn表中记录着动作的分栏，系统运行时，左侧菜单栏提供了几块不同的功能，每一块就是一个分栏，每添加一个分栏，该表中的记录就会增加一条,相对应的，左侧菜单栏中也会新增机一个栏。actiongroup表：actiongroup表记录着动作所在的组。groupmanager表：groupmanager表

12、记录着管理组的相关信息，每添加一个管理组，这里的记录就会增加一条。mastergroup表：mastergroup表记录着管理员所在的管理组，由于一名管理员可能同同时属于多个组，所以该表中关于某一名管理员的记录可能有多条。master表：master表记录着所有管理员的信息，每添加一个管理员，该表就会增加一条记录。权限管理及其实现思路l 需求：oa系统包含众多模块，要求能够通过权限管理，控制不同用户对模块的访问权限，而且需要控制到（增删改查）CRUD操作的级别。要求能通过角色对用户进行统一授权，在某些特殊情况下，能够单独对用户进行授权。l 分析n 概念模型l 设计：n 在用户与角色的关系中，以

13、用户为主来进行设计符合客户的使用习惯，即“将多个角色授予某个用户（让用户拥有多个角色）”，比“将多个用户添加到某个角色上”更加让人容易理解。n 模块的授权以针对角色为主，即大部分的情况下，针对角色来分配模块的权限n 一旦根据角色划分好权限之后，就可以进行用户的创建工作，同时可以给用户分配角色（可以为多个），用户将拥有其所属角色的所有权限（这样就达到了统一控制的目的）n 由于一个用户可以拥有多个角色，系统无法对角色的授权进行控制（或者说无需对其授权进行控制，因为为了给客户提供更大的灵活性），所以很有可能出现授权有冲突的多个角色被授予同一个用户的情况，比如：角色A对模块A有删除权限，但角色B对模块

14、A的删除权限则被禁止，这时候，如果将角色A和角色B同时授予用户A，则会造成困扰，究竟用户A对模块A的删除权限是允许还是不允许？它应该是以角色A的授权为准，还是应该以角色B的授权为准？针对这个问题，可以考虑如下解决办法：u 第一种解决办法是：如果多个角色之间有授权冲突，则不允许将这些角色同时授予同一个用户，比如，在上述例子中，不允许将角色A和角色B同时授予用户Au 第二种解决办法是：允许将有授权冲突的角色同时授予同一个用户，但用户在某个时刻只能扮演其中的某个角色。在用户登陆后台管理界面之后，可以通过切换角色，来执行不同的操作！u 第三种解决办法是：允许将有授权冲突的角色同时授予同一个用户，对用户

15、的这些角色来说，有优先级的概念，当将角色分配给用户的时候，应该设置它的优先级。同一个角色在不同的用户那里可能具有不同的优先级。当授权有冲突的时候，以优先级更高的角色授权为准。u 第一种解决办法限制太死，不够灵活；第二种解决办法，客户的反馈是不够方便（需要不断切换）；因此本设计方案将采取第三种解决办法n 至此，用户与角色之间的设计思路便清晰起来：n 再来看授权，可以把模块的增删改查操作授予某个角色或用户，并设置为允许或禁止此操作。我们可以考虑使用授权控制列表来存储授权信息。现有需求下，授权的主要要素是：一个是角色或用户；一个是模块；一个是操作；一个是允许/禁止。这也就是授权控制列表（ACL）的主

16、要要素。n 进一步的思考是：操作包括“增删改查”四种操作，针对这每一种操作，需要一个对应的“允许/禁止”标识。最直观和直接的考虑便是：ACL针对每种操作设置一个属性，和一个“允许/禁止”的标识。但是这种设计会造成灵活性的缺失。比如有可能随着需求的变更，添加了其它的操作类型，那时候必须对ACL做必要的更改才能适应需求的变化。为了适应这种可预见的需求，可将操作及其“允许/禁止”标识设计如下：u 在ACL中，设计一个int类型的状态位：aclState，在Java中，int类型有32位，用位(bit)来表示操作类型（暂定：第0位表示“增”；第1位表示“删”；第2位表示“改”；第3位表示“查”），位的

17、值（对于“位”来说，只能取值0或1）用来表示“允许/禁止”（0表示禁止，1表示允许）。这样，操作类型及其“允许/禁止”标识便能合二为一，而且提高了灵活性（能支持将来可能会增加的多达32种操作类型），因为对于某个模块而言，针对这个模块的操作能够超过32个的情况，是几乎不会发生的，因此对这种特殊情况可以不予考虑。n 客户要求在特殊的情况下，能够直接对用户进行授权。意思是不管其角色的授权如何，始终采取针对用户的授权来作为最终的授权。而且，要求控制到的粒度是模块（即可以针对某个模块设置给某用户单独的授权）。当然，在设置好授权之后，可以在适当的时候再开放给用户使用。因此，这里有一个针对用户的授权是否有效

18、的问题。可采取添加另外一个int类型的状态位（aclTriState）的办法来满足这种需求。这个额外状态位用-1表示针对用户的授权无效；用0表示针对用户的授权有效。之所以使用-1和0来表示无效/有效，是因为-1代表了一个32位全1的int类型值；而0则代表了一个32位全0的int类型值。此设计隐含的意思是：aclTriState的位与aclState的位一致，而且某个位所表示的操作也是一致的，取1表示无效，取0表示有效（用0还是1来表示有效，这是无关紧要的事情）。这种设计是为了将来可能扩展的需要。现在的需求是能对模块的授权控制其有效/无效即可，将来有可能需要对模块的操作（增删改查）的授权控制其有效/无效。这种控制粒度更细。如果要控制到更细的粒度，那么，aclTriState可以取更多的状态值，来表示操作级别的有效/无效。u 有效/无效的意思是：如果无效，则用户对此模块的授权将受到其所属角色的统一控制；如果有效，则角色对此模块的授权将无法影响到拥有这个角色的用户的授权。l 实现n 权限管理模块在实现上，有多个用例需要实现：管理模块信息、管理用户信息、管理角色信息、给用户分配角色、给角色授权、给用户授权、获取用户授权列表、判断用户对某个模块的某操作是否有允许授权n 其中比较重要的是：授权、获取用户授权列表以及判断用户对某个模块的某操作