一个系统包含众多模块,要求能够通过权限管理,控制不同用户对模块的访问权限,而且需要控制到对某个模块的某个操作（增删改查）的级别。一般情况下，通过角色对用户进行统一授权，在某些特殊情况下，能够单独对用户进行授权。

        一、给用户分配角色。涉及到的模块有：

       角色和用户的关系：以用户为主来进行设计符合客户的使用习惯，即将多个角色授予某个用户，也就是用户拥有多个角色。        模块的授权以角色为主，即大部分情况下，针对角色来分配模块的权限。        一旦根据角色划分好权限之后，就可以进行用户的创建工作。用户创建后，就可以给用户分配角色(可以拥有多个角色)，这样，用户将拥有其所属角色的所有权限。       由于一个用户可以拥有多个角色，系统无法对角色的授权进行控制，所以很有可能出现授权有冲突的多个角色被授予同一个用户的情况。例如：角色A对模块A有删除权限，但角色B对模块A的删除权限则被禁止，这时候，如果将角色A和角色B同时授予用户A，则会造成困扰，究竟用户A对模块A的删除权限是允许还是禁止？用户A的权限应该以角色A为准还是以角色B为准？      下面是三种解决方案 a. 如果多个角色之间有授权冲突，则不允许将这些角色同时授予同一个用户。 b. 允许将有授权冲突的角色同时授予同一个用户，但用户在某个时刻只能扮演其中的某个角色。在用户登录后台管理界面之后，可以通过切换角色，来执行不同的操作。 c. 允许将有授权冲突的角色同时授予同一个用户，对用户的这些角色来说，有优先级的概念，当将角色分配给用户的时候，应该设置它的优先级。同一个角色在不同的用户那里可能具有不同的优先级。当授权有冲突的时候，以优先级更高的角色授权为准。      第一种方案不够灵活，第二种方案客户使用不方便，需要不断切换，一般情况下，第三种方案为最佳方案。

      二、授权：把模块的增删改查操作授予某个角色或用户，并设置为允许或禁止此操作。授权需要的要素：角色/用户、模块、操作、允许/禁止。 操作包括增、删、改、查（CRUD）,针对这每一种操作，需要一个对应的“允许/禁止”标识。所以，最直观和直接的是在ACL中针对每种操作设置一个属性，和一个“允许/禁止”标识。但是这种设计会造成灵活性的缺失，例如：当要添加其他的操作类型时，就必须对ACL做必要的更改，为了适应这种可预见的需求，可将CRUD和"允许/禁止"标识设计如下：        在ACL中，设计一个int类型的状态位，aclState。在java中，int类型有32位，用为来表示操作类型（可以自己定义：第0、1、2、3为分表表示增、删、改、查，用位的值来表示允许/禁止（0表示禁止，1表示允许）。这样，操作类型及其“允许/禁止”标识便能合二为一，而且提高了灵活性，能支持将来可能会增加的多达32中操作类型。

       要求在特殊的情况下，能够直接对用户进行授权。不管其角色的授权如何，始终采取针对用户的授权来作为最终的授权。而且，要求控制到的粒度是模块。这里需要增加对用户的授权是否有效的标识。可以在ACL中添加一个int类型的状态aclTriState，当控制到的粒度为模块时，aclTriState为-1时表示针对用户授权无效，用0表示针对用户的授权有效。当控制到的粒度为模块的操作（增删改查）时，aclTriState可以去更多的状态值，来表示增删改查的有效或无效，aclTriState和aclState的位是完全对应的。       这里说的有效/无效的意思是：如果无效，则用户对此模块的授权将受到其所属角色的统一控制，如果有效，则角色对此模块的授权将无法影响到拥有这个角色的用户的授权。   

权限管理的实现：         权限管理模块的实现，需要多个用例：管理模块信息、管理用户信息、管理角色信息、给用户分配角色、给角色授权、给用户授权、获取用户授权列表、判断用户对某个模块的某操作是否允许授权         授权：针对用户或角色授权，在授权界面上，根据系统现有模块，列出授权树，可选择其中的某些模块和某些操作进行授权。由于授权界面的复杂性，采取DWR来辅助实现授权界面。        获取用户授权列表：在用户登录系统之后，需要根据用户的授权情况，获得用户的授权列表，并根据用户的授权列表，在后台界面大导航菜单上显示出用户拥有权限的模块，允许用户对这些模块进行操作。        判断用户对某个模块的某操作是否允许授权：为了控制用户对模块的增删改查操作，需要根据用户的授权情况，决定是否显示“增加”删除、修改等按钮或链接。

本文参考：http://www.docin.com 之OA知识点总结