security2.apt

anewssystem新闻发布系统集成使用了spring hibernate freemarker EXTJS等开源框架 可以作为学习参考

 ---
 权限管理
 ---
 Lingo
 ---
 2007-05-29

关于用户权限管理的问题，有了一些自己的想法

*部门概念

 无论是springside-1.0中的user - role - authority - resource四层结构，还是springside-2.0中的user - role - resource三层结构，都是演示了无部门的权限模型。

 而在实际应用中，比如赵杰的DMIS，成都EAI和极品OA中，使用了添加了部门的权限模型，就是说在user - role - resource中又增加了dept的部分，这样做的好处是，不同部门可以使用相同名称的角色，在设置角色权限的时候，根据部门分别授权，而用户登陆之后，根据本身处在的不同部门，就可以被授予不同的权限。

 这种权限模型的最大好处是，当员工发生平级调动的时候，比如技术部的普通员工，调动到客户服务部之后， 因为角色名都是普通员工，只需要改动此员工的部门，不需要对他的权限设置再进行处理，就可以让他使用新工作岗位的功能权限。

 但问题是，模型增加了一个dept，却大大的增加了模型的复杂程度，原本role - resource之间的多对多关系，变成了role - dept - resource三者之间的网状多对多对多的关系，role与dept结合之后，才能唯一决定使用的权限。如果把角色设置为，软件部项目经理，硬件部项目经理，感觉也是怪怪的，所以说也是应该让部门与角色结合，这样就可以使用诸如“项目经理”这种同名角色，在使用角度上来说是更便利了。但害怕出现与部门锁定的情况，影响跨部门角色的设置与使用。

 想到一个可能实现的解决方法，那就是让dept仅仅与role关联，我们在显示页面中看到的是一个角色名，而实际上数据库中保存着多个角色列表，这些角色列表分别对应每个部门，这样就达到role与resource单独管理，免得加入dept的关系，让数据模型变得更加复杂。现在感觉这样的设置方式，可以达到不增加程序模型的复杂度，同时可以提升用户体验的作用，只不过在设置role的时候，还需要多考虑一下具体的细节问题，比如默认的角色应该是可以在所有部门下使用的（不属于任何一个部门，只是一种缺省情况下的考虑。），增加一个特定部门的角色，就应该覆盖掉默认的角色权限。这个时候再给用户分配角色的时候，如何选择特定的角色，角色分配权限的时候。这些时候就要在界面易用性上下工夫了。
 
 现在对如何实现这样的模型完全没有思路。而且角色权限的时候，很可能要根据部门把一个角色的权限分配多次，这样是不是也让管理人员的工作量提高了呢？而且不知道实际中这样的是不是真正给工作带来便利。所以有待进一步的研究啊。

 假想使用部门概念的情况：公司中人员的技术能力差别不显著，不同部门的员工可以随意变动，而且不同部门中的员工职务名称也是类似的，技术部的一般员工，高级员工，经理，客户服务部的一般员工，高级员工，经理。而且每个员工通常只分配一种角色，这样对角色进行统一管理的时候，以及平级调动的时候就显得很方便。

*职务问题

 在公司中，人员都会有自己的职务分属，也是根据职务来决定自己负责的工作与权限。但系统中常常使用角色role来代替职务来发生作用，约束人员的权限。能不能在系统中使用职务来代替角色呢？我认为是不可以的。

 第一，人员的权限可能会频繁发生变动，而职务的变动可能与权限的变动相比，则稳定得多。比如经常发生在繁忙的时候一个人身兼数职的情况，而在相对清闲的时候，他又会继续去做自己的本职工作。为了解决这种情况，我们就需要抽象出粒度更细的角色，来负责动态分配用户可能经常改变的权限。

 第二，职务是一种树状结构，而角色更趋向于扁平结构。实际中，职务上严格区分上下级关系的，似乎更能体现出不同用户的权限大小，而角色可以当作是一组权限的集合，角色之间没有必然的上下级关系，仅仅是用来简化操作，便于理解的一种手段。从这个角度上来说，扁平式的角色更利于程序实现。

 第三，职务是来自现实工作中的，一种模糊的称谓，是一种感性的认识，更利于人们的记忆和浏览。而角色是为了程序的数学模型，而抽象出来的，更精确的表示功能集合的一个理性概念，更利于逻辑实现。