Spring安全–幕后

安全任务（例如，用户身份验证和用户查看应用程序资源的授权）通常由应用程序服务器处理。可以将这些任务委托给Spring安全性流程，以减轻应用程序服务器处理这些任务的负担。 Spring安全性基本上通过实现标准javax.servlet.Filter来处理这些任务。为了在应用程序中初始化Spring安全性，您需要在web.xml中声明以下过滤器：

<filter><filter-name>springSecurityFilterChain</filter-name><filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class></filter><filter-mapping><filter-name>springSecurityFilterChain</filter-name><url-pattern>/*</url-pattern></filter-mapping>

现在，这个过滤器（springSecurityFilterChain）仅将请求委托给Spring安全框架，在此框架中定义的安全任务将由在应用程序上下文中定义的安全过滤器处理。那么这是怎么发生的呢？

在DelegatingFilterProxy（javax.servlet.Filter的实现）的doFilter方法内，将检查spring应用程序上下文中是否有名为“ springSecurityFilterChain”的bean。这个'springSecurityFilterChain'bean实际上是为spring过滤器链定义的别名。

<alias name="filterChainProxy" alias="springSecurityFilterChain"/>

因此，当在应用程序上下文中完成检查时，它将返回filterChainProxy bean。此过滤器链与javax.servlet.FilterChain的链不同，web.xml中定义的Java过滤器使用javax.servlet.FilterChain来调用下一个可能的过滤器（如果存在的话）或将请求传递给servlet / jsp。 bean filterChainProxy包含在Spring应用程序上下文中定义的安全过滤器的有序列表。所以这是下一组问题：

1.谁初始化/定义这个filterChainProxy？
2.在Spring应用程序上下文中定义了哪些安全过滤器？
3.这些安全过滤器与web.xml中定义的普通过滤器有何不同？

现在是第一个问题，当在应用程序上下文中定义了安全名称空间的‹http›元素时，将初始化filterChainProxy。这是‹http›元素的基本结构：

<sec:http auto-config="true"><sec:intercept-url pattern="/**" access="ROLE_USER" />
</sec:http><sec:authentication-manager id="authenticationManager"><sec:authentication-provider><sec:user-service><sec:user name="admin" password="password" authorities="ROLE_USER, ROLE_ADMIN" /><sec:user name="user" password="password" authorities="ROLE_USER" /></sec:user-service></sec:authentication-provider>
</sec:authentication-manager>

现在，来自Spring框架的HttpSecurityBeanDefinitionParser读取了这个‹http›元素，以在应用程序上下文中注册filterChainProxy。将auto-config设置为true的http元素实际上是以下内容的简写形式：

<sec:http><sec:form-login /><sec:http-basic /><sec:logout />
</sec:http>

稍后我们将讨论‹http›的子元素。因此，现在提到第二个问题，默认情况下，所有过滤器都在过滤器链中注册了什么？这是Spring文档的答案：

‹http›名称空间块始终创建一个SecurityContextPersistenceFilter ， ExceptionTranslationFilter和FilterSecurityInterceptor 。 这些是固定的，不能用替代方法替代。

因此，默认情况下，当我们添加‹http›元素时，将添加以上三个过滤器。并且由于将auto-config设置为true，BasicAuthenticationFilter，LogoutFilter和UsernamePasswordAuthenticationFilter也被添加到过滤器链中。现在，如果您查看任何这些过滤器的源代码，它们也是标准的javax.servlet.Filter实现。但是，通过在应用程序上下文而不是在web.xml中定义这些过滤器，应用程序服务器会将控件转移到Spring以处理与安全性相关的任务。 Spring的filterChainProxy将负责链接将应用于请求的安全过滤器。这回答了第三个问题。

为了更好地控制要应用于请求的安全筛选器，我们可以定义自己的FilterChainProxy实现。

<bean id="filterChainProxy" class="org.springframework.security.web.FilterChainProxy"><sec:filter-chain-map path-type="ant"><sec:filter-chain pattern="/images/*" filters="none"/><sec:filter-chain pattern="/**" filters="securityContextFilter, logoutFilter, formLoginFilter, servletApiFilter, anonFilter, exceptionTranslator, filterSecurityInterceptor, customFilter1, customeFilter2" /></sec:filter-chain-map>
</bean>

从上面的xml中，我们看到我们不希望对图像应用任何过滤器，而对于其余的请求，则指定了必须应用的一系列过滤器。因此，通常，我们按照从最小约束到最大约束的顺序指定过滤器链。但是通常不需要这种注册我们自己的过滤器链的方法。 Spring通过‹http›元素提供了多个挂钩，通过这些挂钩我们可以更好地控制安全性的应用方式。因此，我们将详细介绍所有可以通过‹http›元素配置的内容。

1.身份验证：HttpBasicAuthentication和基于表单登录的身份验证
2.通过ACL（访问控制列表）的授权支持
3.注销支持 4.匿名登录支持 5.记住我身份验证 6.并发会话管理

（1）身份验证：身份验证可以通过两种方式处理-HttpBasicAuthentication和基于表单登录的身份验证。我们将在短期内简要讨论这两个。在理解这些内容之前，最好对AuthenticationManager有基本的了解，它是通过Spring安全性实现身份验证的核心。在身份验证管理器元素内，我们定义了可用于该应用程序的所有身份验证提供程序。身份验证提供程序包含UserDetailsService的实现。 Spring将用户信息加载到UserDetailsService中，并将用户名/密码组合与登录时提供的凭据进行比较。这是UserDetailsService接口：

package org.springframework.security.core.userdetails;import org.springframework.dao.DataAccessException;/*** Core interface which loads user-specific data.* It is used throughout the framework as a user DAO and is the strategy used by the* {@link org.springframework.security.authentication.dao.DaoAuthenticationProvider DaoAuthenticationProvider}.* The interface requires only one read-only method, which simplifies support for new data-access strategies.* @see org.springframework.security.authentication.dao.DaoAuthenticationProvider* @see UserDetails* @author Ben Alex*/
public interface UserDetailsService {/*** Locates the user based on the username. In the actual implementation, the search may possibly be case* insensitive, or case insensitive depending on how the implementation instance is configured. In this case, the* <code>UserDetails</code> object that comes back may have a username that is of a different case than what was* actually requested..** @param username the username identifying the user whose data is required.** @return a fully populated user record (never <code>null</code>)** @throws UsernameNotFoundException if the user could not be found or the user has no GrantedAuthority* @throws DataAccessException if user could not be found for a repository-specific reason*/UserDetails loadUserByUsername(String username)throws UsernameNotFoundException, DataAccessException;
}

