一个最小的SPring Security Maven 依赖通常和下面的类似:

如果你使用的额外的功能比如LDAP，OpenID，等等，你需要包含适当的模块，查阅Section 1.4.3,"Project Modules" 项目模块.

最小的Gradle一组典型的依赖如下:

如果你使用了 LDAP, OpenID, 等等. 你需要包含相应的模块，请参阅“Project Modules” 项目模块.

在 Spring Security 3.0, 代码库被分割到单独的jar，这样可以更清楚的分隔不用功能区域和第三方依赖。如果你使用Maven构建你的项目，那么这些都是需要你添加到你的pom.xml中的. 甚至你没有使用Maven，我们建议你请求pom.xml文件来获取第三方依赖和版本。另一个好办法是检查实例应用程序的库。

因为Spring Security是一个开源项目，我们强烈建议您使用Git签出源代码。这可以让你完全访问所有势力应用程序，你可以轻松地构建最先进的最新版本的项目。有了项目的源代码对debug有非常大的帮助。异常堆栈跟踪不再是模糊的黑盒问题，你可以沿着他找出到底发生了什么。源代码是中级文档，通常也是最简答的项目实际是如何工作的地方。

要获取项目源代码，请使用一下git命令:

这可以让你在本地机器上访问到整个项目的历史记录（包括所有版本和分支）.

下一步是在war里注册springSecurityFilterChain。这可以通过Spring在Servlet 3.0+环境中对 Spring’s WebApplicationInitializer supportWebApplicationInitializer的支持进行了java配置，Spring Security提供了基本的抽象类 AbstractSecurityWebApplicationInitializer这可以确保springSecurityFilterChain 已经被注册。我们使用AbstractSecurityWebApplicationInitializer 的不同方式取决于你是已经在使用Spring框架还是只是用了Spring Security。

如果你没有使用Spring MVC 或Spring，你需要传递 WebSecurityConfig 到超类来确保配置被使用，你可以参考下面的例子:

SecurityWebApplicationInitializer 将会做下面的事情:

如果我们在应用程序的其他地方已经使用了Spring，那么我们已经有了一个 WebApplicationInitializer用来载入Spring的配置。如果我们使用上面的配置将会得到一个错误。所以我们应该使用已经存在的 ApplicationContext 注册Spring Security。举个例子，如果我们使用Spring MVC我们的 SecurityWebApplicationInitializer 应该看起来和下面差不多:

这回简单的只为你的应用程序的所有URL注册springSecurityChain过滤器。然后我们需要确保这个Security配置被载入到我们已经存在的 WebSecurityConfig。例如，如果你使用Spring MVC 它应该被加入到 getRootConfigClasses()

一般来说，LogoutHandler的实现类可以参阅到注销处理中。他们被用来执行必要的清理，因而他们不应该抛出错误，我们提供您各种实现：

请查看 Remember-Me的接口和实现 获取详情。

流式API提供了调用相应的LogoutHandler 实现的快捷方式, 而不是直接提供LogoutHandler 的实现。例如：deleteCookies() 允许指定注销成功时要删除一个或者多个cookie。这是一个添加 CookieClearingLogoutHandler的快捷方式。

LogoutSuccessHandler被LogoutFilter在成功注销后调用，用来进行重定向或者转发相应的目的地。注意这个借口与LogoutHandler几乎一样，但是可以抛出异常。

下面是提供的一些实现：

和前面提到的一样，你不需要直接指定SimpleUrlLogoutSuccessHandler。而使用流式API通过设置logoutSuccessUrl()快捷的进行设置SimpleUrlLogoutSuccessHandler。注销成功 后将重定向到设置的URL地址。默认的地址是 /login?logout.

在REST API场景中HttpStatusReturningLogoutSuccessHandler会进行一些有趣的改变。LogoutSuccessHandler允许你设置一个返回给客户端的HTTP状态码（默认返回200）来替换重定向到URL这个动作。

我们已经看到了一个单用户配置到内存验证的示例，下面是配置多个用户的例子：

你可以找一些更新来支持JDBC的验证。下面的例子假设你已经在应用程序中定义好了DataSource， jdbc-javaconfig 示例提供了一个完整的基于JDBC的验证。

你可以找一些更新来支持LDAP的身份验证， ldap-javaconfig 提供了一个完成的使用基于LDAP的身份验证的示例。

上面的例子中使用一下LDIF和前如何Apache DS LDAP示例。

您可以通过一个自定义的AuthenticationProvider为bean定义自定义身份验证。 例如， 下面这个例子假设自定义身份验证SpringAuthenticationProvider实现了AuthenticationProvider:

NOTE:`AuthenticationManagerBuilder`如果还不密集这将仅被使用。

你可以通过一个自定义的UserDetailsService为bean定义自定义身份验证。 例如，下面这个例子假设自定义身份验证SpringDataUserDetailsService实现了UserDetailsService:

NOTE:`AuthenticationManagerBuilder`如果还不密集这将被仅被使用并且没有AuthenticationProviderBean申明。

你也可以通过让passwordencoder为bean自定义密码如何编码。 例如，如果你使用BCrypt，你可以添加一个bean定义如下图所示：

我们可以在任何使用@Configuration的实例上，使用@EnableGlobalMethodSecurity注解来启用基于注解的安全性。例如下面会启用Spring的@Secured注解。

添加一个注解到一个方法（或者一个类或者接机）会限制对相应方法的访问。Spring Security的原生注解支持定义了一套用于该方法的属性。这些将被传递AccessDecisionManager到来做实际的决定：

使用如下代码启用JSR-250注解的支持

这些都是基于标准的，并允许应有个你简单的基于角色的约束，但是没有Spring Security的本地注解的能力。要使用基于表达书的语法，你可以使用：

和响应Java代码如下：

有时候你可能需要执行一些比@EnableGlobalMethodSecurity注解允许的更复杂的操作。对于这些情况，你可以扩展GlobalMethodSecurityConfiguration确保@EnableGlobalMethodSecurity注解出现在你的子类。例如如果你想提供一个定制的MethodSecurityExpressionHandler，你可以使用下面的配置：

关于可以被重写的方法的更多信息，请参考GlobalMethodSecurityConfiguration的java文档。

命名空间是设计用来捕捉框架最常见用途和提供一个简化和简介的语法用来在应用程序中打开他们。设计师基于框架中的大规模依赖，并且可以划分为以下几个方面：

我们将在后续章节查看怎么配置他们。

你需要做的第一件事情是添加下面的过滤器定义到你的web.xml文件：

这提供了一个钩子到Spring Security的网页基础设施。DelegatingFilterProxy是一个委托了在应用的Context中定义为bean的过滤器实现的一个Spring框架类，在这种情况下，bean的名字是springSecurityFilterChain，这是网络安全命名空间创建的一个基础类。注意你不能自己使用这个bean名字。一旦你添加这个到你的web.xml，你就可以开始编辑你的应用程序上下文文件，网络安全服务被配置到<http>元素。

开始开启网页安全你只需要：

这表示，我们想要对我们应用程序中的所有URL进行性检测。需要角色ROLE_USER访问他们，我们使用一个包含username和password的表单登录到应用程序，我们希望有一个注销的URL，让我们可以登出应用程序。<http>元素是所有网站相关的命名空间功能的父元类。<intercept-url>元素定义了一个规则使用ant语法去匹配传入的请求的URL。 （在网站应用基础设施章节，查看 Request Matching and HttpFirewall来了解匹配是如何执行的） 你也可以环衬正则表达式语法（查看附录了解更多）。这个access属性定义了这个匹配的规则需要的访问需求。默认是一个典型的用逗号分隔的角色列表，有其中一个符合则允许执行这个请求。 前缀"ROLE_" 是一个标记，只是一个和用户的授权进行简单的比较。换句话说，一个简单的基于角色的检查会被应用。Spring Security的访问控制不仅限于简单角色(因此使用前缀来区分不同类型的)。

