权限管理第一章

                 J2EE权限系统（基本思路）
                      目录
一.  概述………………………………………………………………………………
二.  目的…………………………………………………………………………………
三.  需求
3.1.       描述……………………………………………………………………….
3.2.       分析……………………………………………………………………….
四.  实现方案………………………………………………………………………………
4.1.       技术策略………………………………………………………………………；
4.2.       基于RBAC的实现…………………………………………………………………
4.2.1.       RBAC介绍…………………………………………………………….
4.2.2.       实现方案…………………………………………………………….
4.2.3.       优缺点分析………………………………………………………….
五.  个人观点…………………………………………………………….. …………………….



一． 概述
权限管理，几乎是每一个项目都会涉及的模块，每一个人对其的理解，都有所不同。 在这里主要是解决怎样构建一个通用，灵活，方便管理的权限管理系统的描述，及解决思路，做一个详细的描述。
 
二.  目的
     构建一个通用，灵活，方便管理的权限管理系统。
三.  需求
3.1.       需求描述

1、灵活、通用、方便；
2、高度安全并可靠；
3、易于扩展；
4、结构完整，代码清晰，易于阅读

技术要求：
1、需要提供详细设计文档，阐述基本思路与实现方法
2、资源控制（对象资源和数据资源的控制方法）；
3、权限关系建模；
4、访问控制方法；
5、业务逻辑层的访问接口；

3.2. 需求分析
通过对要求的理解：
一．权限管理要实现：灵活、通用、方便的目标，数据库设计，权限模型设计应该是关键，对2者设计，對需求反復的分析幾次，希望，在程序设计的时候，做出更好的扩展，由此，了解关键的地方是在资源控制上（对象资源，数据资源）！
二．权限管理登陆：提供身份认证功能，通过此功能标识用户身份。
    三．权限菜单列表： 认证通过后，显示用户可操作的资源列表，对一般的权限管理。对与一些门户网站，用户打开网站，可对一些资源信息进行预览等等，但是对于系统资源，不能进行编辑操作等。通过对该用户的权限验证来，判断用户是否对该资源进行编辑操作权限。
   四．资源控制：
1、对象资源(功能模块)操作的控制（角色也属于对象资源）
对象资源操作的控制在系统上主要分为两个方面：
         正常途径系统资源操作的控制
体现在实际的需求上通常是页面上的功能菜单、按钮、链接等等。
         非法途径系统资源操作的控制.
体现在实际的需求上是防止通过非法的URL（sql注入等）或命令等方式对受保护的系统资源进行操作。
2、数据资源操作的控制
数据资源操作的控制在系统中实际的体现通常是用户只能访问相应数据资源操作权限范围内的数据。通常的理解是，行级数据的访问和列级数据的访问权限操作上面。假如在一个具体的数据库表中有600条数据，A用户能够对前200条数据库修改，查询，删除
        B用户能够对中间200条数据进行修改，查询，删除
        C：用户能够对最后200条数据进行修改，查询，删除

  四.  实现方案

4.1. 技术策略
 设计模型
采用基于角色的用户安全管理，使用基于 用户—角色—权限模型构建权限设计模型。
一个用户可以拥有多个角色，一个角色，可以多个权限（操作资源）。在实际的项目中，需求可能是不断的变化，那么我们的权限模型也要做出适当的调整：

         身份认证
为识别用户身份，通常将用户的身份记录在Session中，也就是当用户登录时即获取用户的身份信息，并将其记录到Session里，当需要进行身份认证的时候通过从Session中获取用户的身份信息来实现用户的身份认证。但是你会遇到这些问题：