Spring提供了此服务的两个内置实现：

（a）在应用程序上下文中存储用户登录名/密码详细信息：

当应用程序的用户很少时，这非常适合。可以如下初始化：

<sec:authentication-manager id="authenticationManager"><sec:authentication-provider><sec:user-service><sec:user name="admin" password="password" authorities="ROLE_ADMIN,ROLE_USER"/><sec:user name="user" password="password" authorities="ROLE_USER"/></sec:user-service></sec:authentication-provider>
</sec:authentication-manager>

‹authentication-provider›标记对应于DaoAuthenticationProvider，它实际上调用提供的UserDetailsService的实现。在这种情况下，我们将直接以XML提供用户名和密码。当应用程序的用户群很大时，我们希望将信息存储在数据库中。

为‹user-service›初始化的对应的Bean是org.springframework.security.core.userdetails.memory.InMemoryDaoImpl

（b）在数据库中存储用户详细信息：这是必须初始化的方式。

<sec:authentication-manager id="authenticationManager"><sec:authentication-provider><sec:jdbc-user-service data-source-ref="dataSource" /></sec:authentication-provider>
</sec:authentication-manager>

Spring中的相应类是org.springframework.security.core.userdetails.jdbc.JdbcDaoImpl。如果查看此类，则可以发现用户名和密码存储在users表中，可以分配给用户的角色存储在Authoritys表中。稍后我们将讨论角色。这些是此类从数据库中获取用户凭据和权限的查询：

