IOS首选

Runtime Environment 运行环境

Spring Security 3.0需要Java 5.0运行时环境或更高版本。由于Spring Security的目标是以独立的方式运行，所以没有必要将任何特殊的配置文件放入Java运行时环境中。特别是，不需要配置特殊的Java身份验证和授权服务(JAAS)策略文件，也不需要将Spring Security放在公共的类路径位置。

同样，如果您使用的是EJB容器或Servlet容器，就不需要在任何地方放置任何特殊的配置文件，也不需要在服务器类加载器中包含Spring Security。所有必需的文件都将包含在您的应用程序中。

这种设计提供了最大的部署时间灵活性，因为您可以简单地将您的目标工件(无论是JAR、WAR还是EAR)从一个系统复制到另一个系统，它将立即工作。

9.2 Core Components （核心组件）

在Spring Security 3.0中，spring-security-core jar的内容被剥离到最低限度。它不再包含任何与网络应用安全、LDAP或命名空间配置相关的代码。我们将在这里看一看核心模块中的一些Java类型。它们代表框架的构建块，所以如果您需要简单的名称空间配置，那么理解它们是什么很重要，即使您实际上不需要直接与它们交互。

9.2.1 SecurityContextHolder, SecurityContext and Authentication Objects（安全上下文持有者、安全上下文和身份验证对象）

最基本的对象是SecurityContextHolder（安全上下文持有者）。我们在这里存储应用程序当前安全上下文的详细信息，包括当前使用该应用程序的主体的详细信息。默认情况下，SecurityContextHolder使用ThreadLocal来存储这些细节，这意味着安全上下文始终对同一执行线程中的方法可用，即使安全上下文没有作为参数显式传递给这些方法。这种情况下使用ThreadLocal是非常安全的，只要记得在处理完当前主体的请求以后，把这个线程清除就行了。当然，Spring Security自动帮你管理这一切了， 你就不用担心什么了。

有些程序并不适合使用ThreadLocal，因为它们处理线程的特殊方法。比如Swing客户端也许希望Java Virtual Machine里所有的线程 都使用同一个安全环境。SecurityContextHolder可以在启动时配置策略，以指定您希望如何存储上下文。对于独立的应用程序，您可以使用SecurityContextHolderSecurityContextHolder可以在启动时配置策略，以指定您希望如何存储上下文。对于独立的应用程序，您可以使用SecurityContextHolder.MODE_GLOBAL策略。其他程序可能也想由安全线程产生的线程也承担同样的安全标识。这是通过使用SecurityContextHolder.MODE_INHERITABLETHREADLOCAL实现。第一个是设置系统属性，第二个是调用SecurityContextHolder的静态方法。大多数应用程序不需要修改默认值，但是如果你想要修改，可以看一下SecurityContextHolder的JavaDocs中的详细信息了解更多。

Obtaining information about the current user（获取关于当前用户的信息）

在SecurityContextHolder中，我们存储当前与应用程序交互的主体的详细信息。Spring Security使用一个身份验证对象来表示这些信息。您通常不需要自己创建身份验证对象，但是用户查询身份验证对象是很常见的。您可以从应用程序中的任何位置使用以下代码块来获取当前经过身份验证的用户的名称，例如:

 

 

调用getContext()返回的对象是SecurityContext接口的一个实例。这是保存在线程本地存储中的对象。正如我们将在下面看到的，Spring Security中的大多数身份验证机制都返回一个UserDetails实例作为主体。

9.2.2 The UserDetailsService（用户详细信息服务）

从上面的代码片段中需要注意的另一点是，您可以从身份验证对象中获取一个主体。主体只是一个客体。大多数情况下，这可以转换成一个UserDetails对象。UserDetails是Spring安全的核心接口。它代表一个主体，但是以一种可扩展的和特定于应用程序的方式。将UserDetails视为您自己的用户数据库和SecurityContextHolder内部的Spring Security需要之间的适配器。作为来自您自己的用户数据库的表示，您经常会将UserDetails转换为您的应用程序提供的原始对象，因此您可以调用特定于业务的方法(如getEmail()，getEmployeeNumber()，等等)。

现在你可能想知道，我什么时候提供一个用户详细信息对象？我怎么做呢?我想你说这个东西是声明式的，我不需要写任何代码——什么给出了？

简而言之，有一个叫做UserDetailsService（用户详细服务）的特殊接口。此接口上的唯一方法接受基于字符串的用户名参数并返回UserDetails（用户详细信息）:

 

 

这是在Spring Security中为用户加载信息的最常见的方法，当需要关于用户的信息时，您会在整个框架中看到它的使用。

在成功的身份验证中，UserDetails（用户详细信息）用于构建存储在SecurityContextHolder中的Authentication（身份验证对象）(下面将详细介绍)。好消息是我们提供了大量的用户细节服务实现，包括一个使用内存映射(InMemoryDaoImpl)的实现和一个使用JDBC (JdbcDaoImpl)的实现。然而，大多数用户倾向于编写自己的代码，他们的实现通常只是简单地位于代表他们的雇员、客户或应用程序的其他用户的现有数据访问对象(DAO)之上。请记住，无论您的UserDetailsService返回什么，都可以使用上面的代码片段从安全上下文持有者获得。

关于UserDetailsService经常会有一些混淆。它纯粹是用户数据的DAO，除了向框架内的其他组件提供数据之外，不执行其他功能。特别是，它不会对用户进行身份验证，这是由AuthenticationManager完成的。在许多情况下，如果需要自定义身份验证过程，直接实现AuthenticationProvider更有意义。