为了添加一些用户，你可以直接在命名空间直接定义一组测试数据。

上面的配置定义了两个用户，他们的密码和在这个应用程序里的角色（这将用于访问控制）。也可以使用用户服务从标准的属性文件properties载入用户信息user-service。查看内存认证部分文件格式的更多细节in-memory authentication 。使用 <authentication-provider>元素意思是这些用户信息将被认证管理器使用到请求验证。你可以设置多个<authentication-provider>元素来定义不同的验证源每一个都会被一次访问到。

此时你应该可以开始你的应用程序，你将被要求登录。尝试一下或者尝试使用附带的项目教程实例。

你可能会想当系统提示你登录这些登录表单哪里来的，因为我们都没有提供任何HTML和JSP文件。事实上我们并没有明确的设定一个登陆页的URL，Spring Security自动生成了一个，基于处理登录的URL标准值。以及登录后跳转的URL然后命名空间提供了大量的支持，让你可以自定义这些选项，例如如果你想自己设计登录页面，你可以使用：

另外请注意一个额外的intercept-url元素，来指定登录页的请求可以被任何匿名用户访问:[AuthenticatedVoter 类可以提供更多 匿名身份验证] AuthenticatedVoter IS_AUTHENTICATED_ANONYMOUSLY被处理的细节]. 否则请求会被/**规则匹配这将是不可能访问到登录页面。这是一个常见的配置错误，将导致应用无限循环。Spring Security会产生一条经过到日志中如果你的登录页被保护了。它也可以设置让所有请求完全匹配特定模式而绕过安全过滤器，通过定义像这样单独http元素的规则：

从Spring Security 3.1开始允许使用多个http元素来为不用的请求规则分别定义Security Filter Chain配置。如果http元素的pattern属性为设置则匹配所有请求。创建不进行安全检查的规则是这个语法的一个简答的例子，这个规则会被映射到一个空的过滤链。我们将会在后面的安全过滤链章节找到更多细节。[多个<http>元素的使用时一个非常重要的功能，例如它允许命名空间在一个应用程序中同时支持有状态和无状态的相同URL之前的语法，使用filters="none"属性到一个intercept-url元素与这一变化相抵触，在3.1将不再支持 。

重要的一点需要认识到，这些不安全的请求将完全无视任何Spring Security 的web相关的配置或附加属性，例如requires-channel通道的限定，所以在请求期间你将无法访问当前用户信息，或调用需要进行安全验证的方法。如果你想让安全过滤链被应用另外也可以使用 access='IS_AUTHENTICATED_ANONYMOUSLY'。

如果你想使用基本验证来替换掉表单的登录，你可以将配置修改如下:

当用户访问被保护的资源时，基本身份验证将优先弹出提示框来进行登录。在这总配置如果想使用基于表单的登录，他仍然有效。例如，将登录嵌入另外一个网页。

logout元素，增加了一个登出导航到一个特定URL的支持，默认的登出URL是 /logout。但是你可以使用logout-url属性指定为其他的URL。更多的属性你可以从附录找到。

在实践中，你将需要将一些名字添加到应用程序上下文文件中更具扩展性的数据源。你有可能想把用户信息存放在注入数据库或者LDAP服务器中。LDAP命名空间的配置在LDAP chapter章节，这里就不说了。,如果你的应用程序上下文中有一个Spring Security的 UserDetailsService的实现叫做"myUserDetailsService"，你可以这样使用：

如果你想用一个数据库，你可以这样用：

在应用程序上下文中，"securityDataSource"是DataSource bean的名字，指明一个数据库包含标准的 Spring Security user data tables. 另外， 你可以配置一个Spring Security JdbcDaoImpl bean 并且指明它使用user-service-ref属性:

你也可以像下面一样使用标准的AuthenticationProvider

myAuthenticationProvider是应用程序上下文的一个bean名字 。他实现了AuthenticationProvider接口。 你可以设置多个验证供应商，这样这些供应商就会按照定义的顺序被查询。看看 验证管理器和命名空间 章节“验证管理器和命名空间”连接AuthenticationManager在命名空间中怎么被配置。

查看独立的Remember-Me chapter章节来查看该功能的配置。

如果你的应用程序同时支持HTTP和HTTPS，你要求特定的URL只能使用HTTPS，这是可以直接使用<intercept-url>的requires-channel属性:

有了这个配置,如果用户试图访问任何匹配的"/secure/**"模式使用HTTP,他们将首先被重定向到一个HTTPS URL脚注:[想要了解channel-processing 如何实现，请查阅java文档ChannelProcessingFilter以及相关的类]。可用的选项是“http”、“https”或“任何”。使用价值“任何”意味着可以使用HTTP或HTTPS。

该选项可选值为"http","https"或者"any"，使用"any"意思是使用HTTP或者HTTPS均可。如果应用程序使用HTTP和HTTPS非标准的端口，你可以指定如下端口映射的列表：

请注意,为了真正的安全,应用程序不应该使用HTTP或HTTP和HTTPS之间切换。它应该开始在HTTPS(与用户进入一个HTTPS URL)使用安全连接,以避免任何中间人攻击的可能性。

通过一个简单的改变，命名空间可支持用 OpenID 替换或者添加到普通的基于表单登录：

然后，你应该将自己注册为一个OpenID供应商（如myopenid.com），并添加用户信息到你的基于内存的<user-service>:

你应该能够使用myopenid.com网站登录来进行验证。另外，也可以通过设置 openid-login元素的user-service-ref属性来指定一个UserDetailsService bean来使用OpenID。查看前面的authentication providers章节了解更多信息请注意，我们省略从上述用户配置中的密码属性，由于该组的用户数据只被用于加载当前的用户。内部会产生一个随机密码，放置你意外的将这个用户数据用作验证源到你的配置中的其他地方。

查看如何定制头元素的更多信息请查看安全HTTP响应头章节。

如果你以前使用过Spring Security，你就会知道，这个 框架维护一个过滤器链，以便应用它的服务。你可能想要添加自己的过滤器到过滤器堆栈的特定位置，或者使用一个Spring Security还没有一个命名空间配置的选项的过滤器（比如CAS）。或者你想使用一个标准命名空间过滤器的定制化版本，比如UsernamePasswordAuthenticationFilter是由 <form-login>元素显式的使用Bean来获取一些额外的高级配置选项，在过滤器链不直接暴露的情况下，你怎么使用命名空间配置这一点？

使用命名空间时过滤器的顺序始终严格执行，当创建应用程序上下文，过滤器Bean被命名空间处理代码进行排序，标准的Spring Security过滤器都具有的命名空间和一个众所周知的位置的别名。

标准过滤器别名和顺序，别名和创建的命名空间元素/属性在下表列出，按照过滤器在链中出现的顺序列出：

你可以添加自己的过滤器到列表中，使用custom-filter过滤元件和这些名字来指定你的过滤器应该出现在的位置之一：

你也可以使用after和before属性来让你的过滤器插入到列表中的其他过滤器的前面和后面。FIRST和LAST可以用在position属性来设置你希望将你的过滤器插入到整个列表的前面或者后面。

如果你替换的命名空间过滤器需要一个验证入口点（例如：在认证过程是通过尝试触发未认证用户访问以受保护资源）你也需要添加一个定制的入口点Bean。

这个元素用来在你的应用程序中启用基于安全性（通过设置元素的appropriate属性），同时分组将应用到整个应用程序上下文的安全切入点声明。你应该只定义一个<global-method-security>元素。下面的定义可以开启Spring Security的@Secured支持:

添加一个注解到类或者接口的方法中可以限制对相应方法的访问。Spring Security的原生注解支持定义了一套用于该方法的属性。这些将被传递到AccessDecisionManager用来做实际的决定：

启用 JSR-250 注解使用

这些都是基于标准的，并允许应用简单的基于角色的约束，但是没有Spring Security的原生注解强大。要使用新的基于表达式的语法，你可以使用

等价的Java代码如下

基于表达式的注解是一个很好的选择，如果你需要定义超过一个检查当前用户列表中的角色名称的简单的规则。

如果你需要使用一个更复杂的访问控制策略，那么很容易的为方法和Web安全设置替代方案。

对于方法安全，通过在access-decision-manager-ref上设置global-method-security 属性来为应用程序指导适当的 AccessDecisionManager的Bean ID。

网站安全的语法一样，但是是在http元素上。

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

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

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

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

这是Spring Security用户加载信息的最常用的方法并且每当需对用户的信息时你会看到它使用的整个框架。

成功认证后，UserDetails用于构建存储在SecurityContextHolder(详见 以下)的Authentication对象。好消息是，我们提供了一些UserDetailsService的实现，包括一个使用内存映射(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中的。

从这一点上来看，用户被认为是被验证的。让我们看看一些代码作为一个例子:

在这里我们已经写了一个小程序，要求用户输入一个用户名和密码并执行上述序列。这个AuthenticationManager我们这里将验证用户的用户名和密码将其设置成一样的，它给每一个用户分配一个单一的角色。从上面输出的将是类似的东西:

请注意，你通常不需要写任何这样的代码。这个过程通常会发生在内部，以一个web认证过滤器为例，我们刚刚在这里的代码显示，在Spring Security中究竟是什么构成了验证的问题，有一个相对简单的答案。用户验证时，SecurityContextHolder包含一个完全填充的Authentication对象的用户进行身份验证。

事实上，Spring Security不介意你如何把Authentication对象包含在SecurityContextHolder内。唯一的关键要求是SecurityContextHolder包含Authentication在AbstractSecurityInterceptor之前(我们会看到更多的版本)需要用户授权操作。

你可以(很多用户都这样做)写一个自己的过滤器或MVC控制器来提供验证系统的交互，这些都不是基于Spring Security的。比如，你也许使用容器管理认证，从ThreadLocal或JNDI里获得当前用户信息。或者，你的公司可能有一个遗留系统，它是一个企业标准，你不能控制它。这种情况下，很容易让Spring Security工作，也能提供验证能力。你所需要的就是写一个过滤器(或等价物)从指定位置读取第三方用户信息，把它放到SecurityContextHolder里。在这种情况下，你还需要考虑的事情通常是由内置的认证基础设施自动照顾。例如，缓存请求的情况下你可能需要事先创建一个HTTP会话，在编写客户端响应之前 ^[1]。

如果你想知道AuthenticationManager是如何以现实世界的例子来实现，我们可以来看看 核心服务一章.

ExceptionTranslationFilter是一个Spring Security过滤器，用来检测是否抛出了Spring Security异常。这些异常会被AbstractSecurityInterceptor抛出，它主要用来提供验证服务。我们会在下一节讨论AbstractSecurityInterceptor，但是现在，我们只需要知道，它是用来生成Java，并且要知道和HTTP没什么关系，或者如何验证一个主体。而ExceptionTranslationFilter提供这些服务，使用特点那个的响应，返回错误代码403(如果主体被验证了，但是权限不足-在上边的步骤七),或者启动一个AuthenticationEntryPoint(如果主体没有被认证，然后我们需要进入步骤三)。

AuthenticationEntryPoint对应上面列表中的步骤三。如你所想的，每个web应用程序都有默认的验证策略(好的，这可以在Spring Security里配置一切，但是让我们现在保持简单)。每个主要验证系统会有它自己的AuthenticationEntryPoint实现， 会执行动作，如同步骤三里的描述一样。

在你的浏览器决定提交你的认证证书之后(使用HTTP表单发送或者是HTTP头),服务器部分需要有一些东西来"收集"这些验证信息。现在我们到了上述的第六步。 在Spring Security里，我们需要一个特定的名字，来描述从用户代码（通常是浏览器）收集验证信息的功能，这个名字就是"验证机制"。实例是窗体的基本登录和基本的身份验证。一旦认证细节已从用户代理收集,建立一个Authentication "request"对象，然后提交给AuthenticationManager。

验证机制重新获得了组装好的Authentication对象时，它会认为请求有效，把Authentication放到SecurityContextHolder里的，然后导致原始请求重审(第七步)。另一方面,如果AuthenticationManager驳回了请求,验证机制会让用户代码重试(第二步)。

根据不同的应用程序类型，在用户操作的过程中需要有合适的策略来保存security信息。在一个典型的web应用中，一个用户登录系统之后就会被一个特有的session Id所唯一标识,服务器会将session作用期间的principal数据保存在缓存中。在Spring Security中,保存SecurityContext的任务落在了SecurityContextPersistenceFilter身上，它默认将上下文当做HttpSession属性保存在HTTP请求中,并且将每一个请求的上下文保存在SecurityContextHolder中，最重要的功能,是在请求结束之后,清理SecurityContextHolder。你不需要处于安全的目的直接和HttpSession打交道。在这里仅仅只是不需要那样做-总是使用SecurityContextHolder来代替HttpSession。

许多其他的应用（举个例子：一个无状态的RESTful风格web服务）不使用Http Session并且每次请求过来都会进行验证。然而比较重要的是:`SecurityContextPersistenceFilter`被包含在过滤器链中,并确保每次请求完毕之后清理SecurityContextHolder。

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

对那些不熟悉AOP的人，需要理解的关键问题是Spring Security可以帮助你保护方法的调用，就像保护web请求一样。大多数人对保护服务层里的安全方法非常按兴趣。这是因为在目前这一代J2EE程序里，服务器放了更多业务相关的逻辑。如果你只是需要保护服务层的方法调用，Spring标准AOP平台就够了。如果你想直接保护领域对象，你会发现AspectJ非常值得考虑。

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

那么什么是一个"安全对象"呢?Spring Security使用术语是指可以有安全性的任何对象(如授权决策)应用于它。最常见的例子就是方法调用和web请求。

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

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

默认情况下(从Spring Security 3.1开始)的ProviderManager将试图清除它返回一个成功的认证请求的Authentication`对象的任何敏感的身份验证信息。这可以防止密码等个人资料超过保留时间。

当使用用户对象的高速缓存时，例如，改善在无状态情况下应用程序的性能，这可能导致问题。如果Authentication包含在高速缓存（诸如UserDetails实例）的对象的引用中，将其凭证移除，则它将不再能够进行对缓存的值进行验证。你需要考虑到这一点，如果你使用的是高速缓存。一个显而易见的解决方案是让一个对象的副本，无论是在高速缓存中执行或在AuthenticationProvider它创建返回Authentication对象。另外，你可以在ProviderManager中禁用eraseCredentialsAfterAuthentication。查看Javadoc了解更多信息。

Spring Security中实现最简单的AuthenticationProvider是DaoAuthenticationProvider，也是最早支持的框架。它利用了UserDetailsService（作为DAO）去查找用户名和密码。它的用户进行身份验证通过userdetailsservice加载`usernamepasswordauthenticationtoken `提交密码进行一对一的比较。配置提供程序是非常简单的:

这个PasswordEncoder是可选的。一个PasswordEncoder提供编码以及UserDetails对象提出的密码是从配置UserDetailsService返回的解码。 这将更加详细 如下。

简单的使用去创建一个自定义的UserDetailsService实现选择从一个持久性引擎中提取信息，但许多应用程序不需要这么复杂。尤其是如果你正在建设一个原型应用或刚刚开始结合Spring Security当你真的不想花时间配置数据库或写作userdetailsservice实现。对于这种情况，一个简单的选项是使用安全性 命名空间的user-service元素:

这也支持一个外部属性文件的使用:

属性文件应包含在表单条目

例如

Spring Security还包括UserDetailsService，它可以从一个JDBC数据源获得认证信息。内部Spring JDBC的使用，避免了一个全功能对象关系映射（ORM）的复杂性来存储用户信息。如果你的应用程序不使用ORM工具，你可以写一个自定义UserDetailsService重用在你可能已经创建好的映射文件上。回到 JdbcDaoImpl，实例的配置如下：:

您可以通过修改上面的DriverManagerDataSource使用不同的关系型数据库管理系统。你也可以从JNDI获得，与任何其他的Spring配置使用一个全球性的数据源。

密码散列对于Spring Security不是唯一的，但是一个共同的来源是对于不熟悉概念的用户。哈希（或摘要）算法是一个单向函数，它由一些输入数据，如密码产生一块固定长度的输出数据（散列）的。作为一个例子，字符串"密码"（十六进制）的MD5哈希。

从这一方面来说hash的是"单向"，要获得给定的散列值这是很困难的(实际上是不可能的)，或者说实际上任何可能的输出都会产生散列值的原始输入。这个属性使得哈希值对于进行身份验证是非常有用的。它们可以被存储在用户数据库作为替代明文口令，即使值受到损害它们也不会立刻露出可用于登录的密码。请注意，这也意味着一旦它被编码，你就没有办法恢复密码。

随着密码的哈希值的使用有一个潜在的问题就是如果一个普通的词用于输入，则相对容易得到哈希的单向属性。人们倾向于选择类似的密码和巨大的字典，这些以前被黑客攻击的网站都可以在线。例如，如果你使用谷歌搜索哈希值5f4dcc3b5aa765d61d8327deb882cf99，你会很快发现原来的"密码"。以类似的方式，攻击者可以构建散列的字典从标准单词列表中查找原来的密码。有一种方法帮助防止这种情况就是有一个合适的强密码策略，以防止常用的单词被使用。另一个是计算散列何时使用"salt"。这是它与计算散列之前密码组合的每个用户的已知数据的附加字符串。理想情况下，数据应该是随机的，但在实践中，任何salt值通常是最好没有。使用的salt意味着攻击者必须建立散列每个salt值的一个单独的字典，使得攻击更加复杂（但不是不可能）。

Bcrypt自动生成每个密码随机salt值时，它被编码，并存储在一个标准格式的BCrypt的字符串。

当一个认证供应商（如Spring Security的DaoAuthenticationProvider）需要对某个用户的已知值提交的认证请求来检查密码和存储的密码以某种方式进行编码，然后提交的值必须准确使用编码相同的算法。这个取决于你的检查，这些都是兼容的，因为Spring Security没有对持久值的控制。如果添加的密码散列以你的身份验证配置Spring Security的，和你的数据库中包含明文密码，那么就没有办法验证成功。即使你知道你的数据库是使用MD5编码的密码，例如，你的应用程序被配置为使用Spring Security的Md5PasswordEncoder，那么有很多事情会是错误的。数据库可以具有在Base 64编码的密码，例如当编码器使用十六进制字符串（缺省值）。替代地数据库可以是使用大写，而从编码器的输出为小写。为了确保，你需要写一个测试，以检查输出从你配置的密码编码器与一个已知的密码和salt的组合，并检查它相匹配的数据库值之前，进一步尝试通过您的应用程序进行验证。使用诸如BCrypt标准将避免这些问题。

如果你想生成您的用户数据库编码密码，直接在Java中进行存储，那么你可以使用PasswordEncoder上的encode方法。

When testing any non safe HTTP methods and using Spring Security’s CSRF protection, you must be sure to include a valid CSRF Token in the request. To specify a valid CSRF token as a request parameter using the following:

If you like you can include CSRF token in the header instead:

You can also test providing an invalid CSRF token using the following:

It is often desirable to run tests as a specific user. There are two simple ways of populating the user:

There are a number of options available to associate a user to the current HttpServletRequest. For example, the following will run as a user (which does not need to exist) with the username "user", the password "password", and the role "ROLE_USER":

You can easily make customizations. For example, the following will run as a user (which does not need to exist) with the username "admin", the password "pass", and the roles "ROLE_USER" and "ROLE_ADMIN".

If you have a custom UserDetails that you would like to use, you can easily specify that as well. For example, the following will use the specified UserDetails (which does not need to exist) to run with a UsernamePasswordAuthenticationToken that has a principal of the specified UserDetails:

You can run as anonymous user using the following:

This is especially useful if you are running with a default user and wish to execute a few requests as an anonymous user.

If you want a custom Authentication (which does not need to exist) you can do so using the following:

You can even customize the SecurityContext using the following:

We can also ensure to run as a specific user for every request by using MockMvcBuilders's default request. For example, the following will run as a user (which does not need to exist) with the username "admin", the password "password", and the role "ROLE_ADMIN":

If you find you are using the same user in many of your tests, it is recommended to move the user to a method. For example, you can specify the following in your own class named CustomSecurityMockMvcRequestPostProcessors:

Now you can perform a static import on SecurityMockMvcRequestPostProcessors and use that within your tests:

While it has always been possible to authenticate with HTTP Basic, it was a bit tedious to remember the header name, format, and encode the values. Now this can be done using Spring Security’s httpBasic RequestPostProcessor. For example, the snippet below:

will attempt to use HTTP Basic to authenticate a user with the username "user" and the password "password" by ensuring the following header is populated on the HTTP Request:

You can easily create a request to test a form based authentication using Spring Security’s testing support. For example, the following will submit a POST to "/login" with the username "user", the password "password", and a valid CSRF token:

It is easy to customize the request. For example, the following will submit a POST to "/auth" with the username "admin", the password "pass", and a valid CSRF token:

We can also customize the parameters names that the username and password are included on. For example, this is the above request modified to include the username on the HTTP parameter "u" and the password on the HTTP parameter "p".

While fairly trivial using standard Spring MVC Test, you can use Spring Security’s testing support to make testing log out easier. For example, the following will submit a POST to "/logout" with a valid CSRF token:

You can also customize the URL to post to. For example, the snippet below will submit a POST to "/signout" with a valid CSRF token:

At times it may be valuable to assert that there is no authenticated user associated with the result of a MockMvcinvocation. For example, you might want to test submitting an invalid username and password and verify that no user is authenticated. You can easily do this with Spring Security’s testing support using something like the following:

It is often times that we must assert that an authenticated user exists. For example, we may want to verify that we authenticated successfully. We could verify that a form based login was successful with the following snippet of code:

If we wanted to assert the roles of the user, we could refine our previous code as shown below:

Alternatively, we could verify the username:

We can also combine the assertions:

你可以使用属性filters = "none"替代供应一个过滤器bean列表。这将完全忽略安全筛选器链中的请求模式。请注意，任何匹配此路径将没有任何身份验证或授权服务应用，将可自由访问。如果你想在一个请求中使用的SecurityContext内容的内容，那么它必须通过保安过滤器链。否则，SecurityContextHolder不会被填充且内容也将空。

如果用户请求一个安全HTTP资源这个AuthenticationEntryPoint将被调用，但他们不被认证。适当的AuthenticationException或AccessDeniedException将被安全拦截器进一步拆毁了调用堆栈，触发入口点的commence方法。这确实呈现给用户的适当的反应，使认证可以开始工作。我们这里使用的是LoginUrlAuthenticationEntryPoint，这将请求重定向到一个不同的URL（一般是一个登录页面）。使用将取决于你想要的认证机制的实际实现在应用程序中使用。

如果用户已经通过身份验证，他们试图访问受保护的资源会发生什么?在正常使用情况下，这不应该发生，因为应用程序的工作流程应该仅限于用户访问的操作。例如，HTML链接到一个管理页面可能隐藏唉一个没有管理员角色的用户中。你不能依赖隐藏链接的安全,总是有一个可能性,用户只会直接输入URL,以绕过限制。或者，他们可能会修改一个RESTful URL来改变一些参数值。您的应用程序必须对这些方案进行保护，或者它绝对会是不安全的。您通常会使用简单的网络层安全性约束适用于基本的网址，并使用更具体的方法，基于安全上的服务层接口真正明确什么是允许的。

如果一个AccessDeniedException被抛出并且用户已经被认证，那么这意味着一个操作已经尝试了它们不具有足够的权限。在这种情况下，ExceptionTranslationFilter将调用第二策略，AccessDeniedHandler。默认情况下,AccessDeniedHandlerImpl被使用，这只是发送一个403（禁止）响应于客户端。此外，还可以配置明确的实例（如在上面的例子），并设置一个错误页面的URL，它会请求转发 ^[7]. 这可以是一个简单的“拒绝访问”页上，如一个JSP，或者它可以是更复杂的处理程序，如一个MVC的控制器。当然，你可以自己实现接口，并使用自己的实现。

它也可以提供当你自定义你的应用程序时使用命名空间来配置AccessDeniedHandler。详见 命名空间附录 了解更多详情。

ExceptionTranslationFilter另一个责任是调用AuthenticationEntryPoint之前保存当前的请求。这允许使用已经验证后要恢复的请求(看到之前的概述 web 认证).一个典型示例是在用户登录表单,然后重定向到默认的原始URL SavedRequestAwareAuthenticationSuccessHandler(见 下方).

该RequestCache封装用于存储和检索HttpServletRequest实例所需的功能。默认HttpSessionRequestCache被使用，其中该请求存储在HttpSession。该RequestCacheFilter具有实际恢复从当用户被重定向到原始URL缓存中保存的请求工作。

在正常情况下，你不需要修改任何此功能，但保存的请求处理是一个“尽力而为”的做法，有可能是其默认的配置是无法处理的情况。使用这些接口，使得它完全可插入从Spring Security 3.0起。

从Spring Security 3.0起,加载和存储安全上下文的工作现在是委托给一个单独的策略接口:

该HttpRequestResponseHolder只是一个容器传入的请求和响应对象，允许实现替换这些包装类。返回的内容将被传递给过滤器链。

默认实现HttpSessionSecurityContextRepository,存储安全上下文作为HttpSession的属性 ^[8]. 对于此实现最重要的配置参数是allowSessionCreation属性，它默认为true,从而使类来创建一个会话如果它需要一个存储身份验证的用户的安全上下文(它不会创建一个除非认证发生和安全上下文的内容改变了)。如果你不希望创建一个会话,则可以将此属性设置为false:

或者你可以提供 NullSecurityContextRepository的一个实例, 一个 null object 的实现, 这将防止安全上下文被存储，即使已经在会话期间创建一个该实例请求。

该过滤器调用配置AuthenticationManager处理每个认证请求。继成功认证或认证失败的目的地是由AuthenticationSuccessHandler和AuthenticationFailureHandler策略接口分别控制。过滤器属性允许你设置这些，所以你可以完全自定义行为 ^[10]. 一些标准的实现，如SimpleUrlAuthenticationSuccessHandler，SavedRequestAwareAuthenticationSuccessHandler，SimpleUrlAuthenticationFailureHandler和ExceptionMappingAuthenticationFailureHandler提供。看一看这些类的Javadoc和AbstractAuthenticationProcessingFilter来获取它们是如何工作的概述和所支持的特性。

如果认证成功，将所得Authentication对象将被放置到SecurityContextHolder。配置的AuthenticationSuccessHandler将被重定向或用户转发给适当的目的地。默认情况下使用SavedRequestAwareAuthenticationSuccessHandler,这意味着用户将被重定向到他们要求的原始目的地之前，他们被要求登录。

如果身份验证失败,则将调用AuthenticationFailureHandler配置。

HttpServletRequest.getRemoteUser() 将返回SecurityContextHolder.getContext().getAuthentication().getName()的结果。 这通常是当前的用户名。这可能是有用的,如果你想在应用程序中显示当前用户名。此外,检查如果这是空可以用来表示如果一个用户已经通过身份验证或者是匿名的。知道用户是否通过身份验证可以用于确定特定UI元素应该显示（即注销链接应该只显示如果用户身份验证）。

HttpServletRequest.getUserPrincipal()将返回SecurityContextHolder.getContext().getAuthentication()的结果。这意味着它是一个 Authentication 通常是 UsernamePasswordAuthenticationToken的一个实例使用基于用户名和密码的身份验证。这可能是有用的,如果你需要更多关于用户的信息。例如,您可能已经创建了一个自定义UserDetailsService,返回一个自定义的UserDetails包含您的用户的姓名。你可以用以下获得这些信息:

The HttpServletRequest.isUserInRole(String) 将确定 SecurityContextHolder.getContext().getAuthentication().getAuthorities() 包含一个 GrantedAuthority 角色传入的 isUserInRole(String)。 一般用户不应通过"ROLE_" 前缀到这个方法,因为它是自动添加的。例如,如果你想要确定当前用户有权力"ROLE_ADMIN",你可以使用以下:

这可能是有用的确定应该显示特定的UI组件。例如,您可能只显示管理链接如果当前用户是管理员。

The HttpServletRequest.authenticate(HttpServletRequest,HttpServletResponse)方法可用于确保用户身份验证。如果他们没有身份验证,配置AuthenticationEntryPoint将用于请求用户进行身份验证(即重定向到登录页面)。

The HttpServletRequest.login(String,String) 方法可用于验证用户与当前AuthenticationManager。例如,下面将尝试验证用户名 "user"和密码"password":

The HttpServletRequest.logout() 方法可以用于记录当前用户。

通常这意味着SecurityContextHolder将被清除,HttpSession将失效,任何“记住我”身份验证将清理干净,等。然而,LogoutHandler配置实现将取决于你的Spring Security配置。需要注意是,在HttpServletRequest.logout()被调用,你要还负责编写一个响应。通常这将涉及一个重定向到欢迎页面。

The AsynchContext.start(Runnable) 的方法,确保您的凭据将传播到新的线程。使用 Spring Security的并发支持Spring Security覆盖AsyncContext.start(可运行),以确保当前SecurityContext处理可运行时使用。例如,以下将输出当前用户的身份验证:

如果你使用的是基于Java的配置,你已经准备好了。如果你使用XML配置中,有一些是必要的更新。第一步是确保你更新你的web.xml使用至少3.0模式如下所示:

接下来你需要确保你的springSecurityFilterChain设置处理异步请求。

就是这样!现在的Spring Security将确保您的SecurityContext是在异步请求传播了。

那么它是怎样工作的？如果你是不是真的感兴趣，请随时跳过这一节的其余部分，否则就继续阅读。这是内置在Servlet规范,但有一点调整,Spring Security确保事情妥善处理异步请求。Spring Security 3.2之前,securitycontextholder的securitycontext自动保存只要httpservletresponse承诺。这可能会导致在异步环境下的问题。例如,考虑以下:

问题是,这个线程是未知的Spring Security,所以SecurityContext中不会传播到它。这意味着当我们提交HttpServletResponse没有SecuriytContext。当Spring Security的自动保存SecurityContext支持HttpServletResponse就会失去我们的登录用户。

自从3.2版本开始，Spring Security是足够聪明，不再自动保存SecurityContext，一旦遵守协议 HttpServletResponse的HttpServletRequest.startAsync（）将尽快被调用。

The HttpServletRequest.changeSessionId() 是默认的方法防止 固定会话 损害Servlet 3.1或更高的版本。

为了实现HTTP基本身份验证,您需要添加一个BasicAuthenticationFilter到你的过滤器链。应用程序上下文应包含BasicAuthenticationFilter及其所需的合作者:

配置的AuthenticationManager处理每个认证请求。如果认证失败，配置AuthenticationEntryPoint将被用来重试认证过程。通常你会在组合使用过滤器BasicAuthenticationEntryPoint，它会返回一个合适的头部重试HTTP基本身份验证的401响应。如果认证成功，将所得Authentication对象将和平常一样被放入SecurityContextHolder。

如果认证事件成功，或者认证不需要执行，因为HTTP头部没有包含支持的认证请求，过滤器链将继续正常工作。过滤器链中断的唯一情况是，如果认证失败了，Auth`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节。 enticationEntryPoint`被调用。

既然我们已经回顾了理论,让我们看看如何使用它。为了实现HTTP摘要认证，必须在过滤器链定义DigestAuthenticationFilter。这个应用上下文将需要定义DigestAuthenticationFilter及其所需的合作者：

配置UserDetailsService是必要的因为DigestAuthenticationFilter必须有一个用户的明文密码直接访问。如果您正在使用您的DAO中的编码密码，摘要身份验证将无法工作 ^[11]. 这个DAO的协作者，与UserCache一起，通常直接与DaoAuthenticationProvider共享。该authenticationEntryPoint属性必须是DigestAuthenticationEntryPoint，使DigestAuthenticationFilter能够获得正确的realmName和key再进行摘要计算。

像BasicAuthenticationFilter，如果认证成功，Authentication请求令牌将被放置到了SecurityContextHolder。如果认证事件成功，或者认证不需要执行，因为HTTP头部没有包含摘要认证请求，过滤器链将继续正常。过滤器链中断的唯一情况是，如果认证失败了AuthenticationEntryPoint被调用，如前一段讨论。

摘要式身份验证的RFC提供了一系列附加功能，以进一步提高安全性。例如，随机数可以在每次请求被改变。尽管如此，Spring Security的实施旨在最大限度地减少执行（和用户代理出现不兼容）的复杂性，并避免保存服务器端的状态。你被邀请审查RFC 2617如果你想更详细地探索这些功能。据我们所知，Spring Security的实现中遵守了RFC的最低标准。

这个实现支持 Simple Hash-Based Token Approach中描述的简单方法。TokenBasedRememberMeServices生成一个RememberMeAuthenticationToken,由RememberMeAuthenticationProvider处理。一个key认证提供者和TokenBasedRememberMeServices之间共享。此外，TokenBasedRememberMeServices需要一个UserDetailsService可以实现检索比较用户名和密码的目的，并生成RememberMeAuthenticationToken包含正确GrantedAuthority的一个UserDetailsService。如果用户提供无效的cookie，应该应用一些注销命令。TokenBasedRememberMeServices还实现了Spring Security的` logouthandler 接口，所有可以用`LogoutFilter自动清除cookie。

在应用程序环境方面，remember-me服务需要的bean类如下:

不要忘记添加你的RememberMeServices实现UsernamePasswordAuthenticationFilter.setRememberMeServices()的属性,包括RememberMeAuthenticationProvider在AuthenticationManager.setProviders（）中的列表，并添加RememberMeAuthenticationFilter到你的FilterChainProxy(一般在你的UsernamePasswordAuthenticationFilter之后)。

这个类可以以同样的方式作为TokenBasedRememberMeServices被使用，但它另外需要与PersistentTokenRepository存储令牌进行配置。有两种标准实现。

数据库模式如上面所描述 Persistent Token Approach.

一个常见的问题是"我是否需要保护JSON请求的javascript ?"简短的答案是，这取决于你。但是，你必须非常小心，因为有CSRF攻击可以影响JSON请求。例如，一个恶意用户可以使用以下格式，创建一个 CSRF和JSON使用以下form:

这将产生以下JSON结构

如果一个应用程序没有验证内容类型，那么它会接触到这种攻击。根据设置,验证内容类型的Spring MVC应用程序仍然可以利用更新URL后缀结尾".json"如下所示:

如果我的应用程序是无状态的呢?这并不意味着你是受保护的。事实上,如果用户对于一个给定的请求不需要在web浏览器中执行任何操作,他们可能仍然容易受到CSRF攻击。

例如,考虑一个应用程序使用一个定制的cookie,其中包含所有的声明进行身份验证,而不是JSESSIONID。当CSRF是由自定义cookie与在该JSESSIONID cookie在前面的例子中相同的方式发送的，请求被发送。

使用基本身份验证的用户也容易受到CSRF攻击，因为浏览器会自动包括以同样的方式，在我们前面的例子中该JSESSIONID的cookie会发送任何请求的用户名密码。

防止CSRF攻击的第一步是确保你的网站使用适当的HTTP动词。具体来说，前Spring Security的CSRF支持可以使用，你需要确定你的应用程序使用PATCH，POST, PUT, and/or DELETE对于任何修改状态。

这不是一个Spring安全限制的支持，而是进行适当的预防CSRF的一般要求。原因是包括在一个HTTP GET私人信息可能导致的信息泄露。看到 RFC 2616 Section 15.1.3在URI的敏感信息编码 一般的指导对于敏感信息使用POST而不是GET。

下一步是要包括你的应用程序中的Spring Security的CSRF保护。有些框架处理无效CSRF无效用户的会话令牌，而这将导致 其自身的问题。相反，在默认情况下Spring Security的CSRF保护将产生一个HTTP 403访问被拒绝。这可以通过配置AccessDeniedHandler以不同方式处理。

Spring Security 4.0,CSRF保护与XML配置默认启用。如果你想禁用CSRF保护,下面可以看到相应的XML配置。

CSRF保护默认情况下使用Java配置启用。如果您想禁用CSRF，下面可以看到相应的Java配置。请参考Javadoc中的CSRF()在CSRF保护是如何自定义配置的。

一个问题是,预期CSRF令牌存储在HttpSession中,所以一旦HttpSession到期你的配置将收到一个InvalidCsrfTokenException AccessDeniedHandler。如果您使用的是默认的AccessDeniedHandler,浏览器将会得到一个HTTP 403并显示错误消息。

一个简单的方法，有一些JavaScript可以减轻一个活跃的用户体验超时，让用户知道他们的会话即将到期。用户可以点击一个按钮继续，并刷新会话。

另外，指定一个自定义的AccessDeniedHandler允许你以任何你喜欢的方式处理InvalidCsrfTokenException。 有关如何自定义AccessDeniedHandler的例子参考提供的链接为 xml 和 Java configuration.

最后，应用程序可以配置为使用 CookieCsrfTokenRepository这将不会过期。 正如前面提到的,这不是安全的使用一个会话,但在许多情况下已经足够好。

为了防止 forging登录请求 在登录表单中应该也要防止CSRF攻击。因为CsrfToken存储在HttpSession中，这意味着一个HttpSession将尽快创建CsrfToken令牌属性进行访问。 虽然这听起来很糟糕，一个RESTful / stateless的体系结构对于实现实际的安全是必要的。如果没有的状态，我们什么都没有，如果令牌被攻破，我们可以做的。实事求是地讲，在CSRF令牌的尺寸非常小，应该对我们的架构可以忽略不计的影响。如果没有状态，如果令牌被攻破，我们没有什么可以做的。实际上,CSRF令牌的规模和体系结构很小应该对我们的架构有一个微不足道的影响。

一种保护登录常用技术是使用一个javascript函数在表单提交之前获得一个有效的CSRF令牌。通过这样做，没有必要去想会话超时因为表单提交前有创建会话（在上一节中讨论） (假设 CookieCsrfTokenRepository 没有配置而不是), 因此，用户当他想提交用户名/密码可以停留在登录页面上为了达到这个目标,你可以采取Spring Security提供的CsrfTokenArgumentResolver的优势，并像它在这里描述暴露的端点。

添加CSRF将更新LogoutFilter只使用HTTP POST。这确保了注销需要CSRF令牌和一个恶意的用户不能强制注销用户。

一种方法是使用一种形式的日志。如果你真的想要一个链接，你可以（即也许隐藏表单）使用JavaScript，让链接执行POST。对于禁止使用JavaScript的浏览器,您可以选择有链接的用户注销确认页面执行POST。

如果你真的想使用HTTP GET注销你可以这样做,但请记住这一般不推荐。例如,下面的Java配置将执行任意的HTTP方法请求URL /logout执行注销:

有两个选项来使用CSRF保护multipart/form-data.每个选项都有其权衡。

该HiddenHttpMethodFilter应放在Spring Security的过滤器之前。一般来说这是事实，但它可能能够对防止CSRF攻击有更多的影响。

请注意，HiddenHttpMethodFilter只覆盖一个POST HTTP方法，所以这实际上是不可能造成任何实际问题。但是，它仍然是最好的做法，以确保它被放置在Spring Security过滤器之前。

在过去的Spring Security要求你提供自己的缓存控制您的web应用程序。这似乎是合理的,但是浏览器缓存已经进化到包括缓存安全连接。这意味着用户可以查看经过身份验证的页面,注销,然后恶意用户可以使用浏览器历史记录查看缓存页面。为了帮助缓解Spring Security增加了对高速缓存控制的支持，这将插入以下头部作为你的回应。

简单的添加<头部 没有子元素的元素会自动添加缓存控制和不少其他保护措施。 不过，如果你只想要缓存控制，你可以使用Spring Security的XML命名空间与 <cache-control> 元素和headers@defaults-disabled 属性。

同样，您可以在Java配置中启用缓存控制类似以下:

如果你真的想要缓存特定的反应,您的应用程序可以选择性地调用 HttpServletResponse.setHeader(String,String) 覆盖头部Spring Security的设置。为了保证CSS，JavaScript之类的东西是用的并且图像正确缓存。

当使用Spring Web MVC,这通常是在你的配置中。例如,下面的配置设置将确保缓存头你所有的资源:

历史上的浏览器，包括Internet Explorer，试图想请求的内容类型使用 content sniffing。这就使得浏览器通过猜测来改善用户体验的内容类型没有指定内容类型的资源。例如,如果一个浏览器遇到一个JavaScript文件,该文件没有指定的内容类型,它会猜内容类型,然后执行它。

content sniffing的问题是，这允许恶意用户使用polyglots（即一个文件，是作为多种内容类型有效）来执行XSS攻击。例如，某些网站可能会允许用户提交一个有效的PostScript文档到网站，并查看它。恶意用户可能会创建一个 postscript文件，这也是一个有效的JavaScript文件 并用它执行XSS攻击。

通过添加以下content sniffing可以禁用我们的响应头:

就像缓存控制元件,nosniff指令添加默认情况下使用<headers>元素时,没有子元素。 然而,如果你想要更多的控制,添加头文件可以使用 <content-type-options>元素和headers@defaults-disabled属性，如下所示:

X-Content-Type-Options头默认情况下使用Spring Security添加Java配置。如果你想要更多的控制头,您可以显式地指定以下内容类型选项:

当你输入你的银行的网站,你输入mybank.example.com 或者你输入 https://mybank.example.com? 如果您省略https协议,你可能容易受到 中间人攻击。即使网站执行重定向到 https://mybank.example.com 恶意用户能够拦截最初的HTTP请求和操作响应(即重定向到 https://mibank.example.com 和窃取他们的凭证)。

很多用户忽略了https协议，这就是为什么 HTTPHTTP严格传输安全（HSTS） 已创建。一旦mybank.example.com 添加为 HSTS host,浏览器可以提前知道任何请求 mybank.example.com 应该解读为 https://mybank.example.com.这大大降低了发生中间人攻击的可能性。

一个网站被标记为HSTS主机有主机预装到浏览器的一个方法。另一种是将"Strict-Transport-Security"头添加到响应。例如，以下将指示浏览器把域作为一年的HSTS主机（一年有大约31536000秒）:

可选includeSubDomains指令指示Spring安全子域(即secure.mybank.example.com)也应该被视为一个 HSTS域。

至于其它头部，Spring Security的默认添加HSTS。您可以自定义HSTS头部与<hsts>元素如下所示:

类似地,您可以只启用HSTS头与Java配置:

HTTP Public Key Pinning (HPKP) 是一个安全特性，它讲述了一个web客户端关联特定加密公钥与一个特定的web服务器以防止中间人(MITM)攻击和伪造的证书。

为了确保在TLS会话中使用服务器的公钥的真实性，这个公钥被包装成一个X。509证书通常由一个证书颁发机构(CA)签名。Web客户端如浏览器信任了很多这些CA，这都可以创建任意域名证书。 如果攻击者能够破坏一个CA，他们可以执行各种TLS连接MITM攻击。 HPKP可以规避HTTPS协议这一威胁,告诉客户端公钥属于一个特定的web服务器。 HPKP是在首次使用(TOFU)技术信托。第一次web服务器经由该公钥属于它的特殊HTTP头告诉客户端，客户端存储此信息的给定时间段。 当客户端访问服务器,它预计包含公钥证书的指纹通过HPKP已知。如果服务器提供一个未知的公共密钥，客户端应呈现警告给用户。

为你的网站启用这个特性很简单,当在HTTPS访问你的网站时返回Public-Key-Pins HTTP头。 例如，以下将指导用户代理只报告密码验证失败的给定URI(via the report-uri directive) 2 引脚:

一个 pin 验证失败 report 是一个标准的JSON结构,可以捕获通过web应用程序的API或HPKP主办的公开报告服务, 比如, REPORT-URI.

可选的includeSubDomains指令指示浏览器也与给定引脚验证子域。

相对于其他的头部，Spring Security没有默认添加HPKP。你可以定制HPKP头与<hpkp> 元素如下所示:

同样，您可以启用Java配置HPKP头:

允许给你的网站添加框架可能是一个安全问题。例如，使用巧妙的CSS样式用户可能会被欺骗点击的东西，他们不打算 (video demo)。 例如，登录到他们的银行用户可能会点击一个按钮授予其他用户访问。这种攻击被称为 Clickjacking.

有很多方法来缓解点击劫持攻击。例如，为了保护您可以使用传统的点击劫持的攻击的浏览器 frame breaking code. 虽然并不完美，但断码的框架是可以为传统的浏览器做的最好的。

解决点击劫持更先进的方法是使用 X-Frame-Options 头:

X-Frame-Options响应头指示浏览器阻止任何网站，这个头在响应中被呈现在一个框架中。 默认情况下,Spring Security禁用iframe内呈现。

你可以定制X-Frame-Options和 frame-options 元素。 例如,以下将指示Spring Security用 "X-Frame-Options: SAMEORIGIN" 允许iframes在同一个域:

同样，您可以自定义框架选项在Java配置中使用相同的起源:

有些浏览器已经内置支持过滤掉 reflected XSS attacks。这决不是完整的证明,但协助XSS的保护。

过滤通常是默认启用,所以添加头部通常只是确保它被启用和指示浏览器检测到XSS攻击时该做什么。例如,过滤器可能试图改变的内容至少入侵方式仍然呈现一切。有时,这种类型的替代可以成为 XSS 漏洞本身。相反，它是最好的阻止内容，而不是试图修复它。要做到这一点，我们可以添加以下头部:

在默认情况下已经包括了这个头。然而，我们可以自定义它，如果我们想。 例如:

同样，您可以在Java配置中自定义XSS保护如下:

Content Security Policy (CSP)是一个web应用程序可以利用的机制来减轻内容注入漏洞,如跨站点脚本（XSS）。 CSP是一种声明性政策,为web应用程序提供了一个工具的作者声明，并最终通知客户端(用户代理)对web应用程序的来源将加载资源。

web应用程序可以通过使用CSP使用下列其中一个HTTP头的响应:

每个这些头被用作一种机制，以提供一个 security policy 到客户端。 安全策略包含了一组 security policy directives (例如, script-src 和 object-src), 每个负责宣布限制为特定的资源表示形式。

例如，Web应用程序可以声明，预计加载特定，可信来源的脚本，通过再响应以下头部:

试图加载脚本以外另一个来源是什么中声明script-src指令将被用户代理。 此外，如果 report-uri 指令在安全政策声明，然后违反将由用户代理来声明的URL进行报告.

例如,如果一个web应用程序违反了安全政策声明,下面的响应头将指导用户代理发送违反政策的报告中指定的URL report-uri 指令。

Violation reports 是标准JSON结构,可以捕获通过web应用程序的API或公开托管CSP违反报告服务,比如, REPORT-URI.

Content-Security-Policy-Report-Only头提供了web应用程序的作者的能力和管理员监控安全策略,而不是执行它们。 这个头通常用在当试验and/or开发一个网站的安全策略。 当一个政策被认为是有效的,它可以执行使用 Content-Security-Policy 头字段。

鉴于以下响应头,政策声明脚本可能加载两种可能的来源。

如果违反了这一政策,试图从 evil.加载脚本, 用户代理将发送一个违反报告宣布 _report-uri 指令指定的URL,但仍然允许违反资源负载。

也许有些时候你希望注入自定义的安全标头不支持您的应用程序的。例如,下面的自定义安全头:

当使用XML命名空间,这些头部可以添加到响应使用 <header>元素如下所示:

同样，头部可以在Java配置中添加到响应如下所示:

当命名空间或Java配置不支持你想要的头部你可以自定义一个HeadersWriter 实例甚至提供一个自定义实现的 HeadersWriter。

让我们看看一个例子使用一个自定义的XFrameOptionsHeaderWriter的实例。也许你想允许框架内容有着相同的起源。这很容易支持通过设置 policy 属性 "SAMEORIGIN", 但让我们看看一个更明确的例子使用 ref 属性。

我们还可以限制框架的内容为与Java配置相同的起源:

有时你可能想要只对某些请求写头部。例如,也许你想只保护你的登录页面不被攻击，你可以使用 DelegatingRequestMatcherHeaderWriter 。 当使用XML命名空间配置, 这可以如下所示:

我们还可以使用java配置防止框架的内容到登录页面:

建立并发控制通过命名空间或使用bean具有有益的副作用，为您提供一个参考的` sessionregistry 可以直接应用在在您的应用程序.因此,即使你不想限制用户会话的数量,它可能值得建立基础设施.你可以建立`maximumSession财产到- 1允许无限的会话.如果你使用的命名空间，您可以利用session-registry-alias属性为内部创建SessionRegistry的别名设置.提供一个参考，你可以注射到你自己的bean.

getAllPrincipals()方法为您提供当前身份验证的用户的列表.您可以列出用户会话通过呼叫getAllSessions(Object principal, boolean includeExpiredSessions)方法，返回SessionInformation对象列表.您也可以终止用户会话通过在SessionInformation实例中呼叫expireNow()，当用户返回到应用程序时，他们将被阻止进行。您可能会发现这些方法在一个管理应用程序中是有用的，例如.看看javadoc的更多信息

In order to properly secure your application it is important to understand Spring’s WebSocket support.

Spring contains a section titled Flow of Messages that describes how messages flow through the system. It is important to note that Spring Security only secures the clientInboundChannel. Spring Security does not attempt to secure the clientOutboundChannel.

The most important reason for this is performance. For every message that goes in, there are typically many more that go out. Instead of securing the outbound messages, we encourage securing the subscription to the endpoints.

Consider the following scenario. A user visits bank.com and authenticates to their account. The same user opens another tab in their browser and visits evil.com. The Same Origin Policy ensures that evil.com cannot read or write data to bank.com.

With WebSockets the Same Origin Policy does not apply. In fact, unless bank.com explicitly forbids it, evil.com can read and write data on behalf of the user. This means that anything the user can do over the websocket (i.e. transfer money), evil.com can do on that users behalf.

Since SockJS tries to emulate WebSockets it also bypasses the Same Origin Policy. This means developers need to explicitly protect their applications from external domains when using SockJS.

Fortunately, since Spring 4.1.5 Spring’s WebSocket and SockJS support restricts access to the current domain. Spring Security adds an additional layer of protection to provide defence in depth.

By default Spring Security requires the CSRF token in any CONNECT message type. This ensures that only a site that has access to the CSRF token can connect. Since only the Same Origin can access the CSRF token, external domains are not allowed to make a connection.

Typically we need to include the CSRF token in an HTTP header or an HTTP parameter. However, SockJS does not allow for these options. Instead, we must include the token in the Stomp headers

Applications can obtain a CSRF token by accessing the request attribute named _csrf. For example, the following will allow accessing the CsrfToken in a JSP:

If you are using static HTML, you can expose the CsrfToken on a REST endpoint. For example, the following would expose the CsrfToken on the URL /csrf

The javascript can make a REST call to the endpoint and use the response to populate the headerName and the token.

We can now include the token in our Stomp client. For example:

If you want to allow other domains to access your site, you can disable Spring Security’s protection. For example, in Java Configuration you can use the following:

SockJS may use an transport that leverages an iframe. By default Spring Security will deny the site from being framed to prevent Clickjacking attacks. To allow SockJS frame based transports to work, we need to configure Spring Security to allow the same origin to frame the content.

You can customize X-Frame-Options with the frame-options element. For example, the following will instruct Spring Security to use "X-Frame-Options: SAMEORIGIN" which allows iframes within the same domain:

Similarly, you can customize frame options to use the same origin within Java Configuration using the following:

SockJS uses a POST on the CONNECT messages for any HTTP based transport. Typically we need to include the CSRF token in an HTTP header or an HTTP parameter. However, SockJS does not allow for these options. Instead, we must include the token in the Stomp headers as described in Adding CSRF to Stomp Headers.

It also means we need to relax our CSRF protection with the web layer. Specifically, we want to disable CSRF protection for our connect URLs. We do NOT want to disable CSRF protection for every URL. Otherwise our site will be vulnerable to CSRF attacks.

We can easily achieve this by providing a CSRF RequestMatcher. Our Java Configuration makes this extremely easy. For example, if our stomp endpoint is "/chat" we can disable CSRF protection for only URLs that start with "/chat/" using the following configuration:

If we are using XML based configuration, we can use the csrf@request-matcher-ref. For example: