最基础的对象就是SecurityContextHolder。 我们把当前应用程序的当前安全环境的细节存储到它里边了， 它也包含了应用当前使用的主体细节。 默认情况下，SecurityContextHolder使用ThreadLocal存储这些信息， 这意味着，安全环境在同一个线程执行的方法一直是有效的， 即使这个安全环境没有作为一个方法参数传递到那些方法里。 这种情况下使用ThreadLocal是非常安全的， 只要记得在处理完当前主体的请求以后，把这个线程清除就行了。 当然，Spring Security自动帮你管理这一切了， 你就不用担心什么了。

有些程序并不适合使用ThreadLocal， 因为它们处理线程的特殊方法。比如，swing客户端也许希望 JVM里的所有线程都使用同一个安全环境。 SecurityContextHolder可以使用一个策略进行配置 在启动时，指定你想让上下文怎样被保存。对于一个单独的应用系统，你可以使用 SecurityContextHolder.MODE_GLOBAL策略。 其他程序可能想让一个线程创建的线程也使用相同的安全主体。 这时可以使用SecurityContextHolder.MODE_INHERITABLETHREADLOCAL。 想要修改默认的SecurityContextHolder.MODE_THREADLOCAL模式，可以使用两种方法。 第一个是设置系统属性。另一个是调用 SecurityContextHolder的静态方法。大多数程序不需要修改默认值， 但是如果你需要做修改，先看一下 SecurityContextHolder的JavaDoc中的详细信息。

Object principal = SecurityContextHolder.getContext().getAuthentication().getPrincipal();

if (principal instanceof UserDetails) {
  String username = ((UserDetails)principal).getUsername();
} else {
  String username = principal.toString();
}

从上面的代码片段中还可以看出另一件事，就是你可以从Authentication对象中获得安全主体。 这个安全主体就是一个对象。 大多数情况下，可以强制转换成UserDetails对象。 UserDetails是一个Spring Security的核心接口。 它代表一个主体，是扩展的，而且是为特定程序服务的。 想一下UserDetails章节，在你自己的用户数据库和如何把Spring Security需要的数据放到SecurityContextHolder里。 为了让你自己的用户数据库起作用，我们常常把UserDetails转换成你系统提供的类，这样你就可以直接调用业务相关的方法了（比如getEmail(), getEmployeeNumber()等等）。

现在，你可能想知道，我应该什么时候提供这个UserDetails对象呢？ 我怎么做呢？ 我想你说这个东西是声明式的，我不需要写任何代码，怎么办？ 简单的回答是，这里有一个特殊的接口，叫UserDetailsService。 这个接口里的唯一一个方法，接收String类型的用户名参数，返回UserDetails：

  UserDetails loadUserByUsername(String username) throws UsernameNotFoundException;

这是获得从Spring Security中获得用户信息的最常用方法，你会看到它在框架中一直被用到。 当需要获得一个用户的信息的时候。