1， 登陆成功后，用户信息放在Session中，当再次跳转到别的页面，Session取不出来用户的信息
2， 如果你的项目为实时监控项目（用户信息的24小时在线），一般不浪费系统的资源，我们在选择存放集合信息的时候，一般有2种选择：Session用来存放少量的信息，而使用request来保存大量的用户信息，用于在页面遍历显示.还有一点就是一般做集群的系统，Session也是尽量不用的（为什么，其实很不是很清楚）。在平常一般的系统都会出现Session过期的现象，是实时监控项目上，解决的方法有多种多样，在这样，将2种方法（就知道2种方法，一种没测试过）：一种是将信息存放在XML种（没测试过），一种是使用map替代Session。
3，
使用缓存（时间短，消耗服务器系统的资源），或使用Cookie来记录用户的登陆信息（在客户端，只要用户不删除可以保存很久，自动登陆就是由其实现，但是安全性，不能很好的保障）.在系统中最好由用前者来实现。
4、上面说啦半天，也没说用什么实现.具体的是使用Acegi来实现的。
         权限校验的体现
权限校验的体现通常只是对于系统菜单、按钮显示的控制 和对于拥有权限的数据的访问上。
它们共同依赖于资源权限校验和数据权限校验，对于系统菜单、按钮的显示上的控制为在生成菜单、按钮的Html时做权限级的判断，当操作主体不具备权限时则不生成该菜单、按钮的Html，从技术角度分析为方便使用者，避免使用者调用权限校验接口，通常的做法为提供菜单、按钮的标签，通过标签生成的菜单和按钮即为经过权限过滤的。
具体的实现思路是： 当用户正确的登陆进入系统后，加载用户的权限信息，放入集合。使用自定义标签来和页面显示的对象资源操作比较，该用户是否具有xx权限（比较一般有2种：一种是角色，一种是具体的操作方法），如果有就显示该对象资源，没有就不显示。可能我讲的还是不明确，你可能要问：
我项目中没有用Acegi可以实现，对对象资源的操作吗？
我具体的是用的是Struts，中调用Action，那怎么比较？ 
这些问题，留给大家，想一下，具体的，我会在后面用个简单的例子来说明（复杂的写不大到）。  在这里可能是吧兑现资源说的还明白，但是没有提到数据资源的操作，其实让大家失望啦，这一点，我也没有很明白的。 具体的数据资源，我还是在方法中来实现，用什么？ Where XXX，具体的不同的用户操作的同一个表中中的不同数据资源，也看成方法的调用，对象资源的控制上面。。。。。o(∩_∩)o…
         性能
为提高权限系统在授权以及校验权限时的性能，采用缓存技术，在用户登陆成功后，将用户信息存放在Session一段显示限制的时间内。在这段时间内，如果用户直接关闭页面（没看到几个人会去点击注销按钮），当用户再次登陆的时候，验证的信息直接从缓存中获取用户信息。
         安全性
安全性方面来讲在B/S系统中通常有两个方面需要控制：
         通过非法途径访问系统文件
采用的技术策略为将需要受保护的文件放入WEB-INF文件夹中，在WEB-INF下的文件除了在服务器上能直接访问外，通过普通的URL是无法访问到的。
其次的做法为做Filter链，即对需要受保护的资源做访问的Filter，如操作者不具备权限则直接报出错误，跳转到别的页面（用的是Filter链）。我也见过这样的做法，是将Jsp页面调用的方法，返回的参数都加密，让客户端的用户不能查看其具体的请求路径，这样用Filter方式，发送请求到服务器端，在解密，这样比较麻烦，如果不是明确的要求，一般不采用.还用将用户的重要信息，加密后存放数据库，当用户查看个人的信息的时候，要再次的解密，也是比较的繁琐，以前，只是听过有密码学，接触一点，头就晕啦。
         通过非法途径访问系统操作
采用的技术策略为对每个直接暴露对外的需要受权限保护的对象做操作级别的权限控制，一般是使用SQL注入扥，来直接调用服务器端的方法，来获取服务器端的重要信息。在做项目的时候，一般都会考虑到这方面的安全性。安全是一个很广的话题，在这里做轻淡的描述一下，就ok啦！

         技术框架