-- Fetch user credentials: 
select username,password,enabled from users where username = ?
-- Fetch user authorities: 
select username,authority from authorities where username = ?

现在假设您有一个旧数据库，您的用户详细信息存储在其他表中，然后我们可以配置Spring为获取用户凭据和权限而执行的获取查询。假设我有一个成员表，其中包含ID，用户名，密码字段，以及角色表，其中包含用户名，角色字段。这是我们必须配置的方式：

<sec:authentication-manager id="authenticationManager"><sec:authentication-provider><!-- TBD <password-encoder hash="md5"/> --><sec:jdbc-user-service id="userDetailsService" data-source-ref="dataSource" users-by-username-query="SELECT username, password, true as enabledFROM MEMBERWHERE username=?"authorities-by-username-query="SELECT member.username, role.role as authoritiesFROM ROLE role, MEMBER memberWHERE role.member_id=member.id and member.username=?"/></sec:authentication-provider>
</sec:authentication-manager>

现在介绍执行身份验证的方法：

HttpBasicAuthentication：可以如下配置：

<sec:http auto-config="true"><sec:http-basic />
</sec:http>

默认情况下，启用此选项后，浏览器通常会显示一个登录对话框供用户登录。代替登录对话框，我们可以配置它以显示特定的登录页面。这种身份验证是在超文本传输协议标准中正式定义的。登录凭据（以base 64编码）已通过Authentication http标头发送到服务器。但是它有它自己的缺点。最大的问题与注销服务器有关。大多数浏览器倾向于缓存会话，不同的用户无法通过刷新浏览器重新登录。定义‹http-basic›实际上在幕后定义了BasicAuthenticationFilter过滤器。身份验证成功后，身份验证对象将放入Spring securityContext中。可以通过类SecurityContextHolder访问安全上下文。这是BasicAuthenticationFilter bean声明的样子：

<sec:custom-filter position="BASIC_AUTH_FILTER" ref="basicAuthenticationFilter" /><bean id="basicAuthenticationFilter" class="org.springframework.security.web.authentication.www.BasicAuthenticationFilter"><property name="authenticationManager" ref="authenticationManager"/><property name="authenticationEntryPoint" ref="authenticationEntryPoint"/>
</bean><bean id="authenticationEntryPoint" class="org.springframework.security.web.authentication.LoginUrlAuthenticationEntryPoint"><property name="loginFormUrl" value="/login.jsp"/>
</bean>

有关过滤器位置的更多详细信息，请参阅枚举org.springframework.security.config.http.SecurityFilters

基于表单登录的身份验证：这是我们启用它的方式：

<sec:form-login login-page="/login.jsp"/>

但是Spring提供了多个钩子。属性default-target-url指定登录页面在用户进行身份验证后应该进入的位置，而authentication-failure-url定义在身份验证失败时用户应该进入的页面。

<sec:form-login login-page="/login.jsp" default-target-url="/app/messagePost" authentication-failure-url="/login.jsp?error=true"/>

下一组属性是： 始终使用默认目标，身份验证成功处理程序引用和身份验证失败处理程序引用 。 身份验证成功时，将调用authentication-success-handler-ref ， 身份验证失败时，将调用authentication-failure-handler-ref 。这是AuthenticationSuccessHandler和AuthenticationFailureHandler的接口。

/*** Strategy used to handle a successful user authentication.* <p>* Implementations can do whatever they want but typical behaviour would be to control the navigation to the* subsequent destination (using a redirect or a forward). For example, after a user has logged in by submitting a* login form, the application needs to decide where they should be redirected to afterwards* (see {@link AbstractAuthenticationProcessingFilter} and subclasses). Other logic may also be included if required.** @author Luke Taylor* @since 3.0*/
public interface AuthenticationSuccessHandler {/*** Called when a user has been successfully authenticated.** @param request the request which caused the successful authentication* @param response the response* @param authentication the <tt>Authentication</tt> object which was created during the authentication process.*/void onAuthenticationSuccess(HttpServletRequest request, HttpServletResponse response,Authentication authentication) throws IOException, ServletException;
}/*** Strategy used to handle a failed authentication attempt.* <p>* Typical behaviour might be to redirect the user to the authentication page (in the case of a form login) to* allow them to try again. More sophisticated logic might be implemented depending on the type of the exception.* For example, a {@link CredentialsExpiredException} might cause a redirect to a web controller which allowed the* user to change their password.** @author Luke Taylor* @since 3.0*/
public interface AuthenticationFailureHandler {/*** Called when an authentication attempt fails.* @param request the request during which the authentication attempt occurred.* @param response the response.* @param exception the exception which was thrown to reject the authentication request.*/void onAuthenticationFailure(HttpServletRequest request, HttpServletResponse response,AuthenticationException exception) throws IOException, ServletException;
}

Spring有2个内置的成功处理程序实现。 SimpleUrlAuthenticationSuccessHandler和SavedRequestAwareAuthenticationSuccessHandler。后者扩展了前者。

SavedRequestAwareAuthenticationSuccessHandler的目的是将用户带到他已重定向到Login页面进行身份验证的页面。这是定义了form-login›元素时的默认成功处理程序。我们也可以使用自定义实现来覆盖它。假设我们总是希望在用户登录后显示特定页面，而不是让他进入他之前所在的页面，我们可以将always-use-default-target设置为true。

对于故障处理程序，还有两种内置的实现：SimpleUrlAuthenticationFailureHandler和ExceptionMappingAuthenticationFailureHandler。后者扩展了前者。

我们仅在SimpleUrlAuthenticationFailureHandler的情况下指定单个URL，在身份验证失败的情况下将引导用户进入，在ExceptionMappingAuthenticationFailureHandler的情况下，我们根据身份验证异常的类型指定用户将被引导到的多个URL（org.springframework的子类.security.core.AuthenticationException）在身份验证过程中抛出（UserDetailsService实现将引发异常）。

同样，在定义自定义登录页面时，我们将用户名和密码字段分别标记为j_username和j_password ，并且Submit操作将默认为j_spring_security_check 。我们还可以配置这些字段名称，并通过分别指定以下属性来提交操作： 用户名参数，密码参数和login-processing-url 。

过滤器定义如下所示：

<sec:custom-filter position="FORM_LOGIN_FILTER" ref="formLoginFilter" />
<bean id="formLoginFilter" class="org.springframework.security.web.authentication.UsernamePasswordAuthenticationFilter"><property name="authenticationManager" ref="authenticationManager"/><property name="filterProcessesUrl" value="/j_spring_security_check"/><property name="usernameParameter" value="username "/><property name="passwordParameter" value="password"/><property name="authenticationSuccessHandler"><bean class="org.springframework.security.web.authentication.SavedRequestAwareAuthenticationSuccessHandler "><property name="alwaysUseDefaultTargetUrl" value="true"/><property name="defaultTargetUrl" value="/success.jsp"/></bean></property><property name="authenticationFailureHandler"><!--bean class=" org.springframework.security.web.authentication.SimpleUrlAuthenticationFailureHandler "/--><bean id="authenticationFailureHandler" class="org.springframework.security.web.authentication.ExceptionMappingAuthenticationFailureHandler"><property name="exceptionMappings"><props><prop key="org.springframework.security.authentication.BadCredentialsException">/login/badCredentials</prop><prop key="org.springframework.security.authentication.CredentialsExpiredException">/login/credentialsExpired</prop><prop key="org.springframework.security.authentication.LockedException">/login/accountLocked</prop><prop key="org.springframework.security.authentication.DisabledException">/login/accountDisabled</prop></props></property></bean></property></bean>