当成功通过验证时，UserDetails会被用来 建立Authentication对象，保存在SecurityContextHolder里。 (更多的信息可以参考下面的#tech-intro-authentication-mgr)。 好消息是我们提供了好几个UserDetailsService实现，其中一个使用了 内存中的map(InMemoryDaoImpl)另一个而是用了JDBC (JdbcDaoImpl)。 虽然，大多数用户倾向于写自己的，使用这些实现常常放到已有的数据访问对象（DAO）上，表示它们的雇员，客户或其他企业应用中的用户。 记住这个优势，无论你用什么UserDetailsService返回的数据都可以通过SecurityContextHolder获得，就像上面的代码片段讲的一样。

除了主体，另一个Authentication提供的重要方法是getAuthorities()。 这个方法提供了GrantedAuthority对象数组。 毫无疑问，GrantedAuthority是赋予到主体的权限。 这些权限通常使用角色表示，比如ROLE_ADMINISTRATOR 或 ROLE_HR_SUPERVISOR。 这些角色会在后面，对web验证，方法验证和领域对象验证进行配置。 Spring Security的其他部分用来拦截这些权限，期望他们被表现出现。 GrantedAuthority对象通常使用UserDetailsService读取的。

通常情况下，GrantedAuthority对象是应用程序范围下的授权。 它们不会特意分配给一个特定的领域对象。 因此，你不能设置一个GrantedAuthority，让它有权限展示编号54的Employee对象，因为如果有成千上网的这种授权，你会很快用光内存（或者，至少，导致程序花费大量时间去验证一个用户）。 当然，Spring Security被明确设计成处理常见的需求，但是你最好别因为这个目的使用项目领域模型安全功能。

简单回顾一下，Spring Security主要是由一下几部分组成的：

现在，你应该对这种重复使用的组件有一些了解了。 让我们贴近看一下验证的过程。

让我们考虑一种标准的验证场景，每个人都很熟悉的那种。

前三个项目执行了验证过程，所以我们可以看一下 Spring Security的作用。

从这一点开始，用户已经通过校验了。让我们 看一些代码作为例子。

import org.springframework.security.authentication.*;
import org.springframework.security.core.*;
import org.springframework.security.core.authority.GrantedAuthorityImpl;
import org.springframework.security.core.context.SecurityContextHolder;

public class AuthenticationExample {
  private static AuthenticationManager am = new SampleAuthenticationManager();

  public static void main(String[] args) throws Exception {
    BufferedReader in = new BufferedReader(new InputStreamReader(System.in));

    while(true) {
      System.out.println("Please enter your username:");
      String name = in.readLine();
      System.out.println("Please enter your password:");
      String password = in.readLine();
      try {
        Authentication request = new UsernamePasswordAuthenticationToken(name, password);
        Authentication result = am.authenticate(request);
        SecurityContextHolder.getContext().setAuthentication(result);
        break;
      } catch(AuthenticationException e) {
        System.out.println("Authentication failed: " + e.getMessage());
      }
    }
    System.out.println("Successfully authenticated. Security context contains: " +
              SecurityContextHolder.getContext().getAuthentication());
  }
}

class SampleAuthenticationManager implements AuthenticationManager {
  static final List<GrantedAuthority> AUTHORITIES = new ArrayList<GrantedAuthority>();

  static {
    AUTHORITIES.add(new GrantedAuthorityImpl("ROLE_USER"));
  }

  public Authentication authenticate(Authentication auth) throws AuthenticationException {
    if (auth.getName().equals(auth.getCredentials())) {
      return new UsernamePasswordAuthenticationToken(auth.getName(),
        auth.getCredentials(), AUTHORITIES);
      }
      throw new BadCredentialsException("Bad Credentials");
  }
}

这里 我们写了一些程序，询问用户输入一个用户名和密码， 然后执行上面的顺序。我们实现的AuthenticationManager 会验证所有用户名和密码一样的用户。 它为每个永固分配一个单独的角色。上面输出的信息 将会像这样：

Please enter your username:
bob
Please enter your password:
password
Authentication failed: Bad Credentials
Please enter your username:
bob
Please enter your password:
bob
Successfully authenticated. Security context contains: \
 org.springframework.security.authentication.UsernamePasswordAuthenticationToken@441d0230: \
 Principal: bob; Password: [PROTECTED]; \
 Authenticated: true; Details: null; \
 Granted Authorities: ROLE_USER
        

注意，你没必要写这些代码。这些处理都是发生在内部的， 比如在一个web验证过滤器中。我们只是使用了这些代码， 来演示真实情况下的问题，Spring Security提供了一个简单的答案。 一个用户被验证，当 SecurityContextHolder包含了完整的 Authentiation对象。

实际上，Spring Security不知道你怎么把 Authentication对象放到 SecurityContextHolder里。唯一关键的要求是 SecurityContextHolder包含了一个 Authentication表示了一个主体， 在AbstractSecurityInterceptor之前（我们以后会看到更多） 需要验证一个用户操作。

你可以（许多人都这样做）写自己的过滤器，或MVC控制器来提供验证系统， 不基于Spring Security。比如 你可能使用容器管理的验证，让当前用户有效 在TheadLocal或JNDI位置。或者你可能为一个公司工作，你没有什么控制力。 这种情况下，使用Spring Security很简单， 还是提供验证功能。 你需要做的是些一个过滤器（或什么设备） 从一个地方读取第三方用户信息， 构建一个Spring Security特定的Authentication对象， 把它放到SecurityContextHolder里。 在这种情况下，你也需要考虑 那些平常由内置的架构自动提供的功能。 比如，你也许需要预先创建一个HTTP会话来 为不同的请求缓存上下文， 在你把响应内容写入到客户端之前^[9]。

如果你想知道AuthenticationManager是如何实现的， 我们会在***看到。

ExceptionTranslationFilter是一个Spring Security过滤器 负责检测任何一个Spring Security抛出的异常。 这些异常会被AbstractSecurityInterceptor抛出， 这是一个验证服务的主要提供器。我们会在下一章讨论AbstractSecurityInterceptor， 而现在我们需要知道它产生Java异常， 不知道HTTP，也不知道如何验证一个主体。 对应的ExceptionTranslationFilter负责这个服务， 特别负责返回错误代码403（如果主体已经通过授权， 但是权限不足 - 像上面的第七步）， 或者启动一个AuthenticationEntryPoint（如果 主体还没有授权，因此我们会进入上面的第三步）。

AuthenticationEntryPoint负责上面的步骤三。 像你想的那样，每个web应用会有一个默认的验证策略 （好，这可能像其他东西一样在Spring Security里配置， 但现在让我们保持简单）。每个主要的验证系统会有他们自己的 AuthenticationEntryPoint实现， 典型的执行一个动作，描述在第三步。

一旦你的浏览器提交了你的验证证书（像HTTP表单POST或者HTTP头） 这些需要一些服务器的东西保存这些权限信息。 但是现在我们进入上面的第六步。 在Spring Security中我们有一个特定的名称，为了收集验证信息的操作。 从一个用户代码中（通常是浏览器），引用它作为一个“验证机制”。 例子是基于表单的登录和BASIC验证。 一旦验证细节被从用户代理处收集到， 一个Authentication 请求对象就会被建立，然后放到AuthenticationManager。

在验证机制获得完全的 Authentication后，它会认为请求合法， 把Authentication放到 SecurityContextHolder里，然后让原始请求重试 （上面第七步）。如果，其他可能， AuthenticationManager拒绝了请求， 请求机制会让用户代理重试（上面第二步）。

依照应用类型，这里需要一个策略， 在用户操作之间保存安全环境。在一个典型的web应用中， 一个用户日志，一次或顺序被它的session id。服务器缓存 主体信息在session整个过程中，在Spring Security中，保存 SecurityContext，从请求失败 SecurityContextPersistenceFilter，默认保存到 HttpSession里的一个属性，在HTTP请求之间。 它重新保存环境到SecurityContextHolder，为每个请求。 然后为每个请求清空SecurityContextHolder。 你不应该为了安全目的，直接操作HttpSession。 这里有简单的方法实现 - 一直使用SecurityContextHolder代替。

很多其他类型的应用（比如，一个无状态的REST web服务）不会使用 HTTP会话，会在每次请求时，重新验证。然而，这对 SecurityContextPersistenceFilter也很重要，确保包含在 SecurityContextHolder中，在每次请求后清空。

如果你熟悉AOP的话，就会知道有几种不同的拦截方式：之前，之后，抛异常和环绕。 其中环绕是非常有用的，因为advisor可以决定是否执行这个方法，是否修改返回的结果，是否抛出异常。 Spring Security为方法调用提供了一个环绕advice，就像web请求一样。 我们使用Spring的标准AOP支持制作了一个处理方法调用的环绕advice，我们使用标准filter建立了对web请求的环绕advice。

对那些不熟悉AOP的人，需要理解的关键问题是Spring Security可以帮助你保护方法的调用，就像保护web请求一样。 大多数人对保护服务层里的安全方法非常按兴趣。 这是因为在目前这一代J2EE程序里，服务器放了更多业务相关的逻辑（需要澄清，作者不建议这种设计方法，作为替代的，而是应该使用DTO，集会，门面和透明持久模式压缩领域对象，但是使用贫血领域对象是当前的主流思路，所以我们还是会在这里讨论它）。 如果你只是需要保护服务层的方法调用，Spring标准AOP平台（一般被称作AOP联盟）就够了。 如果你想直接保护领域对象，你会发现AspectJ非常值得考虑。

可以选择使用AspectJ还是Spring AOP处理方法验证，或者你可以选择使用filter处理web请求验证。 你可以不选，选择其中一个，选择两个，或者三个都选。 主流的应用是处理一些web请求验证，再结合一些在服务层里的Spring AOP方法调用验证。

所以，什么是“secure object”？ Spring Security使用应用任何对象，可以被安全控制（比如一个验证决定）提供到它上面。 最常见的例子是方法调用和web请求。

Spring Security支持的每个安全对象类型都有它自己的类型，它们都是AbstractSecurityInterceptor的子类。 很重要的是，如果主体是已经通过了验证，在AbstractSecurityInterceptor被调用的时候，SecurityContextHolder将会包含一个有效的Authentication。

AbstractSecurityInterceptor提供了一套一致的工作流程，来处理对安全对象的请求，通常是：