使用Struts+Hibernate+Spring+Acegi(安全框架)构建，明確分层思想，基本实现结构完整，代码清晰，易于阅读控制的要求，下面是将分层的具体信息表示如下：
层 实现
视图 Struts标记，html，jsp等
控制 Struts中的Action(负责控制业务逻辑层与表现层的交互)
业务层 负责实现业务逻辑,独立的抽出一层，用来封装具体的业务操作
数据操作层 具体的底层对数据库操作的方法
安全层 Acegi使用Filter链来验证，授权用户权限信息
也许这样的架构，开发起来效率也许不是很高，但是在开发过程中，应对需求的变化，项目的重构，维护。。等方面还是比较好的选择，将创建的过程，已经使用word描述起详细的搭建步骤，详细请看。《ssh框架搭建步驟.doc》。.Acegi J2EE安全框架的整合，应为其自身的特点，和Web容器能够很好的集成。安全涉及到两个不同的概念：
Acegi这里不做具体的介绍，大家当网上搜一下，一堆一堆的！
认证：确认用户是否确实是他们所宣称的身份
授权：确认用户是否有允许执行一个特定的操作。
用户通过登陆页面，发出登陆请求，系统通过一组Filter，首先认证用户的身份，通过则加载对应的角色，权限等信息，将用户信息放进缓存中。然后，对用户的请求的URL 资源进行保护，对调用Service的方法的拦截保护，对异常进行拦截显示，实现资源控制（对象资源和数据资源的控制方法）。 
4.2 基于RBAC的实现
    RBAC介绍
基于角色的标准权限模型：如1 RBAC所示,其根据需求通常是以该模型为基础，在该模型的基础上对该模型做出一定的扩展，来满足需求。

图表 1 RBAC 0模型
         RBAC0定义了能构成一个RBAC控制系统的最小的元素集合
在RBAC之中,包含用户users(USERS)、角色roles(ROLES)、目标objects(OBS)、操作operations(OPS)、许可权permissions(PRMS)五个基本数据元素，权限被赋予角色,而不是用户，当一个角色被指定给一个用户时，此用户就拥有了该角色所包含的权限。会话sessions是用户与激活的角色集合之间的映射。RBAC0与传统访问控制的差别在于增加一层间接性带来了灵活性，RBAC1、RBAC2、RBAC3都是先后在RBAC0上的扩展。
         RBAC1引入角色间的继承关系
角色间的继承关系可分为一般继承关系和受限继承关系。一般继承关系仅要求角色继承关系是一个绝对偏序关系，允许角色间的多继承。而受限继承关系则进一步要求角色继承关系是一个树结构，在子角色继承父角色，其权限信息，也将拥有其父角色的的权限列表。
         RBAC2模型中添加了权限分离关系
RBAC2的约束规定了权限被赋予角色时,或角色被赋予用户时,以及当用户在某一时刻激活一个角色时所应遵循的强制性规则。责任分离包括静态责任分离和动态责任分离。约束与用户-角色-权限关系一起决定了RBAC2模型中用户的访问许可。
         RBAC3包含了RBAC1和RBAC2
既提供了角色间的继承关系，又提供了责任分离关系。

通过上面章节对RBAC的介绍，从RBAC模型中我们可以看出它已经实现了一个使用起来很方便的授权模型，并同时也就权限的继承，权限的排斥和包含提出了解决的模型。
针对在技术策略中未描述的授权模型和权限校验部分做实现方案的讲解。
 权限的继承
 权限的继承在RBAC的模型中通过增加角色的自关联来实现，即角色可拥有子角色，子角色继承父角色的权限。按照此模型可以看出在授权时维护权限的继承也是非常的简单，维护角色的自关联模型即可。
         权限的排斥和包含
权限的包含与排斥，包含举例来说就是权限A可包含权限B，体现出来即为拥有权限A即自动拥有了权限B，而排斥举例来说就是角色不可同时拥有权限A和权限B。通常的做法是通过在资源的操作权限模型中增加自关联模型以定义哪些资源的操作权限是排斥和包含的，在授权时可以看到同样需要维护的只是资源权限的自关联模型。

         资源权限校验
根据上面的授权模型，在做资源权限校验的时候需要经过以下步骤：
         判断用户所在的角色是否拥有对资源进行操作的权限
