Spring Security 提供了基于javaEE的企业应有个你软件全面的安全服务。这里特别强调支持使用SPring框架构件的项目，Spring框架是企业软件开发javaEE方案的领导者。如果你还没有使用Spring来开发企业应用程序，我们热忱的鼓励你仔细的看一看。熟悉Spring特别是一来注入原理两帮助你更快更方便的使用Spring Security。

人们使用Spring Secruity的原因有很多，单大部分都发现了javaEE的Servlet规范或EJB规范中的安全功能缺乏典型企业应用场景所需的深度。提到这些规范，重要的是要认识到他们在WAR或EAR级别无法移植。因此如果你更换服务器环境，这里有典型的大量工作去重新配置你的应用程序员安全到新的目标环境。使用Spring Security 解决了这些问题，也为你提供许多其他有用的，可定制的安全功能。

正如你可能知道的两个应用程序的两个主要区域是“认证”和“授权”（或者访问控制）。这两个主要区域是Spring Security 的两个目标。“认证”，是建立一个他声明的主题的过程（一个“主体”一般是指用户，设备或一些可以在你的应用程序中执行动作的其他系统）。“授权”指确定一个主体是否允许在你的应用程序执行一个动作的过程。为了抵达需要授权的店，主体的身份已经有认证过程建立。这个概念是通用的而不只在Spring Security中。

在身份验证层，Spring Security 的支持多种认证模式。这些验证绝大多数都是要么由第三方提供，或由相关的标准组织，如互联网工程任务组开发。另外Spring Security 提供自己的一组认证功能。具体而言，Spring Security 目前支持所有这些技术集成的身份验证：

很多独立软件供应商，因为灵活的身份验证模式二选择Spring Security。这样做允许他们快速的集成到他们的终端客户需求的解决方案而不用进行大量工程或者改变客户的环境。如果上面的验证机制不符合你的需求，Spring Security 是一个开放的平台，要实现你 自己的验证机制检查。Spring Security 的许多企业用户需要与不遵循任何安全标准的“遗留”系统集成，Spring Security可以很好的与这类系统集成。

无论何种身份验证机制，Spring Security提供一套的授权功能。这里有三个主要的热点区域，授权web请求、授权方法是否可以被调用和授权访问单个域对象的实例。为了帮助让你分别了解这些差异，认识在Servlet规范网络模式安全的授权功能，EJB容器管理的安全性和文件系统的安全。Spring Security在这些重要的区域提供授权功能，我们将在手册后面进行介绍。

Spring Security 以“The Acegi Secutity System for Spring” 的名字始于2013年晚些时候。一个问题提交到Spring 开发者的邮件列表，询问是否已经有考虑一个机遇Spring 的安全性社区实现。那时候Spring 的社区相对较小（相对现在）。实际上Spring自己在2013年只是一个存在于ScourseForge的项目，这个问题的回答是一个值得研究的领域，虽然目前时间的缺乏组织了我们对它的探索。

考虑到这一点，一个简单的安全实现建成但是并没有发布。几周后，Spring社区的其他成员询问了安全性，这次这个代码被发送给他们。其他几个请求也跟随而来。到2014年一月大约有20万人使用了这个代码。这些创业者的人提出一个SourceForge项目加入是为了，这是在2004三月正式成立。

在早些时候，这个项目没有任何自己的验证模块，身份验证过程依赖于容器管理的安全性和Acegi安全性。而不是专注于授权。开始的时候这很适合，但是越来越多的用户请求额外的容器支持。容器特定的认证领域接口的基本限制变得清晰。还有一个相关的问题增加新的容器的路径，这是最终用户的困惑和错误配置的常见问题。

Acegi安全特定的认证服务介绍。大约一年后，Acegi安全正式成为了Spring框架的子项目。1.0.0最终版本是出版于2006 -在超过两年半的大量生产的软件项目和数以百计的改进和积极利用社区的贡献。

Acegi安全2007年底正式成为了Spring组合项目，更名为"Spring Security"。

如今Spring Security有一个强大的和积极的开源社区。在支持论坛上有成千上万的关于Spring Security的消息。有一个活跃的核心的开发人员，他们的代码本身和一个活跃的社区，也经常分享补丁和支持他们的同龄人。

了解Spring Security发布版本号如何工作是很有用的，他可以帮助你识别出工作（或缺乏的功能）设计到参与迁移到项目的未来版本，每个发布使用3个整数，MAJOR.MINOR.PATCH（主版本、次要版本、补丁版本）.这样做的目的是主版本是不兼容的，API大范围的升级。次要版本应该保留大部分源代码和二进制兼容旧版本的次要版本，认为可能有一些设计变更和不兼容的更新。补丁版本应该向前向后完美兼容。包含一些bug和缺陷修复这些意外的改变。

在某种程度上，你受到变化的影响取决于你的代码是如何紧密集成的。如果你正在做大量定制，你更可能受到比简单的命名空间配置更大的影响。

你应该总是推出一个新版本之前彻底测试你的应用程序。

你可以通过几种方式获取Spring Security。你可以从 Spring Security 页面下载一个分发包。从Maven库下载分离的jar文件。另外你也可以从源代码自己编译。

第一步是创建我们的java配置。这个配置在你的应用程序中创建一个springSecurityFilterChain 的Servlet的过滤器 springSecurityFilterChain负责所有安全（例如 保护应用程序的URL，验证提交的用户名和密码，重定向到登陆的表单等等）。你可以在下面找到大部分java配置项的例子:

真的是没有太多的配置，但它确实有很多功能，你可以在下面找到功能摘要:

到目前为止我们的WebSecurityConfig只包含了关于如何验证我们的用户的信息。Spring Security怎么知道我们相对所有的用户进行验证？Spring Securityn怎么知道我们需要支持基于表单的验证？原因是WebSecurityConfigurerAdapter在configure(HttpSecurity http)方法中提供了一个默认的配置，看起来和下面类似:

上面的默认配置:

你可以看到这个配置和下面的XML命名配置相似:

java配置使用and()方法相当于XML标签的关闭。 这样允许我们继续配置父类节点。如果你阅读代码很合理，想配置请求验证， 并使用表单和HTTP基本身份验证进行登录。

然而，java配置有不同的默认URL和参数，当你自定义用户登录页是需要牢记这一点。让我们的URL冯家RESTful，另外不要那么明显的观察出我么你在使用Spring Security这样帮助我们避免信息泄露。 information leaks。比如：

你可能会想知道系统提示您登录表单从哪里来的，因为我们都没有提供任何的HTML或JSP文件。由于Spring Security的默认配置并没有明确设定一个登录页面的URL，Spring Security自动生成一个，基于这个功能被启用，使用默认URL处理登录的提交内容，登录后跳转的URL等等。

自动生成的登录页面可以方便应用的快速启动和运行，大多数应用程序都需要提供自己的登录页面。要做到这一点，我们可以更新我们的配置，如下所示：

一个我么当前配置使用的JSP实现的页面如下：

我们的例子中要求用户进行身份验证并且在我们应用程序的每个URL这样做。我么你可以通过给http.authorizeRequests()添加多个子节点来指定多个定制需求到我们的URL。例如：

当使用WebSecurityConfigurerAdapter, 注销功能会自动应用。默认是访问URL`/logout`将注销登陆的用户：

和登录功能类似，你也有不同的选项来定制你的注销功能：

一般来说，为了定制注销功能，你可以添加 LogoutHandler和LogoutSuccessHandler的实现。 对于许多常见场景，当使用流食式API时，这些处理器会在幕后进行添加。

到现在为止我们只看了一下基本的验证配置，让我们看看一些稍微高级点的身份验证配置选项。

我们可以配置多个HttpSecurity实例，就像我们可以有多个<http>块. 关键在于对WebSecurityConfigurationAdapter进行多次扩展。例如下面是一个对/api/开头的URL进行的不同的设置。

从2.0 开始Spring Security对服务层的方法的安全有了实质性的改善。他提供对JSR-250的注解安全支持像框架原生@Secured注解一样好。从3.0开始你也可以使用新的基于表达式的注解 expression-based annotations。你可以应用安全到单独的bean，使用拦截方法元素去修饰Bean声明，或者你可以在整个服务层使用 AspectJ风格的切入点保护多个bean。

Spring Security的Java配置没有公开每个配置对象的每一个属性，这简化了广大用户的配置。毕竟如果要配置每一个属性，用户可以使用标准的Bean配置。

虽然有一些很好的理由不直接暴露所有属性，用户可能仍然需要更多高级配置，为了解决这个Spring Security引入了ObjectPostProcessor概念，用来替换java配置的对象实例。例如：如果你想在filterSecurityPublishAuthorizationSuccess里配置FilterSecurityInterceptor属性，你可以想下面一样：

命名空间配置在Spring框架的2.0版本就可以使用了，他允许你通过额外的XML架构元素补充传统的Spring bean应用程序上下文。你可以从Spring的参考文档找到更多信息 Reference Documentation.。命名空间元素可以简单的允许配置单个bean，或者更强大的，定义一个可选的配置语法，这样更贴近问题域并且对用户隐藏背后的复杂性。一个简单的元素可以隐藏多个bean和添加到应用程序上下文的多个处理步骤。例如：从安全命名空间添加后面的元素到应用程序上下文将开始一个LDAP服务到应用程序内用于测试：

这比配置一个Apache木服务器bean简单的多。最常见的替代配置需求是ldap-server元素的属性支持，用户不用担心他们要创建的bean属名称:[你可以从:specialcharacters,macros[LDAP 身份验证]找到如何使用ldap-server元素的更多的信息. ] 。当编译应用的Context文件时良好的XML编译器应该可以提供您可用的属性和元素的信息。我们建议你尝试使用 Spring Tool Suite，它具有与标准Spring命名空间工作的特别的功能。

为了在你的应用程序上下文中使用安全命名空间，你需要将spring-security-config包含到你的classpath中。然后在你的上下文文件中加入以下的结构声明：

在很多示例（包括示例应用程序）中你将会看到，我们经常使用security作为默认的命名空间而不是使用beans，这样我们可以在所有安全命名空间中忽略前缀，使得内容更加容易阅读。如果你的应用程序上下文被分割成单独的文件，大部分的安全配置被放到一个文件中，你可能也想这样做。你的安全应用上下文文件应该像下面的一样：

我们假设在这一章节我们都使用这种语法。

在这一章，我们将看看怎么创建一个命名空间配置来使用框架的主要功能。让我们假设你想要快速的使用命名空间配置添加验证支持和访问控制和一些测试的登录到一个已经存在的网站应用程序。然后我们看看如何验证数据库和其他的安全仓库。在后续章节我们将介绍更多高级的命名空间配置选项。

从2.0版本开始Spring Security改进了对服务层方法的安全支持，它提供了对JSR-250注解安全支持以及框架的原生@Secured注解支持。从3.0开始你也可以使用新的expression-based annotations。你可以将安全应用到单个bean。使用intercept-methods元素装饰Bean的声明。或者你可以在使用AspectJ风格的切入点应用安全到整个服务层的多个Bean类。

