通过场景分析acegi的设计原理.docVIP

通过场景分析acegi的设计原理 首先描述最简单的身份验证后台的处理过程 用户输入需要确认自己身份的信息，如账号与密码或许需要其它信息 也许你希望提供多种有方式的验证形式，由系统选择最合适的那一种，如从数据库(DAO)或是通过身份验证中心的服务(ACS)统一管理等 根据账号找到指定源中的用户、密码及所拥有的权限(如果没找到就抛出异常)等用户的身份信息，验证用户输入的信息与源中返回的信息是否一致(如密码) 为了不至于每次都重复上面的过程，还要将验证后的信息缓存起来，如放到session中 与acegi结合分析 用户提交后为了能进行上述的处理，acegi不是通过请求-影响模式，而是能过Servlet的Filter实现的。可以理解成这个身份验证的主入口，不同的处理机制采用不同的Filter,类名的规则为*ProcessingFilter，这些类全部都继承至javax.servlet.Filter接口。下面是几个常用的过滤器 模块 功能 BasicProcessingFilter 按照RFC1945处理基本的身份验证请求 CasProcessingFilter 处理耶鲁大学的中心身份验证服务器(CAS)许可 AnonymousProcessingFilter 对匿名身份的处理 AuthenticationProcessingFilter 处理类似于Servlet规范的j_security_check的Http form post 在Spring的配置过程中有些过滤器除了自身的信息外，还有可能需要切入点，以便切入到其它模块中的配置信息。如AuthenticationProcessingFilter验证不通过的处理页面或要采用的协议、CasProcessingFilter需要提交到CAS上的其他信息。它们的统一接口类为AuthenticationEntryPoint在此要注意的是，切入点与过滤器之间有着密切的联系与对应关系的。 acegi为了实现多种方式的验证形式提供了AuthenticationManager接口，目的是对多种验证形式进行管理，并通过指定的验证形式返回用户的身份。所以上述的过滤器均会调用该接口的authenticate(Authentication authentication)方法以返回当前用户的身份信息。该接口主要的实现类是ProviderManager AuthenticationProvider(身份验证供应器)接口有很多实现类，每个都致力于处理一个特定身份验证的具体实现，AuthenticationManager负责轮询AuthenticationProvider列表，并使用第一个能够处理给定的Authentication请求对象的AuthenticationProvider。身份验证供应器也就是上面说的验证形式。最常用的是DaoAuthenticationProvider，实现从数据库中获取用户的身份信息 在acegi中用户的身份信息存放到以Authentication接口的实现类的实例中。在介绍该接口之前先要了解一些关键术语 principal(主体)指可以执行操作的用户、服务或代理(agent)，即身份验证的发启者 credential(凭证)指主体提供密码之类用于身份验证(authentication)的信息戳 authentication(身份验证)确定调用者身份的过程 authorization(授权)指决定哪个主体准许执行给定操作的过程 Authentication接口包含主体标示、主体的凭证以及主体所拥有的一组权限。 Authentication接口继承java.security.Principal接口，因此Authentication天生就要满足主体的类型。该接口实际上是上述几个关键词对象化的一个容器，它存储了身份验证的全部信息。由此会发现它与AuthenticationProvider(身份验证供应器)有着天然的联系，如对于数据库的供应器它只要记录用户的帐号和密码，但对于CAS它还可能还要记录服务器响应的列表，或是与认证相关的其它信息。因此该接口对应身份验证供应器有多个实现类。正因为于此，所有的实现类对于开发者来说几乎是隐藏在，可以理解成工具或是服务类 下面对Authentication接口中的方法做详细扩展说明 getPrincipal(获得主体)与getCredential(获得凭证)，它们的设置过程：无论何种验证形式用户都是通过用户输入帐号和密码开始的，过滤器会拦截用户的请求，由验证管理器(AuthenticationManager)找到合适的身份验证供应器(AuthenticationProvider)提供身份验证。在AuthenticationManager接口只有一个方