最小的Spring Security Maven依赖关系集通常如下所示：

如果您正在使用LDAP，OpenID等附加功能，则还需要包含相应的项目模块。

Maven仓库

<repositories>

<!-- ... possibly other repository elements ... -->

<repository>

	<id>spring-snapshot</id>

	<name>Spring Snapshot Repository</name>

	<url>http://repo.spring.io/snapshot</url>

</repository>

</repositories>

<repositories>

<!-- ... possibly other repository elements ... -->

<repository>

	<id>spring-milestone</id>

	<name>Spring Milestone Repository</name>

	<url>http://repo.spring.io/milestone</url>

</repository>

</repositories>

Spring框架

<dependencyManagement>

	<dependencies>

	<dependency>

		<groupId>org.springframework</groupId>

		<artifactId>spring-framework-bom</artifactId>

		<version>{spring-version}</version>

		<type>pom</type>

		<scope>import</scope>

	</dependency>

	</dependencies>

</dependencyManagement>

最小的Spring Security Gradle依赖关系集通常如下所示：

如果您正在使用LDAP，OpenID等附加功能，则还需要包含相应的项目模块。

Gradle存储库

repositories {

	mavenCentral()

}

repositories {

	maven { url 'https://repo.spring.io/snapshot' }

}

repositories {

	maven { url 'https://repo.spring.io/milestone' }

}

使用Spring 4.0.x和Gradle

configurations.all {

	resolutionStrategy.eachDependency { DependencyResolveDetails details ->

		if (details.requested.group == 'org.springframework') {

			details.useVersion '{spring-version}'

		}

	}

}

在Spring Security 3.0中，代码库被细分为独立的jar，这些jar更清楚地区分了不同的功能区域和第三方依赖关系。 如果您使用Maven构建项目，那么这些模块将添加到您的pom.xml中。 即使您不使用Maven，我们也建议您参考pom.xml文件以了解第三方依赖关系和版本。 或者，一个好主意是检查示例应用程序中包含的库。

核心 - spring-security-core.jar

远程处理 - spring-security-remoting.jar

Web - spring-security-web.jar

Config - spring-security-config.jar

LDAP - spring-security-ldap.jar

OAuth 2.0核心 - spring-security-oauth2-core.jar

OAuth 2.0客户端 - spring-security-oauth2-client.jar

OAuth 2.0 JOSE - spring-security-oauth2-jose.jar

ACL - spring-security-acl.jar

CAS - spring-security-cas.jar

OpenID - spring-security-openid.jar

测试 - spring-security-test.jar

由于Spring Security是一个开源项目，我们强烈建议您使用git来检查源代码。 这将使您可以完全访问所有示例应用程序，并且可以轻松构建项目的最新版本。 拥有项目的源代码对于调试也有很大的帮助。 异常堆栈跟踪不再是晦涩难解的黑盒问题，但您可以直接找到导致问题的线路并计算出发生的情况。 源代码是项目的最终文档，通常是查找实际内容的最简单方式。

要获得项目的源代码，请使用以下git命令：

这将使您可以访问本地计算机上的整个项目历史记录（包括所有版本和分支机构）。

import org.springframework.beans.factory.annotation.Autowired;

import org.springframework.context.annotation.*;

import org.springframework.security.config.annotation.authentication.builders.*;

import org.springframework.security.config.annotation.web.configuration.*;

@EnableWebSecurity

public class WebSecurityConfig implements WebMvcConfigurer {

	@Bean

	public UserDetailsService userDetailsService() throws Exception {

		InMemoryUserDetailsManager manager = new InMemoryUserDetailsManager();

		manager.createUser(User.withDefaultPasswordEncoder().username("user").password("password").roles("USER").build());

		return manager;

	}

}