在表单登录的情况下，如基本身份验证中所述，注销不会有任何问题。但是缺点是用户名和密码在标题中以明文形式发送。这可以通过使用加密技术对密码进行编码来解决。 Spring使用身份验证提供程序中的‹password-encoder›元素对此提供了内置支持。这是我们必须如何配置它：

<sec:authentication-manager id="authenticationManager"><sec:authentication-provider><sec:password-encoder hash="md5"/><sec:jdbc-user-service data-source-ref="dataSource" /></sec:authentication-provider>
</sec:authentication-manager>

2.通过ACL进行授权支持： Spring通过‹http›中的‹intercept-url›支持授权。

<sec:http access-decision-manager-ref="accessDecisionManager"><sec:intercept-url pattern="/app/messageList*" access="ROLE_USER,ROLE_ANONYMOUS"/><sec:intercept-url pattern="/app/messagePost*" access="ROLE_USER"/><sec:intercept-url pattern="/app/messageDelete*" access="ROLE_ADMIN"/><sec:intercept-url pattern="/app/*" access="ROLE_USER"/><form-login login-page="/login.jsp" default-target-url="/app/messagePost" authentication-failure-url="/login.jsp?error=true"/><!-- Other settings -->
</sec:http>

每个intercept-url指定一个URL模式，用户访问这些与指定模式匹配的URL必须具有的角色。请注意，网址格式始终以“ *”结尾。如果未指定“ *”，则问题是黑客可以通过仅在url中传递一些参数来绕过安全机制。

因此，在幕后发生的事情是当Spring将所有这些URL作为元数据传递给FilterSecurityInterceptor时被拦截。因此，这是不使用‹intercept-url›即可配置的方法：

<sec:custom-filter position="FILTER_SECURITY_INTERCEPTOR" ref="filterSecurityInterceptor" />
<bean id="filterSecurityInterceptor" class="org.springframework.security.web.access.intercept.FilterSecurityInterceptor"><property name="authenticationManager" ref="authenticationManager"/><property name="accessDecisionManager" ref="accessDecisionManager"/><property name="securityMetadataSource"><sec:filter-security-metadata-source lowercase-comparisons="true" request-matcher="ant" use-expressions="true"><sec:intercept-url pattern="/app/messageList*" access="ROLE_USER,ROLE_ANONYMOUS"/><sec:intercept-url pattern="/app/messagePost*" access="ROLE_USER"/><sec:intercept-url pattern="/app/messageDelete*" access="ROLE_ADMIN"/><sec:intercept-url pattern="/app/*" access="ROLE_USER"/></sec:filter-security-metadata-source></property>
</bean>

因此，从上面的代码中您可以看到匿名用户只能访问messageList页面，并且要查看其他任何页面，他应该以用户身份登录到应用程序。同样，如果您仔细观察Bean声明，则有一个属性'accessDecisionManager'。这样做的目的是什么？

实际上是由Bean做出访问控制决策。它必须实现AccessDecisionManager接口。 Spring提供了三个内置的访问决策管理器。在了解访问决策管理器的工作原理之前，我们需要知道AccessDecisionVoter到底是什么。 AccessDecisionManager实际上由一个或多个访问决策投票者组成。该投票者封装了允许/拒绝/放弃用户查看资源的逻辑。投票弃权或多或少类似于根本不投票，因此投票结果由AccessDecisionVoter接口中定义的ACCESS_GRANTED，ACCESS_DENIED和ACCESS_ABSTAIN常量字段表示。我们可以定义自定义访问决策投票者，并将其注入我们的访问决策管理器定义中。现在回到内置的决策管理器，他们是：

AffirmativeBased：至少一名选民必须投票才能授予访问权限
基于共识：大多数选民必须投票才能授予访问权限
基于一致意见：所有选民都必须投票弃权或授予访问权限（无投票人投票才能拒绝访问）