这一章节假设你有一些Spring Security中访问控制的底层架构的知识。如果没有，你可以跳过它，后面再来看，这部分针对那些真正需要进行一些定制而不是简单的基于角色的安全用户。

当你使用命名空间配置时，一个AccessDecisionManager实例将会自动创建并注册用来按照你在intercept-url和protect-pointcut（还有如果你使用了方法注解安全也包含在内）定义的访问属性进行访问决策。

默认的策略是使用一个AffirmativeBased、AccessDecisionManager和RoleVoter``AuthenticatedVoter，你也可以从authorization章节找到更多信息.

Spring Security中主要的提高验证服务的借口是AuthenticationManager，这通常是一个Spring Security的ProviderManager类的实例。如果你以前用过框架你可能已经熟悉了。如果不是后面的 technical overview chapter章节会讲到。这个bean是通过authentication-manager命名空间来注册。你不能使用自定义的AuthenticationManager如果通过命名空间使用HTTP或方法安全，但是这不应该是一个问题，因为你可以完全控制所使用的好的AuthenticationProvider。

你可能需要使用ProviderManager注册其他的AuthenticationProvider Bean，你可以使用<authentication-provider>元素的ref属性，属性的值是你要添加的bean的名字，例如：

另一个常见的需求是，上下文中的另一个bean可能需要引用AuthenticationManager，你可以注册一个AuthenticationManager的别名在应用程序上下文中的其他地方使用这个名字。

本教程样本是一个让你入门的很好的基础的例子。它完全使用而来简单命名空间配置。编译好的应用程序包含在分发的zip包中。随时可以部署到你的Web容器(spring-security-samples-tutorial-3.1.x.war)。 form-based的认证机制结合remember-me 功能，验证供应商提供使用cookie自动基础登录。

我们建议你从本示例开始，因为XML非常小，易于遵循。最重要的是，你可以把这个XML文件（和它对应的web.xml入口）轻松地添加到现有的应用程序中。在这个基本集成成功的时候，我们建议你试着添加方法验证和领域对象安全。

该示例是一个高级的例子，它展示除了基本的应用程序安全领域对象的访问控制列表（ACL）的更强大的功能。本申请提供了一个接口让用户能够管理简单的联系人数据库（域对象）。

拷贝WAR问价你从Spring Security 分发包到你自己的容器的webapps 目录来部署它。war名字是spring-security-samples-contacts-3.1.x.war(扩展的版本号取决于你的版本号)。

开始你的容器后检查应用程序是否可用载入，访问 http://localhost:8080/contacts (或者其他适合你的容器URL)。

接下来，单击"Debug"。系统将提示你进行身份验证，以及页面提示的一系列用户名和密码。简单验证，显示一个结果页面。它应该包含类似于一下成功信息：

一旦你成功地收到上述消息，返回到示例应用程序的主页，点击"Manage"。然后，你可以使用这个应用程序。注意只有当前用户的联系人会被显示，并且只有拥有ROLE_SUPERVISOR可用授权去删除联系人，在幕后MethodSecurityInterceptor保护业务对象。

这应用程序允许你修改与不同的联系人相关联的访问控制列表。一定要试试这个，并了解它是如何工作通过检查应用程序上下文XML文件。

LDAP例子程序提供了一个基本的配置和使用命名空间和使用传统的bean同等设置在同一个应用程序上下文文件。这意味着，其实是在这个应用程序中配置了两个相同的身份验证提供者。

OpenID的示例演示了如何使用命名空间来配置OpenID和如何设置为Google，Yahoo和OpenID设置 attribute exchange配置（如果你愿意的话，也可以添加其他的供应商）。它使用一个基于JQery的 openid-selector，以提供用户友好的登录页面，它允许用户很容易的选择一个验证提供者，而不是输入OpenID标识符。

应用程序的不同之处在于它允许任何用户访问该站点认证情景（只要他们的OpenID身份验证是成功的）。当你第一次登录时，你会得到一个"Welcome [your name]"的消息。如果你注销并重新登录（以相同的身份），那么这应更改为"欢迎回来"，这是通过使用一个实现自定义的UserDetailsService它分配一个标准角色给任何用户，并在内部存储身份的map。显然，一个真正的应用程序将使用一个数据库替换它。看一看源代码了解更多信息，此类还考虑到，不同供应商返回不同属性，并建立相应用户名。

CAS示例要求你同时运行CAS服务器和CAS客户端。 它不包含在发行包，所以你应该按照 the introduction描述签出目标代码。你会发现sample/cas目录下的相关文件。还有在那里一个Readme.txt文件，这也解释了如何直接从源代码运行服务器和客户端，完全支持SSL。

该JAAS是很简单的如何用Spring Security 使用JAAS LoginModule 的例子。所提供的LoginModule将成功地验证用户，如果用户名和密码相等，否则抛出一个LoginException异常。在本示例中使用的AuthorityGranter总是授予角色ROLEUSER。示例应用程序还演示了如何通过设置LoginModule的jaas-api-provision等于true返回JAAS Subjec来运行。

此示例应用程序演示了如何绑定bean从pre-authentication 框架从Java EE容器使用登录信息。用户名和角色是由容器设置的。

代码是samples/preauth.

Spring Security 使用JIRA来管理bug报告和改进请求，如果你发现错误，请使用JIRA记录报告。不要在支持论坛，邮件列表，或通过电子邮件项目的记录。这些方法是临时的，我们更喜欢使用正式的流程。

如果可能的话，在你的问题的报告摸清提供一个JUnit测试，演示任何不正确的行为。或者，更好的是，提供了一个可以解决这个问题的补丁。同样，非常欢迎的提出改进需求，虽然我们只接受、有对应的单元测试的改进请求。这是必要的，以确保保持项目的测试覆盖率。

问题跟踪系统你可以通过这里访问： https://github.com/spring-projects/spring-security/issues.

我们欢迎你参与Spring Security项目。有贡献的方法很多，包括阅读论坛，并响应来自其他人的问题，编写新的代码，改进现有的代码，协助文档，开发样品或教程，或则干脆提出建议。

欢迎为Spring Security 提出问题和意见。你可以使用Spring社区 论坛网站http://spring.io/questions[http://spring.io/questions] 和其他Spring Security框架的用户进行讨论。请记住，正如前面说的使用JIRA提交bug报告。

Spring Security 3.0需要Java 5.0的运行环境或者更高的版本. 由于 Spring Security 是以独立的方式运作, 就不需要什么特殊的配置文件到你的Java运行环境。特别是, 不需要配置专门的Java认证和授权服务(JAAS)策略文件或将Spring Security的位置放到普通路径中。

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

这种设计给部署时间提供了最大的灵活性，你可以简单的复制你的目标文件(可以是JAR, WAR或者EAR)从一个系统到另一个系统，它会立即开始工作。

在Spring Security 3.0的版本中，spring-security-core中的内容被精简到了最低限度。它不再包含web应用安全,LDAP或命名空间配置的任何代码。我们来看看一些Java类型，你会在核心模块中找到。它们代表了框架的基石，所有如果你需要越过一个简单的命名空间配置，那么最重要的是你要明白它们是什么，即使你不需要直接与它们进行交互。

Spring Security可以在很多不同的认证环境下使用。虽然我们推荐人们使用Spring Security，不与已存在的容器管理认证系统结合，但它也是支持的-使用你自己的属性验证系统进行整合。

现在让我们来看看你在Web应用程序中使用Spring Security的情况(不启用web.xml安全性)。用户如何进行身份验证和建立安全环境?

考虑一个典型的Web应用程序的身份验证过程:

Spring Security使用鲜明的类负责上面提到的每个步骤。主要的部分是（为了使用他们） ExceptionTranslationFilter, 一个 AuthenticationEntryPoint 一个验证机制, 我们在上一节看到它负责调用AuthenticationManager。

负责Spring Security访问控制决策的主要接口是AccessDecisionManager。它有一个decide方法，它需要一个Authentication对象请求访问,一个"secure object"(见下文)和安全元数据属性的列表适用的对象(如一个列表哪些角色需要被访问授权)。

Spring Security支持终端用户看到异常消息的本地化。如果你的应用程序是专为讲英语的用户设计的，你不需要做任何事情，因为默认所有的安全信息都是英文的，如果你需要支持其他地方，你需要知道的一切都被包含在这部分。

所有异常消息都可以本地化，包括有关验证失败和访问被拒绝（授权失败）的消息。这主要集中在开发者和系统发布（包括不正确的属性，接口违反合同，使用不正确的构造器，开始验证，日志调试等级）异常和日志消息没有本地化，而是使用硬编码的Spring Security的英文代码。

在spring-security-core-xx.jar的运输中你会发现一个org.springframework.security 包含了 messages.properties文件,以及一些常用版本的本地化语言。这应该是你的ApplicationContext,因为Spring Security实现了Spring的MessageSourceAware界面，希望这些消息是依赖于应用程序上下文启动的时候注入。通常你需要做的是创建你的应用程序上下文参考消息里面的bean。一个例子如下所示：

该messages.properties是按照标准的资源束命名方式，为Spring Security的消息所支持的默认语言。这个默认的文件是英文的。

如果您希望自定义messages.properties文件，或支持其他语言，您应该复制该文件，相应地重命名它，并在上面的bean定义中注释它。在这个文件中没有大量的消息密钥，因此本地化不应该被认为是一个重大举措。如果你对这个文件执行定为操作，请考虑与社区分享你的工作通过记录JIRA任务和附加被你恰当命名的messages.properties本地化版本。

Spring Security依赖于Spring"s的本地化支持，以实际查找适当的消息。为了这项工作，你必须确保从传入请求的区域存储在Spring’s`org.springframework.context.i18n.LocaleContextHolder`。Spring MVC的` DispatcherServlet 会自动为你的程序做，但因为Spring Security的过滤器在那之前被调用，`localecontextholder需在过滤器被呼叫之前建立在包含正确的Locale里。你也可以在你自己的过滤器里面做这个（必须做完这项在Spring Security的web.xml过滤之前）或者你可以使用Spring的RequestContextFilter。请参阅Spring Framework文档，以进一步详细说明使用Spring定位。

“联系人”示例应用程序设置为使用本地化消息。

该 AuthenticationManager只是一个接口，这样的实现可以是我们选择的任何东西，但它是如何在实践中运作的?如果我们需要检查多个授权数据库或者将不同的授权服务结合起来，类似数据库和LDAP服务器?

Spring Security的默认实现被称为ProviderManager而非处理身份验证请求本身，它委托给一个列表去配置AuthenticationProvider，其中每个查询反过来，看它是否能进行认证。每个提供程序都将抛出一个异常或返回一个完全填充的身份验证对象。还记得我们的好朋友，UserDetails和UserDetailsService吗?如果没有，回到前面的章节刷新你的记忆。到验证的认证请求的最常见的方法是加载相应UserDetails并针对已经由用户输入所述一个检查加载密码。这是由DaoAuthenticationProvider所使用的方法（见下文）。加载的UserDetails对象-尤其是GrantedAuthority的IT包含-建设是返回一个成功验证，并存储在SecurityContext完全填充Authentication对象时，将被使用。