下一步是向战争注册{{0}。 这可以在Servlet 3.0+环境中的 Spring的WebApplicationInitializer支持的Java配置中完成。 不出所料，Spring Security提供了一个基类AbstractSecurityWebApplicationInitializer，可确保springSecurityFilterChain为您注册。 我们使用AbstractSecurityWebApplicationInitializer的方式取决于我们是否已经使用Spring，或者Spring Security是我们应用程序中唯一的Spring组件。

• [abstractsecuritywebapplicationinitializer-without-existing-spring] - 如果您尚未使用Spring，请使用这些说明

• [abstractsecuritywebapplicationinitializer-with-spring-mvc] - 如果您已经在使用Spring，请使用这些说明

不存在Spring的==== AbstractSecurityWebApplicationInitializer

如果您没有使用Spring或Spring MVC，则需要将WebSecurityConfig传递给超类，以确保获取配置。 你可以在下面找到一个例子：

SecurityWebApplicationInitializer将执行以下操作：

• 为应用程序中的每个URL自动注册springSecurityFilterChain过滤器

• 添加加载WebSecurityConfig的ContextLoaderListener。

具有Spring MVC的AbstractSecurityWebApplicationInitializer。====

如果我们在应用程序的其他地方使用Spring，我们可能已经有一个加载我们的Spring配置的WebApplicationInitializer。 如果我们使用以前的配置，我们会得到一个错误。 相反，我们应该使用现有的ApplicationContext注册Spring Security。 例如，如果我们使用Spring MVC，我们的SecurityWebApplicationInitializer将如下所示：

这只会为应用程序中的每个URL注册springSecurityFilterChain过滤器。 之后，我们将确保WebSecurityConfig在我们现有的ApplicationInitializer中加载。 例如，如果我们使用Spring MVC，它将被添加到getRootConfigClasses()

protected void configure(HttpSecurity http) throws Exception {

	http

		.authorizeRequests()

			.anyRequest().authenticated()

			.and()

		.formLogin()

			.and()

		.httpBasic();

}

<http>

	<intercept-url pattern="/**" access="authenticated"/>

	<form-login />

	<http-basic />

</http>

protected void configure(HttpSecurity http) throws Exception {

	http

		.authorizeRequests()

			.anyRequest().authenticated()

			.and()

		.formLogin()

			.loginPage("/login")

			.permitAll();

}

<c:url value="/login" var="loginUrl"/>

<form action="${loginUrl}" method="post">

	<c:if test="${param.error != null}">

		<p>

			Invalid username and password.

		</p>

	</c:if>

	<c:if test="${param.logout != null}">

		<p>

			You have been logged out.

		</p>

	</c:if>

	<p>

		<label for="username">Username</label>

		<input type="text" id="username" name="username"/>

	</p>

	<p>

		<label for="password">Password</label>

		<input type="password" id="password" name="password"/>

	</p>

	<input type="hidden"

		name="${_csrf.parameterName}"

		value="${_csrf.token}"/>

	<button type="submit" class="btn">Log in</button>

</form>

protected void configure(HttpSecurity http) throws Exception {

	http

		.authorizeRequests()

			.antMatchers("/resources/**", "/signup", "/about").permitAll()

			.antMatchers("/admin/**").hasRole("ADMIN")

			.antMatchers("/db/**").access("hasRole('ADMIN') and hasRole('DBA')")

			.anyRequest().authenticated()

			.and()

		// ...

		.formLogin();

}

protected void configure(HttpSecurity http) throws Exception {

	http

		.logout()

			.logoutUrl("/my/logout")

			.logoutSuccessUrl("/my/index")

			.logoutSuccessHandler(logoutSuccessHandler)

			.invalidateHttpSession(true)

			.addLogoutHandler(logoutHandler)

			.deleteCookies(cookieNamesToClear)

			.and()

		...

}

通常，LogoutHandler 实现指示能够参与注销处理的类。 预计它们将被调用来执行必要的清理。 因此他们应该 不会抛出异常。 提供了各种实现：

• {安全API-URL}组织/ springframework的/安全/网络/认证/了rememberMe / PersistentTokenBasedRememberMeServices.html [对PersistentTokenBasedRememberMeServices]

• {安全API-URL}组织/ springframework的/安全/网络/认证/了rememberMe / TokenBasedRememberMeServices.html [TokenBasedRememberMeServices]

• {安全API-URL}组织/ springframework的/安全/网络/认证/注销/ CookieClearingLogoutHandler.html [CookieClearingLogoutHandler]

• {安全API-URL}组织/ springframework的/安全/网络/ CSRF / CsrfLogoutHandler.html [CsrfLogoutHandler]

• {安全API-URL}组织/ springframework的/安全/网络/认证/注销/ SecurityContextLogoutHandler.html [SecurityContextLogoutHandler]

有关详细信息，请参阅记住我的接口和实现。

Fluent API不是直接提供LogoutHandler实现，而是提供了快捷方式，它们提供了相应的LogoutHandler实现。 例如。 deleteCookies()允许指定在注销成功时删除一个或多个Cookie的名称。 与添加CookieClearingLogoutHandler相比，这是一条捷径。

在LogoutFilter成功注销后调用LogoutSuccessHandler，以处理例如 重定向或转发到适当的目的地。 请注意，界面与LogoutHandler几乎相同，但可能会引发异常。

提供了以下实现：

• {安全API-URL}组织/ springframework的/安全/网络/认证/注销/ SimpleUrlLogoutSuccessHandler.html [SimpleUrlLogoutSuccessHandler]

• HttpStatusReturningLogoutSuccessHandler

如上所述，您不需要直接指定SimpleUrlLogoutSuccessHandler。 相反，流利的API通过设置logoutSuccessUrl()来提供快捷方式。 这将设置封面下的SimpleUrlLogoutSuccessHandler。 提供的URL将在注销发生后重定向到。 默认值是/login?logout。

REST API类型场景中的HttpStatusReturningLogoutSuccessHandler可能很有趣。 取而代之的是在成功注销后重定向到URL，这个LogoutSuccessHandler允许您提供一个简单的HTTP状态代码来返回。 如果未配置，则缺省情况下将返回状态代码200。

• Logout Handling

• Testing Logout

• HttpServletRequest.logout()

• 记住我的接口和实现 CSRF警告部分中的-  Logging Out

• 部分Single Logout（CAS协议）

• Spring Security XML命名空间部分中logout element的文档

您可以在下面找到最低限度的WebFlux安全配置：

此配置提供表单和http基本身份验证，设置授权以要求经过身份验证的用户访问任何页面，设置默认登录页面和默认注销页面，设置与安全性相关的HTTP标头，CSRF保护等。

您可以在下面找到最小WebFlux安全配置的显式版本：

该配置明确设置了与我们最小配置相同的所有内容。 从这里您可以轻松地对默认值进行更改。

Spring Boot 2.0为OAuth 2.0登录带来了全面的自动配置功能。

本节介绍如何使用Google作为Authentication Provider配置{gh-samples-url} / boot / oauth2login [OAuth 2.0 Login sample]，并涵盖以下主题：

• Initial setup

• Setting the redirect URI

• Configure application.yml

• Boot up the application

初始设置

设置重定向URI

配置application.yml

启动应用程序

ClientRegistration是向OAuth 2.0或OpenID Connect 1.0 Provider注册的客户端的代表。

客户端注册保存信息，如客户端ID，客户端密码， 授权授权类型，重定向URI，范围，授权URI，令牌URI和其他详细信息。

ClientRegistration及其属性定义如下：

下表概述了Spring Boot 2.0 OAuth客户端属性到ClientRegistration属性的映射。

ClientRegistrationRepository充当OAuth 2.0 / OpenID Connect 1.0 ClientRegistration（s）的存储库。

Spring Boot 2.0自动配置绑定spring.security.oauth2.client.registration.[registrationId]下的每个属性 到ClientRegistration的实例，然后在ClientRegistrationRepository内组合ClientRegistration个实例中的每个实例。

自动配置还将ClientRegistrationRepository注册为ApplicationContext中的@Bean 以便它可用于依赖注入，如果应用程序需要的话。

以下列表显示了一个示例：

CommonOAuth2Provider为众多知名供应商预先定义了一组默认客户端属性：Google，GitHub，Facebook和Okta。

例如，authorization-uri，token-uri和user-info-uri不会经常更改提供者。 因此，提供默认值以减少所需的配置是有意义的。

如前所述，当我们configured a Google client时，只需要client-id和client-secret属性。

以下列表显示了一个示例：

对于您可能需要指定不同的registrationId的情况，例如google-login， 您仍然可以通过配置provider属性来利用客户端属性的自动默认功能。

以下列表显示了一个示例：

有一些OAuth 2.0提供商支持多租户，这会为每个租户（或子域）生成不同的协议端点。

例如，向Okta注册的OAuth客户端分配给特定的子域，并拥有自己的协议端点。

对于这些情况，Spring Boot 2.0为配置自定义提供程序属性提供以下基本属性：spring.security.oauth2.client.provider.[providerId]。

以下列表显示了一个示例：

<1>基本属性（spring.security.oauth2.client.provider.okta）允许自定义配置协议端点位置。

用于OAuth客户端支持的Spring Boot 2.0自动配置类为OAuth2ClientAutoConfiguration。

它执行以下任务：

• 从配置的OAuth客户端属性中注册由ClientRegistration（s）组成的ClientRegistrationRepository @Bean。

• 提供WebSecurityConfigurerAdapter @Configuration并通过httpSecurity.oauth2Login()启用OAuth 2.0登录。

如果您需要根据您的特定要求覆盖自动配置，可以通过以下方式进行：

• Register a ClientRegistrationRepository @Bean

• Provide a WebSecurityConfigurerAdapter

• Completely Override the Auto-configuration

注册一个ClientRegistrationRepository @Bean

@Configuration

public class OAuth2LoginConfig {

	@Bean

	public ClientRegistrationRepository clientRegistrationRepository() {

		return new InMemoryClientRegistrationRepository(this.googleClientRegistration());

	}

	private ClientRegistration googleClientRegistration() {

		return ClientRegistration.withRegistrationId("google")

			.clientId("google-client-id")

			.clientSecret("google-client-secret")

			.clientAuthenticationMethod(ClientAuthenticationMethod.BASIC)

			.authorizationGrantType(AuthorizationGrantType.AUTHORIZATION_CODE)

			.redirectUriTemplate("{baseUrl}/login/oauth2/code/{registrationId}")

			.scope("openid", "profile", "email", "address", "phone")

			.authorizationUri("https://accounts.google.com/o/oauth2/v2/auth")

			.tokenUri("https://www.googleapis.com/oauth2/v4/token")

			.userInfoUri("https://www.googleapis.com/oauth2/v3/userinfo")

			.userNameAttributeName(IdTokenClaimNames.SUB)

			.jwkSetUri("https://www.googleapis.com/oauth2/v3/certs")

			.clientName("Google")

			.build();

	}

}

提供WebSecurityConfigurerAdapter

@EnableWebSecurity

public class OAuth2LoginSecurityConfig extends WebSecurityConfigurerAdapter {

	@Override

	protected void configure(HttpSecurity http) throws Exception {

		http

			.authorizeRequests()

				.anyRequest().authenticated()

				.and()

			.oauth2Login();

	}

}

完全覆盖自动配置

@Configuration

public class OAuth2LoginConfig {

	@EnableWebSecurity

	public static class OAuth2LoginSecurityConfig extends WebSecurityConfigurerAdapter {

		@Override

		protected void configure(HttpSecurity http) throws Exception {

			http

				.authorizeRequests()

					.anyRequest().authenticated()

					.and()

				.oauth2Login();

		}

	}

	@Bean

	public ClientRegistrationRepository clientRegistrationRepository() {

		return new InMemoryClientRegistrationRepository(this.googleClientRegistration());

	}

	private ClientRegistration googleClientRegistration() {

		return ClientRegistration.withRegistrationId("google")

			.clientId("google-client-id")

			.clientSecret("google-client-secret")

			.clientAuthenticationMethod(ClientAuthenticationMethod.BASIC)

			.authorizationGrantType(AuthorizationGrantType.AUTHORIZATION_CODE)

			.redirectUriTemplate("{baseUrl}/login/oauth2/code/{registrationId}")

			.scope("openid", "profile", "email", "address", "phone")

			.authorizationUri("https://accounts.google.com/o/oauth2/v2/auth")

			.tokenUri("https://www.googleapis.com/oauth2/v4/token")

			.userInfoUri("https://www.googleapis.com/oauth2/v3/userinfo")

			.userNameAttributeName(IdTokenClaimNames.SUB)

			.jwkSetUri("https://www.googleapis.com/oauth2/v3/certs")

			.clientName("Google")

			.build();

	}

}

@Configuration

public class OAuth2LoginConfig {

	@EnableWebSecurity

	public static class OAuth2LoginSecurityConfig extends WebSecurityConfigurerAdapter {

		@Override

		protected void configure(HttpSecurity http) throws Exception {

			http

				.authorizeRequests()

					.anyRequest().authenticated()

					.and()

				.oauth2Login();

		}

	}

	@Bean

	public ClientRegistrationRepository clientRegistrationRepository() {

		return new InMemoryClientRegistrationRepository(this.googleClientRegistration());

	}

	@Bean

	public OAuth2AuthorizedClientService authorizedClientService() {

		return new InMemoryOAuth2AuthorizedClientService(this.clientRegistrationRepository());

	}

	private ClientRegistration googleClientRegistration() {

		return CommonOAuth2Provider.GOOGLE.getBuilder("google")

			.clientId("google-client-id")

			.clientSecret("google-client-secret")

			.build();

	}

}

OAuth2AuthorizedClient是授权客户端的代表。 当最终用户（资源所有者）授予客户端访问其受保护资源的权限时，客户端被认为是被授权的。

OAuth2AuthorizedClient用于将OAuth2AccessToken与ClientRegistration（客户端）和资源所有者关联起来，该所有者是授予授权的Principal最终用户。

OAuth2AuthorizedClientService的主要作用是管理OAuth2AuthorizedClient个实例。 从开发人员的角度来看，它提供了查找与客户端关联的OAuth2AccessToken的功能，以便它可以用来发起对资源服务器的请求。

开发人员还可以在ApplicationContext（覆盖Spring Boot 2.0自动配置）中注册OAuth2AuthorizedClientService@Bean，以便能够查找与特定相关的OAuth2AccessToken ClientRegistration（客户端）。

以下列表显示了一个示例：

以下其他资源介绍了高级配置选项：

• OAuth 2.0 Login Page

• 授权端点：

  • AuthorizationRequestRepository

• Redirection Endpoint

• 令牌端点：

  • OAuth2AccessTokenResponseClient

• UserInfo端点：

  • Mapping User Authorities

  • Configuring a Custom OAuth2User

  • OAuth 2.0 UserService

  • OpenID Connect 1.0 UserService

我们已经看到了为单个用户配置内存认证的例子。 以下是配置多个用户的示例：

您可以找到更新以支持基于JDBC的身份验证。 以下示例假定您已经在应用程序中定义了DataSource。 jdbc-javaconfig示例提供了使用基于JDBC的身份验证的完整示例。

您可以找到更新以支持基于LDAP的身份验证。 ldap-javaconfig示例提供了使用基于LDAP的身份验证的完整示例。

上面的示例使用以下LDIF和嵌入式Apache DS LDAP实例。

您可以通过将自定义AuthenticationProvider公开为bean来定义自定义身份验证。 例如，假设SpringAuthenticationProvider实现AuthenticationProvider，以下将自定义认证：

注：仅当AuthenticationManagerBuilder尚未填充时才会使用

您可以通过将自定义UserDetailsService公开为bean来定义自定义身份验证。 例如，假设SpringDataUserDetailsService实现UserDetailsService，以下将自定义认证：

注意：仅当AuthenticationManagerBuilder尚未填充且未定义AuthenticationProviderBean时才会使用此选项。

您还可以通过将PasswordEncoder公开为bean来自定义密码的编码方式。 例如，如果您使用bcrypt，则可以添加一个bean定义，如下所示：

@EnableWebSecurity

public class MultiHttpSecurityConfig {

	@Bean

	public UserDetailsService userDetailsService() throws Exception {

		// ensure the passwords are encoded properly

		UserBuilder users = User.withDefaultPasswordEncoder();

		InMemoryUserDetailsManager manager = new InMemoryUserDetailsManager();

		manager.createUser(users.username("user").password("password").roles("USER").build());

		manager.createUser(users.username("admin").password("password").roles("USER","ADMIN").build());

		return manager;

	}

	@Configuration

	@Order(1)

	public static class ApiWebSecurityConfigurationAdapter extends WebSecurityConfigurerAdapter {

		protected void configure(HttpSecurity http) throws Exception {

			http

				.antMatcher("/api/**")

				.authorizeRequests()

					.anyRequest().hasRole("ADMIN")

					.and()

				.httpBasic();

		}

	}

	@Configuration

	public static class FormLoginWebSecurityConfigurerAdapter extends WebSecurityConfigurerAdapter {

		@Override

		protected void configure(HttpSecurity http) throws Exception {

			http

				.authorizeRequests()

					.anyRequest().authenticated()

					.and()

				.formLogin();

		}

	}

}

我们可以在任何@Configuration实例上使用@EnableGlobalMethodSecurity注释来启用基于注释的安全性。 例如，以下内容将启用Spring Security的@Secured注释。

然后向方法（在类或接口上）添加注释将相应地限制对该方法的访问。 Spring Security的本地注释支持为该方法定义了一组属性。 这些将被传递给AccessDecisionManager以供它作出实际的决定：

可以使用支持JSR-250注释

这些都是基于标准的，允许应用简单的基于角色的约束，但是没有Spring Security的本地注释的强大功能。 要使用新的基于表达式的语法，您可以使用

和等效的Java代码将会是

有时您可能需要执行比@EnableGlobalMethodSecurity批注允许的操作更复杂的操作。 对于这些实例，您可以扩展GlobalMethodSecurityConfiguration，确保@EnableGlobalMethodSecurity注释存在于您的子类中。 例如，如果您想提供自定义MethodSecurityExpressionHandler，则可以使用以下配置：

有关可覆盖的方法的其他信息，请参阅GlobalMethodSecurityConfiguration Javadoc。

Spring Security通过使用ReactiveSecurityContextHolder设置的https://projectreactor.io/docs/core/release/reference/#context[Reactor’s Context]支持方法安全性。 例如，这将演示如何检索当前登录的用户的消息。

与this::findMessageByUsername定义为：

以下是在反应式应用程序中使用方法安全性时的最小方法安全配置。

考虑以下课程：

结合上述配置，@PreAuthorize("hasRole('ADMIN')")将确保findByMessage仅由具有角色ADMIN的用户调用。 请注意，标准方法安全性中的任何表达式都适用于@EnableReactiveMethodSecurity。 但是，目前我们只支持表达式的Boolean或boolean的返回类型。 这意味着表达式不能阻止。

当与WebFlux安全进行集成时，Spring Security会根据经过验证的用户自动建立Reactor Context。

您可以在{gh-samples-url} / javaconfig / hellowebflux-method [hellowebflux-method]中找到完整的示例

@Override

protected void configure(HttpSecurity http) throws Exception {

	http

		.authorizeRequests()

			.anyRequest().authenticated()

			.withObjectPostProcessor(new ObjectPostProcessor<FilterSecurityInterceptor>() {

				public <O extends FilterSecurityInterceptor> O postProcess(

						O fsi) {

					fsi.setPublishAuthorizationSuccess(true);

					return fsi;

				}

			});

}

public class MyCustomDsl extends AbstractHttpConfigurer<MyCustomDsl, HttpSecurity> {

	private boolean flag;

	@Override

	public void init(H http) throws Exception {

		// any method that adds another configurer

		// must be done in the init method

		http.csrf().disable();

	}

	@Override

	public void configure(H http) throws Exception {

		ApplicationContext context = http.getSharedObject(ApplicationContext.class);

		// here we lookup from the ApplicationContext. You can also just create a new instance.

		MyFilter myFilter = context.getBean(MyFilter.class);

		myFilter.setFlag(flag);

		http.addFilterBefore(myFilter, UsernamePasswordAuthenticationFilter.class);

	}

	public MyCustomDsl flag(boolean value) {

		this.flag = value;

		return this;

	}

	public static MyCustomDsl customDsl() {

		return new MyCustomDsl();

	}

}

@EnableWebSecurity

public class Config extends WebSecurityConfigurerAdapter {

	@Override

	protected void configure(HttpSecurity http) throws Exception {

		http

			.apply(customDsl())

				.flag(true)

				.and()

			...;

	}

}

org.springframework.security.config.annotation.web.configurers.AbstractHttpConfigurer = sample.MyCustomDsl

@EnableWebSecurity

public class Config extends WebSecurityConfigurerAdapter {

	@Override

	protected void configure(HttpSecurity http) throws Exception {

		http

			.apply(customDsl()).disable()

			...;

	}

}

<security:ldap-server />

<beans xmlns="http://www.springframework.org/schema/beans"

xmlns:security="http://www.springframework.org/schema/security"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://www.springframework.org/schema/beans

		http://www.springframework.org/schema/beans/spring-beans-3.0.xsd

		http://www.springframework.org/schema/security

		http://www.springframework.org/schema/security/spring-security.xsd">

	...

</beans>

<beans:beans xmlns="http://www.springframework.org/schema/security"

xmlns:beans="http://www.springframework.org/schema/beans"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://www.springframework.org/schema/beans

		http://www.springframework.org/schema/beans/spring-beans-3.0.xsd

		http://www.springframework.org/schema/security

		http://www.springframework.org/schema/security/spring-security.xsd">

	...

</beans:beans>

命名空间旨在捕获框架的最常见用途，并提供简化和简洁的语法来在应用程序中启用它们。 该设计基于框架内的大规模依赖关系，可分为以下几个方面：

• Web / HTTP Security - 最复杂的部分。 设置用于应用框架认证机制的过滤器和相关服务bean，保护URL，呈现登录和错误页面等等。

• 业务对象（方法）安全性_ - 保护服务层的选项。

• AuthenticationManager - 处理来自框架其他部分的认证请求。

• AccessDecisionManager - 为网络和方法安全提供访问决策。 一个默认的将被注册，但你也可以选择使用一个自定义的，使用普通的Spring bean语法声明。

• AuthenticationProviders - 身份验证管理员验证用户身份的机制。 命名空间为几个标准选项提供了支持，同时也提供了添加使用传统语法声明的自定义bean的方法。

• UserDetailsS​​ervice - 与身份验证提供程序密切相关，但其他bean通常也需要它。

我们将在下面的章节中看到如何配置这些。

您需要做的第一件事是将以下过滤声明添加到您的web.xml文件中：

这为Spring Security Web基础结构提供了一个钩子。 DelegatingFilterProxy是一个Spring框架类，它委派一个过滤器实现，它在应用程序上下文中定义为一个Spring bean。 在这种情况下，bean被命名为"springSecurityFilterChain"，它是由命名空间创建的用于处理Web安全性的内部基础设施bean。 请注意，您不应该自己使用这个bean名称。 将这些内容添加到您的web.xml后，即可开始编辑您的应用程序上下文文件。 Web安全服务使用<http>元素进行配置。

您只需启用网络安全即可

其中说我们希望我们应用程序中的所有URL都受到保护，要求角色ROLE_USER能够访问它们，我们希望使用带有用户名和密码的表单登录应用程序，并且我们希望注册注销URL这将允许我们注销应用程序。 <http>元素是所有与Web相关的名称空间功能的父项。 <intercept-url>元素定义了一个pattern，它使用蚂蚁路径样式语法脚注与传入请求的URL匹配：[请参阅关于传递的部分：特殊字符，宏[请求匹配和HttpFirewall] Web应用程序基础结构一章，了解如何实际执行匹配的更多细节。]。 您也可以使用正则表达式匹配作为替代（有关更多详细信息，请参阅命名空间附录）。 access属性定义匹配给定模式的请求的访问要求。 通过默认配置，这通常是逗号分隔的角色列表，其中一个用户必须被允许发出请求。 前缀"ROLE_"是一个标记，表示应该与用户权限进行简单比较。 换句话说，应该使用正常的基于角色的检查。 Spring Security中的访问控制不限于使用简单角色（因此使用前缀来区分不同类型的安全属性）。 我们稍后会看到解释如何变化脚注：[{0}}属性中逗号分隔值的解释取决于pass的实现：specialcharacters，macros [AccessDecisionManager] 。 在Spring Security 3.0中，该属性也可以使用pass：specialcharacters，macros [EL expression]来填充。

要添加一些用户，您可以直接在命名空间中定义一组测试数据：

这是存储相同密码的安全方式的一个例子。 密码前缀为{bcrypt}，用于指示支持任何已配置的PasswordEncoder进行匹配的DelegatingPasswordEncoder，并使用BCrypt对密码进行散列处理：

上面的配置定义了两个用户，他们的密码和他们在应用程序中的角色（将用于访问控制）。 也可以使用user-service上的properties属性从标准属性文件加载用户信息。 有关文件格式的更多详细信息，请参阅in-memory authentication中的部分。 使用<authentication-provider>元素意味着用户信息将被认证管理器用于处理认证请求。 您可以有多个<authentication-provider>元素来定义不同的身份验证源，并且每个元素都会依次进行查询。

此时您应该能够启动您的应用程序，并且您将需要登录才能继续。 尝试一下，或尝试使用该项目附带的"tutorial"示例应用程序进行试验。

由于我们没有提及任何HTML文件或JSP，因此您可能想知道登录表单从何时被提示登录。 实际上，由于我们没有明确设置登录页面的URL，因此Spring Security会根据启用的功能自动生成一个URL，并使用处理提交的登录的URL的标准值，用户将默认的目标URL在登录后被发送到等等。 但是，命名空间提供了大量的支持来允许您自定义这些选项。 例如，如果您想提供自己的登录页面，则可以使用：

另请注意，我们已经添加了一个额外的intercept-url元素来说明登录页面的任何请求应该可供匿名用户使用脚注：[请参阅关于pass的章节：specialcharacters，macros [匿名身份验证]]以及关于值IS_AUTHENTICATED_ANONYMOUSLY如何处理的更多细节AuthenticatedVoter类。]。 否则，请求将与模式/ **匹配，并且无法访问登录页面本身！ 这是一个常见的配置错误，并且会导致应用程序中出现无限循环。 如果您的登录页面似乎受到保护，Spring Security将在日志中发出警告。 通过为模式定义一个单独的http元素，也可以让所有匹配特定模式的请求完全绕过安全过滤器链，如下所示：

从Spring Security 3.1开始，现在可以使用多个http元素为不同的请求模式定义单独的安全过滤器链配置。 如果从http元素中省略pattern属性，它将匹配所有请求。 创建一个不安全的模式就是这种语法的一个简单例子，其中模式映射到一个空的过滤器链脚注：[使用多个<http>元素是一个重要的特性，允许名称空间同时支持有状态和无状态例如，在同一个应用程序中的路径。 以前使用intercept-url元素上的属性filters="none"的语法与此更改不兼容，并且在3.1中不再支持。]。 我们将在Security Filter Chain一章中更详细地讨论这种新语法。

认识到这些不安全的请求将完全忽略任何Spring Security Web相关配置或诸如requires-channel之类的附加属性是非常重要的，因此您将无法访问当前用户的信息或在请求。 如果您仍希望应用安全筛选器链，请使用access='IS_AUTHENTICATED_ANONYMOUSLY'作为替代方案。

如果您想使用基本身份验证而不是表单登录，请将配置更改为

然后，基本身份验证将优先，并在用户尝试访问受保护资源时用于提示登录。 如果您希望使用此配置，表单登录仍然可用，例如通过嵌入其他网页的登录表单。

设置默认的登录后目的地

<http pattern="/login.htm*" security="none"/>

<http use-expressions="false">

<intercept-url pattern='/**' access='ROLE_USER' />

<form-login login-page='/login.htm' default-target-url='/home.htm'

		always-use-default-target='true' />

