acegi security实践教程—入门
Acegi Security概念
Acegi Security是基于J2EE的企业软件应用提供全面的安全服务。通俗的说，就是封装的安全框架。提到安全，大家脑子中第一反应肯定是权限控制。的确如此，安全主要的功能就是为了权限控制。
Acegi Security 和Spring Security 是一回事吗?为啥搜索Acegi Security框架，有时会发现一会这样配置，一会那样配置？开始以为是版本问题，回来翻阅了几个版本后，发现还真不是你你想像的那样。实际上Acegi Security和Spring Security是两个框架，怎么说呢？
Acegi Security框架是基于spring framework，后来成为spring一个子项目，经过完善，更名为spring security。虽然spring security是在acegi security 发展而来，但是的确是两种框架，当然他们之间也有很多相似原理的配置。
Acegi相对于现在来说，已经是古老的框架。很多公司几乎很少在用，若为了实现安全服务，一般都在用spring security框架，毕竟acegi不更新了哈，不更新，意思遇到问题，会很费周折的，就如目前xp系统从开始宣布停止打补丁，估计会有相应一批人都直接去营业厅去取款而非ATM机【ATM机风险造谣与否 与本人无关哈!】
当初研究这个acegi框架，纯属误打误撞。为了解决无权限问题，一直怀疑封装的jar问题，就这样研究了几天，最后并不是此acegi框架bug，不过也是因为acegi框架发现此问题，后续会有详细解说。
Acegi Security功能总括
上文说到，acegi security是安全框架，无论acegi security，任何安全框架，无非主要两个功能：认证和授权
认证主要如下：
• HTTP BASIC authentication headers (an IEFT RFC-based standard)• HTTP Digest authentication headers (an IEFT RFC-based standard)• HTTP X.509 client certificate exchange (an IEFT RFC-based standard)• LDAP (a very common approach to cross-platform authentication needs, especially in large environments)• Form-based authentication (for simple user interface needs)• Computer Associates Siteminder• JA-SIG Central Authentication Service (otherwise known as CAS, which is a popular open source single sign on system)• Transparent authentication context propagation for Remote Method Invocation (RMI) and HttpInvoker (a Spring remoting protocol)• Automatic "remember-me" authentication (so you can tick a box to avoid re-authentication for a predetermined period of time)• Anonymous authentication (allowing every call to automatically assume a particular security identity)• Run-as authentication (which is useful if one call should proceed with a different security identity)• Java Authentication and Authorization Service (JAAS)• Container integration with JBoss, Jetty, Resin and Tomcat (so you can still use Container Manager Authentication if desired)
如果其中的认证还不能满足需求，当然这个可以自己写个认证
授权主要如下:
授权web请求【URL资源的访问控制】、授权方法【业务类方法的访问控制】、授权单个领域对象【领域对象的访问控制 】
URL资源的访问控制：针对url是否有权限访问，当然acegi框架可以使用正则或Ant来匹配url，比如：/index.jsp需要ROLE_LOGIN权限 、 /*action需要ROLE_ADMIN权限。这是粗粒度控制，也是最简单最不安全控制。
业务类方法的访问控制：对于类的方法、比如addUser、deleteUser方法。spring类的方法都可以被acegi来管理。这属于细粒度权限控制。原来我们是如何实现呢？使用jstl标签 if(){}else{}
领域对象的访问控制:主要针对第二种类方法所属的对象。比如登陆CSDN论坛，只可以操作自己帖子，而非别人的帖子。
至于使用那种方式，主要针对需求而言。
Acegi Security主要组件
分析源码，你会发现中心组件：SecurityContextHolder，一看就是个容器，存放Security Context，Security Context存放用户权限信息，知道这点就掌握了核心。
还有关键的认证，主要通过authenticationManager【认证管理器】，但是认证管理器都是委托给多个Provider是具体来认证，比如：daoAuthenticationProvider【从数据库读取身份信息】
还有关键的授权，主要通过accessDecisionManager【访问控制管理器】，主要通过投票机制decisionVoters来投票授权，若投票成功，则授权成功即有权限；若投票失败，则授权失败即没有权限。
另外还有一个重要的封装身份信息UserDetails、其中UserDetailsService是从读取用户信息的接口，大家可以实现自己的UserDetails【后续会介绍】。
上图中SecurityContext存放的身份信息，不是UserDetails，而是Authentication对象。实际上是acegi把从后台获取的UserDetails转化成Authentication对象，然后存放到SecurityContext对象中。
acegiFilter介绍：
acegi security框架主要通过Filter为桥梁达到认证和授权的功能。
多个Filter执行是靠过滤连顺序执行的，但是访问时不是直接通过真正的Filter，而是通过Filter Proxy代理类来访问具体的Filter。
常用的Filter以及顺序如下：
ChannelProcessingFilter：重定向到另一种协议。
ConcurrentSessionFilter ：因为不使用任何SecurityContextHolder的功能，但是需要更新SessionRegistry来表示当前的发送请求的认证信息。
HttpSessionContextIntegrationFilter：sessionFilter，把securityContext放到session中，以备下次再访问，其实就是为了保存权限对象。
Authentication processing mechanisms：因为Filter有顺序的，这个对象时包括很多同级Filter，比如鲫鱼表单的认证AuthenticationProcessingFilter，基于Basic弹框认证BasicProcessingFilter，基于Cas认证CasProcessingFilter主要是通过认证管理器获取权限对象存放到securityContextHolder中。
AnonymousProcessingFilter：匿名处理fiter,如果没有响应的权限对象，则会存放一个匿名权限对象。
ExceptionTranslationFilter：异常filter，捕获异常的，比如出现无权限或未登陆错误。
FilterSecurityInterceptor：主要在转向url时，进行授权操作，通过安全访问控制器调用投票机制进行授权。
Acegi权限控制的主要流程：
上图不是特别特别详细，不过已经涵盖了主要的流程思路。
当访问url时,根据配置，acegi进行控制。acegi控制流程是通过过滤连形式，首先session判断是否有securitycontext中，若有就把securitycontex权限对象存放到securitycontext中，若没有就securitycontext生成一个new securitycontext。然后进入N个过滤器，对url进行认证，读取用户权限放入securitycontext中；认证阶段认证后，进入访问控制管理器，根据配置投票器来进行授权，判断是否有权限访问其受保护资源。
这篇博客宏观地介绍了acegi，接下来会给出相应的demo进一步测试分析。