权限管理
权限管理是指在各等级，各部门和个人都有自己的权限，不能越权，那就有一个分配这些权限的地方，这就是权限管理。
一、在web里，权限管理是Web应用项目中比较关键的环节，因为浏览器是每一台计算机都已具备的，如果不建立权限管理系统，那么一个“非法用户”可以轻而易举通过浏览器访问Web应用项目中的所有功能。因此需要权限管理系统进行权限检测，让经过授权的用户可以正常合法的使用已授权的功能，而对那些未授权的非法用户拒之门外。 一个好的权限管理系统应该对每一类或每一个用户，分配不同的系统操作权限，并应具有扩展性，也就是它可以加入到任何一个带有权限管理的Web应用项目中，就像构件一样可以被重复使用。 同时，还要提醒开发者，开发一个Web应用项目时，应尽可能的将整个系统细化，分解为若干个子模块，最后组合成一个完整的应用。也只有这样，才容易实现为每一类或每一个用户分配不同的操作权限。
二、在软件里权限管理是指管理员、人事部以及财务部高级权限的地方，拥有权限更大，全员工根据自己的岗位职能分工有着相应的权限，只有查看权限不能拥有创建、编辑、删除的权限等等。
Spring Acegi权限控制引言近年来，随着Internet技术的迅猛发展，计算机网络已深入到了人们的工作、学习和日常生活中，于是，怎样构建安全的web应用也成为了当前最热门的话题。Spring是一个基于IoC（Inversion of Control）和AOP（Aspect Oriented Programming）的构架多层J2EE应用系统的框架。Spring框架正在以其优良的特性吸引了越来越多的开发人员的关注，并在大量的系统开发中被使用。然而，现有的Spring框架本身并没有提供对系统安全性的支持，本文通过介绍一种可用于Spring框架中的安全框架Acegi，并对在Spring框架中使用Acegi实现安全用户认证和资源授权控制进行了较深入的研究和扩展，同时给出了可行的解决方案。
2、Spring框架和Acegi安全框架介绍
2.1 spring 框架Spring框架是由Open Source开发的一个优秀的多层J2EE系统框架，它为企业级应用提供了一个非常轻量级的解决方案，大大地降低了应用开发的难度与复杂度，提高了开发的速度。
Spring框架的核心是IoC和AOP。IoC是一种设计模式，即IoC模式。IoC模式进一步降低了类之间的耦合度，并且改变了传统的对象的创建方法，实现了一种配置式的对象管理方式，Spring框架中由IoC容器负责配置性的对象的管理。IoC模式极大的提高了系统开发与维护的灵活性。
AOP是一种编程模式，它是从系统的横切面关注问题。传统的面向对象编程OOP主要从系统的垂直切面对问题进行关注，对于系统的横切面关注很少，或者说很难关注，这样当考虑到系统的安全性、日志、事务以及其他企业级服务时，OOP就无能为力了，只能在所有相关类中加入类似的系统服务级的代码。AOP为解决系统级服务问题提供了一种很好的方法。AOP将系统服务分解成方面看待，并为类提供一种声明式系统服务方式。Java类不需要知道日志服务的存在也不需要考虑相关的代码。所以，用AOP编写的应用程序是松耦合的，代码的复用性就提高了。
2.2 Acegi 安全框架借助于Spring框架，开发者能够快速构建结构良好的WEB应用，但现有的Spring框架本身没有提供安全相关的解决方案。同样来自于Open Source 社区的Acegi安全框架为实现基于Spring框架的WEB应用的安全控制提供了一个很好的解决方案。Acegi本身就是利用Spring提供的IoC和AOP机制实现的一个安全框架，它将安全性服务作为J2EE平台中的系统级服务，以AOP Aspect形式发布。所以借助于Acegi安全框架，开发者能够在Spring使能应用中采用声明式方式实现安全控制。
Acegi安全框架主要由安全管理对象、拦截器以及安全控制管理组件组成。安全管理对象是系统可以进行安全控制的实体，Acegi框架主要支持方法和URL请求两类安全管理对象；拦截器是Acegi中的重要部件，用来实现安全控制请求的拦截，针对不同的安全管理对象的安全控制请求使用不同的拦截器进行拦截；安全控制管理部件是实际实现各种安全控制的组件，对被拦截器拦截的请求进行安全管理与控制，主要组件包括实现用户身份认证的AuthenticationManager、实现用户授权的AccessDecisionManager 以及实现角色转换的RunAsManager。安全管理对象、拦截器以及安全控制管理组件三者关系如图1所示。
3、Acegi安全框架在基于Spring框架的系统中的应用
3.1 分析系统安全性需求首先，需要明确进行安全控制的对象，可为业务方法和URL资源。
其次，需要进一步明确，系统身份认证资料和资源授权信息的数据持久化形式。
3.2 Acegi安全系统数据库设计在Acegi框架中支持多种安全信息的持久化方式，可以在配置文件中配置或存放在关系数据库。由于在实际应用中，需求是经常发生变化的。所以，在配置文件中配置是满足不了实际应用需求的。然而，Acegi本身对权限表的设计非常简单，users表{username，password，enabled} 和authorities表{username，authority}，这样简单的设计肯定无法适用复杂的权限需求。为了解决权限管理的复杂性，在这里引入了role（角色）的概念，使得用户和权限分离，一个用户拥有多个角色，一个角色拥有多个相应的权限，这样就更灵活地支持安全策略。
同时，为了更好地配合Acegi安全框架，还引入resource（资源）的概念，资源可分为URL和FUNCTION（方法）两种，一个权限可以对应多个资源3.3 认证管理器，授权管理器的配置实现系统的安全控制，首先需要对系统的安全管理器和授权管理器进行配置，系统进行认证和授权需要获取安全信息，Acegi本身提供了对认证信息的获取机制，在实现认证与授权过程中，系统将主动根据配制信息和相应的信息解释安全信息的读取。
授权管理器的配置方法与认证管理器的配置基本类似，这里不再讨论。
3.4 安全请求拦截器的配置以上配置完成后，就需要配置安全拦截器。不同的安全管理对象需要使用不同的安全拦截器。对于方法级的安全认证需要使用的拦截器为MethodSecurityInterceptor，而应用于URL资源的安全拦截器为FilterSecurityInterceptor 。其中，MethodSecurityInterceptor拦截器是借助于Spring Aop实现的，而FilterSecurityInterceptor拦截器是借助于Servlet Filter 实现的。本文以URL资源请求的安全拦截器为例说明配置情况。
由于URL资源请求安全拦截是借助于过滤器进行的。因此首先要配置Acegi Servlet过滤器。过滤器类似于AOP Around装备，实现在web资源调用前后进行的一些操作6种过滤器，他们依次构成Servlet过滤器链，依次处理客户请求。需要注意的是过滤器配置的顺序是不能交换的，当不需要使用某个过滤器时，可直接将其删除和注释。过滤器在web.xml中配置形式为：
以上代码是SecurityEnforcementFilter的配置，该过滤器对用户是否有访问web资源作出最后的决定。其它的过滤器的配置类同。
配置完过滤器后，需要对拦截器FilterSecurityInterceptor进行配置，
objectDefinitionSource属性定义了那些受保护的URL资源，其中引用了一个本地对象filterObjectDefinitionSource。filterObjectDefinitionSource类从数据库中读取需要保护的URL安全信息，它扩展了PathBasedFilterInvocationDefinition Map类。
同样，实现了另外一个methodObjectDefinitionSource类从数据库中读取需要保护的FUNCTION资源，它扩展了MethodDefinitionMap类。限于篇幅，在这里就不列出具体实现的源代码。
4、结束语 由于Spring在越来越多的项目中的应用，因此基于Spring应用的安全控制系统的研究就显得非常重要。Acegi提供了对Spring应用安全的支持，然而 Acegi本身提供的实例并不能满足大规模的复杂的权限需求，本文通过扩展Acegi的数据库设计即可满足复杂的权限需求。然而，怎样将Acegi应用到非Spring的系统中，还有待进一步研究。
Spring Acegi优缺点优点总体说来 Spring Security 具有以下几个优点：
1. 提供了一套权限框架，这套框架是可行的；
2. 提供了很多用户身份认证功能，可以节约大量开发工作；
3. 提供了角色判断功能，这点既是优点又是缺点；
4. 提供了 form-login 、 remember me 等控制。
其中 2 、 4 两点，对于我们中国开发者（我对国外系统不大了解），可用性并不大。我们的系统大多采用用户名 / 密码身份认证模式，大多公司都有可复用代码。 form-login 、 remember me 等这些功能，并不是难以开发，而且可用之处也并不多。
缺点我个人认为 Spring Security 存在以下几个硬伤：
1. 角色被“编码”到配置文件和源文件，这样最终用户就不能创建角色了。但最终用户期望自己来控制角色。因为在项目实施过程中，客户可能并不能确定有哪些角色，以及角色怎么分配给系统用户。角色大多需要等到系统上线后，才能确定。这些编码有：
a) url 的权限控制， ；
b) java 方法的权限控制， @Secured("IS_AUTHENTICATED_ANONYMOUSLY") ；
c) java 方法的权限控制， ；
2. RBAC 这种被广泛运用的模型，没有在 Spring Security 体现出来；
3. Spring Security 没有提供好的细粒度（数据级）权限方案，提供的缺省实现维护工作量大，在大数据量情况下，几乎不可用；
4. Spring Security 对于用户、角色、权限之间的关系，没有提供任何一种维护界面。不过从 Spring Security 角度看，确实没有必要有界面。角色创建、角色和权限直接的关系，都被“编码”到配置文件和源文件了；
5. Spring Security 学习难度大，配置文件还是很多。我承认有很多高手，但我们也看到有很多新人加入软件开发领域。付出如此大的学习代价，获得这么一点点好处，个人觉得并不值得。