如果你使用的命名空间，创建并在内部进行维护ProviderManager的一个实例，您可以通过使用命名空间身份验证提供元素添加提供商。(see 命名空间章节)。在这种情况下，你不应该声明在应用程序上下文中的ProviderManager bean。但是，如果你没有使用命名空间，那么你会这样声明:

在上面的例子中，我们有三个提供者。它们试图在顺序显示(它是通过使用一个List的暗示)，每个提供者都能尝试验证，或者通过简单的返回null跳过认证。如果所有的实现都返回null，则ProviderManager将抛出一个ProviderNotFoundException。如果你有兴趣了解更多的有关提供者，请参考ProviderManager的JavaDocs。

身份验证机，如Web表单登录处理过滤器被注入到ProviderManager的引用，将调用它来处理自己的身份验证请求。你需要的供应商有时可以与认证机制互换，而在其他时间，他们将依赖于特定的认证机制。例如，DaoAuthenticationProvider和LdapAuthenticationProvider给它提交一个简单的用户名/密码验证请求，并因此将与基于表单登录或HTTP基本验证工作的机制兼容。另一方面，一些认证机制创建只能由单一类型AuthenticationProvider解释的认证请求对象。这一方面的一个例子是JA-SIG CAS，它使用一个服务票据的概念，因此可以仅通过一个CasAuthenticationProvider进行认证。你不必太在意这一点，因为如果你忘记注册一个合适的供应商，你会简单地收到一个ProviderNotFoundException不进行认证的尝试。

本参考指南早些时候提到的，大多数的认证供应商利用的` userdetails 和 userdetailsservice 接口。回想一下，`UserDetailsService是一个方法:

返回的UserDetails是提供给getters的一个接口，以保证非空的认证信息，例如，用户名，密码，授权和用户帐户是否被启用或禁用。大多数认证供应商将使用UserDetailsService，即使用户名和密码不作为认证决定的一部分。他们可以使用返回的UserDetails对象为其GrantedAuthority信息对象，因为其他的一些系统（如LDAP或X.509或CAS等）承担了实际验证凭证的的责任。

鉴于UserDetailsService就是这么简单实现的，它应该便于用户检索使用自己选择的持久化策略的认证信息。话虽如此，Spring Security确实包括了许多有用的基本实现，我们将在下面看到。

Spring Security的 PasswordEncoder接口用于支持密码以某种方式在持久存储中进行编码。你不应该在纯文本中存储密码。总是使用单向密码算法如BCrypt使用内置的混淆值，对于每个存储的密码都是不同的。不要使用普通的哈希函数，如MD5或SHA，甚至是一个混淆的版本。BCrypt是故意设计成慢，用于阻碍离线密码破解，而标准的散列算法是快速和能轻易地被用来测试在并行密码定制的硬件上。你可能会认为这并不适用于你，因为你的密码数据库是安全的，和离线攻击不是一个风险线上的。如果是这样的话，做一些研究并阅读所有的高知名度、一直被嘲笑存储密码不安全并已妥协的网站。最好是在安全的一边。对于安全性使用org.springframework.security.crypto.bcrypt.BCryptPasswordEncoder"是一个不错的选择。在其他常见的编程语言中也有兼容的实现，所以对于互相操作性它也是一个很好的选择。

如果你使用的是已经有哈希密码的遗留系统，那么你需要使用一个解码器来匹配你当前的算法，至少要等到你可以将用户迁移到一个更安全的方案（通常这将涉及到要求用户设置一个新的密码，因为哈希值是不可逆的）。Spring Security具有包含传统的密码编码功能的实现，即org.springframework.security.authentication.encoding包。该DaoAuthenticationProvider可与新的或旧的PasswordEncoder类型注入。

Before we can use Spring Security Test support, we must perform some setup. An example can be seen below:

This is a basic example of how to setup Spring Security Test. The highlights are:

Remember we added the @PreAuthorize annotation to our HelloMessageService and so it requires an authenticated user to invoke it. If we ran the following test, we would expect the following test will pass:

The question is "How could we most easily run the test as a specific user?" The answer is to use @WithMockUser. The following test will be ran as a user with the username "user", the password "password", and the roles "ROLE_USER".

Specifically the following is true:

Our example is nice because we are able to leverage a lot of defaults. What if we wanted to run the test with a different username? The following test would run with the username "customUser". Again, the user does not need to actually exist.

We can also easily customize the roles. For example, this test will be invoked with the username "admin" and the roles "ROLE_USER" and "ROLE_ADMIN".

If we do not want the value to automatically be prefixed with ROLE_ we can leverage the authorities attribute. For example, this test will be invoked with the username "admin" and the authorities "USER" and "ADMIN".

Of course it can be a bit tedious placing the annotation on every test method. Instead, we can place the annotation at the class level and every test will use the specified user. For example, the following would run every test with a user with the username "admin", the password "password", and the roles "ROLE_USER" and "ROLE_ADMIN".

Using @WithAnonymousUser allows running as an anonymous user. This is especially convenient when you wish to run most of your tests with a specific user, but want to run a few tests as an anonymous user. For example, the following will run withMockUser1 and withMockUser2 using @WithMockUser and anonymous as an anonymous user.

While @WithMockUser is a very convenient way to get started, it may not work in all instances. For example, it is common for applications to expect that the Authentication principal be of a specific type. This is done so that the application can refer to the principal as the custom type and reduce coupling on Spring Security.

The custom principal is often times returned by a custom UserDetailsService that returns an object that implements both UserDetails and the custom type. For situations like this, it is useful to create the test user using the custom UserDetailsService. That is exactly what @WithUserDetails does.

Assuming we have a UserDetailsService exposed as a bean, the following test will be invoked with an Authentication of type UsernamePasswordAuthenticationToken and a principal that is returned from the UserDetailsService with the username of "user".

We can also customize the username used to lookup the user from our UserDetailsService. For example, this test would be executed with a principal that is returned from the UserDetailsService with the username of "customUsername".

We can also provide an explicit bean name to look up the UserDetailsService. For example, this test would look up the username of "customUsername" using the UserDetailsService with the bean name "myUserDetailsService".

Like @WithMockUser we can also place our annotation at the class level so that every test uses the same user. However unlike @WithMockUser, @WithUserDetails requires the user to exist.

We have seen that @WithMockUser is an excellent choice if we are not using a custom Authentication principal. Next we discovered that @WithUserDetails would allow us to use a custom UserDetailsService to create our Authentication principal but required the user to exist. We will now see an option that allows the most flexibility.

We can create our own annotation that uses the @WithSecurityContext to create any SecurityContext we want. For example, we might create an annotation named @WithMockCustomUser as shown below:

You can see that @WithMockCustomUser is annotated with the @WithSecurityContext annotation. This is what signals to Spring Security Test support that we intend to create a SecurityContext for the test. The @WithSecurityContext annotation requires we specify a SecurityContextFactory that will create a new SecurityContext given our @WithMockCustomUser annotation. You can find our WithMockCustomUserSecurityContextFactory implementation below:

We can now annotate a test class or a test method with our new annotation and Spring Security’s WithSecurityContextTestExecutionListener will ensure that our SecurityContext is populated appropriately.

When creating your own WithSecurityContextFactory implementations, it is nice to know that they can be annotated with standard Spring annotations. For example, the WithUserDetailsSecurityContextFactory uses the @Autowired annotation to acquire the UserDetailsService:

If you reuse the same user within your tests often, it is not ideal to have to repeatedly specify the attributes. For example, if there are many tests related to an administrative user with the username "admin" and the roles ROLE_USER and ROLE_ADMIN you would have to write:

Rather than repeating this everywhere, we can use a meta annotation. For example, we could create a meta annotation named WithMockAdmin:

Now we can use @WithMockAdmin in the same way as the more verbose @WithMockUser.

Meta annotations work with any of the testing annotations described above. For example, this means we could create a meta annotation for @WithUserDetails("admin") as well.

In order to use Spring Security with Spring MVC Test it is necessary to add the Spring Security FilterChainProxy as a Filter. It is also necessary to add Spring Security’s TestSecurityContextHolderPostProcessor to support Running as a User in Spring MVC Test with Annotations. This can be done using Spring Security’s SecurityMockMvcConfigurers.springSecurity(). For example:

Spring MVC Test provides a convenient interface called a RequestPostProcessor that can be used to modify a request. Spring Security provides a number of RequestPostProcessor implementations that make testing easier. In order to use Spring Security’s RequestPostProcessor implementations ensure the following static import is used:

Spring MVC Test also provides a RequestBuilder interface that can be used to create the MockHttpServletRequest used in your test. Spring Security provides a few RequestBuilder implementations that can be used to make testing easier. In order to use Spring Security’s RequestBuilder implementations ensure the following static import is used:

At times it is desirable to make various security related assertions about a request. To accommodate this need, Spring Security Test support implements Spring MVC Test’s ResultMatcher interface. In order to use Spring Security’s ResultMatcher implementations ensure the following static import is used:

当使用Servlet过滤器时，你显然需要声明他们的web.xml，否则将被servlet容器忽略。在Spring Security，过滤器类也都在Spring bean中定义应用上下文，从而能够利用Spring的丰富的依赖注入的设施和生命周期接口的优势。Spring的DelegatingFilterProxy提供web.xml和应用程序上下文之间的链接

当使用DelegatingFilterProxy，你会看到这样的事情在web.xml文件中:

请注意，该过滤器实际上是一个DelegatingFilterProxy，而不是类，会实现过滤器的逻辑。什么DelegatingFilterProxy所做的是通过向其从Spring应用程序上下文中的bean委托Filter的方法。这使得bean来从Spring Web应用程序上下文的生命周期支持和配置灵活性中受益。bean必须实现javax.servlet.Filter并且必须具有相同的名称，在filter-name元素。阅读DelegatingFilterProxy的Javadoc的更多信息

Spring Security的网络基础设施，只能通过委托给FilterChainProxy的一个实例使用。安全过滤器不应该由自己来使用。理论上你可以声明每个弹簧安全过滤器bean，你需要在你的应用程序的上下文文件并添加相应的DelegatingFilterProxy到web.xml每个过滤器中，确保他们正确排序，但是这是很麻烦的并且如果你有很多的过滤器会很快弄乱了web.xml文件。FilterChainProxy让我们将一个条目添加到web.xml和完全处理应用程序上下文文件来管理我们的网络安全bean。它是使用DelegatingFilterProxy连接的，就像在上面的例子，随着filter-name设为"filterChainProxy"bean的名称。然后过滤器链中声明应用程序上下文相同的bean的名称。这里有一个例子:

