用户认证过程
　　Acegi支持多种方式的用户认证：如典型的基于数据库的认证、基于LDAP的认证、基于Yale中心认证等方式。不同的认证环境拥有不同的用户认证方式，现在我们先抛开这些具体的细节，考察一下Acegi对受限资源进行访问控制的典型过程：
    1．你点击一个链接访问一个网页；
    2．浏览器发送一个请求到服务器，服务器判断出你正在访问一个受保护的资源；
    3．如果此时你并未通过身份认证，服务器发回一个响应提示你进行认证——这个响应可能是一个HTTP响应代码，抑或重定向到一个指定页面；
    4．根据系统使用认证机制的不同，浏览器或者重定向到一个登录页面中，或者由浏览器通过一些其它的方式获取你的身份信息（如通过BASIC认证对话框、一个Cookie或一个X509证书）；
    5．浏览器再次将用户身份信息发送到服务器上（可能是一个用户登录表单的HTTP POST信息、也可能是包含认证信息的HTTP报文头）；
    6．服务器判断用户认证信息是否有效，如果无效，一般情况下，浏览器会要求你继续尝试，这意味着返回第3步。如果有效，则到达下一步；
    7．服务器重新响应第2步所提交的原始请求，并判断该请求所访问的程序资源是否在你的权限范围内，如果你有权访问，请求将得到正确的执行并返回结果。否则，你将收到一个HTTP 403错误，这意味着你被禁止访问。
    在Acegi框架里，你可以找到对应以上大多数步骤的类，其中ExceptionTranslationFilter、AuthenticationEntryPoint、AuthenticationProvider以及Acegi的认证机制是其中的代表者。

    ExceptionTranslationFilter是一个Acegi的Servlet过滤器，它负责探测抛出的安全异常。当一个未认证用户访问服务器时，Acegi将引发一个Java异常。Java异常本身对HTTP请求以及如何认证用户是一无所知的，ExceptionTranslationFilter适时登场，对这个异常进行处理，启动用户认证的步骤（第3步）。如果已认证用户越权访问一个资源，Acegi也将引发一个Java异常，ExceptionTranslationFilter则将这个异常转换为HTTP 403响应码（第7步）。可见，Acegi通过异常进行通讯，
ExceptionTranslationFilter接收这些异常并作出相应的动作。

    当ExceptionTranslationFilter通过Java异常发现用户还未认证时，它到底会将请求重定向哪个页面以要求用户提供认证信息呢？这通过咨询AuthenticationEntryPoint来达到目的——Acegi通过AuthenticationEntryPoint描述登录页面。

    当你的浏览器通过HTTP表单或HTTP报文头向服务器提供用户认证信息时，Acegi需要将这些信息收集到Authentication中，Acegi用“认证机制”描述这一过程。此时，这个新生成Authentication只包含用户提供的认证信息，但并未通过认证。
AuthenticationProvider负责对Authentication进行认证。AuthenticationProvider究竟如何完成这一过程呢？请回忆一下上节我们所介绍的UserDetails和UserDetailsService，大多数AuthenticationProvider通过UserDetailsService获取和未认证的Authentication对应的UserDetails并进行匹配比较来完成这一任务。当用户认证信息匹配时，Authentication被认为是有效的，AuthenticationProvider进一步将UserDetails中权限、ACL等信息拷贝到Authentication。
当Acegi通过认证机制收集到用户认证信息并填充好Authentication后，Authentication将被保存到SecurityContextHolder中并处理用户的原始请求（第7步）。

    你完全可以抛开Acegi的安全机制，编写自己的Servlet过滤器，使用自己的方案构建Authentication对象并将其放置到SecurityContextHolder中。也许你使用了CMA（Container
Managed Authentication：容器管理认证），CMA允许你从ThreadLocal或JNDI中获取用户认证信息，这时你只要获取这些信息并将其转换为Authentication就可以了。