</http>

logout元素通过导航到特定的URL添加了对注销的支持。 默认注销网址为/logout，但您可以使用logout-url属性将其设置为其他内容。 关于其他可用属性的更多信息可以在命名空间附录中找到。

在实践中，您将需要一个更可扩展的用户信息来源，而不是添加到应用程序上下文文件中的几个名称。 您很可能希望将您的用户信息存储在数据库或LDAP服务器中。 LDAP命名空间配置在LDAP chapter中处理，所以我们不会在这里介绍它。 如果您在应用程序上下文中有一个名为"myUserDetailsService"的Spring Security {0}}的自定义实现，那么您可以使用这种方法进行身份验证

如果你想使用数据库，那么你可以使用

"securityDataSource"是应用程序上下文中DataSource bean的名称，指向包含标准Spring Security user data tables的数据库。 或者，您可以配置Spring Security JdbcDaoImpl bean并使用user-service-ref属性指向该bean：

您还可以使用标准的AuthenticationProvider bean，如下所示

其中myAuthenticationProvider是您的应用程序上下文中实现AuthenticationProvider的bean的名称。 您可以使用多个authentication-provider元素，在这种情况下，提供程序将按其声明的顺序进行查询。 有关如何使用名称空间配置Spring Security AuthenticationManager的更多信息，请参阅验证管理器和名称空间。

添加密码编码器

<beans:bean name="bcryptEncoder"

	class="org.springframework.security.crypto.bcrypt.BCryptPasswordEncoder"/>

<authentication-manager>

<authentication-provider>

	<password-encoder ref="bcryptEncoder"/>

	<user-service>

	<user name="jimi" password="$2a$10$ddEWZUl8aU0GdZPPpy7wbu82dvEw/pBpbRvDQRqA41y6mK1CoH00m"

			authorities="ROLE_USER, ROLE_ADMIN" />

	<user name="bob" password="$2a$10$/elFpMBnAYYig6KRR5bvOOYeZr1ie1hSogJryg9qDlhza4oCw1Qka"

			authorities="ROLE_USER" />

	</user-service>

</authentication-provider>

</authentication-manager>

有关remember-me命名空间配置的信息，请参阅单独的Remember-Me chapter。

如果您的应用程序同时支持HTTP和HTTPS，并且您要求只能通过HTTPS访问特定的URL，则可以使用<intercept-url>上的requires-channel属性直接支持此功能：

使用此配置，如果用户尝试使用HTTP访问任何匹配"/secure/**"模式的内容，则会首先将其重定向到HTTPS URL脚注：[有关如何实现频道处理的更多详细信息，请参阅Javadoc对于ChannelProcessingFilter和相关类。]。 可用选项为"http"，"https"或"any"。 使用值"any"表示可以使用HTTP或HTTPS。

如果您的应用程序使用HTTP和/或HTTPS的非标准端口，则可以按如下方式指定端口映射列表：

请注意，为了确保安全，应用程序不应该使用HTTP或在HTTP和HTTPS之间切换。 它应该从HTTPS开始（用户输入HTTPS URL）并始终使用安全连接以避免任何可能的中间人攻击。

检测超时

<http>

...

<session-management invalid-session-url="/invalidSession.htm" />

</http>

<http>

<logout delete-cookies="JSESSIONID" />

</http>

<LocationMatch "/tutorial/logout">

Header always set Set-Cookie "JSESSIONID=;Path=/tutorial;Expires=Thu, 01 Jan 1970 00:00:00 GMT"

</LocationMatch>

并发会话控制

<listener>

<listener-class>

	org.springframework.security.web.session.HttpSessionEventPublisher

</listener-class>

</listener>

<http>

...

<session-management>

	<concurrency-control max-sessions="1" />

</session-management>

</http>

<http>

...

<session-management>

	<concurrency-control max-sessions="1" error-if-maximum-exceeded="true" />

</session-management>

</http>

会话固定攻击保护

命名空间支持 OpenID的登录，而不是普通的基于表单的登录，或者除了普通的基于表单的登录外，还可以进行简单的更改：

然后，您应该向OpenID提供商（例如myopenid.com）注册您自己，并将用户信息添加到您的内存<user-service>中：

您应该可以使用myopenid.com网站进行身份验证。 通过设置openid-login元素上的user-service-ref属性，还可以选择特定的UserDetailsService bean来使用OpenID。 有关更多信息，请参阅authentication providers上的上一节。 请注意，我们从上述用户配置中省略了密码属性，因为这组用户数据仅用于为用户加载权限。 随机密码将在内部生成，从而防止您在配置中的其他位置意外地将此用户数据用作身份验证源。

属性交换

<openid-login>

<attribute-exchange>

	<openid-attribute name="email" type="http://axschema.org/contact/email" required="true"/>

	<openid-attribute name="name" type="http://axschema.org/namePerson"/>

</attribute-exchange>

</openid-login>

OpenIDAuthenticationToken token =

	(OpenIDAuthenticationToken)SecurityContextHolder.getContext().getAuthentication();

List<OpenIDAttribute> attributes = token.getAttributes();

有关如何自定义标题元素的其他信息，请参阅参考文献的安全性HTTP响应头部分。

如果您以前使用过Spring Security，那么您会知道该框架维护一系列过滤器以应用其服务。 您可能希望将自己的过滤器添加到特定位置的堆栈中，或者使用当前没有命名空间配置选项（例如CAS）的Spring Security过滤器。 或者您可能想要使用标准名称空间过滤器的自定义版本，例如由<form-login>元素创建的UsernamePasswordAuthenticationFilter，以利用可用的一些额外配置选项显式的bean。 你怎么能用命名空间配置来做到这一点，因为过滤器链不直接暴露？

使用名称空间时，过滤器的顺序始终严格执行。 在创建应用程序上下文时，过滤器bean按名称空间处理代码进行排序，标准Spring Security过滤器在名称空间和知名位置都有一个别名。

[filter-stack]中显示了创建过滤器的过滤器，别名和命名空间元素/属性。 过滤器按照它们在过滤器链中出现的顺序列出。

。标准过滤器别名和排序

您可以使用custom-filter元素和其中一个名称来指定您的过滤器应显示在的位置，您可以将自己的过滤器添加到堆栈中：

如果您希望将过滤器插入堆栈中另一个过滤器之前或之后，也可以使用after或before属性。 名称"FIRST"和"LAST"可以与position属性一起使用，以指示您希望过滤器分别出现在整个堆栈之前或之后。

。避免过滤器位置冲突

如果要替换需要身份验证入口点的名称空间过滤器（即身份验证过程由未经身份验证的用户尝试访问受保护的资源触发），则还需要添加自定义入口点Bean。

设置自定义AuthenticationEntryPoint

此元素用于在应用程序中启用基于注释的安全性（通过在元素上设置适当的属性），并将安全性切入点声明分组在一起，这些声明将应用于整个应用程序上下文中。 您应该只声​​明一个<global-method-security>元素。 以下声明将支持Spring Security的@Secured：

向方法（在类或接口上）添加注释会相应地限制对该方法的访问。 Spring Security的本地注释支持为该方法定义了一组属性。 这些将被传递给AccessDecisionManager，以便做出实际的决定：

可以使用支持JSR-250注释

这些都是基于标准的，允许应用简单的基于角色的约束，但是没有Spring Security的本地注释的强大功能。 要使用新的基于表达式的语法，您可以使用

和等效的Java代码将会是

如果您需要定义简单的规则，而不是根据用户的权限列表检查角色名称，则基于表达式的注释是一个不错的选择。

使用protect-pointcut添加安全性切入点

<global-method-security>

<protect-pointcut expression="execution(* com.mycompany.*Service.*(..))"

	access="ROLE_USER"/>

</global-method-security>

如果您需要使用更复杂的访问控制策略，则很容易为方法和网络安全设置替代方案。

对于方法安全性，您可以通过将global-method-security中的access-decision-manager-ref属性设置为应用程序上下文中相应的AccessDecisionManager bean的id来执行此操作：

Web安全的语法是相同的，但在http元素上：

<authentication-manager>

<authentication-provider ref="casAuthenticationProvider"/>

</authentication-manager>

<bean id="casAuthenticationProvider"

	class="org.springframework.security.cas.authentication.CasAuthenticationProvider">

...

</bean>

<security:authentication-manager alias="authenticationManager">

...

</security:authentication-manager>

<bean id="customizedFormLoginFilter"

	class="com.somecompany.security.web.CustomFormLoginFilter">

<property name="authenticationManager" ref="authenticationManager"/>

...

</bean>

Security Debug Information

Authentication object is of type:

org.springframework.security.authentication.UsernamePasswordAuthenticationToken

Authentication object as a String:

org.springframework.security.authentication.UsernamePasswordAuthenticationToken@1f127853:

Principal: org.springframework.security.core.userdetails.User@b07ed00: Username: rod; \

Password: [PROTECTED]; Enabled: true; AccountNonExpired: true;

credentialsNonExpired: true; AccountNonLocked: true; \

Granted Authorities: ROLE_SUPERVISOR, ROLE_USER; \

Password: [PROTECTED]; Authenticated: true; \

Details: org.springframework.security.web.authentication.WebAuthenticationDetails@0: \

RemoteIpAddress: 127.0.0.1; SessionId: 8fkp8t83ohar; \

Granted Authorities: ROLE_SUPERVISOR, ROLE_USER

Authentication object holds the following granted authorities:

ROLE_SUPERVISOR (getAuthority(): ROLE_SUPERVISOR)

ROLE_USER (getAuthority(): ROLE_USER)

Success! Your web filters appear to be properly configured!

最基本的对象是SecurityContextHolder。 这是我们存储应用程序当前安全上下文的详细信息的地方，其中包括当前使用该应用程序的主体的详细信息。 默认情况下，SecurityContextHolder使用ThreadLocal来存储这些细节，这意味着安全上下文始终可用于同一执行线程中的方法，即使安全上下文没有作为这些方法的论点。 以这种方式使用ThreadLocal是非常安全的，因为如果在处理当前委托人的请求之后谨慎清除线程，那么这是非常安全的。 当然，Spring Security会自动为您处理，因此您无需担心。

有些应用程序并不完全适合使用ThreadLocal，因为它们使用线程的具体方式。 例如，Swing客户端可能希望Java虚拟机中的所有线程使用相同的安全上下文。 可以在启动时使用策略配置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();

}

UserDetails loadUserByUsername(String username) throws UsernameNotFoundException;

除了委托人之外，Authentication提供的另一个重要方法是getAuthorities()。 此方法提供了一组GrantedAuthority对象。 毫不奇怪，GrantedAuthority是授予校长的权威。 此类权限通常为"roles"，如ROLE_ADMINISTRATOR或ROLE_HR_SUPERVISOR。 稍后将为Web授权，方法授权和域对象授权配置这些角色。 Spring Security的其他部门有能力解释这些权威，并希望他们出席。 GrantedAuthority对象通常由UserDetailsService加载。

通常，GrantedAuthority对象是应用程序范围的权限。 它们不是特定于给定域对象的。 因此，您不可能有GrantedAuthority代表对{54}的对象Employee的许可权，因为如果有成千上万的此类权限，您会很快耗尽内存（至少，导致应用程序花费很长时间来验证用户）。 当然，Spring Security的设计明确是为了处理这个常见的需求，但是你应该使用项目的域对象安全功能来达到这个目的。

回想一下，到目前为止，Spring Security的主要构建块是：

• SecurityContextHolder，以提供对SecurityContext的访问。

• SecurityContext来保存Authentication和可能的特定于请求的安全信息。

• Authentication，以特定于Spring Security的方式表示主体。

• GrantedAuthority，以反映授予主体的应用程序范围的权限。

• UserDetails，从应用程序的DAO或其他安全数据源提供必要的信息来构建Authentication对象。

• UserDetailsService，以基于String的用户名（或证书ID等）传递时创建UserDetails。

现在您已经了解了这些重复使用的组件，让我们仔细看看认证过程。

我们来考虑一下每个人都熟悉的标准身份验证方案。

1. 提示用户使用用户名和密码登录。

2. 系统（成功）验证密码对用户名是否正确。

3. 获取该用户的上下文信息（其角色列表等）。

4. 为用户建立安全上下文

5. 用户可能会继续执行某些操作，该操作可能受访问控制机制保护，访问控制机制会针对当前安全上下文信息检查操作所需的权限。

前三项构成了认证过程，因此我们将在Spring Security中看看这些是如何发生的。

1. 获取用户名和密码并将其合并到UsernamePasswordAuthenticationToken（Authentication界面的一个实例，我们之前看到）的一个实例中。

2. 将令牌传递给AuthenticationManager的实例进行验证。

3. AuthenticationManager在成功验证时返回完全填充的Authentication实例。

4. 通过调用SecurityContextHolder.getContext().setAuthentication(…​)传入返回的认证对象来建立安全上下文。

从那时起，用户被认为是被认证的。 我们来看一些代码作为例子。

这里我们写了一个小程序，要求用户输入用户名和密码并执行上述顺序。 我们在此处实施的AuthenticationManager将验证任何用户名和密码相同的用户。 它为每个用户分配一个角色。 从上面的输出将会是这样的：

请注意，您通常不需要编写任何代码。 该过程通常在内部发生，例如在Web认证过滤器中。 我们刚刚在这里包含了代码，以表明在Spring Security中实际构成认证的问题有一个相当简单的答案。 当SecurityContextHolder包含完全填充的Authentication对象时，会对用户进行身份验证。

实际上，Spring Security并不介意如何将Authentication对象放入SecurityContextHolder中。 唯一关键的要求是SecurityContextHolder包含表示AbstractSecurityInterceptor之前的委托人{我们稍后会看到更多信息}的Authentication需要授权用户操作。