命名空间元素filter-chain是用来方便设置应用程序中所需的安全过滤器链。 ^[2]它映射一个特定的URL模式的从filters元素指定的bean的名字建立了过滤器列表，并结合SecurityFilterChain类型的bean。该pattern属性需要一个Ant路径和最具体的URI应该首先出现。 ^[3] 在运行时，FilterChainProxy将定位相匹配的当前Web请求，并由filters属性指定的过滤器bean列表将被应用到该请求的第一个URI模式。过滤器会按照它们定义的顺序调用，所以你必须在这是适用于一个特定的URL过滤器链的完全控制。

您可能已经注意到，我们已宣布两个SecurityContextPersistenceFilter在过滤器链（ASC的简称allowSessionCreation，SecurityContextPersistenceFilter的属性）。因为web服务从来不会在请求jsessionid，创造HttpSession表示这样的用户代理是一种浪费。如果你这需要这最大的扩展能力高容量的应用程序，我们建议您使用上面的方法。对于较小的应用程序，使用SecurityContextPersistenceFilter（其默认allowSessionCreation为true）就足够了。

需要注意的是FilterChainProxy不会调用它配置了过滤器标准过滤器生命周期方法。我们建议你使用Spring的应用程序上下文的生命周期接口作为替代，就像你对任何其他的Spring bean一样。

当我们看到如何使用命名空间配置建立网络安全,我们使用了DelegatingFilterProxy和"springSecurityFilterChain"这个名字。您现在应该能够看到，这是由FilterChainProxy的名称创建的命名空间。

过滤器链中定义的顺序是非常重要的。不论你使用的是哪一种过滤器，顺序应该如下:

Spring Security有几个方面，你已经定义模式对传入的请求，以决定该请求应如何处理测试。这发生在FilterChainProxy决定的请求应通过传递该过滤器链，也当FilterSecurityInterceptor决定哪些安全约束适用于请求。要了解什么机制和针对你定义的模式进行测试时使用什么URL值是非常重要的。

