acegiv104中文参考手册

acegiv104中文参考手册内容摘要：

rity会高效的处理这种普遍的需求，但是你不会使用领域对象安全功能 来实现这个目的。 最后，但不是不重要，你有时候需要在 HTTP 请求之间存储 SecurityContext。 另外有些时候你在每次请求的时候都会重新认证 principal，不过大部分时候你会存储 SecurityContext。 HttpSessionContextIntegrationFilter在 HTTP之间存储 SecurityContext。 正如类名字显示的那样，它使用 HttpSession来进行存储。 基于安全原因，你永远都不要直接和 HttpSession交互。 没有理由这么做，所以记得使用 SecurityContextHolder来代替。 让我们回忆一下， Acegi Security的基本组成构件是： • SecurityContextHolder,提供对 SecurityContext 的所有访问方式。 • SecurityContext, 存储 Authentication以及可能的请求相关的安全信息。 • HttpSessionContextIntegrationFilter, 在 web请求之间把SecurityContext 存储在 HttpSession中。 • Authentication, 以 Acegi Security的方式表现 principal。 • GrantedAuthority, 表示赋予一个 principal 的应用范围的权限。 • UserDetails, 为从你的应用程序 DAO中获取必要的信息来构建一个Authentication 对象。 • UserDetailsService,用传入的 String类型的 username（或者认证 ID，或类似）来创建一个 UserDetails。 现在你已经理解了这些重复使用的组件，让我们仔细看看认证过程吧。 . 认证 正如我们在手册开始部 分所说的那样， Acegi Security适用于很多认证环境。 虽然我们建议大家使用 Acegi Security自身的认证功能而不是和容器管理认证（ Container Managed Authentication）集成，但是我们仍然支持这种和你私有的认证系统集成的认证。 让我们先从 Acegi Security完全自行管理管理web安全的角度来探究一下认证，这也是最复杂和最通用的情形。 想象一个典型的 web应用的认证过程： 1．你访问首页，点击一个链接。 2．一个请求被发送到服务器，服务器判断你是否请求一 个被保护的资源。 3．因为你当前未被认证，服务器发回一个回应，表明你必须通过认证。 这个回应可能是一个 HTTP回应代码，或者重定向到一个特定的网页。 4．基于不同的认证机制，你的浏览器会重定向到一个网页好让你填写表单，或者浏览器会用某种方式获取你的身份认证（例如一个 BASIC认证对话框，一个cookie，一个 X509证书等等。 ）。 5．浏览器会发回给服务器一个回应。 可能是一个包含了你填写的表单内容的HTTP POST，或者一个包含你认证详细信息的 HTTP header。 6．接下来服务器会判断提供的认证信息是 否有效。 如果它们有效，你进入到下一步。 如果它们无效，那么通常请求你的浏览器重试一次（你会回到上两步）。 7．你引发认证的那个请求会被重试。 但愿你认证后有足够的权限访问那些被保护的资源。 如果你有足够的访问权限，请求就会成功。 否则，你将会受到一个意味 “禁止 ”的 HTTP403错误代码。 在 Acegi Security中，对应上述的步骤，有对应的类。 主要的参与者（按照被使用的顺序）是： ExceptionTranslationFilter， AuthenticationEntryPoint， 认证机制 (authentication mechanism)， 以及 AuthenticationProvider。 ExceptionTranslationFilter是 Acegi Security用来检测任何抛出的安全异常的过滤器 (filter)。 这种异常通常是由 AbstractSecurityInterceptor抛出的，它是授权服务的主要提供者。 我们将会在下一部分讨论AbstractSecurityInterceptor，现在我们只需要知道它产生 Java异常，并且对于 HTTP或者如何认证一个 principal 一无所知。 反而是ExceptionTranslationFilter提供这样的服务，它负责要么返回 403错误代码(如果 principal 通过了认证，只是缺少足够的权限，象上述第 7步那样 )，要么加载一个 AuthenticationEntryPoint (如果 principal 还没有被认证，那么我们要从第 3步开始 )。 AuthenticationEntryPoint负责上述的第 3步。 如你所想，每个 web应用都有一个默认的认证策略（象 Acegi Security中几乎所有的东西一样，它也是可配置的，不过我们现在还是还 是从简单开始）。 每个主流的认证系统都有它自己的AuthenticationEntryPoint实现，负责执行第 3步中描述的动作。 当浏览器确定要发送你的认证信息（ HTTP 表单或者 HTTP header），服务器上需要有什么东西来 “收集 ”这些认证信息。 现在我们在上述的第 6步。 在 Acegi Security中对从用户代理（通常是浏览器）收集认证信息有一个特定的名字，这个名字是 “认证机制（ authentication mechanism） ”。 当认证信息从客户代理收集过来以后，一个 “认证请求（ Authentication request） ”对象被创建，并发送到 AuthenticationProvider。 Acegi Security中认证的最后一环是一个 AuthenticationProvider。 非常简单，它的职责是取用一个认证请求（ Authentication request）对象，并且判断它是否有效。 这个 provider要么抛出一个异常，要么返回一个组装完毕的Authentication对象。 还记得我们的好朋友 UserDetails 和 UserDetailsService 吧。 如果没有，回到前一部分 重新回忆一下。 大部分的AuthenticationProviders 都会要求 UserDetailsService 提供一个UserDetails对象。 如前所述，大部分的应用程序会提供自己的UserDetailsService，尽管有些会使用 Acegi Security提供的 JDBC或者 inmemory实现。 作为成品的 UserDetails 对象，特别是其中的GrantedAuthority[]s，在构建完备的 Authentication对象时会被使用。 当认证机制（ authentication mechanism）取回组装完全的 Authentication对象后，它将会相信请求是有效的，将 Authentication放到SecurityContextHolder中，并且将原始请求取回（上述第 7步）。 反之，AuthenticationProvider则拒绝请求，认证机制（ authentication mechanism）会请求用户重试（上述第 2步）。 在讲述典型的认证流程的同时，有个好消息是 Acegi Security不关心你是如何把Authentication放到 SecurityContextHolder内的。 唯一关键的是在AbstractSecurityInterceptor授权一个请求之前，在SecurityContextHolder中包含一个代表了 principal 的 Authentication。 你可以（很多用户确实）实现自己的过滤器（ filter）或者 MVC控制器（ controller）来提供和不是基于 Acegi Security的认证系统交互。 例如，你可能使用使用容器管理认证（ Container Managed Authentication），从 ThreadLocal 或者 JNDI中获 取当前用户信息，使得它有效。 或者，你工作的公司有一个遗留的私有认证系统，而它是公司 “标准 ”，你对它无能为力。 在这种情况之下也是非常容易让 Acegi Security运作起来，提供认证能力。 你所需要做的是写一个过滤器（或等价物）从某处读取第三方用户信息，构建一个 Acegi Security式的Authentication对象，把它放到 SecurityContextHolder中。 这非常容易做，也是一种广泛支持的集成方式。 acegi参考手册 ()[译 ]第二章 技术概览 [下 ] . 安全对象 如 果你熟悉 AOP，你会知道有很多种 advice可用： before, after, throws 和 around。 around advice 非常有用，因为它能够选择是否选择是否执行一个方法调用，是否修改返回值，以及是否抛出异常。 Acegi Security对方法调用和web请求都提供 around advice。 我们使用 AOP联盟实现对方法调用的around advice，对于 web请求的 around advice 则是使用标准的过滤器（ Filter）。 对于那些不熟悉 AOP的人来说，关键是要理解 Acegi Security能够帮助你保护方法调用以及 web请求。 大多数人对保护他们服务层的方法调用感兴趣。 这是因为在当前的 J2EE应用中，服务层包含了大多数的业务逻辑（声明，作者不赞成这种设计，反而支持正确封装的领域模型以及 DTO， assembly, facade 以及 transparent persistence patterns，而不是当前主流的贫血模型，我们将在这里讨论）。 如果你需要保护 service层的方法调用，使用标准的 Spring AOP平台（或者被成为 AOP 联盟（ AOP Alliance））就足够了。 如果你需要直接对领域模型进行保护，那么可以考虑使用 AspectJ。 你可以选择对使用 AspectJ 或者 AOP联盟（ AOP Alliance）对方法进行授权，或者你可以选择使用过滤器（ filter）来对 web请求进行授权。 你将 0个， 1个，2个或者 3个这些方法一起使用。 主流的用法是执行一些 web请求授权，以及在服务层使用 AOP联盟（ AOP Alliance）对一些方法调用授权。 Acegi Security使用 “安全对象 ”（ secure object）这个词来指任何能够将安全应用于其上的对象。 每个 Acegi Security支持的安全对象都有自己的类，它是AbstractSecurityInterceptor的子类。 重要的一点是，如果一个 principal通过认证，当 AbstractSecurityInterceptor执行的时候，SecurityContextHolder中要包含一个有效的 Authentication。 AbstractSecurityInterceptor提供一个固定的工作流程来处理安全对象请求。 这个工作流程包括查找和当前请求相关联的 “配置属性（ configuration attributes） ”。 配置属性（ configuration attributes）可以被认为是对被AbstractSecurityInterceptor使用的类有特殊含义的字符串。 他们通常针对AbstractSecurityInterceptor使用 XML进行配置。 反正，AbstractSecurityInterceptor会询问 AccessDecisionManager “这是配置属性（ configuration attributes），这是当前的认证对象（ Authentication object），这 是当前请求的详细信息－那么这个特定的 principal 可以执行这个特定的操作吗。 ”。 假如 AccessDecisionManager判定允许这个请求，那么AbstractSecurityInterceptor一般来说就继续执行请求。 虽然这样，用户在少数情况之下可能需要替换 SecurityContext 中的 Authentication，可以通过AccessDecisionManager调用一个 RunAsManager来实现。 在某些不常见的情形下这将非常有用，例如服务层的方法需要用另一种标识（身份）来调用远程系统。 这可能有所帮助，因为 Acegi Security自动在不同的服务器之间传播安全标识（假设你正确配置了 RMI或者 HttpInvoker remoting protocol client）。 随着安全对象处理和返回－意味着方法调用完毕或者过滤器链（ filter chain）处理完毕－ AbstractSecurityInterceptor有最后的机会来处理调用。 这时，AbstractSecurityInterceptor可能会修改返回的对象。 我们可能要这样做，因为授权判断不能在安全对象调用途中执行。 由 于高度的可。