默认情况下，将基于AffirmativeBased的访问决策管理器初始化，其中包含2个投票者：RoleVoter和AuthenticatedVoter。如果用户具有所需角色，RoleVoter会授予访问权限。但是请注意，如果投票者必须授予访问权限，则该角色必须以“ ROLE_”前缀开头。但这也可以为其他前缀定制。我们将很快看到如何做。 AuthenticatedVoter仅在用户通过身份验证时才授予访问权限。接受的身份验证级别为IS_AUTHENTICATED_FULLY，IS_AUTHENTICATED_REMEMBERED和IS_AUTHENTICATED_ANONYMOUSLY。假设我们要定义一个自定义投票器，并将其添加到访问决策管理器中，我们可以这样做：

<sec:http access-decision-manager-ref="accessDecisionManager" auto-config="true"><!-- filters declaration go here-->
</sec:http><bean id="accessDecisionManager" class="org.springframework.security.access.vote.AffirmativeBased"><property name="decisionVoters"><list><bean class="org.springframework.security.access.vote.RoleVoter"><!-- Customize the prefix--><property name="rolePrefix" value="ROLE_"/></bean><bean class="org.springframework.security.access.vote.AuthenticatedVoter"/><bean class="com.pramati.security.voters.CustomVoter"/></list></property>
</bean>

3.注销支持： Spring提供了一个处理程序来处理注销请求。可以配置如下：

<sec:http><!-- Other filter declarations here --><sec:logout /></sec:http>

默认情况下，注销URL映射到/ j_spring_security_logout 。我们可以通过指定logout-url属性来自定义该URL。同样，当用户注销时，他将被带到上下文路径根。如果必须将用户重定向到其他URL，则必须通过logout-success-url进行配置。这是您的操作方式：

<sec:logout logout-url="/j_logMeOut" logout-success-url="/app/messageList"/>

如果您希望登录页面在不同的情况下有所不同，而不是默认使用一个特定的网址，那么我们必须实现LogoutSuccessHandler并将其引用到‹logout›元素

<sec:logout logout-url="/j_logMeOut" success-handler-ref="customLogoutSuccessHandler"/>

如果您不想使用‹logout›元素，则可以按以下方法定义底层过滤器：

<sec:custom-filter position="LOGOUT_FILTER" ref="logoutFilter" />
<bean id="logoutFilter" class="org.springframework.security.web.authentication.logout.LogoutFilter"><constructor-arg value="/pages/Security/logout.html" /><constructor-arg><list><bean class="org.springframework.security.web.authentication.logout.SecurityContextLogoutHandler"/></list></constructor-arg><property name="filterProcessesUrl" value="/j_logMeOut"/>
</bean>

4.匿名登录支持：默认情况下，Spring创建一个匿名角色。

因此，当您将角色指定为“ ROLE_ANONYMOUS”或“ IS_AUTHENTICATED_ANONYMOUSLY”时，任何匿名用户都可以查看该页面。在AffirmativedBased访问决策管理器中，当RoleVoter看到访问属性设置为“ ROLE_ANONYMOUS”时，将授予访问权限。同样，如果将访问属性设置为“ IS_AUTHENTICATED_ANONYMOUSLY”，则AuthenticatedVoter会授予访问权限。

假设要为匿名用户分配其他角色名称，则可以按如下方式覆盖默认配置：

<sec:http><sec:intercept-url pattern="/login.jsp*" filters="none"/><sec:intercept-url pattern="/*" access="ROLE_USER"/><!-- Defines a custom role in place of ROLE_ANONYMOUS. ROLE_ANONYMOUS will no more work, use ROLE_GUEST instead of it--><sec:anonymous username="guest" granted-authority="ROLE_GUEST" />
</sec:http><p style="text-align: justify;">Here is the how the underlying filter can be defined if you don't want to use ‹anonymous› element:</p>1
<sec:custom-filter position="ANONYMOUS_FILTER" ref="anonymousFilter" />
<bean id="anonymousFilter" class="org.springframework.security.web.authentication.AnonymousAuthenticationFilter" ><property name="userAttribute" value="ROLE_GUEST" />
</bean>