Servlet规范定义了HttpServletRequest其中有几个属性是通过getter方法访问，以及我们可能要匹配。这些都是contextPath，servletPath，pathInfo和queryString。 Spring Security唯一感兴趣的仅仅是在确保应用程序中的路径，所以contextPath被忽略。不幸的是，servlet规范并没有定义到底什么是servletPath和pathInfo的值将包含特定请求URI。例如，一个URL的每个路径段可包含参数, 定义在 RFC 2396 ^[4]. 该规范并没有明确说明是否这些都应该被包含在`servletPath和pathInfo的价值观和行为的不同servlet容器之间变化。有一种危险，当一个应用程序被部署在一个容器中，而不是从这些值中的路径参数，攻击者可以将它们添加到请求的URL,以意外导致模式匹配成功或失败。 ^[5]. 在传入的URL的其他变化也可能。它可能包含路径遍历序列（如/../）或多个斜杠（//），这也可能导致匹配失败。一些容器标准化这些之前执行servlet映射,但其他人没有。为了防止类似这些问题，FilterChainProxy采用了HttpFirewall战略，检查和包装的要求。未规范化请求默认自动拒绝和路径参数和复制斜线匹配的目的被删除。 ^[6]. 因此，至关重要的一个FilterChainProxy用于管理安全过滤器链。需要注意的是servletPath和pathInfo值由容器解码，所以你的应用程序不应该有任何有效的路径包含分号，这些部分将被删除匹配的目的。

正如上面提到的，默认的策略是使用Ant风格的路径进行匹配，这可能是大多数用户的最佳选择。该策略在使用Spring的AntPathMatcher执行对级联servletPath和pathInfo的格局不区分大小写的匹配类AntPathRequestMatcher实现，忽视了queryString。

如果由于某种原因，你需要一个更强大的匹配策略，您可以使用正则表达式。然后RegexRequestMatcher战略的实现。看到这个类的Javadoc获取更多信息。

在实践中我们建议你使用方法安全服务层,控制您的应用程序访问,并不完全依赖于在Web应用程序级别定义的安全约束的使用。URL改变,很难考虑所有可能的应用程序的URL可能支持和如何处理请求。你应该尝试限制自己使用一些简单的容易理解的路径。总是试图用"deny-by-default"的方法,全方位通配符( / or ) 定义和拒绝访问。

安全在服务层定义更健壮且难以绕过,所以你应该利用Spring Security的方法安全选项。

如果您使用的过滤器也基于其他一些框架，那么你需要确保Spring Security过滤器是第一位的。这使得SecurityContextHolder到时由其他过滤器被填充以供使用。例子是使用SiteMesh的来装饰您的网页或类似Wicket的Web框架，它使用一个过滤器来处理其请求。

正如我们在命名空间章节前面所看到的，它可以使用多个http元素来定义不同的URL模式来进行不同的安全配置。每个元素创建内部FilterChainProxy内的过滤器链和应该映射的URL模式。这些元素将声明它们的添加顺序，所以最具体的模式必须再次先声明。这里的另一个例子，与上面有一个类似的情况，在应用程序支持一个无国籍的RESTful API和一个正常的网络应用，用户可以登录使用的一种形式。

我们已经看到了 FilterSecurityInterceptor简要讨论访问控制 ，我们已经与其中<intercept-url>元素相结合，在内部配置的命名空间中使用它。现在，我们将看到如何明确将其FilterChainProxy其配置为使用，其配套过滤器ExceptionTranslationFilter一起。典型的配置示例如下所示:

FilterSecurityInterceptor负责处理HTTP资源的安全性。它需要一个AuthenticationManager和AccessDecisionManager参考。它也有提供适用于不同的HTTP URL请求的配置属性。回头参考技术介绍中这些原始的讨论。

在FilterSecurityInterceptor配置属性可以两种方式进行配置。上面显示的第一个，使用<filter-security-metadata-source>命名空间元素。这类似于<http>元素的命名空间，但 <intercept-url>的子元素只使用pattern和 access的属性。使用逗号分隔不同的配置属性,适用于每个HTTP URL。第二个选择是编写自己的‘SecurityMetadataSource’,但这超出了本文的范围。不管采用哪种方式，在SecurityMetadataSource负责返回一个List<ConfigAttribute>包含所有用一个安全的HTTP URL相关联的配置属性。

应当指出的是，FilterSecurityInterceptor.setSecurityMetadataSource（）方法实际上是FilterInvocationSecurityMetadataSource的一个实例。这是一个标记接口，它的子类是SecurityMetadataSource。它只是表示SecurityMetadataSource明白FilterInvocation。在简单的利益，我们将继续参考FilterInvocationSecurityMetadataSource作为SecurityMetadataSource，因为区别是无关紧要大多数用户。为了简单起见，我们将继续参考FilterInvocationSecurityMetadataSource作为SecurityMetadataSource，因为对于大多数用户区别是无关紧要。

通过命名空间的语法创建的SecurityMetadataSource获得通过匹配在配置的pattern属性请求的URL特定FilterInvocation配置属性。这表现在，它确实为命名空间配置相同的方式。默认的是处理所有表达式作为Apache Ant的路径和正则表达式还支持更复杂的情况。request-matcher属性用于指定模式的类型被使用。它是不可能的相同的定义内混合表达式语法。作为一个例子，使用正则表达式，而不是Ant paths的先前的配置将按如下表示:

模式总是按照它们被定义的顺序进行。因此，重要的是，更具体的模式被定义在列表中比不太具体的模式更高。这是反映在我们的例子上面，在更具体的/secure/super/模式似乎比/secure/模式更高。如果它们被逆转，/secure/模式会一直匹配，并且/secure/super/模式将永远不会被评估。

该ExceptionTranslationFilter在FilterSecurityInterceptor安全过滤器堆栈的上面。它没有做任何实际的安全执法本身，而是处理由安全拦截器抛出的异常，并提供合适的HTTP响应。

我们涵盖所有重要的过滤器在技术概述这一章，所以你可能想在这一点上重新阅读该部分。让我们先来看看，你会如何配置它与一个FilterChainProxy使用。一个基本的配置只需要bean本身。

正如我们之前看到的,这个过滤器有两个主要的任务。它负责存储` securitycontext 内容之间的HTTP请求和当请求完成结算 securitycontextholder`。清除ThreadLocal其中存储的上下文是必不可少的，因为它可能会以其他方式可能是一个线程被替换成servlet容器的线程池，仍连接一个特定的用户的安全上下文。这个线程可能在稍后的阶段中使用，与错误的凭证执行操作。

我们现在看到的三个主要的过滤器总是存在在一个Spring Security web配置。这些也都是这是由命名空间<http>元素自动创建，并且不能被替代被取代的三种。现在唯一缺少的是一个实际的认证机制，而这将允许用户进行身份验证。该过滤器是最常用的身份验证过滤器，也是最常用的一种认证过滤器 ^[9]. 另外，它还提供了<form-login>元素的命名空间的实现。有三个阶段需要进行配置。

登录表单包含username和password输入字段，并发布到由过滤器（默认情况下这是/login）监测的URL。基本的过滤器配置看起来是这样的：

以下部分将介绍Servlet 3集成Spring Security的方法。

以下部分描述了Servlet3.1与Spring Security集成的方法。

BasicAuthenticationFilter负责处理HTTP头部中的基本认证证书。这可以用于验证由Spring远程协议(如Hessian和Burlap)的呼叫以及正常的浏览器的用户代理（如Firefox和Internet Explorer）。 HTTP基本认证的标准是由RFC 1945，第11条规定，以及BasicAuthenticationFilter符合这个RFC。基本身份验证是一个有吸引力的认证方法，因为它是非常广泛的，部署在用户代理和实施是非常简单的（它只是一个用户名的Base64编码:密码，在HTTP头中指定）。

DigestAuthenticationFilter能够消化处理HTTP头部中的认证证书。摘要式身份验证试图解决许多基本身份验证的弱点，特别是保证凭据从不通过线路明文形式发送。许多用户支持摘要式身份验证，包括Firefox和Internet Explorer。标准管理HTTP摘要认证由RFC 2617定义,更新摘要式身份验证的一个早期版本由RFC 2069标准规定。大多数用户代理实现RFC 2617。Spring Security的DigestAuthenticationFilter兼容“auth”质量认证的保护(qop)规定的RFC 2617,这也与RFC 2069提供向后兼容性。摘要式身份验证是一个更有吸引力的选择,如果您需要使用未加密的HTTP(即没有TLS / HTTPS)并希望最大化安全的身份验证过程。事实上WebDAV协议摘要式身份验证是一个强制性的要求,指出由RFC 2518 17.1节可见。

摘要式身份验证的核心是一个"nonce"。这是一个服务器生成的值。Spring Security nonce采用以下格式:

DigestAuthenticatonEntryPoint有一个属性指定用于生成nonce令牌的key,以及nonceValiditySeconds属性确定过期时间(默认300,等于5分钟)。只要nonce是有效的，摘要就会通过串联字符串包括用户名，密码，随机数，被请求的URI，一个客户端产生的随机数（仅该用户代理每个请求生成一个随机值），域名等，然后执行MD5哈希值。如果他们不同意一个包含值(如密码),服务器和用户代理执行此计算消化,就会导致不同的哈希码。在Spring Security实现中，如果服务器生成的nonce已经过期（但是摘要还是有效），在DigestAuthenticationEntryPoint将发送一个"stale=true"头。这告诉用户代理没有必要打扰用户（如用户名和密码等是正确的），而只是采用了全新的随机数再试一次。

对于DigestAuthenticationEntryPoint的参数nonceValiditySeconds而言一个适当的值取决于您的应用程序。非常安全的应用程序应该注意一个拦截认证头可以用来模拟本体，直到expirationTime中包含的特定场合。这是关键的原则，选择适当的设置，但它是不寻常的，非常安全的应用程序不能运行在第一个实例的TLS/HTTPS。

因为摘要式身份验证的更复杂的实现，经常有用户代理的问题。例如，IE不能在同一个会话的请求提出了一个“opaque”令牌。因此Spring Security封装了所有状态信息进入到“nonce”令牌中。在我们的测试中,Spring Security的实现与FireFox和ie能可靠地工作,正确处理nonce超时等。

Remember-me或persistent-login身份验证是指网站能够记住一个主体的身份之间的会话。这通常是通过发送cookie给浏览器，以及在未来的会话中发现的cookie，并进行自动登录发生完成的。Spring Security提供了这些操作发生的必要的挂钩，并有两个具体的remember-me实现。其中一个使用散列来保护基于cookie标记的安全性，另一个使用了数据库或其他持久化存储机制来保存生成的标记。

注意，所有实现都需要一个UserDetailsService。如果您正在使用身份验证提供者不使用UserDetailsService(例如,LDAP提供者),那么它不会工作,除非你也有一个UserDetailsService应用程序上下文中的bean。

这种方法使用散列来完成remember-me策略。本质上一个cookie发送到浏览器交互验证成功后,使用的cookie组成结构如下：

因此，remember-me的令牌在指定的期间是有效的，提供的用户名，密码和密钥不会改变。值得注意的是，这有一个潜在的安全问题，任何用户代理在remember-me令牌到期之前捕获到它，令牌将是可用的。这与摘要式身份验证问题是同样的问题。如果本人知道令牌已被抓获，他们可以轻松地更改他们的密码，并立即注销所有的remember-me标记。如果需要更显著的安全性，你应该使用在下一节中描述的方法。另外记得remember-me服务根本不应该被使用。

如果你熟悉在namespace configuration命名空间配置这一章中讨论的主题，你可以启用remember-me认证只需添加<remember-me>元素:

UserDetailsService一般会自动选择。如果你有一个以上的应用环境，你需要指定哪一个应该使用user-service-ref属性，其中的值在你的UserDetailsService bean的名称中设置。

这种方法是基于文章 http://jaspan.com/improved_persistent_login_cookie_best_practice 有一些小的修改 ^[12]. 若要使用命名空间配置的这种方法，你应该提供一个数据源引用:

数据库应该包含一个persistent_logins表,使用以下SQL创建(或同等的):

Remember-me是用于 UsernamePasswordAuthenticationFilter,并通过AbstractAuthenticationProcessingFilter超类的钩子实现。 它也被运用在BasicAuthenticationFilter. 钩子会在合适的时候调用一个具体RememberMeServices。 该接口看起来像这样:

请参考JavaDocs获得什么方法都做了更充分的讨论，不过注意在这个阶段，AbstractAuthenticationProcessingFilter仅调用loginFail（）和loginSuccess（）方法。当SecurityContextHolder 不包含 Authentication时autoLogin()方法被RememberMeAuthenticationFilter调用。因此，此接口提供了基本的remember-me的实现与认证相关的事件的充分通知，和代表的执行情况时，一个候选Web请求可能包含一个cookie并希望被记住。这种设计允许任何数目的remember-me实现策略。我们已经看到上面Spring Security提供两种实现方法。我们来看看这些。

在我们讨论Spring Security如何保护应用程序不受CSRF攻击之前，我们将解释什么是CSRF攻击。让我们来看一个具体的例子来更好地理解。

假设你的银行网站提供允许从当前登录的用户转移钱转到另一个银行账户的形式。例如，HTTP请求可能看起来像:

现在假装你身份验证你的银行网站，然后再不注销，请访问一个恶意的网站。恶意的网站包含以下形式的HTML页面:

你想赢钱,所以你点击submit按钮。在这个过程中，你无意中转移$100到恶意用户。这是因为，虽然恶意的网站不能看到你的cookies，与银行相关的cookies仍然与请求一起发送。

最糟糕的是，这整个过程可能已经使用JavaScript自动化。这意味着你甚至没有需要点击的按钮。那么我们该如何保护自己免受此类攻击?

问题是，从银行网站上的HTTP请求，和从恶意的网站的要求是完全一样的。这就意味着没有办法拒绝来自恶意的网站的请求,允许请求来自银行的网站。为了抵御CSRF攻击我们需要确保请求中有一些恶意的网站是无法提供的。

一种解决方案是使用 同步器标记模式. 这个解决方案是保证每个请求除了需要我们的会话cookie，还用随机生成的令牌作为HTTP参数。提交一个请求时,服务器必须查找参数和比较它的期望值和实际值的请求。如果值不匹配,请求失败。

我们可以轻松的预期，只要更新每个HTTP请求的令牌。这样做可以安全地自同源策略保证了恶意的网站无法读取响应。此外，我们不希望包括HTTP GET随机令牌，因为这可能会导致标记被泄露。

让我们来看看我们的例子将如何改变。假定随机产生的标记存在于一个HTTP参数name_csrf。例如，要转账的要求是这样的:

你会注意到，我们添加了_csrf参数的随机值。现在，恶意网站将无法猜测_csrf参数(必须提供明确的恶意网站)，当服务器将实际的令牌与预期的令牌进行比较时，传输将失败。

什么时候应该使用CSRF保护？我们的建议是使用CSRF保护，可以通过浏览器处理普通用户的任何请求。如果你只是创建一个非浏览器客户端使用的服务,你可能会想要禁用CSRF保护。

那么，什么是必要的，使用Spring Security来保护我们的网站不受CSRF攻击的步骤是什么？使用Spring Security的CSRF保护的步骤如下所述:

在实现CSRF时有几个注意事项.

Spring Security的目标是提供默认值,保护用户免受攻击。这并不意味着你被迫接受所有的默认设置。

例如，您可以提供一个自定义CsrfTokenRepository覆盖其中CSRF Token的存储方式。

您还可以指定一个自定义RequestMatcher确定哪些请求受CSRF保护(即也许你不在乎注销是利用)。简而言之,如果Spring Security CSRF保护没有做出你想要的,你可以自定义行为。 请参阅 <csrf>将添加元素文档的细节如何自定义使用XML和CsrfConfigurer javadoc,了解如何使用Java配置将这些自定义设置。

Spring Security允许用户轻松地注入的默认安全标头来帮助保护他们的应用程序。Spring Security默认是包括以下头部:

有关这些标题的更多详细信息，请参见相应的章节:

而这些头文件被认为是最佳方法,应该注意的是,并不是所有的客户端利用头部,所以鼓励进行额外的测试。

您可以自定义特定的头文件。 例如,假设希望你的HTTP响应头部为以下的样子:

具体而言，你希望自定义所有的默认标题与下列:

你可以很容易地用下面的Java配置做到这一点:

另外，如果你正在使用Spring Security的XML配置，你可以使用下面的:

如果你不想要添加默认值,需要明确控制应该使用什么,您可以禁用默认值。一个例子提供了Java和基于XML的配置:

如果您正在使用Spring安全的Java配置以下只会增加 Cache Control.

下面的XML只会增加Cache Control.

如果有必要,你可以禁用所有的HTTP安全响应头下面的Java配置:

如果有必要,你可以禁用所有的HTTP安全响应头下面的XML配置:

Spring安全机制,使它更加方便的将共同安全头添加到您的应用程序。并且,它还提供了钩子,能够添加自定义头部。

SessionManagementFilter检测 SecurityContextRepository的内容违背了现在SecurityContextHolder的内容来决定是否在当前请求用户已经通过身份验证，通常由一个非交互式的身份验证机制，如验证或记脚注:[身份验证机制验证后进行重定向（例如form-login）将不会被SessionManagementFilter检测到，过滤器将不调用身份验证请求，会话管理功能必须在这些情况下分别处理].如果存储库包含一个安全文档，过滤器什么都不做，如果这没有这么做，局部线程SecurityContext包含了一个（不是匿名）Authentication对象.

如果用户当前没有经过身份验证,过滤器将检查是否一个无效的请求会话ID（例如由于超时），并将调用InvalidSessionStrategy的配置，如果一个被设置了.最通常的行为是重定向到一个固定的URL，这是将实现SimpleRedirectInvalidSessionStrategy进行实施.无效的会话时后者也会使用当通过命名空间配置.as described earlier.

SessionAuthenticationStrategy通过SessionManagementFilter 和AbstractAuthenticationProcessingFilter被利用，所以如果你利用了一个定制的form-login例如，你将需要把它注入到这两个，在这种情况下，一个典型的配置，结合命名空间和自定义的beans可能看起来像这样 ：

注意默认的使用，SessionFixationProtectionStrategy可能会导致问题，如果你是存储在session中的bean实施HttpSessionBindingListener，包括Spring session-scoped beans，看这个类中的javadoc寻找更多信息.

Spring Security能防止主体同时访问同一应用程序的多个指定的次数，许多软件公司利用这一强制许可.虽然网络管理员喜欢这个功能，因为它有助于防止人们共享登录名.例如你能停止"Batman"用户从两个不同的会话登录到Web应用程序 ，您可以终止他们的以前的登录，或者当他们尝试再次登录时，你可以报告一个错误 ，预防第二次登陆，请注意，如果您使用的第二种方法，一个没有显式退出的用户（例如谁刚刚关闭了浏览器）将无法再次登录，直到他们的原始会话过期.

并发控制是由命名空间支持的，所以请检查早期的命名空间章节的最简单的配置。虽然有时你需要自定义的东西。

该实现使用了一个SessionAuthenticationStrategy的专门的版本，叫做ConcurrentSessionControlAuthenticationStrategy.

要使用并发会话支持，您需要添加以下 web.xml:

除此之外，你将需要添加ConcurrentSessionFilter 到你的FilterChainProxy.ConcurrentSessionFilter要求两个属性，sessionRegistry一般是指一个SessionRegistryImpl的实例，expiredUrl指向页面时显示会话已过期的页面，一个配置利用命名空间去创建FilterChainProxy和不符合要求的beans如下:

每一次HttpSession开始或者结束,添加一个监听到web.xml 导致一个ApplicationEvent被发布到Spring ApplicationContext.这很关键，因为当一个会话结束时这个允许SessionRegistryImpl被通知，即使他们退出了另一个会话或它超时.

采取 "deny-by-default"在您显式指定什么是允许和禁止一切，它通常被认为是良好的安全实践.定义什么是未经身份验证的用户访问的是一个类似的情况,特别是用于Web应用程序.许多网站要求用户必须对其他比一些网址的任何东西进行身份验证(例如，主界面和登录页面).在这种情况下，它是最简单的定义访问这些特定的网址的访问配置属性，而不是为每一个安全的资源.不同的,在默认情况下` role_something `要求很好说，但有时候也有例外.例如一个应用的登陆，注销，和主页面.你也可以从过滤器链完全忽略这些页面,从而绕过访问控制检查,但这可能是不受欢迎的其他原因,特别是如果经过身份验证的用户的页面的行为会有所不同.

这就是我们所说的匿名身份验证，请注意,没有真正的概念区别用户"anonymously authenticated"和未经过身份验证的用户.Spring Security的匿名身份验证只给您一个更加方便的方式来配置您的访问控制属性.如getCallerPrincipal调用servlet API，仍将返回null,尽管实际上SecurityContextHolder中的一个匿名认证对象.

还有其他的匿名身份验证的情况下是有用的,例如，当一个审计拦截器查询SecurityContextHolder来识别哪个主要是负责一个给定的操作.类可以创建更强劲,如果他们知道SecurityContextHolder总是包含一个“身份验证”对象,而且从不null.

匿名认证提供支持自动使用HTTP配置Spring Security 3时可定制（或禁用）使用<anonymous>元元素.您不需要配置这里所描述的beans，除非你使用传统的bean配置.

三个类 一起提供匿名身份验证功能.AnonymousAuthenticationToken 是一个实现 Authentication ,商店的` GrantedAuthority 适用于匿名委托,有相应的 anonymousauthenticationprovider ,这是链接到 providermanager ,以至于 `AnonymousAuthenticationToken能接受.最后，有一个` anonymousauthenticationfilter ，这是把正常的认证机制后，自动添加一个 anonymousauthenticationtoken 的 securitycontextholder `,如果没有现有的身份验证在那里举行.筛选器和身份验证提供程序的定义如下 :

在筛选器和身份验证提供程序之间共享“key”,使前者所创建的符号被后者的脚注所接受[ key属性的使用不应被视为在这里提供任何真正的安全性.它仅仅是一个簿记锻炼, 如果你是共享一个` providermanager 包含 anonymousauthenticationprovider ,在这样的情形下，它是可能的认证客户端构建`Authentication对象(如RMI调用),然后，一个恶意的客户端可以提交一个` anonymousauthenticationtoken ，它创造了自己 (选择的用户名和权限列表 ).如果`key是人或能被发现，然后代表将被匿名者接受，这不是正常使用的问题，但如果你使用RMI你最好使用一个定制的没有匿名的` providermanager 提供者而不是分享你使用HTTP认证机制. ]. ` userattribute `表达的形式 usernameintheauthenticationtoken，授予权威,这是相同的语法使用等号后的`InMemoryDaoImpl的`userMap”属性.

