对于最新的稳定版本,请使用 Spring Security 6.4.1! |
身份验证持久性和会话管理
一旦您有一个正在对请求进行身份验证的应用程序,重要的是要考虑如何在将来的请求中保留和恢复生成的身份验证。
默认情况下,这是自动完成的,因此不需要额外的代码,但了解是什么很重要requireExplicitSave
表示HttpSecurity
.
如果你愿意,你可以阅读更多关于 requireExplicitSave 的作用或它为什么重要。否则,在大多数情况下,您已完成此部分。
但在您离开之前,请考虑以下用例是否适合您的应用程序:
-
我想限制用户可以同时登录的次数
-
我想自己直接存储身份验证,而不是 Spring Security 为我执行此作
-
我正在手动存储身份验证,并且想要删除它
-
我想将身份验证存储在会话以外的其他位置
-
我正在使用无状态身份验证,但我仍希望将其存储在会话中
-
我正在使用
SessionCreationPolicy.NEVER
但应用程序仍在创建会话。
了解会话管理的组件
Session Management 支持由几个组件组成,这些组件协同工作以提供功能。
这些组件是:这SecurityContextHolderFilter
,这SecurityContextPersistenceFilter
和这SessionManagementFilter
.
在 Spring Security 6 中, |
这SessionManagementFilter
这SessionManagementFilter
检查SecurityContextRepository
针对SecurityContextHolder
确定用户是否在当前请求期间已经过身份验证,通常通过非交互式身份验证机制(如 pre-authentication 或 remember-me)进行身份验证[1].
如果存储库包含安全上下文,则筛选器不执行任何作。
如果没有,则线程本地的SecurityContext
包含一个 (非匿名)Authentication
对象,则筛选条件会假定它们已由堆栈中的前一个筛选条件进行身份验证。
然后,它将调用配置的SessionAuthenticationStrategy
.
如果用户当前未进行身份验证,则过滤器将检查是否请求了无效的会话 ID(例如,由于超时),并将调用配置的InvalidSessionStrategy
(如果已设置)。
最常见的行为只是重定向到一个固定的 URL,这被封装在标准实现中SimpleRedirectInvalidSessionStrategy
.
如前所述,当通过命名空间配置无效的会话 URL 时,也会使用后者。
远离SessionManagementFilter
在 Spring Security 5 中,默认配置依赖于SessionManagementFilter
检测用户是否只是进行身份验证并调用这SessionAuthenticationStrategy
.
这样做的问题在于,这意味着在典型设置中,HttpSession
必须为每个请求读取。
在 Spring Security 6 中,默认情况下,身份验证机制本身必须调用SessionAuthenticationStrategy
.
这意味着无需检测何时Authentication
已完成,因此HttpSession
不需要为每个请求读取。
搬离时要考虑的事项SessionManagementFilter
在 Spring Security 6 中,SessionManagementFilter
默认不使用,因此,来自sessionManagement
DSL 不会产生任何影响。
方法 | 更换 |
---|---|
|
配置 |
|
配置 |
|
如果尝试使用这些方法中的任何一种,将引发异常。
自定义身份验证的存储位置
默认情况下,Spring Security 将安全上下文存储在 HTTP 会话中。但是,以下是您可能希望自定义该自定义的几个原因:
-
您可能希望在
HttpSessionSecurityContextRepository
实例 -
您可能希望将安全上下文存储在缓存或数据库中,以启用水平扩展
首先,您需要创建一个SecurityContextRepository
或使用现有的实现,如HttpSessionSecurityContextRepository
,则可以在HttpSecurity
.
SecurityContextRepository
-
Java
-
Kotlin
-
XML
@Bean
public SecurityFilterChain filterChain(HttpSecurity http) {
SecurityContextRepository repo = new MyCustomSecurityContextRepository();
http
// ...
.securityContext((context) -> context
.securityContextRepository(repo)
);
return http.build();
}
@Bean
open fun filterChain(http: HttpSecurity): SecurityFilterChain {
val repo = MyCustomSecurityContextRepository()
http {
// ...
securityContext {
securityContextRepository = repo
}
}
return http.build()
}
<http security-context-repository-ref="repo">
<!-- ... -->
</http>
<bean name="repo" class="com.example.MyCustomSecurityContextRepository" />
上述配置将 |
如果您使用的是自定义身份验证机制,则可能需要存储Authentication
由您自己.
存储Authentication
手动地
例如,在某些情况下,您可能正在手动对用户进行身份验证,而不是依赖 Spring Security 过滤器。
你可以使用自定义过滤器或 Spring MVC 控制器端点来做到这一点。
如果要保存请求之间的身份验证,请在HttpSession
,例如,您必须这样做:
-
Java
private SecurityContextRepository securityContextRepository =
new HttpSessionSecurityContextRepository(); (1)
@PostMapping("/login")
public void login(@RequestBody LoginRequest loginRequest, HttpServletRequest request, HttpServletResponse response) { (2)
UsernamePasswordAuthenticationToken token = UsernamePasswordAuthenticationToken.unauthenticated(
loginRequest.getUsername(), loginRequest.getPassword()); (3)
Authentication authentication = authenticationManager.authenticate(token); (4)
SecurityContext context = securityContextHolderStrategy.createEmptyContext();
context.setAuthentication(authentication); (5)
securityContextHolderStrategy.setContext(context);
securityContextRepository.saveContext(context, request, response); (6)
}
class LoginRequest {
private String username;
private String password;
// getters and setters
}
1 | 添加SecurityContextRepository 前往控制器 |
2 | 注入HttpServletRequest 和HttpServletResponse 以便能够保存SecurityContext |
3 | 创建未经身份验证的UsernamePasswordAuthenticationToken 使用提供的凭证 |
4 | 叫AuthenticationManager#authenticate 对用户进行身份验证 |
5 | 创建一个SecurityContext 并设置Authentication 在里面 |
6 | 保存SecurityContext 在SecurityContextRepository |
就是这样。
如果您不确定securityContextHolderStrategy
在上面的示例中,您可以在用SecurityContextStrategy
部分.
正确清除身份验证
如果您使用的是 Spring Security 的 Logout Support,那么它会为您处理很多事情,包括清除和保存上下文。 但是,假设您需要手动将用户从您的应用程序中注销。在这种情况下,您需要确保正确清除和保存上下文。
现在,您可能已经熟悉如何清除SecurityContextHolder
通过执行SecurityContextHolderStrategy#clearContext()
.
这很好,但是如果您的应用程序需要显式保存上下文,那么仅仅清除它是不够的。
原因是它不会将其从SecurityContextRepository
,这意味着SecurityContext
仍可用于下一个请求,我们绝对不希望这样。
要确保正确清除和保存身份验证,您可以调用这SecurityContextLogoutHandler
它为我们做了这件事,就像这样:
-
Java
SecurityContextLogoutHandler handler = new SecurityContextLogoutHandler(); (1)
handler.logout(httpServletRequest, httpServletResponse, null); (2)
1 | 创建一个新的SecurityContextLogoutHandler |
2 | 调用logout 方法传入HttpServletRequest ,HttpServletResponse 以及null authentication 的 AS 文件,因为此处理程序不需要它。 |
重要的是要记住,清除和保存上下文只是注销过程的一部分,因此我们建议让 Spring Security 来处理它。
为无状态身份验证配置持久性
有时不需要创建和维护HttpSession
例如,跨请求保留身份验证。
某些身份验证机制(如 HTTP Basic)是无状态的,因此,在每个请求上都会重新验证用户。
如果您不想创建会话,可以使用SessionCreationPolicy.STATELESS
这样:
-
Java
-
Kotlin
-
XML
@Bean
public SecurityFilterChain filterChain(HttpSecurity http) {
http
// ...
.sessionManagement((session) -> session
.sessionCreationPolicy(SessionCreationPolicy.STATELESS)
);
return http.build();
}
@Bean
open fun filterChain(http: HttpSecurity): SecurityFilterChain {
http {
// ...
sessionManagement {
sessionCreationPolicy = SessionCreationPolicy.STATELESS
}
}
return http.build()
}
<http create-session="stateless">
<!-- ... -->
</http>
上述配置为配置SecurityContextRepository
要使用NullSecurityContextRepository
并且还阻止将请求保存在会话中。
如果您正在使用SessionCreationPolicy.NEVER
,您可能会注意到应用程序仍在创建一个HttpSession
.
在大多数情况下,发生这种情况是因为请求保存在会话中,以便经过身份验证的资源在身份验证成功后重新请求。
为避免这种情况,请参考 如何防止被保存请求 部分。
在会话中存储无状态身份验证
如果出于某种原因,您使用的是无状态身份验证机制,但您仍希望将身份验证存储在会话中,则可以使用HttpSessionSecurityContextRepository
而不是NullSecurityContextRepository
.
对于 HTTP Basic,您可以添加一个ObjectPostProcessor
这会更改SecurityContextRepository
由BasicAuthenticationFilter
:
HttpSession
-
Java
@Bean
SecurityFilterChain web(HttpSecurity http) throws Exception {
http
// ...
.httpBasic((basic) -> basic
.addObjectPostProcessor(new ObjectPostProcessor<BasicAuthenticationFilter>() {
@Override
public <O extends BasicAuthenticationFilter> O postProcess(O filter) {
filter.setSecurityContextRepository(new HttpSessionSecurityContextRepository());
return filter;
}
})
);
return http.build();
}
上述内容也适用于其他身份验证机制,例如 Bearer Token Authentication。
了解需要显式保存
在 Spring Security 5 中,默认行为是针对SecurityContext
以自动保存到SecurityContextRepository
使用SecurityContextPersistenceFilter
.
保存必须在HttpServletResponse
正在提交和之前SecurityContextPersistenceFilter
.
遗憾的是,自动持久化SecurityContext
在请求完成之前(即在提交HttpServletResponse
).
跟踪状态以确定是否需要保存也很复杂,这会导致对SecurityContextRepository
(即HttpSession
)。
由于这些原因,SecurityContextPersistenceFilter
已弃用,替换为SecurityContextHolderFilter
.
在 Spring Security 6 中,默认行为是这SecurityContextHolderFilter
只会读取SecurityContext
从SecurityContextRepository
并将其填充到SecurityContextHolder
.
用户现在必须显式保存SecurityContext
使用SecurityContextRepository
如果他们想要SecurityContext
以在请求之间持续存在。
这消除了歧义并提高了性能,因为只需要写入SecurityContextRepository
(即HttpSession
) 时。
运作方式
总之,当requireExplicitSave
是true
,Spring Security 设置这SecurityContextHolderFilter
而不是这SecurityContextPersistenceFilter
配置并发会话控制
如果您希望对单个用户登录应用程序的能力施加限制,Spring Security 通过以下简单的添加来支持开箱即用。 首先,您需要将以下侦听器添加到您的配置中,以使 Spring Security 了解会话生命周期事件:
-
Java
-
Kotlin
-
web.xml
@Bean
public HttpSessionEventPublisher httpSessionEventPublisher() {
return new HttpSessionEventPublisher();
}
@Bean
open fun httpSessionEventPublisher(): HttpSessionEventPublisher {
return HttpSessionEventPublisher()
}
<listener>
<listener-class>
org.springframework.security.web.session.HttpSessionEventPublisher
</listener-class>
</listener>
然后将以下行添加到您的安全配置中:
-
Java
-
Kotlin
-
XML
@Bean
public SecurityFilterChain filterChain(HttpSecurity http) {
http
.sessionManagement(session -> session
.maximumSessions(1)
);
return http.build();
}
@Bean
open fun filterChain(http: HttpSecurity): SecurityFilterChain {
http {
sessionManagement {
sessionConcurrency {
maximumSessions = 1
}
}
}
return http.build()
}
<http>
...
<session-management>
<concurrency-control max-sessions="1" />
</session-management>
</http>
这将防止用户多次登录 - 第二次登录将导致第一次登录无效。
使用 Spring Boot,您可以通过以下方式测试上述配置场景:
-
Java
@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
@AutoConfigureMockMvc
public class MaximumSessionsTests {
@Autowired
private MockMvc mvc;
@Test
void loginOnSecondLoginThenFirstSessionTerminated() throws Exception {
MvcResult mvcResult = this.mvc.perform(formLogin())
.andExpect(authenticated())
.andReturn();
MockHttpSession firstLoginSession = (MockHttpSession) mvcResult.getRequest().getSession();
this.mvc.perform(get("/").session(firstLoginSession))
.andExpect(authenticated());
this.mvc.perform(formLogin()).andExpect(authenticated());
// first session is terminated by second login
this.mvc.perform(get("/").session(firstLoginSession))
.andExpect(unauthenticated());
}
}
您可以使用 Maximum Sessions 示例进行尝试。
您通常希望阻止第二次登录,在这种情况下,您可以使用:
-
Java
-
Kotlin
-
XML
@Bean
public SecurityFilterChain filterChain(HttpSecurity http) {
http
.sessionManagement(session -> session
.maximumSessions(1)
.maxSessionsPreventsLogin(true)
);
return http.build();
}
@Bean
open fun filterChain(http: HttpSecurity): SecurityFilterChain {
http {
sessionManagement {
sessionConcurrency {
maximumSessions = 1
maxSessionsPreventsLogin = true
}
}
}
return http.build()
}
<http>
<session-management>
<concurrency-control max-sessions="1" error-if-maximum-exceeded="true" />
</session-management>
</http>
然后,第二次登录将被拒绝。
“rejected” 是指用户将被发送到authentication-failure-url
如果正在使用基于表单的登录。
如果第二次身份验证通过另一个非交互式机制进行,例如“remember-me”,则会向客户端发送“未授权”(401) 错误。
如果您想使用错误页面,则可以添加属性session-authentication-error-url
到session-management
元素。
使用 Spring Boot,您可以通过以下方式测试上述配置:
-
Java
@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
@AutoConfigureMockMvc
public class MaximumSessionsPreventLoginTests {
@Autowired
private MockMvc mvc;
@Test
void loginOnSecondLoginThenPreventLogin() throws Exception {
MvcResult mvcResult = this.mvc.perform(formLogin())
.andExpect(authenticated())
.andReturn();
MockHttpSession firstLoginSession = (MockHttpSession) mvcResult.getRequest().getSession();
this.mvc.perform(get("/").session(firstLoginSession))
.andExpect(authenticated());
// second login is prevented
this.mvc.perform(formLogin()).andExpect(unauthenticated());
// first session is still valid
this.mvc.perform(get("/").session(firstLoginSession))
.andExpect(authenticated());
}
}
如果您正在为基于表单的登录使用自定义身份验证过滤器,则必须显式配置并发会话控制支持。 您可以使用 Maximum Sessions Prevent Login 示例进行尝试。
检测超时
会话会自行过期,无需执行任何作来确保删除安全上下文。
也就是说,Spring Security 可以检测会话何时过期并采取您指示的特定作。
例如,您可能希望在用户使用已过期的会话发出请求时重定向到特定终端节点。
这是通过invalidSessionUrl
在HttpSecurity
:
-
Java
-
Kotlin
-
XML
@Bean
public SecurityFilterChain filterChain(HttpSecurity http) {
http
.sessionManagement(session -> session
.invalidSessionUrl("/invalidSession")
);
return http.build();
}
@Bean
open fun filterChain(http: HttpSecurity): SecurityFilterChain {
http {
sessionManagement {
invalidSessionUrl = "/invalidSession"
}
}
return http.build()
}
<http>
...
<session-management invalid-session-url="/invalidSession" />
</http>
请注意,如果使用此机制来检测会话超时,则当用户注销并重新登录而不关闭浏览器时,它可能会错误地报告错误。 这是因为当您使会话失效时,会话 Cookie 不会被清除,即使用户已注销,也会重新提交会话 Cookie。 如果是这种情况,您可能希望配置 logout 以清除会话 Cookie。
自定义无效会话策略
这invalidSessionUrl
是一种方便的方法InvalidSessionStrategy
使用SimpleRedirectInvalidSessionStrategy
实现.
如果要自定义行为,可以实现InvalidSessionStrategy
接口并使用invalidSessionStrategy
方法:
-
Java
-
Kotlin
-
XML
@Bean
public SecurityFilterChain filterChain(HttpSecurity http) {
http
.sessionManagement(session -> session
.invalidSessionStrategy(new MyCustomInvalidSessionStrategy())
);
return http.build();
}
@Bean
open fun filterChain(http: HttpSecurity): SecurityFilterChain {
http {
sessionManagement {
invalidSessionStrategy = MyCustomInvalidSessionStrategy()
}
}
return http.build()
}
<http>
...
<session-management invalid-session-strategy-ref="myCustomInvalidSessionStrategy" />
<bean name="myCustomInvalidSessionStrategy" class="com.example.MyCustomInvalidSessionStrategy" />
</http>
注销时清除会话 Cookie
您可以在注销时显式删除 JSESSIONID Cookie,例如使用Clear-Site-Data
页眉在 logout 处理程序中:
-
Java
-
Kotlin
-
XML
@Bean
public SecurityFilterChain filterChain(HttpSecurity http) {
http
.logout((logout) -> logout
.addLogoutHandler(new HeaderWriterLogoutHandler(new ClearSiteDataHeaderWriter(COOKIES)))
);
return http.build();
}
@Bean
open fun filterChain(http: HttpSecurity): SecurityFilterChain {
http {
logout {
addLogoutHandler(HeaderWriterLogoutHandler(ClearSiteDataHeaderWriter(COOKIES)))
}
}
return http.build()
}
<http>
<logout success-handler-ref="clearSiteDataHandler" />
<b:bean id="clearSiteDataHandler" class="org.springframework.security.web.authentication.logout.HeaderWriterLogoutHandler">
<b:constructor-arg>
<b:bean class="org.springframework.security.web.header.writers.ClearSiteDataHeaderWriter">
<b:constructor-arg>
<b:list>
<b:value>COOKIES</b:value>
</b:list>
</b:constructor-arg>
</b:bean>
</b:constructor-arg>
</b:bean>
</http>
这样做的优点是与容器无关,并且适用于任何支持Clear-Site-Data
页眉。
作为替代方法,您还可以在 logout 处理程序中使用以下语法:
-
Java
-
Kotlin
-
XML
@Bean
public SecurityFilterChain filterChain(HttpSecurity http) {
http
.logout(logout -> logout
.deleteCookies("JSESSIONID")
);
return http.build();
}
@Bean
open fun filterChain(http: HttpSecurity): SecurityFilterChain {
http {
logout {
deleteCookies("JSESSIONID")
}
}
return http.build()
}
<http>
<logout delete-cookies="JSESSIONID" />
</http>
遗憾的是,这不能保证适用于每个 servlet 容器,因此您需要在您的环境中对其进行测试。
如果您在代理后面运行应用程序,则还可以通过配置代理服务器来删除会话 cookie。
例如,通过使用 Apache HTTPD 的 |
<LocationMatch "/tutorial/logout">
Header always set Set-Cookie "JSESSIONID=;Path=/tutorial;Expires=Thu, 01 Jan 1970 00:00:00 GMT"
</LocationMatch>
了解 Session Fixation 攻击防护
会话固定攻击是一种潜在风险,恶意攻击者可能通过访问站点来创建会话,然后说服其他用户使用相同的会话登录(例如,通过向他们发送包含会话标识符作为参数的链接)。 Spring Security 通过在用户登录时创建新会话或更改会话 ID 来自动防止这种情况。
配置 Session Fixation Protection
您可以通过在三个建议选项之间进行选择来控制 Session Fixation Protection 的策略:
-
changeSessionId
- 不要创建新会话。 相反,请使用 Servlet 容器 (HttpServletRequest#changeSessionId()
). 此选项仅在 Servlet 3.1 (Java EE 7) 和更新的容器中可用。 在较旧的容器中指定它将导致异常。 这是 Servlet 3.1 和更高版本中的默认设置。 -
newSession
- 创建一个新的 “clean” session,而不复制现有的 session 数据(与 Spring Security 相关的属性仍然会被复制)。 -
migrateSession
- 创建新会话并将所有现有会话属性复制到新会话。 这是 Servlet 3.0 或更早版本中的默认设置。
您可以通过执行以下作来配置会话固定保护:
-
Java
-
Kotlin
-
XML
@Bean
public SecurityFilterChain filterChain(HttpSecurity http) {
http
.sessionManagement((session) - session
.sessionFixation((sessionFixation) -> sessionFixation
.newSession()
)
);
return http.build();
}
@Bean
open fun filterChain(http: HttpSecurity): SecurityFilterChain {
http {
sessionManagement {
sessionFixation {
newSession()
}
}
}
return http.build()
}
<http>
<session-management session-fixation-protection="newSession" />
</http>
当发生会话固定保护时,它会导致SessionFixationProtectionEvent
在 Application 上下文中发布。
如果您使用changeSessionId
,则此保护还会导致任何jakarta.servlet.http.HttpSessionIdListener
,因此如果您的代码同时侦听这两个事件,请谨慎使用。
您还可以将会话固定保护设置为none
以禁用它,但不建议这样做,因为它会使您的应用程序容易受到攻击。
用SecurityContextHolderStrategy
请考虑以下代码块:
-
Java
UsernamePasswordAuthenticationToken token = new UsernamePasswordAuthenticationToken(
loginRequest.getUsername(), loginRequest.getPassword());
Authentication authentication = this.authenticationManager.authenticate(token);
// ...
SecurityContext context = SecurityContextHolder.createEmptyContext(); (1)
context.setAuthentication(authentication); (2)
SecurityContextHolder.setContext(context); (3)
-
创建一个空的
SecurityContext
实例,方法是访问SecurityContextHolder
静态。 -
设置
Authentication
对象在SecurityContext
实例。 -
设置
SecurityContext
实例中的SecurityContextHolder
静态。
虽然上面的代码运行良好,但它可能会产生一些不需要的效果:当组件访问SecurityContext
静态通过SecurityContextHolder
,当有多个应用程序上下文想要指定SecurityContextHolderStrategy
.
这是因为在SecurityContextHolder
每个 ClassLoader 都有一个策略,而不是每个应用程序上下文一个策略。
为了解决这个问题,组件可以连接SecurityContextHolderStrategy
从应用程序上下文。
默认情况下,他们仍将从SecurityContextHolder
.
这些更改主要是内部的,但它们为应用程序提供了自动装配SecurityContextHolderStrategy
而不是访问SecurityContext
静态。
为此,您应该将代码更改为以下内容:
-
Java
public class SomeClass {
private final SecurityContextHolderStrategy securityContextHolderStrategy = SecurityContextHolder.getContextHolderStrategy();
public void someMethod() {
UsernamePasswordAuthenticationToken token = UsernamePasswordAuthenticationToken.unauthenticated(
loginRequest.getUsername(), loginRequest.getPassword());
Authentication authentication = this.authenticationManager.authenticate(token);
// ...
SecurityContext context = this.securityContextHolderStrategy.createEmptyContext(); (1)
context.setAuthentication(authentication); (2)
this.securityContextHolderStrategy.setContext(context); (3)
}
}
-
创建一个空的
SecurityContext
实例使用配置的SecurityContextHolderStrategy
. -
设置
Authentication
对象在SecurityContext
实例。 -
设置
SecurityContext
实例中的SecurityContextHolderStrategy
.
强制创建 Eager Session
有时,急切地创建会话可能很有价值。
这可以通过使用ForceEagerSessionCreationFilter
可使用以下方法进行配置:
-
Java
-
Kotlin
-
XML
@Bean
public SecurityFilterChain filterChain(HttpSecurity http) {
http
.sessionManagement(session -> session
.sessionCreationPolicy(SessionCreationPolicy.ALWAYS)
);
return http.build();
}
@Bean
open fun filterChain(http: HttpSecurity): SecurityFilterChain {
http {
sessionManagement {
sessionCreationPolicy = SessionCreationPolicy.ALWAYS
}
}
return http.build()
}
<http create-session="ALWAYS">
</http>
接下来要读什么
-
使用 Spring Session 的群集会话
SessionManagementFilter
,因为在身份验证请求期间不会调用过滤器。在这些情况下,必须单独处理会话管理功能。