5.记住我身份验证：这是指网站能够记住会话之间主体的身份。 Spring通过在成功进行交互式身份验证后向浏览器发送cookie来实现此目的，该cookie的组成如下：

base64（用户名+“：” + expirationTime +“：” + md5Hex（用户名+“：” + expirationTime +“：”密码+“：” +键））

现在，当浏览器向服务器发出下一个请求时，它还将与此Cookie一起发送。现在，Spring在幕后执行以下操作：
（a）从后端检索给定用户名的密码
（b）从数据库中获取用户名的密码，并计算用户名，密码，expirationTime和密钥的md5Hex（）并将其与Cookie中的值进行比较 （c）如果它们匹配–您已登录！如果不匹配，则说明您提供了伪造的Cookie，或者用户名/密码/密钥之一已更改。

我们可以通过在‹http›中添加元素来启用“记住我”身份验证。这是我们的方法：

<sec:http><!-- Other filter declarations here --><sec:remember-me key="myAppKey"/></sec:http>

通常将自动选择UserDetailsService。如果您的应用程序上下文中有多个，则需要指定与user-service-ref属性一起使用的属性，其中值是UserDetailsService bean的名称。需要注意的一点是，这里存在一个潜在的安全问题，因为“记住我”令牌可以被捕获，并且由于它在到期之前一直有效而可能被滥用。通过使用滚动令牌可以避免这种情况。这是您可以实现基于令牌的“记住我”服务的方法：

<sec:http access-decision-manager-ref="accessDecisionManager"><!-- Other filter declarations here --><remember-me services-alias="rememberMeService" data-source-ref="dataSource"/><!-- <remember-me data-source-ref="dataSource" key="pramati"/> --></sec:http><bean id="tokenRepository" class="org.springframework.security.web.authentication.rememberme.JdbcTokenRepositoryImpl"><property name="dataSource" ref="dataSource"/><property name="createTableOnStartup" value="true"/>
</bean><bean id="rememberMeService" class="org.springframework.security.web.authentication.rememberme.PersistentTokenBasedRememberMeServices"><property name="userDetailsService" ref="userDetailsService"/><property name="tokenRepository" ref="tokenRepository"/>
</bean>

注意事项：

（a）因为在定义bean'tokenRepository'时已指定'createTableOnStartup'为true，所以将在数据库中创建一个新表persistent_logins。这是用于创建表的sql：

create table persistent_logins (username varchar(64) not null,series varchar(64) primary key,token varchar(64) not null,last_used timestamp not null);

（b）我们不再提供自己的安全令牌。 Spring将自动生成令牌并将其放入/更新到persistent_tokens表中。当用户从浏览器访问应用程序并通过选择“记住我”选项登录到应用程序时，将在此表中创建一个条目。下次用户从同一浏览器登录时，用户将自动登录，并且数据库中的令牌值将更改为新值，但系列值保持不变。假设用户现在从其他浏览器登录并选择记住我，那么将为该浏览器创建一个新条目。当他从该浏览器访问应用程序时，随后的更新将发生在该特定行本身上。

因此，使用这种方法的好处是，攻击者将只能使用被盗的cookie，直到受害者用户下次访问该应用程序为止，而不是像先前的单令牌方法那样在记住的cookie的整个生存期内使用它。当受害者下一次访问该网站时，他将使用相同的cookie。现在，Spring将抛出CookieTheftException，该异常可用于通知用户发生了盗窃。

可以使用安全链中的自定义过滤器来定义它，而不用使用到目前为止已使用的元素：

<sec:custom-filter position="REMEMBER_ME_FILTER" ref="rememberMeFilter" /><bean id="rememberMeFilter" class="org.springframework.security.web.authentication.rememberme.RememberMeAuthenticationFilter"><property name="rememberMeServices" ref="rememberMeServices"/><property name="authenticationManager" ref="theAuthenticationManager" />
</bean><bean id="tokenRepository" class="org.springframework.security.web.authentication.rememberme.JdbcTokenRepositoryImpl"><property name="dataSource" ref="dataSource"/><property name="createTableOnStartup" value="false"/>
</bean><bean id="rememberMeServices" class="org.springframework.security.web.authentication.rememberme.PersistentTokenBasedRememberMeServices"><property name="userDetailsService" ref="userDetailsService"/><property name="tokenRepository" ref="tokenRepository"/>
</bean><bean id="rememberMeAuthenticationProvider" class="org.springframework.security.authentication.rememberme.RememberMeAuthenticationProvider"/>