如前所述,匿名身份验证的好处是,所有URI模式可以安全应用。例如

排在匿名身份验证讨论是AuthenticationTrustResolver界面,与相应的AuthenticationTrustResolverImpl实现.这个接口提供了一个isAnonymous(Authentication)的方法,感兴趣的类可以考虑这种特殊类型的身份验证状态.ExceptionTranslationFilter使用这个接口在处理AccessDeniedException,如果抛出AccessDeniedException ,和一个匿名类型的身份验证,而不是扔403(禁止)的反应,过滤器将开始` authenticationentrypoint 所以可以验证正确.这是一个必要的区别,否则，负责将永远被视为"authenticated"，并没有得到一个机会通过表格登录,基本、摘要或其他一些正常的身份验证机制。你会经常看到 role_anonymous 属性在上述拦截器配置更换 is_authenticated_anonymously ，这实际上是一样的定义访问控制,这是一个例子，使用的 authenticatedvoter 我们将看到在authorization chapter.它使用一个 authenticationtrustresolver 处理这个特定的配置属性和访问权限授予匿名用户.它使用一个 authenticationtrustresolver 处理这个特定的配置属性和访问权限授予匿名用户. authenticatedvoter 方法更强大，因为它允许你区分匿名,请记住我和完全身份验证的用户.如果你不需要这个功能,然后你可以坚持`ROLE_ANONYMOUS,这将是由Spring Security的标准` rolevoter `.

Spring Security 4.0 has introduced authorization support for WebSockets through the Spring Messaging abstraction. To configure authorization using Java Configuration, simply extend the AbstractSecurityWebSocketMessageBrokerConfigurer and configure the MessageSecurityMetadataSourceRegistry. For example:

This will ensure that:

Spring Security also provides XML Namespace support for securing WebSockets. A comparable XML based configuration looks like the following:

This will ensure that:

WebSockets reuse the same authentication information that is found in the HTTP request when the WebSocket connection was made. This means that the Principal on the HttpServletRequest will be handed off to WebSockets. If you are using Spring Security, the Principal on the HttpServletRequest is overridden automatically.

More concretely, to ensure a user has authenticated to your WebSocket application, all that is necessary is to ensure that you setup Spring Security to authenticate your HTTP based web application.

Spring Security 4.0 has introduced authorization support for WebSockets through the Spring Messaging abstraction. To configure authorization using Java Configuration, simply extend the AbstractSecurityWebSocketMessageBrokerConfigurer and configure the MessageSecurityMetadataSourceRegistry. For example:

This will ensure that:

Spring Security also provides XML Namespace support for securing WebSockets. A comparable XML based configuration looks like the following:

This will ensure that:

It is important to emphasize that the browser does not enforce the Same Origin Policy for WebSocket connections. This is an extremely important consideration.

SockJS provides fallback transports to support older browsers. When using the fallback options we need to relax a few security constraints to allow SockJS to work with Spring Security.

正如我们在<<技术授予权，技术综述 >>所看到，所有的Authentication实现存储的列表GrantedAuthority对象.这些代表已被授予主要的的当局. GrantedAuthority对象是由` authenticationManager 插入到`Authentication 对象，然后读取 AccessDecisionManager做出判断.

GrantedAuthority是一个只有一个方法的接口

这个方法允许AccessDecisionManager 来判断得到一个精确的String表示的` GrantedAuthority .通过返回一个表示作为一个`String,一个` GrantedAuthority 可以很容易的通过`AccessDecisionManager 来read,如果一个` GrantedAuthority 不能精确地表示为一个`String,` GrantedAuthority 将会被认为是"complex"和`getAuthority() 必须返回为null.

"complex" GrantedAuthority的一个将一个应用于不同客户帐户号码的操作和权限阈值的列表的实现例子.代表这个复杂的` GrantedAuthority 作为`String将是相当困难的，作为一个结果，` getauthority() 方法应该返回`null.这将对任何` accessDecisionManager 表明它需要明确的支持 GrantedAuthority `实施以了解其内容.

