在进行用户身份验证时，最一般的方法是把合法用户的信息放到Session（或其他持久介质如cookie中），以后每次涉及到身份验证时，就把用户的信息取出，在和相应的权限做比较，完成身份验证。

    Acegi的验证机制和上面提到的是完全一样的，不同的是Acegi通过xml文件配置的方式来实现这种验证，而不是把验证过程嵌入到业务逻辑里。

    在Acegi框架里，充当session角色的是SecurityContextHolder类，它保存着应用的安全信息（SecurityContext），其中就包括当前正在使用该系统的用户信息及权限。SecurityContext的认证主体安全信息在一个HTTP请求线程的多个调用之间是共享的（通过ThreadLocal），但它不能在多个请求之间保持共享。为了解决这个问题，Acegi将认证主体安全信息缓存于HttpSession中，当用户请求一个受限的资源时，Acegi通过HttpSessionContextIntegrationFilter将认证主体信息从HttpSession中加载到SecurityContext实例中，认证主体关联的SecurityContext实例保存在Acegi容器级的SecurityContextHolder里。当请求结束之后，HttpSessionContextIntegrationFilter执行相反的操作，将SecurityContext中的认证主体安全信息重新转存到HttpSession中，然后从SecurityContextHolder中清除对应的SecurityContext实例。通过HttpSession转存机制，用户的安全信息就可以在多个HTTP请求间共享，同时保证SecurityContextHolder中仅保存当前有用的用户安全信息。如下图（摘自http://tech.it168.com/j/2007-05-22/200705221448921_1.shtml）：

    上图说明了如何在用户发出请求(可能是一个Http的请求，也可能是也是method或domain object的请求)后，Acegi是如何获得用户信息及其权限的。上面提到，实际上SecurityContext包含的是Authentication对象，这是一个封装对象，通过它，我们即可以获得UserDetail（用户信息），有可以获得GrantedAuthority（用户权限）。

    获得用户身份后，Acegi通过AuthenticationManager来实现身份的认证。它象一个安检入口，对用户身份进行核查，用户必须提供身份认证的凭证（一般是用户名/密码）。在进行身份认证时，AuthenticationManager将身份认证的工作委托给多个AuthenticationProvider。因为在具体的系统中，用户身份可能存储在不同的用户信息安全系统中（如数据库、CA中心、LDAP服务器），不同用户信息安全系统需要不同的AuthenticationProvider执行诸如用户信息查询、用户身份判断、用户授权信息获取等工作。只要有一个AuthenticationProvider可以识别用户的身份，AuthenticationManager就通过用户身份认证，并将用户的授权信息放入到SecurityContext中。

   上述过程就是一个身份验证的过程。下面描述的就是这个流程：

  （1）用户访问首页，并点击了一个链接；

  （2）url请求到达服务器后，服务器判断这个资源是不是受保护的；

  （3）当访问的是受保护资源时，如果用户还没有相应的认证信息 （SecurityContext里没有该用户的Authentication对象），服务器将返回一个http相应，更一般的情形是返回一个页面，通常是登录页面；否则进行第7步；

  （4）在登录页面，用户输入信息（一般是用户名、密码），并提交到服务器；

  （5）服务器获得用户输入的信息；

  （6）服务器验证用户信息是否是合法的，如果不是，通常将再次回到登录页面；

  （7）服务器通过用户身份获得其权限信息（一般放在数据库里），并验证这些权限信息是否能获得该资源的访问。如果能，则返回相应视图；如果不能，则抛出异常（AccessDeniedException）。（能与不能就不是验证机制了，而是授权机制，下面就讨论授权）