您可以（以及许多用户）编写自己的过滤器或MVC控制器，以提供与基于Spring Security的身份验证系统的互操作性。 例如，您可能正在使用容器管理的身份验证，它使当前用户可以从ThreadLocal或JNDI位置获得。 或者，您可能会为拥有旧版专有认证系统的公司工作，该系统是您无法控制的公司"standard"。 在这种情况下，Spring Security很容易运行，并且仍然提供授权功能。 您只需编写一个过滤器（或相当的），从一个位置读取第三方用户信息，构建一个特定于Spring Security的Authentication对象，并将其放入SecurityContextHolder中。 在这种情况下，您还需要考虑通常由内置身份验证基础结构自动处理的事情。 例如，在您将响应写入客户端脚注之前，您可能需要先向cache the context between requests创建一个HTTP会话：[在响应提交后无法创建会话。

如果您想知道如何在实际示例中实现AuthenticationManager，我们将在core services chapter中查看该示例。

Web应用程序中的=== 身份验证 现在我们来探讨一下在Web应用程序中使用Spring Security的情况（未启用web.xml安全性）。 用户如何进行身份验证并建立安全上下文？

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

1. 您访问主页，然后点击链接。

2. 请求发送到服务器，并且服务器确定您已请求受保护的资源。

3. 由于您目前没有进行身份验证，因此服务器会发回一个响应，指出您必须进行身份验证。 响应可能是HTTP响应代码，也可能是重定向到特定网页。

4. 根据验证机制，您的浏览器将重定向到特定的网页，以便您填写表单，或者浏览器以某种方式检索您的身份（通过BASIC身份验证对话框，cookie， X.509证书等）。

5. 浏览器将向服务器发送回应。 这将是一个HTTP POST，其中包含您填写的表单的内容，或者包含您的验证细节的HTTP标头。

6. 接下来，服务器将决定提交的凭证是否有效。 如果它们有效，下一步就会发生。 如果它们无效，通常你的浏览器会被要求重试（所以你回到上面的第二步）。

7. 您为导致身份验证过程所做的原始请求将被重试。 希望您已通过足够的授权机构进行身份验证，以访问受保护的资源。 如果您有足够的访问权限，请求将会成功。 否则，您将收到HTTP错误代码403，表示"forbidden"。

Spring Security具有不同的类，负责上述大多数步骤。 主要参与者（按其使用顺序）是ExceptionTranslationFilter，AuthenticationEntryPoint和"authentication mechanism"，负责调用我们在其中看到的AuthenticationManager前一节。

ExceptionTranslationFilter是一个Spring Security过滤器，负责检测抛出的任何Spring Security异常。 这种例外通常会由授权服务的主要提供者AbstractSecurityInterceptor抛出。 我们将在下一节讨论AbstractSecurityInterceptor，但现在我们只需要知道它会产生Java异常，并且对HTTP没有任何认识，或者如何去认证主体。 相反，ExceptionTranslationFilter提供此服务，具体负责返回错误代码403（如果主体已通过身份验证，并因此缺少足够的访问权限 - 按上述步骤7），或启动AuthenticationEntryPoint（如果委托人未经认证，因此我们需要开始第三步）。

AuthenticationEntryPoint负责上面列表中的第三步。 正如你可以想象的那样，每个Web应用程序都会有一个默认的身份验证策略（当然，这可以像Spring Security中的其他任何东西一样配置，但现在让我们保持简单）。 每个主要认证系统都有自己的AuthenticationEntryPoint实现，通常执行步骤3中描述的操作之一。

一旦您的浏览器提交了您的身份验证凭据（无论是作为HTTP表单发布还是HTTP标头），服务器上都需要有"collects"这些身份验证详细信息。 到目前为止，我们正在上面的列表中的第六步。 在Spring Security中，我们为从用户代理（通常是Web浏览器）收集认证详细信息的功能有一个特殊名称，将其称为"authentication mechanism"。 示例是基于表单的登录和基本身份验证。 一旦从用户代理收集了认证详细信息，就会构建Authentication "request"对象，然后将其呈现给AuthenticationManager。

在认证机制接收到完全填充的Authentication对象后，它将认为请求有效，将Authentication放入SecurityContextHolder，并重试原始请求（步骤7以上）。 另一方面，如果AuthenticationManager拒绝了请求，认证机制将要求用户代理重试（上面的第二步）。

根据应用程序的类型，可能需要制定一个策略来存储用户操作之间的安全上下文。 在典型的Web应用程序中，用户登录一次，随后通过其会话ID进行标识。 服务器缓存持续时间会话的主要信息。 在Spring Security中，存储请求之间SecurityContext的责任归属于SecurityContextPersistenceFilter，缺省情况下，该请求将上下文存储为HTTP请求之间的HttpSession属性。 它将每个请求的上下文恢复到SecurityContextHolder，并且在请求完成时关键地清除SecurityContextHolder。 出于安全目的，您不应直接与HttpSession进行交互。 没有理由这么做 - 总是使用SecurityContextHolder。

许多其他类型的应用程序（例如，无状态的RESTful Web服务）不使用HTTP会话，并将在每个请求中重新进行身份验证。 但是，{{0​​}}包含在链中以确保SecurityContextHolder在每个请求之后被清除仍然很重要。

Spring Security中的=== 访问控制（授权） 负责在Spring Security中制定访问控制决策的主界面是AccessDecisionManager。 它有一个decide方法，它需要一个表示请求主体访问的Authentication对象，一个"secure object"（见下文）以及适用于该对象的安全元数据属性列表（例如a授予访问权限所需的角色列表）。

如果你熟悉AOP，你会意识到有不同类型的建议可用：在之前，之后，投掷和周围。 周围的建议非常有用，因为顾问可以选择是否继续进行方法调用，是否修改响应以及是否抛出异常。 Spring Security为方法调用和Web请求提供了一个周围的建议。 我们使用Spring的标准AOP支持为方法调用提供了全面的建议，并且我们使用标准Filter实现了对Web请求的全面建议。

对于那些不熟悉AOP的人来说，理解的关键是Spring Security可以帮助您保护方法调用以及Web请求。 大多数人都对保护其服务层上的方法调用感兴趣。 这是因为服务层是大多数业务逻辑驻留在当代Java EE应用程序中的地方。 如果你只需要在服务层保证方法调用的安全，Spring的标准AOP就足够了。 如果您需要直接保护域对象，您可能会发现AspectJ值得考虑。

您可以选择使用AspectJ或Spring AOP执行方法授权，也可以选择使用过滤器执行Web请求授权。 您可以一起使用零个，一个，两个或三个这些方法。 主流使用模式是执行一些Web请求授权，再加上服务层上的一些Spring AOP方法调用授权。

那么，无论如何，is是"secure object"？ Spring Security使用这个术语来指代可以有安全性的任何对象（例如授权决定）。 最常见的例子是方法调用和Web请求。

每个受支持的安全对象类型都有其自己的拦截器类，它是AbstractSecurityInterceptor的子类。 重要的是，在AbstractSecurityInterceptor被调用的时候，如果委托人已被认证，则SecurityContextHolder将包含有效的Authentication。

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

1. 查找与当前请求关联的"configuration attributes"

2. 将安全对象，当前Authentication和配置属性提交给AccessDecisionManager以获得授权决定

3. 可以选择更改调用发生的Authentication

4. 允许继续进行安全对象调用（假设授予访问权限）

5. 调用返回后调用AfterInvocationManager（如果已配置）。 如果调用引发异常，则不会调用AfterInvocationManager。

什么是配置属性？

RunAsManager

AfterInvocationManager

扩展安全对象模型

<bean id="messageSource"

	class="org.springframework.context.support.ReloadableResourceBundleMessageSource">

<property name="basename" value="classpath:org/springframework/security/messages"/>

</bean>

<bean id="authenticationManager"

		class="org.springframework.security.authentication.ProviderManager">

	<constructor-arg>

		<list>

			<ref local="daoAuthenticationProvider"/>

			<ref local="anonymousAuthenticationProvider"/>

			<ref local="ldapAuthenticationProvider"/>

		</list>

	</constructor-arg>

</bean>

默认情况下（从Spring Security 3.1开始），ProviderManager将尝试清除成功认证请求返回的Authentication对象中的任何敏感凭据信息。 这可以防止密码等信息被保留超过必要的时间。

例如，当您使用用户对象缓存时，这可能会导致问题，以提高无状态应用程序的性能。 如果Authentication包含对缓存中对象的引用（例如UserDetails实例），并且已删除其凭据，则无法再对缓存值进行身份验证。 如果您使用缓存，则需要考虑这一点。 一个明显的解决方案是先创建对象的副本，无论是在缓存实现中还是在创建返回的Authentication对象的AuthenticationProvider中。 或者，您可以禁用ProviderManager上的eraseCredentialsAfterAuthentication属性。 有关更多信息，请参阅Javadoc。

Spring Security最简单的AuthenticationProvider是DaoAuthenticationProvider，它也是该框架最早支持的之一。 它利用UserDetailsService（作为DAO）来查找用户名，密码和GrantedAuthority。 它仅通过将UsernamePasswordAuthenticationToken中提交的密码与UserDetailsService加载的密码进行比较来对用户进行身份验证。 配置提供者非常简单：

PasswordEncoder是可选的。 PasswordEncoder提供从配置的UserDetailsService返回的UserDetails对象中显示的密码的编码和解码。 这将在below中进行更详细的讨论。

UserDetails loadUserByUsername(String username) throws UsernameNotFoundException;

易于使用创建自定义的UserDetailsService实现，从所选持久性引擎中提取信息，但许多应用程序不需要这种复杂性。 如果您正在构建原型应用程序，或者刚刚开始集成Spring Security，尤其当您不想花时间配置数据库或编写UserDetailsService实现时，情况尤其如此。 对于这种情况，一个简单的选择是使用安全性namespace中的user-service元素：

这也支持使用外部属性文件：

属性文件应该包含表单中的条目

例如

Spring Security还包含一个可以从JDBC数据源获取认证信息的UserDetailsService。 使用内部Spring JDBC，因此避免了用于存储用户详细信息的全功能对象关系映射程序（ORM）的复杂性。 如果您的应用程序确实使用了ORM工具，那么您可能更愿意编写一个自定义UserDetailsService来重用您可能已经创建的映射文件。 返回JdbcDaoImpl，示例配置如下所示：

您可以通过修改上面显示的DriverManagerDataSource来使用不同的关系数据库管理系统。 您也可以像使用其他Spring配置一样使用从JNDI获取的全局数据源。

权限组

多年来，用于存储密码的标准机制已经发展。 开始时密码以纯文本形式存储。 密码被认为是安全的，因为数据存储密码被保存在所需的凭据中以便访问它。 但是，恶意用户能够通过SQL注入等攻击方式找到获取大量"data dumps"用户名和密码的方法。 随着越来越多的用户凭据成为*专家意识到我们需要做更多的事情来保护用户的密码。

然后鼓励开发人员在通过单向散列（如SHA-256）运行密码后存储密码。 当用户尝试认证时，散列密码将与他们键入的密码的散列进行比较。 这意味着系统只需要存储密码的单向散列。 如果发生了违规，那么只有密码的单向散列被暴露。 由于哈希是一种方法，并且在计算上很难猜测给定散列的密码，所以在系统中找出每个密码是不值得的。 为了击败这个新系统，恶意用户决定创建名为https://en.wikipedia.org/wiki/Rainbow_table [Rainbow Tables]的查找表。 他们不是每次都在猜测每个密码，而是一次计算密码并将其存储在查找表中。

为了降低彩虹表的有效性，鼓励开发者使用咸味密码。 而不是仅使用密码作为散列函数的输入，将为每个用户的密码生成随机字节（称为salt）。 盐和用户的密码将通过产生唯一散列的散列函数运行。 盐将以明文形式与用户密码一起存储。 然后当用户尝试认证时，散列密码将与存储的盐的哈希以及他们输入的密码进行比较。 独特的盐意味着Rainbow Tables不再有效，因为每种盐和密码组合的散列值都不相同。

在现代，我们意识到密码哈希（如SHA-256）不再安全。 原因是，使用现代硬件，我们可以每秒执行数十亿次哈希计算。 这意味着我们可以轻松破解每个密码。

现在鼓励开发人员利用自适应单向函数来存储密码。 使用自适应单向函数对密码进行验证是有意识的资源（即CPU，内存等）密集型。 自适应单向函数允许配置随着硬件变得越来越好的"work factor"。 建议"work factor"调整大约1秒钟以验证系统上的密码。 这种权衡是为了让攻击者难以破解密码，但并不那么昂贵，它会给你自己的系统带来过大的负担。 Spring Security试图为"work factor"提供良好的起点，但鼓励用户为自己的系统自定义"work factor"，因为不同系统的性能会有很大差异。 应该使用的自适应单向函数的例子包括 bcrypt PBKDF2 scrypt 和https://en.wikipedia.org/wiki/Argon2[Argon2]。

由于自适应单向函数是故意耗费资源的，因此验证每个请求的用户名和密码将显着降低应用程序的性能。 Spring Security（或任何其他库）没有什么能够加速验证密码，因为通过使验证资源密集而获得安全性。 鼓励用户交换短期凭证（即会话，OAuth令牌等）的长期凭证（即用户名和密码）。 短期凭证可以快速验证而不会有任何安全性损失。

在Spring Security 5.0之前，默认的PasswordEncoder是NoOpPasswordEncoder，它需要纯文本密码。 根据{{​​0}}部分，您可能预计现在默认的PasswordEncoder与BCryptPasswordEncoder类似。 但是，这忽略了三个现实世界的问题：

• 许多使用旧密码编码的应用程序无法轻松迁移

• 密码存储的最佳做法将再次发生变化。

• 作为一个框架，Spring Security不能经常发生重大更改

相反，Spring Security引入了DelegatingPasswordEncoder，它解决了所有的问题：

• 确保使用当前密码存储建议对密码进行编码

• 允许以现代和传统格式验证密码

• 允许将来升级编码

您可以使用PasswordEncoderFactories轻松构建DelegatingPasswordEncoder的实例。

或者，您可以创建自己的自定义实例。例如：

密码存储格式

{id}encodedPassword

{bcrypt}$2a$10$dXJ3SW6G7P50lGmMkkmwe.20cQQubK3.HZWzG3YB1tlRy.fqvM/BG

{noop}password

{pbkdf2}5d923b44a6d129f3ddf3e3c8d29412723dcbde72445e8ef6bf3b508fbf17fa4ed4d6b99ca763d8dc

{scrypt}$e0801$8bWJaSu2IKSn9Z9kM+TPXfOc/9bdYSrN1oD9qfVThWEwdRTnO7re7Ei+fUZRJ68k9lTyuTeUp4of4g24hHnazw==$OAOec05+bXxvuu/1qZ6NUR+xQYvYv7BeL1QxwRpY5Pc=

{sha256}97cde38028ad898ebc02e690819fa220e88c62e0699403e94fff291cfffaf8410849f27605abcbc0 

密码编码

{bcrypt}$2a$10$dXJ3SW6G7P50lGmMkkmwe.20cQQubK3.HZWzG3YB1tlRy.fqvM/BG

密码匹配

入门体验

User user = User.withDefaultPasswordEncoder()

  .username("user")

  .password("password")

  .roles("user")

  .build();

System.out.println(user.getPassword());

// {bcrypt}$2a$10$dXJ3SW6G7P50lGmMkkmwe.20cQQubK3.HZWzG3YB1tlRy.fqvM/BG

UserBuilder users = User.withDefaultPasswordEncoder();

User user = users

  .username("user")

  .password("password")

  .roles("USER")

  .build();

User admin = users

  .username("admin")

  .password("password")

  .roles("USER","ADMIN")

  .build();

故障处理

java.lang.IllegalArgumentException: There is no PasswordEncoder mapped for the id "null"

	at org.springframework.security.crypto.password.DelegatingPasswordEncoder$UnmappedIdPasswordEncoder.matches(DelegatingPasswordEncoder.java:233)

	at org.springframework.security.crypto.password.DelegatingPasswordEncoder.matches(DelegatingPasswordEncoder.java:196)

@Bean

public static NoOpPasswordEncoder passwordEncoder() {

    return NoOpPasswordEncoder.getInstance();

}

<b:bean id="passwordEncoder"

        class="org.springframework.security.crypto.password.NoOpPasswordEncoder" factory-method="getInstance"/>

$2a$10$dXJ3SW6G7P50lGmMkkmwe.20cQQubK3.HZWzG3YB1tlRy.fqvM/BG

{bcrypt}$2a$10$dXJ3SW6G7P50lGmMkkmwe.20cQQubK3.HZWzG3YB1tlRy.fqvM/BG

BCryptPasswordEncoder实施使用广泛支持的https://en.wikipedia.org/wiki/Bcrypt[bcrypt]算法对密码进行哈希处理。 为了使它对密码破解更具抵抗性，bcrypt故意缓慢。 与其他自适应单向函数一样，应该调整大约1秒以验证系统上的密码。

Pbkdf2PasswordEncoder实施使用https://en.wikipedia.org/wiki/PBKDF2[PBKDF2]算法对密码进行哈希处理。 为了破解密码破解PBKDF2是一个故意缓慢的算法。 与其他自适应单向函数一样，应该调整大约1秒以验证系统上的密码。 当需要FIPS认证时，此算法是一个不错的选择。

SCryptPasswordEncoder实施使用https://en.wikipedia.org/wiki/Scrypt[scrypt]算法对密码进行哈希处理。 为了击败定制硬件上的密码破解scrypt是一个故意缓慢的算法，需要大量的内存。 与其他自适应单向函数一样，应该调整大约1秒以验证系统上的密码。

其他PasswordEncoders。==

有大量其他PasswordEncoder实现完全为了向后兼容而存在。 他们都被弃用，表明他们不再被认为是安全的。 但是，由于难以迁移现有的遗留系统，因此没有计划将其删除。

杰克逊支持。===

Spring Security已经增加了Jackson Support来坚持Spring Security相关的类。 这可以提高在处理分布式会话（即会话复制，Spring会话等）时序列化Spring Security相关类的性能。

要使用它，请将JacksonJacksonModules.getModules(ClassLoader)注册为 杰克逊模块。

@RunWith(SpringJUnit4ClassRunner.class)

@ContextConfiguration

public class WithMockUserTests {

@Test(expected = AuthenticationCredentialsNotFoundException.class)

public void getMessageUnauthenticated() {

	messageService.getMessage();

}

@Test

@WithMockUser

public void getMessageWithMockUser() {

String message = messageService.getMessage();

...

}

@Test

@WithMockUser("customUsername")

public void getMessageWithMockUserCustomUsername() {

	String message = messageService.getMessage();

...

}

@Test

@WithMockUser(username="admin",roles={"USER","ADMIN"})

public void getMessageWithMockUserCustomUser() {

	String message = messageService.getMessage();

	...

}

@Test

@WithMockUser(username = "admin", authorities = { "ADMIN", "USER" })

public void getMessageWithMockUserCustomAuthorities() {

	String message = messageService.getMessage();

	...

}

@RunWith(SpringJUnit4ClassRunner.class)

@ContextConfiguration

@WithMockUser(username="admin",roles={"USER","ADMIN"})

public class WithMockUserTests {

@WithMockUser(setupBefore = TestExecutionEvent.TEST_EXECUTION)

@RunWith(SpringJUnit4ClassRunner.class)

@WithMockUser

public class WithUserClassLevelAuthenticationTests {

	@Test

	public void withMockUser1() {

	}

	@Test

	public void withMockUser2() {

	}

	@Test

	@WithAnonymousUser

	public void anonymous() throws Exception {

		// override default to run as anonymous user

	}

}

@WithAnonymousUser(setupBefore = TestExecutionEvent.TEST_EXECUTION)

@Test

@WithUserDetails

public void getMessageWithUserDetails() {

	String message = messageService.getMessage();

	...

}

@Test

@WithUserDetails("customUsername")

public void getMessageWithUserDetailsCustomUsername() {

	String message = messageService.getMessage();

	...

}

@Test

@WithUserDetails(value="customUsername", userDetailsServiceBeanName="myUserDetailsService")

public void getMessageWithUserDetailsServiceBeanName() {

	String message = messageService.getMessage();

	...

}

@WithUserDetails(setupBefore = TestExecutionEvent.TEST_EXECUTION)

@Retention(RetentionPolicy.RUNTIME)

@WithSecurityContext(factory = WithMockCustomUserSecurityContextFactory.class)

public @interface WithMockCustomUser {

	String username() default "rob";

	String name() default "Rob Winch";

}

public class WithMockCustomUserSecurityContextFactory

	implements WithSecurityContextFactory<WithMockCustomUser> {

	@Override

	public SecurityContext createSecurityContext(WithMockCustomUser customUser) {

		SecurityContext context = SecurityContextHolder.createEmptyContext();

		CustomUserDetails principal =

			new CustomUserDetails(customUser.name(), customUser.username());

		Authentication auth =

			new UsernamePasswordAuthenticationToken(principal, "password", principal.getAuthorities());

		context.setAuthentication(auth);

		return context;

	}

}

final class WithUserDetailsSecurityContextFactory

	implements WithSecurityContextFactory<WithUserDetails> {

	private UserDetailsService userDetailsService;

	@Autowired

	public WithUserDetailsSecurityContextFactory(UserDetailsService userDetailsService) {

		this.userDetailsService = userDetailsService;

	}

	public SecurityContext createSecurityContext(WithUserDetails withUser) {

		String username = withUser.value();

		Assert.hasLength(username, "value() must be non-empty String");

		UserDetails principal = userDetailsService.loadUserByUsername(username);

		Authentication authentication = new UsernamePasswordAuthenticationToken(principal, principal.getPassword(), principal.getAuthorities());

		SecurityContext context = SecurityContextHolder.createEmptyContext();

		context.setAuthentication(authentication);

		return context;

	}

}

@WithSecurityContext(setupBefore = TestExecutionEvent.TEST_EXECUTION)

@WithMockUser(username="admin",roles={"USER","ADMIN"})

@Retention(RetentionPolicy.RUNTIME)

@WithMockUser(value="rob",roles="ADMIN")

public @interface WithMockAdmin { }

import static org.springframework.security.test.web.servlet.setup.SecurityMockMvcConfigurers.*;

@RunWith(SpringJUnit4ClassRunner.class)

@ContextConfiguration

@WebAppConfiguration

public class CsrfShowcaseTests {

	@Autowired

	private WebApplicationContext context;

	private MockMvc mvc;

	@Before

	public void setup() {

		mvc = MockMvcBuilders

				.webAppContextSetup(context)

				.apply(springSecurity())

				.build();

	}

...

import static org.springframework.security.test.web.servlet.request.SecurityMockMvcRequestPostProcessors.*;

在测试任何非安全的HTTP方法并使用Spring Security的CSRF保护时，您必须确保在请求中包含有效的CSRF令牌。 使用以下命令将有效的CSRF令牌指定为请求参数：

如果你喜欢，你可以在标题中包含CSRF令牌：

您也可以使用以下测试来提供无效的CSRF令牌：

通常需要以特定用户身份运行测试。 有两种填充用户的简单方法：

• Running as a User in Spring MVC Test with RequestPostProcessor

• Running as a User in Spring MVC Test with Annotations

有多种选项可将用户关联到当前的HttpServletRequest。 例如，以下内容将以用户名"user"，密码"password"和角色"ROLE_USER"作为用户（不需要存在）运行：

您可以轻松进行自定义。 例如，以下内容将以用户名"admin"，密码"pass"和角色"ROLE_USER"和"ROLE_ADMIN"作为用户（不需要存在）运行。

如果您有要使用的自定义UserDetails，则也可以轻松指定。 例如，以下内容将使用指定的UserDetails（不需要存在）与具有指定UserDetails的主体的UsernamePasswordAuthenticationToken一起运行：

您可以使用以下方式以匿名用户身份运行：

如果您使用默认用户运行并希望以匿名用户的身份执行一些请求，则此功能特别有用。

如果您想要自定义Authentication（不需要存在），则可以使用以下方法执行此操作：

您甚至可以使用以下方式自定义SecurityContext：

我们还可以确保使用MockMvcBuilders的默认请求以每个请求的特定用户身份运行。 例如，以下内容将以用户名"admin"，密码"password"和角色"ROLE_ADMIN"作为用户（不需要存在）运行：

如果你发现你在许多测试中使用同一个用户，建议将用户移到一个方法。 例如，您可以在名为CustomSecurityMockMvcRequestPostProcessors的类中指定以下内容：

现在您可以在SecurityMockMvcRequestPostProcessors上执行静态导入，并在您的测试中使用它：

作为用户在Spring MVC测试中使用注解运行=====

作为使用RequestPostProcessor创建用户的替代方法，您可以使用[Testing Method Security]中描述的注释。 例如，以下内容将使用用户名"user"，密码"password"和角色"ROLE_USER"进行测试：

或者，以下内容将使用用户名"user"，密码"password"和角色"ROLE_ADMIN"进行测试：

虽然始终可以使用HTTP Basic进行身份验证，但记住头名称，格式和编码值有点繁琐。 现在可以使用Spring Security的httpBasic RequestPostProcessor完成。 例如，下面的代码片段：

将尝试使用HTTP Basic通过确保在HTTP请求上填充以下标头，以用户名"user"和密码"password"对用户进行身份验证：

import static org.springframework.security.test.web.servlet.request.SecurityMockMvcRequestBuilders.*;

使用Spring Security的测试支持，您可以轻松创建一个请求来测试基于表单的身份验证。 例如，以下内容将使用用户名"user"，密码"password"和有效的CSRF令牌向"/login"提交POST：

定制请求很容易。 例如，以下内容将使用用户名"admin"，密码"pass"和有效的CSRF令牌向"/auth"提交POST：

我们也可以自定义包含用户名和密码的参数名称。 例如，上述请求被修改为在HTTP参数"u"上包含用户名，在HTTP参数"p"中包含密码。

虽然使用标准的Spring MVC测试相当简单，但您可以使用Spring Security的测试支持来简化测试注销。 例如，以下内容将使用有效的CSRF令牌向"/logout"提交POST：

您还可以自定义发布到的URL。 例如，下面的代码段将使用有效的CSRF令牌向"/signout"提交POST：

import static org.springframework.security.test.web.servlet.response.SecurityMockMvcResultMatchers.*;

有时，声明没有经过认证的用户与MockMvc调用的结果关联可能很有价值。 例如，您可能想要测试提交无效的用户名和密码，并验证没有用户通过身份验证。 使用Spring Security的测试支持，您可以使用如下所示轻松完成此操作：

通常我们必须断言经过身份验证的用户存在。 例如，我们可能想验证我们是否成功验证。 我们可以通过以下代码片段验证基于表单的登录是否成功：

如果我们想要声明用户的角色，我们可以改进我们以前的代码，如下所示：

或者，我们可以验证用户名：

我们也可以结合这些断言：

我们也可以对认证进行任意的断言

@RunWith(SpringRunner.class)

@ContextConfiguration(classes = HelloWebfluxMethodApplication.class)

public class HelloWorldMessageServiceTests {

	@Autowired

	HelloWorldMessageService messages;

	@Test

	public void messagesWhenNotAuthenticatedThenDenied() {

		StepVerifier.create(this.messages.findMessage())

			.expectError(AccessDeniedException.class)

			.verify();

	}

	@Test

	@WithMockUser

	public void messagesWhenUserThenDenied() {

		StepVerifier.create(this.messages.findMessage())

			.expectError(AccessDeniedException.class)

			.verify();

	}

	@Test

	@WithMockUser(roles = "ADMIN")

	public void messagesWhenAdminThenOk() {

		StepVerifier.create(this.messages.findMessage())

			.expectNext("Hello World!")

			.verifyComplete();

	}

}

@RunWith(SpringRunner.class)

@ContextConfiguration(classes = HelloWebfluxMethodApplication.class)

public class HelloWebfluxMethodApplicationTests {

	@Autowired

	ApplicationContext context;

	WebTestClient rest;

	@Before

	public void setup() {

		this.rest = WebTestClient

			.bindToApplicationContext(this.context)

			// add Spring Security test Support

			.apply(springSecurity())

			.configureClient()

			.filter(basicAuthentication())

			.build();

	}

	// ...

}

将Spring Security支持应用到WebTestClient后，我们可以使用注释或mutateWith支持。 例如：

Spring Security还为WebTestClient提供CSRF测试支持。 例如：

<filter>

<filter-name>myFilter</filter-name>

<filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>

</filter>

<filter-mapping>

<filter-name>myFilter</filter-name>

<url-pattern>/*</url-pattern>

</filter-mapping>

<bean id="filterChainProxy" class="org.springframework.security.web.FilterChainProxy">

<constructor-arg>

	<list>

	<sec:filter-chain pattern="/restful/**" filters="

		securityContextPersistenceFilterWithASCFalse,

		basicAuthenticationFilter,

		exceptionTranslationFilter,

		filterSecurityInterceptor" />

	<sec:filter-chain pattern="/**" filters="

		securityContextPersistenceFilterWithASCTrue,

		formLoginFilter,

		exceptionTranslationFilter,

		filterSecurityInterceptor" />

	</list>

</constructor-arg>

</bean>

您可以使用属性filters = "none"作为提供过滤器bean列表的替代方法。 这将完全忽略来自安全过滤器链的请求模式。 请注意，与此路径相匹配的任何内容都不会应用认证或授权服务，并且可以*访问。 如果您想在请求期间使用SecurityContext内容的内容，则它必须通过安全筛选器链。 否则，SecurityContextHolder将不会被填充，并且内容将为空。

<b:bean id="httpFirewall"

      class="org.springframework.security.web.firewall.StrictHttpFirewall"

      p:allowSemicolon="true"/>

<http-firewall ref="httpFirewall"/>

@Bean

public StrictHttpFirewall httpFirewall() {

    StrictHttpFirewall firewall = new StrictHttpFirewall();

    firewall.setAllowSemicolon(true);

    return firewall;

}

<b:bean id="httpFirewall"

      class="org.springframework.security.web.firewall.StrictHttpFirewall"

      p:allowedHttpMethods="GET,HEAD"/>

<http-firewall ref="httpFirewall"/>

@Bean

public StrictHttpFirewall httpFirewall() {

    StrictHttpFirewall firewall = new StrictHttpFirewall();

    firewall.setAllowedHttpMethods(Arrays.asList("GET", "POST"));

    return firewall;

}

<!-- Stateless RESTful service using Basic authentication -->

<http pattern="/restful/**" create-session="stateless">

<intercept-url pattern='/**' access="hasRole('REMOTE')" />

<http-basic />

</http>

<!-- Empty filter chain for the login page -->

<http pattern="/login.htm*" security="none"/>

<!-- Additional filter chain for normal users, matching all other requests -->

<http>

<intercept-url pattern='/**' access="hasRole('USER')" />

<form-login login-page='/login.htm' default-target-url="/home.htm"/>

<logout />

</http>

<bean id="filterSecurityInterceptor"

	class="org.springframework.security.web.access.intercept.FilterSecurityInterceptor">

<property name="authenticationManager" ref="authenticationManager"/>

<property name="accessDecisionManager" ref="accessDecisionManager"/>

<property name="securityMetadataSource">

	<security:filter-security-metadata-source>

	<security:intercept-url pattern="/secure/super/**" access="ROLE_WE_DONT_HAVE"/>

	<security:intercept-url pattern="/secure/**" access="ROLE_SUPERVISOR,ROLE_TELLER"/>

	</security:filter-security-metadata-source>

</property>

</bean>

<bean id="filterInvocationInterceptor"

	class="org.springframework.security.web.access.intercept.FilterSecurityInterceptor">

<property name="authenticationManager" ref="authenticationManager"/>

<property name="accessDecisionManager" ref="accessDecisionManager"/>

<property name="runAsManager" ref="runAsManager"/>

<property name="securityMetadataSource">

	<security:filter-security-metadata-source request-matcher="regex">

	<security:intercept-url pattern="\A/secure/super/.*\Z" access="ROLE_WE_DONT_HAVE"/>

	<security:intercept-url pattern="\A/secure/.*\" access="ROLE_SUPERVISOR,ROLE_TELLER"/>

	</security:filter-security-metadata-source>

</property>

</bean>

<bean id="exceptionTranslationFilter"

class="org.springframework.security.web.access.ExceptionTranslationFilter">

<property name="authenticationEntryPoint" ref="authenticationEntryPoint"/>

<property name="accessDeniedHandler" ref="accessDeniedHandler"/>

</bean>

<bean id="authenticationEntryPoint"

class="org.springframework.security.web.authentication.LoginUrlAuthenticationEntryPoint">

<property name="loginFormUrl" value="/login.jsp"/>

</bean>

<bean id="accessDeniedHandler"

	class="org.springframework.security.web.access.AccessDeniedHandlerImpl">

<property name="errorPage" value="/accessDenied.htm"/>

</bean>

如果用户请求安全的HTTP资源，但它们未通过身份验证，则将调用AuthenticationEntryPoint。 一个合适的AuthenticationException或AccessDeniedException将被进一步向下调用堆栈的安全拦截器引发，触发入口点上的commence方法。 这可以向用户提供适当的响应，以便开始认证。 我们这里使用的是LoginUrlAuthenticationEntryPoint，它将请求重定向到不同的URL（通常是登录页面）。 所使用的实际实现将取决于您希望在应用程序中使用的身份验证机制。

如果用户已经通过身份验证并且他们尝试访问受保护的资源，会发生什么情况？在正常使用情况下，不应该发生这种情况，因为应用程序工作流程应限制为用户有权访问的操作。 例如，到管理页面的HTML链接可能对没有管理员角色的用户隐藏。 尽管如此，您不能依赖隐藏链接的安全性，因为用户总是可能直接输入URL来尝试绕过限制。 或者他们可能会修改一个RESTful URL来更改一些参数值。 您的应用程序必须受到保护以免出现这些情况，否则它肯定会变得不安全 您通常会使用简单的Web层安全性将约束应用于基本URL，并在您的服务层接口上使用更具体的基于方法的安全性来真正确定允许的内容。

如果AccessDeniedException被抛出并且用户已经被认证，那么这意味着已经尝试了他们没有足够权限的操作。 在这种情况下，ExceptionTranslationFilter将调用第二个策略AccessDeniedHandler。 默认情况下，使用AccessDeniedHandlerImpl，仅向客户端发送403（禁止）响应。 或者，您可以显式配置一个实例（如上例），并设置一个错误页面URL，它将把请求转发给脚注：[ 我们使用forward，以便SecurityContextHolder仍然包含主体的细节，这对于向用户显示可能是有用的。 在Spring Security的旧版本中，我们依靠servlet容器来处理缺少这种有用上下文信息的403错误消息。 ]. 这可以是简单的"access denied"页面，如JSP，也可以是更复杂的处理程序，如MVC控制器。 当然，你可以自己实现接口并使用你自己的实现。

当您使用命名空间来配置应用程序时，也可以提供自定义的AccessDeniedHandler。 有关更多详情，请参阅the namespace appendix。

ExceptionTranslationFilter职责的另一个责任是在调用AuthenticationEntryPoint之前保存当前请求。 这允许在用户通过身份验证后恢复请求（请参阅之前的web authentication概述）。 一个典型的例子是用户使用表单登录，然后通过默认SavedRequestAwareAuthenticationSuccessHandler（请参阅below）重定向到原始URL。

RequestCache封装了存储和检索HttpServletRequest实例所需的功能。 默认情况下使用HttpSessionRequestCache，将请求存储在HttpSession中。 当用户被重定向到原始URL时，RequestCacheFilter实际上可以恢复缓存中保存的请求。

在正常情况下，您不需要修改任何此功能，但保存的请求处理是"best-effort"方法，并且可能存在默认配置无法处理的情况。 这些接口的使用使它可以从Spring Security 3.0开始完全插入。

<bean id="securityContextPersistenceFilter"

class="org.springframework.security.web.context.SecurityContextPersistenceFilter"/>

从Spring Security 3.0开始，加载和存储安全上下文的工作现在被委派给一个单独的策略接口：

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

默认实现是HttpSessionSecurityContextRepository，它将安全性上下文存储为HttpSession属性脚注：[在Spring Security 2.0及更早版本中，此过滤器被称为HttpSessionContextIntegrationFilter并执行所有存储上下文是由过滤器本身执行的。 如果您熟悉此课程，则可以在HttpSessionSecurityContextRepository上找到大多数可用的配置选项。]。 此实现的最重要的配置参数是allowSessionCreation属性，该属性默认为true，因此如果类需要存储经过身份验证的用户的安全上下文，则允许该类创建会话除非进行认证并且安全上下文的内容已经改变，否则不会创建一个）。 如果您不想创建会话，则可以将此属性设置为false：

或者，您可以提供一个NullSecurityContextRepository实例，一个 空对象实现，它将阻止安全上下文被存储，即使在请求期间已经创建了一个会话。

<bean id="authenticationFilter" class=

"org.springframework.security.web.authentication.UsernamePasswordAuthenticationFilter">

<property name="authenticationManager" ref="authenticationManager"/>

</bean>

过滤器会调用配置的AuthenticationManager来处理每个认证请求。 成功认证或认证失败后的目的地分别由AuthenticationSuccessHandler和AuthenticationFailureHandler策略接口控制。 该过滤器的属性允许您设置这些属性，以便您可以完全自定义行为脚注：[在3.0之前的版本中，此时的应用程序流已经演变为一个阶段，由此类和策略插件。 该决定是为了重构代码以使这两个策略完全负责。]。 提供了一些标准实现，如SimpleUrlAuthenticationSuccessHandler，SavedRequestAwareAuthenticationSuccessHandler，SimpleUrlAuthenticationFailureHandler，ExceptionMappingAuthenticationFailureHandler和DelegatingAuthenticationFailureHandler。 查看这些类的Javadoc，并了解AbstractAuthenticationProcessingFilter以了解它们如何工作以及支持的功能。

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

如果认证失败，则会调用配置的AuthenticationFailureHandler。

HttpServletRequest.getRemoteUser（）将返回通常为当前用户名的SecurityContextHolder.getContext().getAuthentication().getName()的结果。 如果您想在应用程序中显示当前用户名，这会很有用。 此外，检查这是否为空可用于指示用户是否已通过身份验证或匿名。 知道用户是否被认证对于确定是否应该显示某些UI元素是有用的（即，仅当用户被认证时才显示注销链接）。

HttpServletRequest.getUserPrincipal（）将返回SecurityContextHolder.getContext().getAuthentication()的结果。 这意味着在使用基于用户名和密码的身份验证时，它是Authentication，通常是UsernamePasswordAuthenticationToken的实例。 如果您需要有关用户的其他信息，这可能很有用。 例如，您可能已创建一个自定义UserDetailsService，返回包含用户姓名和姓氏的自定义UserDetails。 您可以通过以下方式获取此信息：

HttpServletRequest.isUserInRole（字符串）将确定SecurityContextHolder.getContext().getAuthentication().getAuthorities()是否包含传递给isUserInRole(String)的角色的GrantedAuthority。 通常用户不应将"ROLE_"前缀传入此方法，因为它会自动添加。 例如，如果您要确定当前用户是否具有权限"ROLE_ADMIN"，则可以使用以下内容：

这对确定是否显示某些UI组件可能很有用。 例如，只有当前用户是管理员时，才可以显示管理员链接。

HttpServletRequest.authenticate（HttpServletRequest的，HttpServletResponse的）方法可用于确保用户通过身份验证。 如果它们未通过身份验证，则配置的AuthenticationEntryPoint将用于请求用户进行身份验证（即重定向到登录页面）。

HttpServletRequest.login（字符串，字符串）方法可用于使用当前AuthenticationManager对用户进行身份验证。 例如，以下内容会尝试使用用户名"user"和密码"password"进行身份验证：

可以使用 HttpServletRequest.logout（）方法记录当前用户。

通常这意味着SecurityContextHolder将被清除，HttpSession将失效，任何"Remember Me"认证将被清除，等等。 但是，配置的LogoutHandler实现将根据您的Spring Security配置而有所不同。 请注意，在调用HttpServletRequest.logout（）之后，您仍然负责编写响应。 通常这会涉及重定向到欢迎页面。

确保您的凭据将传播到新线程的 AsynchContext.start（可运行）方法。 使用Spring Security的并发支持，Spring Security会覆盖AsyncContext.start（Runnable），以确保在处理Runnable时使用当前的SecurityContext。 例如，以下内容会输出当前用户的身份验证：

如果您正在使用基于Java的配置，则可以开始使用了。 如果您使用的是XML配置，则需要进行一些更新。 第一步是确保您已更新web.xml以至少使用3.0架构，如下所示：

接下来，您需要确保您的springSecurityFilterChain已设置为处理异步请求。

而已！ 现在，Spring Security将确保您的SecurityContext也在异步请求上传播。

那么它是怎样工作的？如果你不是真的感兴趣，可以跳过本节的其余部分，否则请继续阅读。 其中大部分都是内置到Servlet规范中的，但是有一点调整，Spring Security确实能够正确地处理异步请求。 在Spring Security 3.2之前，只要提交HttpServletResponse，SecurityContextHolder中的SecurityContext就会自动保存。 这可能会导致异步环境中的问题。 例如，请考虑以下几点：

问题是这个Thread对于Spring Security来说是不知道的，所以SecurityContext不会传播给它。 这意味着当我们提交HttpServletResponse时，没有SecuriytContext。 当Spring Security在提交HttpServletResponse时自动保存SecurityContext时，它会丢失我们的登录用户。

从3.2版本开始，Spring Security足够聪明，只要HttpServletRequest.startAsync（）被调用，就不会再自动保存SecurityContext来提交HttpServletResponse。

HttpServletRequest.changeSessionId（）是在Servlet 3.1及更高版本中防止Session Fixation攻击的默认方法。

要实施HTTP基本认证，您需要将BasicAuthenticationFilter添加到您的过滤器链中。 应用程序上下文应包含BasicAuthenticationFilter及其所需的协作者：

配置的AuthenticationManager处理每个认证请求。 如果认证失败，则配置的AuthenticationEntryPoint将用于重试认证过程。 通常，您将结合BasicAuthenticationEntryPoint使用过滤器，该过滤器会返回带有合适标头的401响应，以重试HTTP基本身份验证。 如果认证成功，则像往常一样将生成的Authentication对象放入SecurityContextHolder。

如果认证事件成功，或者由于HTTP标头不包含支持的认证请求而未尝试认证，则过滤器链将照常继续。 过滤器链将被中断的唯一时间是身份验证失败并调用AuthenticationEntryPoint。

base64(expirationTime + ":" + md5Hex(expirationTime + ":" + key))

expirationTime:   The date and time when the nonce expires, expressed in milliseconds

key:              A private key to prevent modification of the nonce token

现在我们已经回顾了理论，让我们看看如何使用它。 要实现HTTP摘要认证，有必要在过滤器链中定义DigestAuthenticationFilter。 应用程序上下文将需要定义DigestAuthenticationFilter及其所需的协作者：

配置的UserDetailsService是必需的，因为DigestAuthenticationFilter必须能够直接访问用户的明文密码。 如果在DAO脚注中使用编码密码，摘要式身份验证将不起作用：[如果DigestAuthenticationFilter.passwordAlreadyEncoded设置为{{}，则可以使用HEX格式（MD5（用户名：realm：password） 1}}。 但是，其他密码编码不适用于摘要式身份验证。]。 DAO协作者和UserCache通常直接与DaoAuthenticationProvider共享。 authenticationEntryPoint属性必须为DigestAuthenticationEntryPoint，以便DigestAuthenticationFilter可以获取正确的realmName和key以进行摘要计算。

与BasicAuthenticationFilter类似，如果认证成功，Authentication请求令牌将被放入SecurityContextHolder中。 如果身份验证事件成功，或者由于HTTP头未包含摘要身份验证请求而未尝试身份验证，则过滤器链将照常继续。 过滤器链将被中断的唯一时间是如果验证失败并且调用AuthenticationEntryPoint，如前段所述。

摘要式身份验证RFC提供了一系列附加功能以进一步提高安全性。 例如，可以在每个请求中更改随机数。 尽管如此，Spring Security实现的目的是尽量减少实现的复杂性（以及可能出现的无疑的用户代理不兼容），并避免存储服务器端状态。 如果您希望更详细地了解这些功能，请您参阅RFC 2617。 据我们所知，Spring Security的实现符合RFC的最低标准。

base64(username + ":" + expirationTime + ":" +

md5Hex(username + ":" + expirationTime + ":" password + ":" + key))

username:          As identifiable to the UserDetailsService

password:          That matches the one in the retrieved UserDetails

expirationTime:    The date and time when the remember-me token expires, expressed in milliseconds

key:               A private key to prevent modification of the remember-me token

<http>

...

<remember-me key="myAppKey"/>

</http>

<http>

...

<remember-me data-source-ref="someDataSource"/>

</http>

create table persistent_logins (username varchar(64) not null,

								series varchar(64) primary key,

								token varchar(64) not null,

								last_used timestamp not null)

Authentication autoLogin(HttpServletRequest request, HttpServletResponse response);

void loginFail(HttpServletRequest request, HttpServletResponse response);

void loginSuccess(HttpServletRequest request, HttpServletResponse response,

	Authentication successfulAuthentication);

此实现支持简单的基于哈希的令牌方法中介绍的更简单的方法。 TokenBasedRememberMeServices生成RememberMeAuthenticationToken，由RememberMeAuthenticationProvider处理。 此身份验证提供程序与TokenBasedRememberMeServices共享一个key。 另外，TokenBasedRememberMeServices需要一个UserDetailsS​​ervice，通过它可以检索用户名和密码以进行签名比较，并生成RememberMeAuthenticationToken以包含正确的GrantedAuthority。 某些注销命令应由应用程序提供，如果用户请求该命令，则会使Cookie无效。TokenBasedRememberMeServices还实现了Spring Security的LogoutHandler界面，因此可以与LogoutFilter一起使用以自动清除cookie。

在应用程序上下文中启用Remember-me服务所需的bean如下所示：

不要忘记将您的RememberMeServices实施添加到您的UsernamePasswordAuthenticationFilter.setRememberMeServices()属性，将RememberMeAuthenticationProvider添加到您的AuthenticationManager.setProviders()列表中，并将RememberMeAuthenticationFilter添加到您的{{5 }}（通常在你的UsernamePasswordAuthenticationFilter之后）。

此类可以与TokenBasedRememberMeServices相同的方式使用，但还需要使用PersistentTokenRepository配置以存储令牌。 有两种标准实现。

仅用于测试的*  InMemoryTokenRepositoryImpl。 *  JdbcTokenRepositoryImpl将令牌存储在数据库中。

数据库模式在持久令牌方法中进行了描述。

POST /transfer HTTP/1.1

Host: bank.example.com

Cookie: JSESSIONID=randomid; Domain=bank.example.com; Secure; HttpOnly

Content-Type: application/x-www-form-urlencoded

amount=100.00&routingNumber=1234&account=9876

<form action="https://bank.example.com/transfer" method="post">

<input type="hidden"

	name="amount"

	value="100.00"/>

<input type="hidden"

	name="routingNumber"

	value="evilsRoutingNumber"/>

<input type="hidden"

	name="account"

	value="evilsAccountNumber"/>

<input type="submit"

	value="Win Money!"/>

</form>

POST /transfer HTTP/1.1

Host: bank.example.com

Cookie: JSESSIONID=randomid; Domain=bank.example.com; Secure; HttpOnly

Content-Type: application/x-www-form-urlencoded

amount=100.00&routingNumber=1234&account=9876&_csrf=<secure-random>

一个常见的问题是"do I need to protect JSON requests made by javascript?"简短的答案是，这取决于。 但是，您必须非常小心，因为存在会影响JSON请求的CSRF漏洞利用。 例如，恶意用户可以创建 使用以下格式的JSON CSRF：

这将产生以下JSON结构

如果应用程序未验证Content-Type，那么它将暴露于此漏洞利用。 根据设置，验证Content-Type的Spring MVC应用程序仍然可以通过更新URL后缀来利用".json"来结束，如下所示：

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

例如，考虑一个应用程序使用包含所有状态的自定义cookie来进行身份验证，而不是JSESSIONID。 当CSRF攻击发生时，自定义cookie将与请求一起发送，其方式与前面示例中发送的JSESSIONID cookie相同。

使用基本身份验证的用户也容易受到CSRF攻击，因为浏览器将自动在任何请求中包含用户名密码，方式与JSESSIONID cookie在前一示例中发送的方式相同。

防止CSRF攻击的第一步是确保您的网站使用正确的HTTP动词。 具体来说，在Spring Security的CSRF支持可以使用之前，您需要确定您的应用程序正在使用PATCH，POST，PUT和/或DELETE来修改状态。

这不是Spring Security支持的限制，而是正确的CSRF预防的一般要求。 原因是在HTTP GET中包含私人信息会导致信息泄露。 有关使用POST而不是GET获取敏感信息的一般指导，请参阅 RFC 2616第15.1.3节对URI中的敏感信息进行编码。

下一步是在您的应用程序中包含Spring Security的CSRF保护。 有些框架通过对用户的会话进行无效处理来处理无效的CSRF令牌，但这会导致its own problems。 相反，默认情况下，Spring Security的CSRF保护将导致HTTP 403访问被拒绝。 这可以通过配置AccessDeniedHandler以不同方式处理InvalidCsrfTokenException来定制。

从Spring Security 4.0开始，默认情况下使用XML配置启用CSRF保护。 如果您想禁用CSRF保护，则可以在下面看到相应的XML配置。

Java Configuration默认启用CSRF保护。 如果您想禁用CSRF，则可以在下面看到相应的Java配置。 有关如何配置CSRF保护的其他自定义，请参阅csrf（）的Javadoc。

表单提交

<c:url var="logoutUrl" value="/logout"/>

<form action="${logoutUrl}"

	method="post">

<input type="submit"

	value="Log out" />

<input type="hidden"

	name="${_csrf.parameterName}"

	value="${_csrf.token}"/>

</form>

Ajax和JSON请求

<html>

<head>

	<meta name="_csrf" content="${_csrf.token}"/>

	<!-- default header name is X-CSRF-TOKEN -->

	<meta name="_csrf_header" content="${_csrf.headerName}"/>

	<!-- ... -->

</head>

<!-- ... -->

$(function () {

var token = $("meta[name='_csrf']").attr("content");

var header = $("meta[name='_csrf_header']").attr("content");

$(document).ajaxSend(function(e, xhr, options) {

	xhr.setRequestHeader(header, token);

});

});

var client = rest.chain(csrf, {

token: $("meta[name='_csrf']").attr("content"),

name: $("meta[name='_csrf_header']").attr("content")

});

CookieCsrfTokenRepository

<http>

	<!-- ... -->

	<csrf token-repository-ref="tokenRepository"/>

</http>

<b:bean id="tokenRepository"

	class="org.springframework.security.web.csrf.CookieCsrfTokenRepository"

	p:cookieHttpOnly="false"/>

@EnableWebSecurity

public class WebSecurityConfig extends

		WebSecurityConfigurerAdapter {

	@Override

	protected void configure(HttpSecurity http) throws Exception {

		http

			.csrf()

				.csrfTokenRepository(CookieCsrfTokenRepository.withHttpOnlyFalse());

	}

}

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

缓解处于超时状态的活动用户的一个简单方法是使用一些JavaScript让用户知道他们的会话即将过期。 用户可以点击一个按钮继续并刷新会话。

或者，指定自定义AccessDeniedHandler可让您以任何方式处理InvalidCsrfTokenException。 有关如何自定义AccessDeniedHandler的示例，请参阅xml和https://github.com/spring-projects/spring-security/blob/3.2.0.RC1/提供的链接config / src / test / groovy / org / springframework / security / config / annotation / web / configurers / NamespaceHttpAccessDeniedHandlerTests.groovy＃L64 [Java配置]。

最后，可以将应用程序配置为使用不会过期的CookieCsrfTokenRepository。 如前所述，这不像使用会话那样安全，但在很多情况下可以足够好。

为了防止 伪造登录请求，登录表单也应该受到保护，以防止CSRF攻击。 由于CsrfToken存储在HttpSession中，这意味着一旦访问CsrfToken令牌属性，就会创建一个HttpSession。 虽然这在RESTful /无状态架构中听起来很糟糕，但现实是状态对于实现实际安全性是必需的。 没有国家，如果令牌受到损害，我们就无能为力。 实际上，CSRF令牌的规模很小，对我们的架构应该有微不足道的影响。

保护登录表单的常用技术是在表单提交之前使用JavaScript函数获取有效的CSRF标记。 通过这样做，不需要考虑会话超时（在前面的章节中讨论过），因为会话是在表单提交之前创建的（假设没有配置CookieCsrfTokenRepository），因此用户可以停留在登录页面上，并在需要时提交用户名/密码。 为了实现这一点，您可以利用Spring Security提供的CsrfTokenArgumentResolver，并公开如here中描述的端点。

添加CSRF将更新LogoutFilter以仅使用HTTP POST。 这可确保注销需要CSRF令牌，并且恶意用户无法强制注销用户。

一种方法是使用表单注销。 如果你真的想要一个链接，你可以使用JavaScript来让链接执行一个POST（即可能在一个隐藏的窗体上）。 对于禁用JavaScript的浏览器，您可以选择使链接将用户带到注销确认页面，该页面将执行POST。

如果你真的想在注销时使用HTTP GET，你可以这样做，但请记住这通常不被推荐。 例如，以下Java配置将执行注销，并使用任何HTTP方法请求URL /注销：

有多种方法可以对多部分/表单数据使用CSRF保护。 每个选项都有其折衷。

• Placing MultipartFilter before Spring Security

• Include CSRF token in action

在Spring Security之前放置MultipartFilter

public class SecurityApplicationInitializer extends AbstractSecurityWebApplicationInitializer {

	@Override

	protected void beforeSpringSecurityFilterChain(ServletContext servletContext) {

		insertFilters(servletContext, new MultipartFilter());

	}

}

<filter>

	<filter-name>MultipartFilter</filter-name>

	<filter-class>org.springframework.web.multipart.support.MultipartFilter</filter-class>

</filter>

<filter>

	<filter-name>springSecurityFilterChain</filter-name>

	<filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>

</filter>

<filter-mapping>

	<filter-name>MultipartFilter</filter-name>

	<url-pattern>/*</url-pattern>

</filter-mapping>

<filter-mapping>

	<filter-name>springSecurityFilterChain</filter-name>

	<url-pattern>/*</url-pattern>

</filter-mapping>

包含CSRF令牌

<form action="./upload?${_csrf.parameterName}=${_csrf.token}" method="post" enctype="multipart/form-data">

HiddenHttpMethodFilter应放置在Spring Security过滤器之前。 总的来说，这是事实，但在防范CSRF攻击时可能会产生额外的影响。

请注意，HiddenHttpMethodFilter只覆盖POST上的HTTP方法，所以这实际上不会导致任何实际问题。 但是，确保在Spring Security过滤器之前放置它仍然是最佳实践。

Cache-Control: no-cache, no-store, max-age=0, must-revalidate

Pragma: no-cache

Expires: 0

X-Content-Type-Options: nosniff

Strict-Transport-Security: max-age=31536000 ; includeSubDomains

X-Frame-Options: DENY

X-XSS-Protection: 1; mode=block

Cache-Control: no-cache, no-store, max-age=0, must-revalidate

Pragma: no-cache

Expires: 0

X-Content-Type-Options: nosniff

X-Frame-Options: SAMEORIGIN

X-XSS-Protection: 1; mode=block

@EnableWebSecurity

public class WebSecurityConfig extends

		WebSecurityConfigurerAdapter {

	@Override

	protected void configure(HttpSecurity http) throws Exception {

		http

			// ...

			.headers()

				.frameOptions().sameOrigin()

				.httpStrictTransportSecurity().disable();

	}

}

<http>

	<!-- ... -->

	<headers>

		<frame-options policy="SAMEORIGIN" />

		<hsts disable="true"/>

	</headers>

</http>

@EnableWebSecurity

public class WebSecurityConfig extends

WebSecurityConfigurerAdapter {

@Override

protected void configure(HttpSecurity http) throws Exception {

	http

	// ...

	.headers()

		// do not use any default headers unless explicitly listed

		.defaultsDisabled()

		.cacheControl();

}

}

<http>

	<!-- ... -->

	<headers defaults-disabled="true">

		<cache-control/>

	</headers>

</http>

@EnableWebSecurity

public class WebSecurityConfig extends

WebSecurityConfigurerAdapter {

@Override

protected void configure(HttpSecurity http) throws Exception {

	http

	// ...

	.headers().disable();

}

}

<http>

	<!-- ... -->

	<headers disabled="true" />

</http>

在过去，Spring Security要求您为您的Web应用程序提供自己的缓存控制。 这在当时似乎是合理的，但浏览器缓存已经发展到包括用于安全连接的缓存。 这意味着用户可以查看已认证的页面并注销，然后恶意用户可以使用浏览器历史记录查看缓存的页面。 为了帮助缓解这个问题，Spring Security增加了缓存控制支持，它将在响应中插入以下头文件。

简单地添加没有子元素的<headers>元素将自动添加缓存控制和其他一些保护。 但是，如果您只需要缓存控制，则可以使用带有<cache-control>元素和headers@defaults-disabled属性的Spring Security的XML名称空间启用此功能。

同样，您可以通过以下方式仅启用Java配置中的缓存控制：

如果您真的想缓存特定的响应，您的应用程序可以选择性地调用 HttpServletResponse.setHeader（字符串，字符串）来覆盖Spring Security设置的标头。 这对于确保像CSS，JavaScript和图像等正确缓存很有用。

在使用Spring Web MVC时，通常在您的配置中完成。 例如，以下配置将确保为所有资源设置缓存标头：

历史上，浏览器（包括Internet Explorer）会尝试使用 内容嗅探来猜测请求的内容类型。 这允许浏览器通过猜测未指定内容类型的资源上的内容类型来改善用户体验。 例如，如果浏览器遇到没有指定内容类型的JavaScript文件，它将能够猜测内容类型并执行它。

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

内容嗅探可以通过将以下标题添加到我们的响应来禁用：

就像缓存控制元素一样，在没有子元素的情况下使用<headers>元素时，默认添加nosniff指令。 但是，如果您想更多地控制添加哪些标题，则可以使用<content-type-options>元素和headers@defaults-disabled属性，如下所示：

默认情况下，Spring Security Java配置会添加X-Content-Type-Options标头。 如果您想更好地控制标题，可以使用以下内容显式指定内容类型选项：

当您输入银行网站时，您是输入mybank.example.com还是输入https://mybank.example.com []？如果您省略https协议，则可能会受 中间人攻击的影响。 即使网站执行https://mybank.example.com的重定向，恶意用户也可能会拦截最初的HTTP请求并操纵响应（即重定向到https://mibank.example.com并窃取其凭据）。

许多用户省略了https协议，这就是 HTTP严格传输安全性（HSTS）创建的原因。 一旦mybank.example.com作为 HSTS主机添加，浏览器可以提前知道任何对mybank.example.com的请求应该被解释为https://mybank.example.com。 这大大降低了发生中间人攻击的可能性。

将站点标记为HSTS主机的一种方法是将主机预加载到浏览器中。 另一种方法是将"Strict-Transport-Security"标头添加到响应中。 例如，以下内容将指示浏览器将域名视为一年的HSTS主机（一年大约有31536000秒）：

可选的includeSubDomains指令指示Spring Security将子域（即secure.mybank.example.com）也视为HSTS域。

与其他标题一样，Spring Security默认添加HSTS。 您可以使用<hsts>元素自定义HSTS标头，如下所示：

同样，您可以只启用带有Java配置的HSTS头文件：

HTTP Public Key Pinning（HPKP）是一项安全功能，它告诉Web客户端将特定的加密公钥与特定的Web服务器相关联，以防止伪造的证书对中间人（MITM）的攻击。

为了确保在TLS会话中使用的服务器公钥的真实性，该公钥被封装到通常由证书颁发机构（CA）签署的X.509证书中。 Web客户端（如浏览器）信任很多这些CA，它们都可以为任意域名创建证书。 如果攻击者能够危害单个CA，他们可以对各种TLS连接执行MITM攻击。 HPKP可以通过告诉客户端哪个公钥属于某个Web服务器来规避HTTPS协议的这种威胁。 HPKP是首次使用信托（TOFU）技术。 Web服务器第一次通过特殊的HTTP头告诉客户端公钥属于它时，客户端将这些信息存储一段给定的时间。 当客户端再次访问服务器时，它需要一个包含指纹已经通过HPKP知道的公钥的证书。 如果服务器提供未知的公钥，则客户端应向用户提供警告。

为您的站点启用此功能非常简单，只需在通过HTTPS访问您的站点时返回Public-Key-Pins HTTP标头即可。 例如，以下内容将指示用户代理仅向指定的URI报告引脚验证失败（通过https://tools.ietf.org/html/rfc7469#section-2.1.4[report-uri]指令）2个引脚：

pin validation failure report是标准的JSON结构，可以通过Web应用程序自己的API或公开托管的HPKP报告服务来捕获，如https://report-uri.io/[REPORT-URI]。

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

与其他标题相反，Spring Security默认不添加HPKP。 您可以使用<hpkp>元素自定义HPKP标题，如下所示：

同样，您可以使用Java配置启用HPKP标题：

允许将您的网站添加到框架可能是一个安全问题。 例如，使用聪明的CSS样式的用户可能会被欺骗点击他们不想要的东西（ 视频演示）。 例如，登录他们银行的用户可能会点击一个按钮，授予对其他用户的访问权限。 这种攻击被称为 点击劫持。

有多种方法可以缓解点击劫持攻击。 例如，为了保护传统浏览器免受点击劫持攻击，您可以使用https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet#Best-for-now_Legacy_Browser_Frame_Breaking_Script [框架破解代码]。 虽然不完美，但对于传统浏览器来说，破解代码是最好的选择。

处理点击劫持的更现代的方法是使用https://developer.mozilla.org/en-US/docs/HTTP/X-Frame-Options[X-Frame-Options]标头：

X-Frame-Options响应头指示浏览器阻止响应中的任何站点在帧中呈现。 默认情况下，Spring Security会禁用iframe中的渲染。

您可以使用frame-options元素自定义X-Frame-Options。 例如，以下内容将指示Spring Security使用允许同一域内的iframe的"X-Frame-Options: SAMEORIGIN"：

同样，您可以使用以下方法自定义框架选项以在Java配置中使用相同的源：

有些浏览器支持过滤https://www.owasp.org/index.php/Testing_for_Reflected_Cross_site_scripting_(OWASP-DV-001)[reflected XSS attacks]。 这绝不是万无一失的，但有助于XSS保护。

默认情况下，过滤通常处于启用状态，因此添加标头通常会确保启用它并指示浏览器在检测到XSS攻击时该执行什么操作。 例如，该过滤器可能会尝试以最小侵入方式更改内容，以继续呈现所有内容。 有时候，这种类型的替换可能会变成 XSS漏洞本身。 相反，最好是阻止内容而不是尝试修复它。 为此，我们可以添加以下标题：

该标题默认包含在内。 但是，如果我们想要，我们可以定制它。 例如：

同样，您可以使用以下方法在Java配置中自定义XSS保护：

https://www.w3.org/TR/CSP2/ [内容安全策略（CSP）]是Web应用程序可以利用的机制来缓解内容注入漏洞，例如跨站点脚本（XSS）。 CSP是一种声明性策略，为Web应用程序作者声明并最终通知客户端（用户代理）有关Web应用程序预期从中加载资源的来源提供了便利。

Web应用程序可以通过在响应中包含以下HTTP标头之一来使用CSP：

• Content-Security-Policy

• Content-Security-Policy-Report-Only

这些标头中的每一个都用作将security policy交付给客户端的机制。 安全策略包含一组security policy directives（例如script-src和object-src），每个负责声明特定资源表示的限制。

例如，Web应用程序可以声明它希望通过在响应中包含以下标题来从特定的可信来源加载脚本：

尝试从其他来源加载脚本，而不是在script-src指令中声明的脚本将被用户代理阻止。 此外，如果在安全策略中声明了https://www.w3.org/TR/CSP2/#directive-report-uri[report-uri]指令，则该违规将由用户代理报告到声明的URL。

例如，如果Web应用程序违反了声明的安全策略，则以下响应标头将指示用户代理将违规报告发送到策略的report-uri指令中指定的URL。

Violation reports是标准的JSON结构，可以通过Web应用程序自己的API或公开托管的CSP违规报告服务来捕获，如https://report-uri.io/[REPORT-URI]。

Content-Security-Policy-Report-Only标头为Web应用程序作者和管理员提供了监控安全策略的功能，而不是强制执行它们。 此标题通常用于为网站试验和/或开发安全策略。 当策略被认为有效时，可以通过使用Content-Security-Policy标头字段来强制实施。

给定以下响应头，该策略声明脚本可以从两个可能来源之一加载。

如果站点违反了此策略，则通过尝试从evil.com加载脚本，用户代理将向report-uri指令指定的声明URL发送违规报告，但仍允许加载违规资源。

配置内容安全策略

script-src 'self' https://trustedscripts.example.com; object-src https://trustedplugins.example.com; report-uri /csp-report-endpoint/

<http>

	<!-- ... -->

	<headers>

		<content-security-policy

			policy-directives="script-src 'self' https://trustedscripts.example.com; object-src https://trustedplugins.example.com; report-uri /csp-report-endpoint/" />

	</headers>

</http>

<http>

	<!-- ... -->

	<headers>

		<content-security-policy

			policy-directives="script-src 'self' https://trustedscripts.example.com; object-src https://trustedplugins.example.com; report-uri /csp-report-endpoint/"

			report-only="true" />

	</headers>

</http>

@EnableWebSecurity

public class WebSecurityConfig extends

WebSecurityConfigurerAdapter {

@Override

protected void configure(HttpSecurity http) throws Exception {

	http

	// ...

	.headers()

		.contentSecurityPolicy("script-src 'self' https://trustedscripts.example.com; object-src https://trustedplugins.example.com; report-uri /csp-report-endpoint/");

}

}

@EnableWebSecurity

public class WebSecurityConfig extends

WebSecurityConfigurerAdapter {

@Override

protected void configure(HttpSecurity http) throws Exception {

	http

	// ...

	.headers()

		.contentSecurityPolicy("script-src 'self' https://trustedscripts.example.com; object-src https://trustedplugins.example.com; report-uri /csp-report-endpoint/")

		.reportOnly();

}

}

其他资源

Referrer Policy是Web应用程序可以利用的机制来管理引用者字段，其中包含最后一个 用户所在的页面。

Spring Security的方法是使用https://www.w3.org/TR/referrer-policy/[Referrer Policy]标头，它提供了不同的https://www.w3.org/TR/referrer-policy/#referrer-政策[政策]：

Referrer-Policy响应头指示浏览器让目的地知道用户以前的来源。

配置Referrer策略

<http>

	<!-- ... -->

	<headers>

		<referrer-policy policy="same-origin" />

	</headers>

</http>

@EnableWebSecurity

public class WebSecurityConfig extends

WebSecurityConfigurerAdapter {

@Override

protected void configure(HttpSecurity http) throws Exception {

	http

	// ...

	.headers()

		.referrerPolicy(ReferrerPolicy.SAME_ORIGIN);

}

}

您可能有时希望将自定义安全标头插入到您的应用程序中，但不支持开箱即用。 例如，给定以下自定义安全标头：

使用XML名称空间时，可以使用<header>元素将这些头添加到响应中，如下所示：

同样，可以使用Java Configuration将头添加到响应中，如下所示：

如果名称空间或Java配置不支持所需的标题，则可以创建自定义HeadersWriter实例，甚至可以提供HeadersWriter的自定义实现。

我们来看看使用XFrameOptionsHeaderWriter的自定义实例的示例。 也许你想允许为相同的来源制作内容。 通过将policy属性设置为"SAMEORIGIN"，很容易支持这一点，但让我们来看看使用ref属性的更明确的示例。

我们还可以通过Java配置将内容的框架限制在相同的原始位置：

有时您可能只想为某些请求编写头文件。 例如，也许你只想保护你的登录页面不被陷害。 您可以使用DelegatingRequestMatcherHeaderWriter来执行此操作。 在使用XML名称空间配置时，可以通过以下方式完成此操作：

我们还可以使用java配置防止内容成帧到登录页面：

<http>

<custom-filter position="FORM_LOGIN_FILTER" ref="myAuthFilter" />

<session-management session-authentication-strategy-ref="sas"/>

</http>

<beans:bean id="myAuthFilter" class=

"org.springframework.security.web.authentication.UsernamePasswordAuthenticationFilter">

	<beans:property name="sessionAuthenticationStrategy" ref="sas" />

	...

</beans:bean>

<beans:bean id="sas" class=

"org.springframework.security.web.authentication.session.SessionFixationProtectionStrategy" />

<listener>

	<listener-class>

	org.springframework.security.web.session.HttpSessionEventPublisher

	</listener-class>

</listener>

<http>

<custom-filter position="CONCURRENT_SESSION_FILTER" ref="concurrencyFilter" />

<custom-filter position="FORM_LOGIN_FILTER" ref="myAuthFilter" />

<session-management session-authentication-strategy-ref="sas"/>

</http>

<beans:bean id="redirectSessionInformationExpiredStrategy"

class="org.springframework.security.web.session.SimpleRedirectSessionInformationExpiredStrategy">

<beans:constructor-arg name="invalidSessionUrl" value="/session-expired.htm" />

</beans:bean>

<beans:bean id="concurrencyFilter"

class="org.springframework.security.web.session.ConcurrentSessionFilter">

<beans:constructor-arg name="sessionRegistry" ref="sessionRegistry" />

<beans:constructor-arg name="sessionInformationExpiredStrategy" ref="redirectSessionInformationExpiredStrategy" />

</beans:bean>

<beans:bean id="myAuthFilter" class=

"org.springframework.security.web.authentication.UsernamePasswordAuthenticationFilter">

<beans:property name="sessionAuthenticationStrategy" ref="sas" />

<beans:property name="authenticationManager" ref="authenticationManager" />

</beans:bean>

<beans:bean id="sas" class="org.springframework.security.web.authentication.session.CompositeSessionAuthenticationStrategy">

<beans:constructor-arg>

	<beans:list>

	<beans:bean class="org.springframework.security.web.authentication.session.ConcurrentSessionControlAuthenticationStrategy">

		<beans:constructor-arg ref="sessionRegistry"/>

		<beans:property name="maximumSessions" value="1" />

		<beans:property name="exceptionIfMaximumExceeded" value="true" />

	</beans:bean>

	<beans:bean class="org.springframework.security.web.authentication.session.SessionFixationProtectionStrategy">

	</beans:bean>

	<beans:bean class="org.springframework.security.web.authentication.session.RegisterSessionAuthenticationStrategy">

		<beans:constructor-arg ref="sessionRegistry"/>

	</beans:bean>

	</beans:list>

</beans:constructor-arg>

</beans:bean>

<beans:bean id="sessionRegistry"

	class="org.springframework.security.core.session.SessionRegistryImpl" />

通过命名空间或使用普通bean设置并发控制具有有用的副作用，即为您提供对可在应用程序中直接使用的SessionRegistry的引用，因此即使您不想限制用户可能拥有的会话数量，无论如何，建立基础架构可能都是值得的。 您可以将maximumSession属性设置为-1以允许无限制的会话。 如果您使用的是名称空间，则可以使用session-registry-alias属性为内部创建的SessionRegistry设置别名，从而为您自己的bean注入引用。

getAllPrincipals()方法为您提供当前已通过身份验证的用户列表。 您可以通过调用getAllSessions(Object principal, boolean includeExpiredSessions)方法列出用户的会话，该方法返回SessionInformation对象列表。 您也可以通过调用SessionInformation实例上的expireNow()来过期用户的会话。 当用户返回到应用程序时，将阻止他们继续进行。 例如，您可以在管理应用程序中找到这些方法。 查看Javadoc以获取更多信息。

<bean id="anonymousAuthFilter"

	class="org.springframework.security.web.authentication.AnonymousAuthenticationFilter">

<property name="key" value="foobar"/>

<property name="userAttribute" value="anonymousUser,ROLE_ANONYMOUS"/>

</bean>

<bean id="anonymousAuthenticationProvider"

	class="org.springframework.security.authentication.AnonymousAuthenticationProvider">

<property name="key" value="foobar"/>

</bean>

<bean id="filterSecurityInterceptor"

	class="org.springframework.security.web.access.intercept.FilterSecurityInterceptor">

<property name="authenticationManager" ref="authenticationManager"/>

<property name="accessDecisionManager" ref="httpRequestAccessDecisionManager"/>

<property name="securityMetadata">

	<security:filter-security-metadata-source>

	<security:intercept-url pattern='/index.jsp' access='ROLE_ANONYMOUS,ROLE_USER'/>

	<security:intercept-url pattern='/hello.htm' access='ROLE_ANONYMOUS,ROLE_USER'/>

	<security:intercept-url pattern='/logoff.jsp' access='ROLE_ANONYMOUS,ROLE_USER'/>

	<security:intercept-url pattern='/login.jsp' access='ROLE_ANONYMOUS,ROLE_USER'/>

	<security:intercept-url pattern='/**' access='ROLE_USER'/>

	</security:filter-security-metadata-source>" +

</property>

</bean>

Spring Security没有提供直接的JSR-356支持，因为这样做没有多大价值。 这是因为格式未知，所以 小泉可以做到保证未知格式。 另外，JSR-356不提供拦截消息的方法，所以安全性会相当侵入。

@Configuration

public class WebSocketSecurityConfig

      extends AbstractSecurityWebSocketMessageBrokerConfigurer {  

    protected void configureInbound(MessageSecurityMetadataSourceRegistry messages) {

        messages

                .simpDestMatchers("/user/*").authenticated()

    }

}

<websocket-message-broker>  

    <intercept-message pattern="/user/**" access="hasRole('USER')" />

</websocket-message-broker>

@Configuration

public class WebSocketSecurityConfig extends AbstractSecurityWebSocketMessageBrokerConfigurer {

    @Override

    protected void configureInbound(MessageSecurityMetadataSourceRegistry messages) {

        messages

                .nullDestMatcher().authenticated()

                .simpSubscribeDestMatchers("/user/queue/errors").permitAll()

                .simpDestMatchers("/app/**").hasRole("USER")

                .simpSubscribeDestMatchers("/user/**", "/topic/friends/*").hasRole("USER")

                .simpTypeMatchers(MESSAGE, SUBSCRIBE).denyAll()

                .anyMessage().denyAll(); 

    }

}

<websocket-message-broker>

    <intercept-message type="CONNECT" access="permitAll" />

    <intercept-message type="UNSUBSCRIBE" access="permitAll" />

    <intercept-message type="DISCONNECT" access="permitAll" />

    <intercept-message pattern="/user/queue/errors" type="SUBSCRIBE" access="permitAll" />

    <intercept-message pattern="/app/**" access="hasRole('USER')" />      

    <intercept-message pattern="/user/**" access="hasRole('USER')" />

    <intercept-message pattern="/topic/friends/*" access="hasRole('USER')" />

    <intercept-message type="MESSAGE" access="denyAll" />

    <intercept-message type="SUBSCRIBE" access="denyAll" />

    <intercept-message pattern="/**" access="denyAll" />

</websocket-message-broker>

为了正确保护你的应用程序，理解Spring的WebSocket支持是很重要的。

消息类型的===== WebSocket授权

了解SUBSCRIBE和MESSAGE消息类型之间的区别以及它在Spring中的工作方式非常重要。

考虑一个聊天应用程序。

• 系统可以通过"/topic/system/notifications"的目的地向所有用户发送通知MESSAGE

• 客户可以通过SUBSCRIBE向"/topic/system/notifications"收到通知。

虽然我们希望客户能够订阅"/topic/system/notifications"，但我们不希望让他们向该目的地发送MESSAGE。 如果我们允许发送MESSAGE到"/topic/system/notifications"，则客户端可以直接向该端点发送消息并模拟系统。

一般而言，应用程序通常会拒绝任何发送到以 经纪人前缀开头的消息（即"/topic/"或"/queue/"）的消息。

目的地上的===== WebSocket授权

了解目的地如何转变也很重要。

考虑一个聊天应用程序。

• 用户可以通过向"/app/chat"的目的地发送消息来向特定用户发送消息。

• 应用程序看到该消息，确保将"from"属性指定为当前用户（我们不能信任客户端）。

• 然后，应用程序使用SimpMessageSendingOperations.convertAndSendToUser("toUser", "/queue/messages", message)将消息发送给收件人。

• 邮件转到"/queue/user/messages-<sessionid>"的目的地

通过上面的应用程序，我们希望允许我们的客户端收听转换为"/queue/user/messages-<sessionid>"的{​​{0}}。 但是，我们不希望客户端能够收听"/queue/*"，因为这可以让客户端看到每个用户的消息。

一般来说，应用程序通常拒绝发送给以 经纪人前缀开头的消息（即"/topic/"或"/queue/"）的任何SUBSCRIBE。 当然，我们可能会提供例外来解释诸如此类的事情

Spring包含标题为 消息流的部分，它描述了消息如何流经系统。 值得注意的是，Spring Security只保护clientInboundChannel。 Spring Security不会尝试保护clientOutboundChannel。

最重要的原因是性能。 对于每一条消息，通常会有更多消息传出。 我们鼓励确保订阅端点，而不是保护出站消息。

考虑以下情况。 用户访问bank.com并向其帐户进行身份验证。 同一用户在其浏览器中打开另一个选项卡并访问evil.com。 同源策略确保evil.com无法读取或写入bank.com数据。

使用WebSockets相同的来源策略不适用。 事实上，除非bank.com明确禁止它，否则evil.com可以代表用户读取和写入数据。 这意味着用户可以通过webSocket进行任何操作（即转账资金），evil.com可以代表该用户进行操作。

由于SockJS试图模拟WebSockets，它也绕过了同源策略。 这意味着开发人员在使用SockJS时需要明确地保护他们的应用程序免受外部域的攻击

幸运的是，自Spring 4.1.5以来，Spring的WebSocket和SockJS支持限制了对 当前域的访问。 Spring Security增加了额外的保护层来提供 深度防守。

默认情况下，Spring Security需要任何CONNECT消息类型中的CSRF token。 这确保只有可访问CSRF令牌的站点才能连接。 由于只有Same Origin可以访问CSRF令牌，因此不允许外部域进行连接。

通常，我们需要将CSRF令牌包含在HTTP标头或HTTP参数中。 但是，SockJS不允许使用这些选项。 相反，我们必须在Stomp标头中包含令牌

通过访问名为_csrf的请求属性，应用程序可以obtain a CSRF token。 例如，以下将允许访问JSP中的CsrfToken：

如果您使用静态HTML，则可以在REST端点上公开CsrfToken。 例如，以下内容将显示URL / csrf上的CsrfToken

JavaScript可以对端点进行REST调用，并使用响应填充headerName和令牌。

我们现在可以在Stomp客户端中包含令牌。 例如：

如果您想允许其他域访问您的网站，可以禁用Spring Security的保护。 例如，在Java配置中，您可以使用以下内容：

SockJS可以使用https://github.com/sockjs/sockjs-client/tree/v0.3.4[transport利用iframe]。 默认情况下，Spring Security将deny站点框起来以防止点击劫持攻击。 为了允许基于SockJS框架的传输工作，我们需要配置Spring Security以允许相同的源来构造内容。

您可以使用frame-options元素自定义X-Frame-Options。 例如，以下内容将指示Spring Security使用允许同一域内的iframe的"X-Frame-Options: SAMEORIGIN"：

同样，您可以使用以下方法自定义框架选项以在Java配置中使用相同的源：

对于任何基于HTTP的传输，SockJS在CONNECT消息上使用POST。 通常，我们需要将CSRF令牌包含在HTTP标头或HTTP参数中。 但是，SockJS不允许使用这些选项。 相反，我们必须按照将CSRF添加到Stomp标题中所述将标记包含在Stomp标头中。

这也意味着我们需要通过Web层来放松我们的CSRF保护。 具体而言，我们希望为我们的连接网址禁用CSRF保护。 我们不希望为每个网址禁用CSRF保护。 否则我们的网站将容易受到CSRF攻击。

我们可以通过提供CSRF RequestMatcher轻松实现此目的。 我们的Java配置使得这非常简单。 例如，如果我们的端点是"/chat"，我们可以仅使用以下配置为仅以"/chat/"开头的URL禁用CSRF保护：

如果我们使用基于XML的配置，我们可以使用csrf@request-matcher-ref。 例如：

String getAuthority();