Spring Security包括一个具体的` GrantedAuthority 实施， grantedauthorityimpl .这允许用户指定的任何String转换成一种` GrantedAuthority .所有的 AuthenticationProvider 的包括与安全架构使用 grantedauthorityimpl`填充Authentication对象.

正如我们在<<安全对象、技术综述>>章节中也看到过的,Spring Security,提供拦截控制访问安全对象如方法调用或Web请求。是否允许进行调用前调用的决定是由`AccessDecisionManager `作出判断.

` accessDecisionManager 被 abstractsecurityinterceptor 和负责制定最终的访问控制决策.`AccessDecisionManager接口包含三种方法:

AccessDecisionManager的decide方法传递了它所需要的所有相关信息，以作出授权决策.尤其,通过安全的“对象”，使这些参数包含在实际的安全对象调用中进行检查.例如,让我们假设安全对象是一个MethodInvocation `资料，这将是很容易实现`MethodInvocation对于任何Customer论点.然后执行某种安全逻辑判断、来确保AccessDecisionManager `主允许对客户操作.如果访问被拒绝并抛出`AccessDeniedException 我们的预期就实现了.

如果` accessDecisionManager 可以处理通过 configattribute ,`supports(ConfigAttribute)方法由AbstractSecurityInterceptor 在决定启动时候命名. supports(Class) 方法被安全拦截器实现，确保配置` accessDecisionManager `支持类型的安全对象的被拦截.

而“AccessDecisionManager”是由“AbstractSecurityInterceptor”在继续之前调用安全对象调用.某些应用程序需要一种方法修改对象的实际安全返回的对象调用.同时您可以很容易地实现自己的AOP实现这一担忧, Spring Security提供了一个方便的钩,几个集成ACL的功能的具体实现.

After Invocation Implementation说明了Spring Security的AfterInvocationManager 以及这个具体实现.

像Spring Security的其他部分，AfterInvocationManager 有一个具体的实现，AfterInvocationProviderManager调查AfterInvocationProvider的表，每一个AfterInvocationProvider允许修改返回对象或抛出AccessDeniedException.的确多个提供者可以修改对象,如之前的供应商的结果传递给下一个列表中.

请注意,如果您正在使用AfterInvocationManager,你仍然需要配置属性,使MethodSecurityInterceptor的AccessDecisionManager允许一个操作.如果您使用的是典型的Spring Security包括“AccessDecisionManager”实现,没有配置属性定义为一个特定的安全方法调用将导致每个“AccessDecisionVoter”投弃权票,相反,如果AccessDecisionManager 性能 “allow IfAllAbstainDecisions”是false就会抛出一个 AccessDeniedException，你可以通过设置“allowIfAllAbstainDecisions”避免这种潜在的问题改变为true（虽然这是一般不推荐），或者（ii）只是确保至少有一个配置属性,一个“AccessDecisionVoter”将投票授权访问，后者(推荐)的方法通常是通过“ROLE_USER”或“ROLE_AUTHENTICATED”配置属性.

它是一个共同的要求，一个特定的应用程序中的角色应该自动"include"其他角色,例如，在一个应用程序中有一个"admin" 和"user"的角色的概念,你可能希望一个管理员能够尽一切正常的用户可以。要做到这一点，你可以确保所有的管理用户也被分配到"user"的角色.另外，您可以修改每一个访问约束，这需要"user"的角色，还包括"admin"的作用.这可能会变得相当复杂，如果你有很多不同的角色在你的应用程序.

使用角色层次结构允许您配置哪些角色（或主管）应包括其他角色（或主管部门）.一个额外的of Spring Security’s RoleVoter的版本，RoleHierarchyVoter配置了一个` rolehierarchy `，从它获得所有的"reachable authorities"，用户被分配。一个典型的配置可能看起来像这样：

在这里，我们有四个角色在一个层次结构 ROLE_ADMIN ⇒ ROLE_STAFF ⇒ ROLE_USER ⇒ ROLE_GUEST.通过身份验证的用户ROLE_ADMIN, 要表现得好像他们所有的四种角色在安全约束的评价与判断,要表现得好像他们所有的四种角色在安全约束的评价与判断,AccessDecisionManager 配置上述RoleHierarchyVoter.>符号可以被认为是意义的"includes".

角色层次结构提供了一个方便的方法简化了您的应用程序的访问控制配置数据和/或减少您需要分配给用户的权限数.对于更复杂的要求，您可能希望定义您的应用程序所需的特定访问权限和被分配给用户的角色之间的逻辑映射，在加载用户信息时将两者翻译成两者之间的关系.

方法在执行安全使用` methodsecurityinterceptor ,这是一个固定的`MethodInvocation .根据配置的方法，一个拦截可能是特定的一个单一的bean或多个beans之间的共享.拦截器使用` methodsecuritymetadatasource 实例获取配置属性，适用于一个特定的方法调用.`MapBasedMethodSecurityMetadataSource用于存储配置属性的键控的方法名称（可以使用通配符），将在内部使用时，这些属性定义在应用程序的上下文中使用的<intercept-methods>拦截或<protect-point>元素。

当然你可以使用一个Spring AOP的代理机制配置一个` methodsecurityiterceptor `直接应用程序上下文中:

AspectJ的安全拦截器是AOP联盟安全拦截器在上一节讨论非常相似。事实上，我们将只讨论在这一部分的差异.

AspectJ拦截器被命名为 AspectJSecurityInterceptor.不像AOP联盟安全拦截器，它依赖于Spring应用程序上下文编织的安全拦截器通过代理,AspectJSecurityInterceptor是基于AspectJ编译器.不会罕见的在同一个程序中使用的两种安全拦截器,与AspectJSecurityInterceptor用于域对象实例安全,AOP联盟` methodsecurityinterceptor `用于服务层安全.

让我们首先考虑的是如何AspectJSecurityInterceptor配置在Spring应用程序上下文：

正如你所看到的，除了类名称，AspectJSecurityInterceptor是完全一样的AOP联盟安全拦截器.事实上，两个拦截器可以共享相同的` securitymetadatasource ,作为 securitymetadatasource 作品 `java.lang.reflect.Method而不是AOP库类。当然,你访问的决定获得有关特定AOP库调用（即` MethodInvocation 或`JoinPoint），这样可以使访问的决定时，考虑的范围之外的标准（如方法的参数）.

下次你需要定义一个AspectJ aspect.例如:

在上面的例子中，安全拦截器将被应用到每一个实例` persistableentity ，这是一个抽象类没有显示（你可以使用任何其他类或`pointcut表达你喜欢）.对于那些好奇的人，` aspectjcallback 是因为 proceed()；声明具有特殊的意义只有在 around() 体。当它想要的目标继续,`AspectJSecurityInterceptor 调用这个匿名` aspectjcallback `类.

你需要配置Spring 负载方面和连接AspectJSecurityInterceptor。一个实现这一的bean声明如下所示：

是这么回事！现在你可以从你的应用程序中的任何地方创建你的豆子，使用任何你认为合适的方式(eg new Person();)他们会拥有安全拦截器的应用

Spring Security 使用Spring EL来支持，你应该看看如何，如果你有兴趣在更深入了解主题。表达式是用"root object" 评估的，作为评价上下文的一部分。Spring Security使用特定的类用于Web和方法安全作为根对象，以提供内置表达式和访问当前主体的值等.

使用表达式来保护个人网址,首先需要设置“use-expressions”属性的< http >为true.Spring Security预期的“访问”属性的< intercept-url >元素包含Spring EL表达式。一个布尔表达式应该评估,定义是否应该允许访问. 例如:

这里我们定义了应用程序的“admin”区域(定义的URL模式)只能提供给用户授予机关“admin”,其IP地址匹配本地子网.在前一节中我们已经看到内置hasRole表达式。表达“hasIpAddress”是另一个内置的表达式是特定于网络安全.这由WebSecurityExpressionRoot下定义，一个实例时用作表达式根对象评估web访问表达式。这个对象也直接暴露的HttpServletRequest对象的名字“请求”,这样你就可以直接调用请求在一个表达式。如果正在使用表情,“WebExpressionVoter”将被添加到“AccessDecisionManager”所使用的名称空间. 如果你不使用名称空间和想使用表情,你必须添加一个配置.

方法安全性是一个更复杂的比一个简单的规则允许或拒绝，Spring Security 3.0介绍了一些新的注释,以便全面支持表达式的使用.

复杂的应用需要的往往不是简单的得到在web请求或方法调用级别来定义访问权限。而是，安全决议需要包括谁（认证），其中（的MethodInvocation）和什么（一些领域对象）。换句话说，授权决策还需要考虑一个方法调用的实际域对象实例的主题。

想象你正在设计申请宠物诊所。将会有两个主要基于spring的应用程序的用户组:宠物诊所的工作人员,以及宠物诊所的客户。员工将获得的所有数据,而你的客户只能看到自己的客户记录。使它更有趣,你的客户可以让其他用户看到他们的客户记录,例如"puppy preschool"的导师或当地的"Pony Club"的总统。使用Spring安全为基础,有几种方法可以使用:

每一个这些方法是完全合法的。然而,第一对授权检查你的业务代码。主要问题包括增强的困难的单元测试和重用会更困难的Customer授权逻辑。获得“GrantedAuthority[]的从Authentication对象也很好,但不会扩展到大量的Customer。如果用户可以访问5000`Customer`(不可能在这种情况下,但试想一下,如果它是一个受欢迎的兽医大小马俱乐部!)所需的内存消耗和时间来构造对象将是不受欢迎的Authentication。最后的方法,直接从外部代码打开Customer,可能是最好的三个。实现关注点分离,不滥用内存或CPU周期,但它仍然是低效的,“AccessDecisionVoter”和最终的商业方法本身将执行调用DAO负责检索AccessDecisionVoter对象。两个访问每个方法调用显然是不可取的。此外,每个方法列出你需要编写自己的访问控制列表(ACL)从头持久性和业务逻辑.

幸运的是,还有另一个选择,我们下面会讲到.

Spring Security的ACL服务运送spring-security-acl-xxx.jar.您需要将这个JAR添加到类路径中使用Spring安全域对象实例的安全功能.

Spring Security的域对象实例的安全能力中心的概念一个访问控制列表(ACL)。每个域对象实例系统中有自己的ACL,和ACL记录的细节,谁能和不能使用域对象。有鉴于此,Spring Security提供三个主要ACL-related功能应用程序:

第一个要点,Spring Security ACL的的一个主要功能模块提供了一个高性能的方式检索ACL。这个ACL库能力是极其重要的,因为每一个域对象实例系统中可能有多个访问控制条目,并且每个ACL可能继承其他树形结构中的ACL(这是开箱即用的支持由Spring Security,非常常用)。Spring Security的ACL能力都是被仔细设计以提供高性能检索ACL,加上可插入的缓存,deadlock-minimizing数据库更新、独立于ORM框架(我们直接使用JDBC),适当的封装,和透明的数据库更新.

给定数据库ACL的操作模块的核心,让我们探索使用四个主要表的默认实现。下面表的大小在一个典型的Spring Security ACL部署,最后列出的表行:

*最后,ACL_ENTRY存储个人权限分配给每个收件人。ACL_OBJECT_IDENTITY列包括一个外键,收件人ACL_SID(外键),是否我们将审计,整数位屏蔽代表实际的权限被授予或拒绝。我们为每个收件人接收一行允许使用一个域对象.

如最后一段中所述,ACL系统使用整数位屏蔽。别担心,你不需要知道的细微之处,转向使用ACL系统,但是我想说的是,我们有32位我们可以打开或关闭。每一个位代表一个许可,并默认权限阅读(0),写(1),创建(2)、删除(第3位)和管理(4)。很容易实现自己的“许可”实例如果你希望使用其他权限,和其余的ACL框架将没有知识的扩展.

重要的是要理解,域对象的数量在系统完全没有影响我们选择使用整数位屏蔽。虽然你有32位用于权限,你可以有数十亿的域对象实例(这将意味着数十亿行ACL_OBJECT_IDENTITY而且很可能ACL_ENTRY)。我们这一点,因为我们发现有时人们错误地认为他们需要一点对于每一个可能的域对象,这并非如此.

现在我们已经提供了一个基本的概述ACL系统做什么,看起来在一个表结构,让我们探索的关键接口。关键接口:

请注意我们的开箱即用的AclService和相关数据库类都使用ANSI SQL.这是主要的数据库.在写这篇文章的时候,系统已经成功测试了使用超音速SQL,PostgreSQL,Microsoft SQL Server和Oracle.

两个样本船与演示Spring Security ACL模块。第一个是联系人样本,另一个是文档管理系统(DMS)样本。我们建议采取一看这些例子.

要开始使用Spring Security ACL的功能,你需要你的ACL信息存储在某个地方。这需要实例化的DataSource使用Spring。DataSource然后注入JdbcMutableAclService和BasicLookupStrategy 实例。后者提供高性能的ACL检索功能,和前提供增变基因功能。指的一个样本船与Spring Security配置的一个示例。您还需要用四个ACL-specific填充数据库表中列出的最后一部分(参见ACL样本的适当的SQL语句).

一旦您创建了所需的模式和实例化JdbcMutableAclService,接下来将需要确保您的域模型支持互操作性的Spring Security ACL包。希望ObjectIdentityImpl 将是足够的,因为它提供了大量的方法可以使用它。大部分人都有包含 public Serializable getId()的方法。如果返回类型是长,或兼容长(例如int),你会发现你不需要提供进一步的考虑ObjectIdentity问题。许多地方的ACL模块依赖长标识符。如果你不使用长(或int,字节等),有一个非常好的机会你需要重新实现的类。我们不打算支持非long标识符在Spring Security的ACL模块,多头已经兼容所有数据库序列,最常见的标识符的数据类型和长度足够容纳所有常见的使用场景。

以下代码片段显示了如何创建一个Acl,或修改现有Acl:

在上面的示例中,我们检索ACL的44号"Foo" 域对象标识符。我们添加一个ACE,然后名叫"Samantha"能"administer"的对象。代码片段相对明显,除了insertAce方法。insertAce方法的第一个参数是确定在什么位置Acl新条目将被插入。在上面的示例中,我们只是把新的现有ACE。最后一个参数是一个布尔值指示是否允许或拒绝。大部分时间它将授予(真实的),但如果是否认(假),实际上是被屏蔽的权限.

Spring Security并不提供任何特殊的集成自动创建、更新或删除acl DAO或存储库操作的一部分。相反,您需要编写代码如上图所示为你单独的域对象.值得考虑使用AOP在服务层与服务层自动把ACL信息操作.我们发现这在过去的一个相当有效的方法.

一旦你使用上述技术将一些ACL信息存储在数据库中,下一步是实际使用ACL信息作为授权决策逻辑的一部分。这里有许多选择。您可以编写自己的AccessDecisionVoter或AfterInvocationProvider 分别触发一个方法调用之前或之后。这些课程将使用AclService来检索相关的ACL,然后调用的ACL。i`Acl.isGranted(Permission[] permission, Sid[] sids, boolean administrativeMode)决定是否授予或拒绝许可。或者,您可以使用我们的`AclEntryVoter, AclEntryAfterInvocationProvider 或 AclEntryAfterInvocationCollectionFilteringProvider类。所有这些类提供一个declarative-based方法评估ACL信息在运行时,释放你需要编写任何代码。请参阅示例应用程序来学习如何使用这些类。

因为大多数pre-authentication机制遵循相同的模式,Spring Security一组类,提供一个内部框架实现pre-authenticated身份验证提供者。这个删除复制和允许添加新的实现结构化的方式,无需写一切从头开始。你不需要知道这些类,如果希望使用类似于X.509 authentication,因为它已经有了一个名称空间配置选项,简单的使用和开始使用。如果你需要使用显式的bean配置或计划编写自己的实现提供的实现如何工作的理解将是有用的。你会发现类“org.springframework.security.web.authentication.preauth”。我们在适当的地方提供一个大纲你应该咨询Javadoc和源.

X.509认证被 own chapter覆盖.下面我们来看看一些类,它们提供支持其他pre-authenticated场景.

LDAP作为一个中央存储库对用户信息和身份验证服务是常用的组织.它也可以用于存储应用程序用户的角色信息.这里有一些不同的场景对于如何配置LDAP服务器，因此Spring Security LDAP提供者是完全可配置的，它使用单独的策略为身份验证和角色接口检索,并提供默认的实现,可以配置为处理各种情况.在使用之前你应该熟悉Spring Security LDAP.以下链接提供了一个很好的介绍涉及的概念和使用OpenLDAP免费的LDAP服务器建立一个目录指南http://www.zytrax.com/books/ldap/[http://www.zytrax.com/books/ldap/]. 一些熟悉的JNDI api用于访问LDAP从Java也可能是有用的。我们在LDAP不使用任何第三方LDAP库(Mozilla,JLDAP等等),但Spring 的广泛使用是由LDAP,如果你打算添加您自己的定制,对这方面有所了解对你的项目可能是有用的.

使用LDAP身份验证时,重要的是要确保你正确配置LDAP连接池。如果你不熟悉如何做到这一点,你可以参考 Java LDAP documentation.

在Spring的LDAP身份验证安全大致可以分为以下几个阶段

唯一的例外是当LDAP目录只是被用于检索用户信息并在本地对其进行身份验证.这个不可能设置有限的读访问属性目录,如用户密码.

下面,我们将看看一些配置场景。完整的可用配置选项的信息,请查阅安全模式名称空间(信息应该在XML编辑器中可用).

你需要做的第一件事是配置的服务器身份验证应该发生。这是通过使用 <ldap-server> 的元素从安全名称空间。这可以配置为指向外部LDAP服务器,使用的url属性:

上面的名称空间配置选项我们使用易于使用,更比使用Spring bean简洁明确。有些情况下,您可能需要了解如何配置Spring Security LDAP直接在您的应用程序上下文。您可能希望定制的一些类的行为,例如。如果你使用名称空间配置,那么你可以跳过这一节和下一个.

LDAP provider,LdapAuthenticationProvider,实际上并不做太多工作本身,而是代表其他两个bean,一个LdapAuthenticator 和一个LdapAuthoritiesPopulator分别负责验证用户和检索用户的组GrantedAuthority.

活动目录支持自己的标准身份验证选项,和正常的使用模式不适合太明显与标准LdapAuthenticationProvider.通常执行身份验证使用域用户名(user@domain),而不是使用LDAP专有名称.为了更简单,Spring Security 3.1有一个身份验证提供者是一个典型的定制活动目录设置.

要使用的任何标签,必须有安全JSP 标签库:

这个标签是用来确定是否应评估其内容。在Spring Security 3.0中,可以以两种方式使用脚注:[遗留的选项从Spring Security 2.0也支持,但不推荐.].第一种方法使用一个web-security expression,access 属性中指定的标签,表达式求值将委托给SecurityExpressionHandler<FilterInvocation> 中定义的应用程序(你应该启用web表达式<http>的名称空间配置,以确保这个服务是可用的).

在与Spring Security PermissionEvaluator共同使用时,标签也可以用来检查权限.例如:

一个常见的需求是只显示一个特定的链接,如果用户实际上是允许点击它。我们如何能提前确定事情是否会被允许吗?这个标签也可以在另一种操作模式,允许您定义一个特定的URL属性。如果允许用户调用的URL,然后标记的身体将被评估,否则它将被忽略。所以你可能类似

在你的程序内使用这个标签也必须的一个实例WebInvocationPrivilegeEvaluator,如果您正在使用名称空间,将自动注册。这是一 个DefaultWebInvocationPrivilegeEvaluator的实例，它创建了一个虚拟网络提供的URL请求,并调用安全拦截器请求是否会成功或失败，这允许您代表您定义的访问控制设置中使用intercept-url声明<http>的名称空间配置省去了重复的信息(如所需的角色)在您的jsp.这种方法还可以加上一个method属性,提供HTTP方法,更具体的匹配.

布尔结果评估标签(是否允许或拒绝访问)通过设置var属性变量名称可以存储在一个页面上下文范围变量,避免复制和重新评估在页面中的其他点.

这个标签允许访问当前存储在安全内 Authentication对象,它直接在JSP中 呈现一个属性对象.所以,例如,如果principal`属性的Authentication是Spring Security的UserDetails的对象的一个实例,之后用<sec:authentication property="principal.username" /> 将会显示当前用户的名称.

