AcegiSecurity基础详解

### Acegi Security 基础详解 #### 1. 认证（Authentication） Acegi Security 的认证服务有几个主要的接口和实现。核心接口是 `Authentication`，它包含主体的身份、凭证以及主体已获得的 `GrantedAuthority`。`GrantedAuthority` 是一个接口，其实现可以根据应用的需求有不同的含义，通常使用 `GrantedAuthorityImpl`，它以字符串形式存储主体被授予的权限。 `AuthenticationManager` 是处理认证请求对象并确定所提供的主体和凭证是否有效的核心接口。如果有效，`AuthenticationManager` 会将适用的 `GrantedAuthority` 填充到 `Authentication` 对象中。其主要实现是 `ProviderManager`，它负责轮询一系列的 `AuthenticationProvider`。 有许多不同的 `AuthenticationProvider`，每个都专门处理特定的 `Authentication` 具体实现。大多数情况下，`DaoAuthenticationProvider` 用于处理认证请求，它会从 `AuthenticationDao` 中检索 `UserDetails`。开发者通常会编写自己的 `AuthenticationDao`，不过 Acegi Security 也提供了生产级别的 `JdbcDaoImpl`。此外，`DaoAuthenticationProvider` 还提供了缓存层集成和编码密码解码等有用功能。 用户与 Acegi Security 进行实际认证请求交互是通过各种认证机制实现的，具体如下表所示： | 模块 | 功能 | 使用原因和时机 | | --- | --- | --- | | BasicProcessingFilter | 按照 RFC 1945 处理基本认证请求 | - 发布安全的 Web 服务<br>- 需要简单的单点登录方法<br>- 希望在浏览器中使用简单的认证对话框而非登录表单 | | CasProcessingFilter | 处理耶鲁大学的中央认证服务（CAS）票据 | - 组织已有 CAS 服务器<br>- 寻找全面的开源单点登录解决方案 | | AuthenticationProcessingFilter | 处理类似于 Servlet 规范中 `j_security_check` 的 HTTP FORM POST 请求 | - 不需要单点登录<br>- Web 应用倾向于基于表单的登录方式 | 每个认证机制都有两个类：`[Strategy]ProcessingFilter` 用于处理认证请求，`[Strategy]ProcessingFilterEntryPoint` 实现 `AuthenticationEntryPoint`，用于通过发送 HTTP 重定向消息或浏览器状态码让浏览器启动指定的认证机制。每个 Web 应用还定义了 `SecurityEnforcementFilter`，用于捕获各种 Acegi Security 异常，并根据情况委托给 `AuthenticationEntryPoint` 或返回 403（访问被拒绝）。 Acegi Security 支持同时使用多种认证机制，例如可以同时处理来自 Web 表单（使用 `AuthenticationProcessingFilter`）和 Web 服务客户端（使用 `BasicProcessingFilter`）的认证请求。对于客户端 - 服务器的富客户端应用，在客户端应用上下文中配置 `RemoteAuthenticationManager`，它接收认证请求对象，并将其中的用户名和密码传递给对应的服务器端 Web 服务。服务器端 Web 服务构建新的认证请求对象，然后传递给服务器端的 `AuthenticationManager`。如果认证成功，`GrantedAuthority` 列表会返回给 `RemoteAuthenticationManager`，富客户端可以据此做出授权决策。 对于已经存在的依赖于 Servlet 规范中 `isUserInRole()`、`getUserPrincipal()` 和 `getRemoteUser()` 方法的 Web 应用，Acegi Security 提供了两种解决方案： - `HttpServletRequestWrapper`：Acegi Security 的 `ContextHolder` 存储 `Authentication`，`ContextHolderAwareRequestWrapper` 通过委托给这些 Acegi Security 对象来实现 Servlet 规范的方法，只需在 `web.xml` 中添加 `ContextHolderAwareRequestFilter` 即可启用替换包装器。 - 容器适配器：虽然在大多数情况下不建议使用，但 Acegi Security 也提供了一些专有 Web 或应用服务器认证接口的实现，允许服务器将认证决策委托给 Acegi Security 的 `AuthenticationManager`。其中，`CasPasswordHandler` 这个容器适配器在某些情况下是被鼓励使用的，因为它可以让企业的 CAS 服务器使用 `AuthenticationManager`。 #### 2. 认证对象的存储 所有主要的 Acegi Security 类和许多用户特定的类都需要访问当前登录用户的信息，具体来说是访问适用于当前主体的已填充的 `Authentication` 对象。Acegi Security 通过 `ContextHolder` 确保任何感兴趣的类都能访问该对象，`ContextHolder` 是一个 `ThreadLocal` 对象，通常用于持有 `SecureContext`，`SecureContext` 提供了 `Authentication` 对象的 getter 和 setter 方法。 在主体请求的整个过程中，`ContextHolder` 必须设置正确的 `Authentication` 对象。对于测试，这个过程通常是一个单独的测试用例；对于富客户端应用，通常是整个应用的执行周期；对于 Web 应用或 Web 服务，通常是一个单独的 HTTP 请求。在请求结束时，需要将 `ContextHolder` 设置为 `null`，否则其他主体可能会重用该线程，从而危及安全。 对于 JUnit 测试，通常在 `setUp()` 和 `tearDown()` 方法中配置 `ContextHolder`。对于富客户端应用，开发者负责在请求期间设置 `ContextHolder`，Spring Rich 中的 `org.springframework.richclient.security` 包提供了支持 Acegi Security 的类，如 `LoginCommand` 和 `LogoutCommand`，可以隐藏 `ContextHolder` 的管理细节。对于 Web 应用和 Web 服务，使用过滤器来满足 `ContextHolder` 的要求，Acegi Security 提供了一系列认证集成过滤器，如下表所示： | 模块 | 功能 | 使用原因和时机 | | --- | --- | --- | | HttpSessionIntegrationFilter | 使用 `HttpSession` 在请求之间存储 `Authentication` | - 由于不推荐使用容器适配器，该过滤器几乎适用于所有情况<br>- 使用 `HttpSession` 在请求之间存储 `Authentication`<br>- 提供不依赖于容器适配器的可移植和灵活的方法 | | HttpRequestIntegrationFilter | 从 `HttpServletRequest.getUserPrincipal()` 获取 `Authentication`，但在请求结束时不能将其写回该位置 | - 使用大多数容器适配器时是必需的，因为这是大多数容器适配器生成的 `Authentication` 唯一可用的位置<br>- 容器负责在请求之间内部存储 `Authentication` | | JbossIntegrationFilter | 从 JBoss 的 `java:comp/env/security/subject` JNDI 位置获取 `Authentication`，但在请求结束时不能将其写回该位置 | - 使用 JBoss 容器适配器时是必需的<br>- 容器负责在请求之间内部存储 `Authentication`<br>- 如果标准的 Web 应用认证机制足够，不要使用 JBoss 容器适配器 | #### 3. 授权（Authorization） 在了解了主体的认证过程以及认证对象在请求之间的存储和通过 `ContextHolder` 访问的方式后，接下来探讨安全的核心目标：授权。 `ConfigAttribute` 是一个重要的接口，它表示适用于安全对象调用的配置设置，类似于 Spring 的事务属性，如 `PROPAGATION_REQUIRED`。`AccessDecisionManager` 负责做出授权决策，它接收安全对象、适用于该安全对象调用的配置属性以及经过验证的 `Authentication` 对象，根据这些信息做出授权决策，可能返回 `void` 或抛出 `AccessDeniedException`。 与认证相关的 `ProviderManager` 类似，`AbstractAccessDecisionManager` 采用基于提供者的方法，轮询一系列的 `AccessDecisionVoter`，每个投票者返回否决、授予或拒绝的投票，最终决策由具体的 `AbstractAccessDecisionManager` 实现决定。`RoleVoter` 是 Acegi Security 中最常用的 `AccessDecisionVoter`，它通过迭代每个配置属性，若其中一个与主体持有的 `GrantedAuthority` 匹配，则投票授予访问权限，是实现基于角色的访问控制的简单方法。`BasicAclVoter` 则是一个更复杂的投票者，将在后续的“域对象实例安全”部分讨论。 为了对安全对象调用进行实际授权，Acegi Security 需要首先拦截该调用。有几种不同类型的安全拦截器，如 `FilterSecurityInterceptor` 通过 `web.xml` 中的 `<filter>` 声明实现，Acegi Security 提供的 `FilterToBeanProxy` 类允许将 `web.xml` 定义的过滤器设置在 Spring bean 容器中；`MethodSecurityInterceptor` 用于保护 bean 容器中定义的 bean，需要使用 Spring 的 `ProxyFactoryBean` 或 `DefaultAdvisorAutoProxyCreator` 以及 `MethodDefinitionSourceAdvisor`；`AspectJSecurityInterceptor` 则使用 AspectJ 编译器进行织入。 当检测到安全对象调用时，`AbstractSecurityInterceptor` 会查找适用于该调用的配置属性。如果没有找到配置属性，该调用被视为公开调用并继续执行；如果找到配置属性，则通过 `AuthenticationManager` 对 `ContextHolder` 中包含的 `Authentication` 进行认证，并请求 `AccessDecisionManager` 对请求进行授权。如果成功，`RunAsManager` 可能会替换 `Authentication` 的身份，然后调用继续执行。调用完成后，`AbstractSecurityInterceptor` 会清理并更新 `ContextHolder` 以包含实际的 `Authentication` 对象，如果定义了 `AfterInvocationManager`，还会调用它。 `AfterInvocationManager` 能够修改安全对象调用返回的对象，通常用于过滤集合，只保留授权的元素，或者在信息受保护时修改实例变量。它接收 `Authentication`、安全对象调用、适用的配置属性以及要返回的对象，并要求返回一个对象，该对象将成为安全对象调用的结果。具体实现 `AfterInvocationP