获取用户所拥有的角色，遍历其角色，以各角色建立Session，并通过判断该角色是否具备权限，如具备则直接返回，如不具备则直到遍历结束。
         递规用户所在角色的父角色判断是否拥有对资源进行操作的权限
当遍历完用户本身的角色得到用户不具备对资源进行该操作的权限时，则开始递规其所在角色的父角色来判断是否拥有对资源进行操作的权限，过程同上，如确定某角色具备，则返回，如不具备直到递规结束。


4.2.2. 实现方案
其实，在上面的设计模型的思想，在数据库中能清晰的体现出来。在最初个人权限程序设计中，使用到 ’组 的概念，来解决‘不同用户拥有相同的角色信息，但是拥有的权限却不同’等问题，当然不用角色，可以更快的解决，直接就是用户和权限。通过组，不再去管什么角色间的继承，权限间的继承等等，它对系统的扩展，灵活性，等造成一定的影响。，有‘角色’，‘组’的概念，我可以将一个角色再细化为个别的子角色信息，然后，再与不同的权限信息关联，在添加一个用户的时候，具体到要添加的子角色信息，当然这样实现也是挺繁琐的，当然个人认为还是要看需求，不能过度的设计，你需求到啦什么样的地步，你就的去想去做。当项目扩展以一个增值的服务功能的时候，可以添加角色，添加角色组，权限扥扥来很好搜的扩展，可以滿足我們通常需要的功能。

   一，数据库设计：

                          如上：

4.2.3.      优缺点分析
从上面的基于RBAC的实现方案中可以看出基于RBAC模型的优点在于：
         易用和高效的授权方式
用户在进行授权时只需对角色进行授权，之后将相应的角色分配给用户即可，维护也是非常方便的。
         简便和高效的授权模型维护
在技术角度来讲，进行授权模型的维护上因为基本只需要维护关联模型而显得简单而高效。
缺点在于：
         复杂的权限校验
在进行权限校验时需要不断的遍历和递规，造成了性能的影响，用缓存其实也不能很好的解决问题，通过Acegi也不能很好的解决该问题。
     对于数据权限的不够支持。

五． 个人观点
个人觉得做一个和实际项目结合的权限管理系统和做一个通用的权限管理系统，后者视乎看起来，容易以些。但是，做起来，才知道，自己迷惑啦，什么是通用？什么样的权限管理系统能通用？像你说的那样，网上资料有很多，但是它常常使我们迷茫，什么是我们需要的？什么使我们能要的？

这个文章写完啦以后，经理给出这样的批语：
   技术切入度还不够
却没有想明白相关的细节要点
还不足以指导实际的编程

  讨论补充观点：
一， 组的概念
二， 权限互斥，怎样解决这个问题？
三， Filter链的组成部分


最讨厌，看帖子不回帖子的人！

评论

3 楼 ranyut 2009-05-19  

我正对权限管理模糊呢
收藏 好好看下
期待第二章。。。

2 楼 SINCE1978 2008-08-26  

权限管理组件最重要的重点是通用，这是组件之所以为组件之关键。而所谓复制效益也在于通用。而难点则是灵活方便，灵活到什么地步？太灵活就是难点。

而可扩展个人觉得几乎可以忽略，对于扩展主流框架虽说都有支持但是使用价值极其有限。struts的扩展、和spring的集成都是可有可无的东东。权限组件堪称一个自维护的MIS，不必扩展。

对于集群，如weblogic集群，有数个weblogic结点，结点间的服务是即时切换的，一旦切换则session要经历钝化和活化，这个也必须处理到。
具体到细粒度的数据处理个人感觉还是不要掺到权限系统中为妙，首要的是通用，要是掺和进细粒度的处理比如对一条数据是只可以读还是可以删可以更新？这个就留给权限系统的使用者自行解决好了，可以提供扩展接口，否则太复杂。

权限系统学习曲线太陡，主要是因为变态的jaas，简直没一处顺眼的，稍微了解了一下acegi，看来spring惯常的简化在此也无能为力了。

1 楼 qujunxi 2008-08-18  

等待第二章