当然,这种事情没有必要使用JSP标记,有些人喜欢保持尽可能少的逻辑视图.您可以在你的MVC控制器访问Authentication对象(通过调用SecurityContextHolder.getContext().getAuthentication())并将数据直接添加到您的模型渲染的视图.

这个标记只在使用Spring Security的ACL模块,它检查一个以逗号分隔的所需权限指定的域对象.如果当前用户所有的权限,然后标记的内容将被评估。如果他们不这样做,它将被忽略.例如

在程序内容中,权限被传递到“PermissionFactory”中定义中定义,将它们转换为ACL`Permission`的实例,所以他们支持任何格式工厂,他们不一定是整数,字符串可以像READ或WRITE.如果没有找到PermissionFactory ,将使用DefaultPermissionFactory的一个实例.程序中的“AclService”将被用于加载Acl的实例提供对象.Acl的将调用所需的权限,以检查是否都是合法的.

这个标签还支持var属性,以同样的方式authorize 的标签.

如果启用了CSRF保护,这个标签插入一个隐藏表单字段的正确名称和值CSRF保护令牌。如果没有启用CSRF保护,这个标签输出.对于任何的<form:form> 标签使用,通常Spring Security自动插入一个CSRF表单字段.但如果由于某种原因你不能使用<form:form>,你可以使用<form:form>更换.

你应该把这个标签在一个HTML <form></form>形式的块,通常地方其他输入字段.不要将这个标签放置在一个Spring <form:form></form:form>,block—Spring Security会自动处理 Spring.

如果启用了CSRF保护,这个标签插入元素标记包含CSRF保护令牌表单字段和标题名称和CSRF保护令牌的值。这些元素标记可用于使用CSRF保护在JavaScript应用程序.

你应该把csrfMetaTags在一个 HTML <head></head> ,通常地方其他元标记。一旦你使用这个标签,你可以使用JavaScript访问表单字段的名称,标题名称.JQuery中使用这个例子使这项任务变得更加简单.

如果不启用CSRF保护,csrfMetaTags输出.

Spring Security提供一个包可以将身份验证请求委托给Java身份验证和授权服务(JAAS).这个包是在下面详细讨论.

AbstractJaasAuthenticationProvider提供JAAS AuthenticationProvider实现的基础.子类必须实现方法,创建了LoginContext. AbstractJaasAuthenticationProvider有许多依赖关系,下面讨论它

DefaultJaasAuthenticationProvider允许将一个JAAS配置的对象注入依赖项。然后使用JAAS配置的注入创建一个LoginContext.这意味着DefaultJaasAuthenticationProvider不绑定任何特定实现的Configuration因为JaasAuthenticationProvider.

JaasAuthenticationProvider 假定默认的Configuration的一个实例http://download.oracle.com/javase/1.4.2/docs/guide/security/jaas/spec/com/sun/security/auth/login/ConfigFile.html[ ConfigFile].这种假设是为了尝试更新Configuration.JaasAuthenticationProvider使用默认配置的创建LoginContext.

假设我们有一个JAAS登录配置文件,/WEB-INF/login.conf, 用下面的内容:

像所有Spring Security beans,JaasAuthenticationProvider通过应用程序上下文配置.下面的定义将对应于上面的JAAS登录配置文件

如果配置,“JaasApiIntegrationFilter”将试图运行“JaasAuthenticationToken”上的Subject。这意味着可以使用访问Subject:

这种集成可以很容易地使用jaas-api-provision配置属性。当集成遗留或外部依赖JAAS Subject API被填充,这个特性很有用

JA-SIG产生一个企业范围的单点登录系统称为CAS。与其他计划,JA-SIG中央身份验证服务是开源的,广泛使用,容易理解,平台独立,支持代理功能。Spring Security完全支持ca,并提供了一个简单的迁移路径从Spring Security的单个应用程序部署到多个应用程序部署的企业级CAS服务器.

你可以从at http://www.ja-sig.org/cas了解更多CAS.您还需要访问这个网站下载CAS服务器文件.

而中科院网站包含文档的细节CAS的体系结构,提出总体概述了Spring Security.Spring Security 3.x支持中科院。在撰写本文时,还在使用CAS服务器3.4版.

在您的企业,您需要设置一个CAS服务器。CAS服务器只是一个标准的WAR文件,所以设置您的服务器没有什么困难。在WAR文件您将定制登录和其他单点登录页面显示给用户.

当部署一个CAS 3.4服务器,您还需要指定一个AuthenticationHandler在deployerConfigContext.xml包含ca。AuthenticationHandler有一个简单的方法,该方法返回一个布尔判断是否一个给定的证书是有效的.你AuthenticationHandler的实现需要链接到某种类型的后端身份验证存储库,如LDAP服务器或数据库,CAS本身包含许多AuthenticationHandler的协助.当你下载服务器和部署war文件时,它被设置为成功进行身份验证的用户输入一个密码匹配他们的用户名,用于测试.

由于Spring Security中科院的web应用程序是很容易.这是假设你已经知道使用Spring安全的基本知识,下面这些是不会再覆盖。我们假设基于命名空间的配置使用,根据需要添加在CAS bean。每个部分建立在前一节。一个完整的CAS sample application可以在Spring Security样本找到.