6.并发会话管理：假设我们不希望用户同时从多个位置登录到应用程序，我们必须在Spring中启用此功能。这是我们的方法：

<sec:http><!-- Other filter declarations here --><sec:session-management session-authentication-error-url="/login.jsp?error=alreadyLoggedin" ><sec:concurrency-control max-sessions="1" error-if-maximum-exceeded="true"expired-url="/login.jsp?error=alreadyLoggedin"/></sec:session-management>
</sec:http>

此外，我们还必须在web.xml中定义一个侦听器，当用户从应用程序注销时，该侦听器对于引发事件（org.springframework.security.core.session.SessionDestroyedEvent）是必需的。

<listener><listener-class>org.springframework.security.web.session.HttpSessionEventPublisher</listener-class>
</listener>

那么，现在幕后发生了什么？ Spring如何获得这种支持？

Spring使用的安全过滤器类似于我们一直在讨论的内容。除此之外，它还使用ApplicationEvents。当spring看到需要并发控制时，它将维护与主体相关联的会话列表。映射结构如下所示（实际上在org.springframework.security.core.session.SessionRegistryImpl中定义）：

ConcurrentMap<Object,Set<String>> principals =new ConcurrentHashMap<Object,Set<String>>();

此处映射的键是User对象，该值是与他相关联的会话ID的集合。因此，当集合的大小大于‹concurrency-control›元素中定义的最大会话的值时，将引发异常。当Spring看到定义的并发控制元素时，SessionRegistryImpl（定义映射的地方）将在ConcurrentSessionControlStrategy内部组成，并注入到UsernamePasswordAuthenticationFilter中。现在，随着用户身份验证成功，Spring在上面讨论的映射中添加了一个条目。

现在，当用户注销时，将在web.xml中定义侦听器时引发SessionDestroyedEvent，如上所示。 SessionRegistryImpl侦听此事件，并从正在维护的映射中删除会话ID条目。否则，即使用户退出另一个会话或超时，一旦超过会话允许量，用户将永远无法再次登录。因此，这是‹concurrency-control›的等效配置：

<sec:http><sec:custom-filter position="CONCURRENT_SESSION_FILTER" ref="concurrencyFilter" /><sec:custom-filter position="FORM_LOGIN_FILTER" ref="myAuthFilter" /><!-- Other filter declarations here --><sec:session-management session-authentication-strategy-ref="sessionAuthenticationStrategy"/>
</sec:http><bean id="concurrencyFilter" class="org.springframework.security.web.session.ConcurrentSessionFilter"><property name="sessionRegistry" ref="sessionRegistry" /><property name="expiredUrl" value="/session-expired.htm" />
</bean><bean id="myAuthFilter" class="org.springframework.security.web.authentication.UsernamePasswordAuthenticationFilter"><property name="sessionAuthenticationStrategy" ref="sessionAuthenticationStrategy" /><property name="authenticationManager" ref="authenticationManager" />
</bean><bean id="sessionAuthenticationStrategy" class="org.springframework.security.web.authentication.session.ConcurrentSessionControlStrategy"><constructor-arg name="sessionRegistry" ref="sessionRegistry" /><property name="maximumSessions" value="1" />
</bean><bean id="sessionRegistry" class="org.springframework.security.core.session.SessionRegistryImpl" />

作为本文的总结，本文涉及了框架的基本配置和底层类，这对于根据我们的特定要求自定义安全性至关重要。

参考： Spring Security –在 prasanthnath博客上， JCG合作伙伴 Prasanth Gullapalli 的幕后花絮。