Spring Boot - 集成 Spring Security

作者: Whyn | 来源:发表于2021-10-12 01:46 被阅读0次

Spring Security应用详解
Spring Boot 集成 Spring Security 实
Shiro、Spring Security整合
Spring Boot整合Spring Security
Spring Security 之 Spring Boot 环境
8.6 Spring Boot集成Spring Security
《Spring Boot极简教程》第16章 Spring Boo
锱铢必较：在spring boot中使用神器防止CSRF攻击
Spring Boot系列--集成Elasticsearch
Spring boot 集成 Spring Security

Spring Security

简介

Spring Security 对认证、授权和常见漏洞保护提供了全方位支持。

注：本篇博文使用的版本为：Spring Security 5.5.2

两个概念释义

认证（Authentication）：认证就是对试图访问资源的用户进行验证。

认证的一个典型的场景就是登录流程，常见的方式就是要求提供用户名和密码，当验证通过的时候，就可以执行授权操作。
授权（Authority）：授权就是对资源进行权限设置，只有用户具备相应权限才能访问。

简单来讲：

认证：你是谁？
授权：你能做什么？

架构总览

原理

Spring Security 在基于 Servlet应用中，其底层是采用了Filter机制实现了对请求的认证、授权和漏洞防御等功能。

简单来说，我们可以为 Servlet 设置一些Filters，这些Filters 就构成了一个FilterChain。每次当请求进来时，首先会被FilterChain中的Filters 依次捕获得到，每个Filter可以对请求进行一些预处理或对响应进行一些后置处理，最后才会到达Servlet。具体流程如下图所示：

FilterChain

注：FilterChain中的Filter主要有两方面作用：

修改HttpServletRequest或HttpServletResponse，这样FilterChain后续的Filters 或Servlet得到的就是被修改后的请求和响应内容。
Filter可以拦截请求，自己作出响应，相当于断开了FilterChain，导致后续的Filters和Servlet无法接收到该请求。

基于 Servlet 规范，我们可以为 Servlet容器注入一些自定义Filters，但是在 Spring 应用中，实现了Filter接口的 Bean 无法被 Servlet容器感知到，因为没有调用ServletContext#addFilter方法注册到FitlerChain中。为了解决这个问题，Spring 提供了一个DelegatingFilterProxy代理类，DelegatingFilterProxy实现了Filter，因此它可以被注入到FilterChain中，同时，当请求到来时，它会把请求转发到 Spring容器中实现了Filter接口的 Bean 实体，所以DelegatingFilterProxy桥接了 Servlet容器和 Spring容器。DelegatingFilterProxy作用示意图大致如下所示：

DelegatingFilterProxy

当请求到来时，DelegatingFilterProxy会从ApplicationContext中获取FilterBean 实体，然后将请求转发给到它，伪代码如下所示：

public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) {
    // Lazily get Filter that was registered as a Spring Bean
    // For the example in DelegatingFilterProxy delegate is an instance of Bean Filter0
    Filter delegate = getFilterBean(someBeanName);
    // delegate work to the Spring Bean
    delegate.doFilter(request, response);
}

FilterChainProxy

前面的步骤其实完成了 Spring容器中的Filters Bean 实体可以注入到 Servlet容器中的FilterChain功能，基于此，Spring Security 向 Spring容器提供了一个FilterChainProxy Bean 实体，该FilterChainProxy实现了Filter接口，因此，请求就会被FilterChainProxy捕获到，这样 Spring Security 就可以开始工作了。具体来说，默认情况下，DelegatingFilterProxy从 Spring容器中获取得到的就是FilterChainProxy实体，而FilterChainProxy也是一个代理类，它最终会将请求转发到 Spring Security 提供的SecurityFilterChain中。流程示意图如下所示：

FilterChainProxy

注：FilterChainProxy就是 Spring Security 真正的入口起始点，调式代码时，将断点设置在FilterChainProxy#doFilter就可以追踪 Spring Security 完整调用流程。

SecurityFilterChain

SecurityFilterChain作用其实跟 Servlet 的FilterChain一样，同样维护了很多Filters，这些Filters 是由 Spring Security 提供的，每个 Security Filter 都有不同的职能，比如登录认证、CSRF防御...如下图所示：

SecurityFilterChain

同时，Spring Security 支持添加多个SecurityFilterChain，每个SecurityFilterChain负责不同的请求（比如依据请求地址进行区分），这样可以为不同的请求设置不同的认证规则。其源码如下所示：

public interface SecurityFilterChain {
    // 匹配请求
    boolean matches(HttpServletRequest request);

    // 获取该 SecurityFilterChain 中的所有 Filter
    List<Filter> getFilters();
}

具体来说，当请求到达FilterChainProxy时，其内部会根据当前请求匹配得到对应的SecurityFilterChain，然后将请求依次转发给到该SecurityFilterChain中的所有 Security Filters。如下图所示：

Multiple SecurityFilterChain

Security Filters

经过前面步骤介绍，我们知道，Spring Security 最终对请求进行处理的就是某个SecurityFilterChain中的 Security Filters，这些Fitlers 都设置为 Bean 注入到 Spring容器中，且这些Filters 的先后顺序很重要。以下是 Spring Security 内置的完整 Security Filter 顺序列表：

ChannelProcessingFilter：确保请求投递到要求渠道。最常见的使用场景就是指定哪些请求必须使用 HTTPS 协议，哪些请求必须使用 HTTP 协议，哪些请求随便使用哪种协议均可。
WebAsyncManagerIntegrationFilter：集成SecurityContext到 Spring Web 异步请求机制中的WebAsyncManager。

注：SecurityContext就是 安全上下文，主要职能就是用于存储用户认证的一些信息。
SecurityContextPersistenceFilter：在每次请求处理之前，从 Session（默认使用HttpSessionSecurityContextRepository）中获取SecurityContext，然后将其设置给到SecurityContextHolder；在请求结束后，就会将SecurityContextHolder中存储的SecurityContext重新保存到 Session 中，并且清除SecurityContextHolder中的SecurityContext。

SecurityContextPersistenceFilter可以通过HttpSecurity#securityContext()及相关方法引入其配置对象SecurityContextConfigurer来进行配置。
HeaderWriterFilter：该过滤器可为响应添加一些响应头，比如添加X-Frame-Options，X-XSS-Protection和X-Content-Type-Options等响应头，让浏览器开启保护功能。

HeaderWriterFilter可以通过HttpSecurity#headers()来定制。
CorsFilter：处理跨域资源共享（CORS）。

CorsFilter可以通过HttpSecurity#cors()来定制。
CsrfFilter：处理跨站请求伪造(CSRF)。

CsrfFilter可以通过HttpSecurity#csrf()来开启或关闭。在前后端分离项目中，不需要使用 CSRF。
LogoutFilter：处理退出登录请求。

LogoutFilter可以通过HttpSecurity#logout()来定制退出逻辑。
OAuth2AuthorizationRequestRedirectFilter：用于构建 OAuth 2.0 认证请求，将用户请求重定向到该认证请求接口。

注：该过滤器需要添加spring-security-oauth2等相关模块。
Saml2WebSsoAuthenticationRequestFilter：基于 SAML 的 SSO 单点登录认证请求过滤器。

注：Saml2WebSsoAuthenticationRequestFilter需要添加 Spring Security SAML 模块。
X509AuthenticationFilter：X509 认证过滤器。

X509AuthenticationFilter可以通过SecurityContext#X509()来启用和配置相关功能。
AbstractPreAuthenticatedProcessingFilter：认证预处理请求过滤器基类，其中认证主体已经由外部系统进行了身份验证。目的只是从传入请求中提取主体上的必要信息，而不是对它们进行身份验证。

可以继承该类进行具体实现并通过HttpSecurity#addFilter方法来添加个性化的AbstractPreAuthenticatedProcessingFilter。
CasAuthenticationFilter：用于处理 CAS 单点登录认证。

注： CasAuthenticationFilter需要添加 Spring Security CAS 模块。
OAuth2LoginAuthenticationFilter：OAuth2.0 登录认证过滤器。

注： OAuth2LoginAuthenticationFilter需要添加spring-security-oauth2等相关模块。
Saml2WebSsoAuthenticationFilter：基于 SAML 的 SSO 单点登录认证过滤器。

注：Saml2WebSsoAuthenticationFilter需要添加 Spring Security SAML 模块。
UsernamePasswordAuthenticationFilter：用于处理表单登录认证。默认处理接口为/login，表单必须提供两个参数：用户名 和密码，默认的参数名(key)为username和password，可以通过usernameParameter和passwordParameter方法进行修改。

UsernamePasswordAuthenticationFilter可以通过HttpSecurity#formLogin()及相关方法引入其配置对象FormLoginConfigurer来进行配置。
OpenIDAuthenticationFilter：基于 OpenID 认证协议的认证过滤器。
DefaultLoginPageGeneratingFilter：如果没有配置登录页面，那么就会默认采用该过滤器生成一个登录表单页面。

注：默认的登录页面接口为/login
DefaultLogoutPageGeneratingFilter：生成默认退出登录页面。

注：默认的退出登录页面接口为/logout
ConcurrentSessionFilter：主要用来判断 Session 是否过期以及更新最新访问时间。该过滤器可能会被多次执行。
DigestAuthenticationFilter：用于处理 HTTP 头部显示的摘要式身份验证凭据。

DigestAuthenticationFilter可以通过HttpSecurity#addFilter()来启用和配置相关功能。
BearerTokenAuthenticationFilter：处理 Token 认证。
BasicAuthenticationFilter：用于检测和处理 Http Baisc 认证。

BasicAuthenticationFilter可以通过HttpSecurity#httpBasic()及相关方法引入其配置对象HttpBaiscConfigurer来进行配置。
RequestCacheAwareFilter：用于用户认证成功后，重新恢复因为登录被打断的请求。当匿名访问一个需要授权的资源时。会跳转到认证处理逻辑，此时请求被缓存。在认证逻辑处理完毕后，从缓存中获取最开始的资源请求进行再次请求。

RequestCacheAwareFilter可以通过HttpSecurity#requestCache()及相关方法引入其配置对象RequestCacheConfigurer来进行配置。
SecurityContextHolderAwareRequestFilter：对请求对象进行包装，增加了一些安全相关方法。

SecurityContextHolderAwareRequestFilter可以通过HttpSecurity#servletApi()及相关方法引入其配置对象ServletApiConfigurer来进行配置。
JaasApiIntegrationFilter：适用于 JAAS （Java 认证授权服务）。如果SecurityContextHolder中拥有的Authentication是一个JaasAuthenticationToken，那么该JaasApiIntegrationFilter将使用包含在JaasAuthenticationToken中的Subject继续执行FilterChain。
RememberMeAuthenticationFilter：当用户没有登录而直接访问资源时，从 cookie 里找出用户的信息，如果 Spring Security 能够识别出用户提供的 remember me cookie，用户将不必填写用户名和密码，而是直接登录进入系统。它先分析 SecurityContext 里有没有Authentication对象，如果有，则不做任何操作，直接跳到下一个过滤器；如果没有，则检查请求里有没有包含 remember-me 的 cookie 信息。如果有，则解析出 cookie 里的验证信息，判断是否有权限。

RememberMeAuthenticationFilter可以通过HttpSecurity#rememberMe()及相关方法引入其配置对象RememberMeConfigurer来进行配置。
AnonymousAuthenticationFilter：匿名认证过滤器，检测SecurityContextHolder中是否存在Authentication对象，如果不存在，就生成一个匿名Authentication对象。

AnonymousAuthenticationFilter可以通过HttpSecurity#anonymous()及相关方法引入其配置对象AnonymousConfigurer来进行配置。
OAuth2AuthorizationCodeGrantFilter：OAuth 2.0 授权码模式，用于处理 OAuth 2.0 授权码响应。
SessionManagementFilter：检测用户是否通过认证，如果已认证，就通过SessionAuthenticationStrategy进行 Session 相关管理操作。

SessionManagementFilter可以通过HttpSecurity#sessionManagement()及相关方法引入其配置对象SessionManagementConfigurer来进行配置。
ExceptionTranslationFilter：可以用于捕获FilterChain上所有的异常，但只处理AccessDeniedException和AuthenticationException异常。
FilterSecurityInterceptor：对 web资源进行一些安全保护操作。
SwitchUserFilter：主要用来作用户切换。

自动配置

依据 Spring Boot 自动配置原理，其会自动加载spring-boot-autoconfigure.jar中/META-INF/spring.factories内键值org.springframework.boot.autoconfigure.EnableAutoConfiguration指定的自动配置类。查看该文件，可以看到，与 Spring Security 相关的自动配置类有如下几个：

org.springframework.boot.autoconfigure.security.servlet.SecurityAutoConfiguration,                                      \
org.springframework.boot.autoconfigure.security.servlet.UserDetailsServiceAutoConfiguration,                            \
org.springframework.boot.autoconfigure.security.servlet.SecurityFilterAutoConfiguration,                                \
org.springframework.boot.autoconfigure.security.reactive.ReactiveSecurityAutoConfiguration,                             \
org.springframework.boot.autoconfigure.security.reactive.ReactiveUserDetailsServiceAutoConfiguration,                   \
org.springframework.boot.autoconfigure.security.rsocket.RSocketSecurityAutoConfiguration,                               \
org.springframework.boot.autoconfigure.security.saml2.Saml2RelyingPartyAutoConfiguration,                               \
org.springframework.boot.autoconfigure.security.oauth2.client.servlet.OAuth2ClientAutoConfiguration,                    \
org.springframework.boot.autoconfigure.security.oauth2.client.reactive.ReactiveOAuth2ClientAutoConfiguration,           \
org.springframework.boot.autoconfigure.security.oauth2.resource.servlet.OAuth2ResourceServerAutoConfiguration,          \
org.springframework.boot.autoconfigure.security.oauth2.resource.reactive.ReactiveOAuth2ResourceServerAutoConfiguration, \

每个配置类都为 Spring Security 注入不同的 Bean 到 Spring容器中。这里我们着重介绍一下SecurityFilterAutoConfiguration和SecurityAutoConfiguration配置类，因为这两个配置类会自动装配DelegatingFilterProxy和FilterChain到 Spring容器中。具体如下：

自动装配`FilterChainProxy`

下面介绍下配置类SecurityAutoConfiguration，具体如下：

首先看下源码：

@Configuration(proxyBeanMethods = false)
@ConditionalOnClass(DefaultAuthenticationEventPublisher.class)
@EnableConfigurationProperties(SecurityProperties.class)
@Import({ SpringBootWebSecurityConfiguration.class, WebSecurityEnablerConfiguration.class,
        SecurityDataConfiguration.class })
public class SecurityAutoConfiguration {

    @Bean
    @ConditionalOnMissingBean(AuthenticationEventPublisher.class)
    public DefaultAuthenticationEventPublisher authenticationEventPublisher(ApplicationEventPublisher publisher) {
        return new DefaultAuthenticationEventPublisher(publisher);
    }

}

SecurityAutoConfiguration导入了3个配置类，我们注重看WebSecurityEnablerConfiguration。

查看WebSecurityEnablerConfiguration配置类，其源码如下：

@Configuration(proxyBeanMethods = false)
@ConditionalOnMissingBean(name = "springSecurityFilterChain")
@ConditionalOnClass(EnableWebSecurity.class)
@ConditionalOnWebApplication(type = ConditionalOnWebApplication.Type.SERVLET)
@EnableWebSecurity
class WebSecurityEnablerConfiguration {
}

当 Spring容器中没有名称为springSecurityFilterChain的 Bean 等条件时，就会加载该配置类，此时@EnableWebSecurity注解生效：

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.TYPE)
@Documented
@Import({ WebSecurityConfiguration.class, SpringWebMvcImportSelector.class, OAuth2ImportSelector.class,
        HttpSecurityConfiguration.class })
@EnableGlobalAuthentication
@Configuration
public @interface EnableWebSecurity {
    boolean debug() default false;
}

注解@EnableWebSecurity又导入了4个配置类，这里着重看下WebSecurityConfiguration：

@Configuration(proxyBeanMethods = false)
public class WebSecurityConfiguration implements ImportAware, BeanClassLoaderAware {
    ...
    /**
     * Creates the Spring Security Filter Chain
     * @return the {@link Filter} that represents the security filter chain
     * @throws Exception
     */
    @Bean(name = "springSecurityFilterChain")
    public Filter springSecurityFilterChain() throws Exception {
        ...
        return this.webSecurity.build();
    }
    ...
}

可以看到，WebSecurityConfiguration#springSecurityFilterChain()最终生成了一个名称为springSecurityFilterChain的 Bean 实体，该 Bean 的实际类型其实为FilterChainProxy，是由WebSecurity#build()方法创建的。

综上，SecurityAutoConfiguration配置类生成了很多 Bean 实体，其中最重要的一个是名称为springSecurityFilterChain的FilterChainProxy对象。

自动装配`DelegatingFilterProxy`

下面介绍下配置类SecurityFilterAutoConfiguration，其源码如下所示：

@Configuration(proxyBeanMethods = false)
@ConditionalOnWebApplication(type = Type.SERVLET)
@EnableConfigurationProperties(SecurityProperties.class)
@ConditionalOnClass({ AbstractSecurityWebApplicationInitializer.class, SessionCreationPolicy.class })
@AutoConfigureAfter(SecurityAutoConfiguration.class) // 须先加载 SecurityAutoConfiguration
public class SecurityFilterAutoConfiguration {
    ...
    @Bean
    @ConditionalOnBean(name = “springSecurityFilterChain”)
    public DelegatingFilterProxyRegistrationBean securityFilterChainRegistration(
            SecurityProperties securityProperties) {
            ...
    }
    ...
}

可以看到，要加载SecurityFilterAutoConfiguration前，必须先加载配置类SecurityAutoConfiguration，该配置类前面已经详细介绍了，主要功能就是注入了一个名称为springSecurityFilterChain的 Bean，因此，此时SecurityFilterAutoConfiguration#securityFilterChainRegistration就会生效，最终生成一个DelegatingFilterProxyRegistrationBean实体。DelegatingFilterProxyRegistrationBean实现了ServletContextInitializer接口，当系统执行ServletWebServerApplicationContext.selfInitialize()进行初始化时，会依次调用到：RegistrationBean.onStartup() --> DynamicRegistrationBean.register() --> AbstractFilterRegistrationBean.addRegistration()，其中，AbstractFilterRegistrationBean#addRegistration()源码如下：

protected Dynamic addRegistration(String description, ServletContext servletContext) {
    Filter filter = this.getFilter();
    return servletContext.addFilter(this.getOrDeduceName(filter), filter);
}

this.getFilter()实际调用的是DelegatingFilterProxyRegistrationBean#getFilter()方法，其内部会创建一个DelegatingFilterProxy实例并返回，源码如下：

public DelegatingFilterProxy getFilter() {
    return new DelegatingFilterProxy(this.targetBeanName, this.getWebApplicationContext()) {
        protected void initFilterBean() throws ServletException {
        }
    };
}

因此，AbstractFilterRegistrationBean#addRegistration()最终就是通过ServletContext#addFilter将一个DelegatingFilterProxy实例注入到 Servlet 的FilterChain中。

以上，就是 Spring Boot 中自动装配 Spring Security 相关配置源码分析，更加详细内容，可参考：

总结

总结一下，在 Servlet应用中，Spring Security 作用机制大致如下：

注册标准Filter：首先，Spring 会自动注入一个DelegatingFilterProxy到 Servlet 的FilterChain中。
请求转发到 Spring Security：当请求到来时，DelegatingFilterProxy就会自动在 Spring容器中搜索名称为springSecurityFilterChain的Filter实体，其实际类型为FilterChainProxy。DelegatingFilterProxy最终会将请求转发给到FilterChainProxy。
找到匹配请求处理的SecurityFilterChain：FilterChainProxy内部维护了一系列SecurityFilterChains，他会依据请求内容找到对应处理该请求的SecurityFilterChain。
请求处理：找到能处理请求的第一个SecurityFilterChain后，就会遍历该SecurityFilterChain内部维护的一系列Filters，依次让这些 Security Filter 处理该请求，完成认证、授权等功能。

Spring Security 架构简单示意图如下所示：

Spring Security structure

基本使用

在 Spring Boot 中集成 Spring Security，只需导入如下依赖：

<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-security</artifactId>
    </dependency>
</dependencies>

无需其他操作，此时项目便已成功使能 Spring Security 提供的认证、授权、安全防护等功能。

默认情况下，Spring Security 采用 Http Basic 认证和表单认证，默认的用户名为user，密码打印在控制台，比如：

# 每次启动后台应用，都会生成一个随机密码
Using generated security password: 81a892eb-8191-45af-9bdb-4acd4f9c32e0

默认 SecurityFilterChain

前面内容有讲述，自动配置类SecurityAutoConfiguration会注入一个名称为springSecurityFilterChain的FilterChainProxyBean 实体到 Spring容器中，实际上，该自动配置类还注入了一个SecurityFilterChainBean，源码追踪如下：

// org\springframework\boot\autoconfigure\security\servlet\SecurityAutoConfiguration.java
@Import({ SpringBootWebSecurityConfiguration.class, WebSecurityEnablerConfiguration.class,
        SecurityDataConfiguration.class })
public class SecurityAutoConfiguration {
...
}

// org\springframework\boot\autoconfigure\security\servlet\SpringBootWebSecurityConfiguration.java
@Configuration(proxyBeanMethods = false)
@ConditionalOnDefaultWebSecurity
@ConditionalOnWebApplication(type = Type.SERVLET)
class SpringBootWebSecurityConfiguration {

    @Bean
    @Order(SecurityProperties.BASIC_AUTH_ORDER)
    SecurityFilterChain defaultSecurityFilterChain(HttpSecurity http) throws Exception {
        // HTTP 请求配置
        http.authorizeRequests().anyRequest().authenticated().and().formLogin().and().httpBasic();
        return http.build();
    }
}

具体负责自动注入的配置类是SpringBootWebSecurityConfiguration，其会向 Spring容器注入一个名称为defaultSecurityFilterChain的SecurityFilterChainBean，这个 Bean 设置了默认的请求权限配置，即使用 Http Basic 认证方式，对所有的授权请求都要进行认证，前端认证会自动生成一个表单页面，供用户进行输入。

默认用户配置

Spring Secuirty 提供的默认用户是由配置类UserDetailsServiceAutoConfiguration自动装配的：

@Configuration(proxyBeanMethods = false)
...
public class UserDetailsServiceAutoConfiguration {
    ...
    @Bean
    @ConditionalOnMissingBean(
            type = "org.springframework.security.oauth2.client.registration.ClientRegistrationRepository")
    @Lazy
    public InMemoryUserDetailsManager inMemoryUserDetailsManager(SecurityProperties properties,
            ObjectProvider<PasswordEncoder> passwordEncoder) {
        // 用户信息来自 SecurityProperties
        SecurityProperties.User user = properties.getUser();
        List<String> roles = user.getRoles();
        return new InMemoryUserDetailsManager(
                // 最后将 user 包装为一个 UserDetails
                User.withUsername(user.getName()).password(getOrDeducePassword(user, passwordEncoder.getIfAvailable()))
                        .roles(StringUtils.toStringArray(roles)).build());
    }
    ...
}

从源码可以看到，默认的用户信息来自SecurityProperties#getUser()方法，追踪源码如下：

@ConfigurationProperties(prefix = "spring.security")
public class SecurityProperties {
    ...
    private final User user = new User();

    public User getUser() {
        return this.user;
    }
    ...
    public static class User {

        // Default user name.
        private String name = "user";

        // Password for the default user name.
        private String password = UUID.randomUUID().toString();

        // Granted roles for the default user name.
        private List<String> roles = new ArrayList<>();
        ...
    }
}

可以看到，SecurityProperties会默认生成一个User，该User默认名为user，默认密码是一个随机UUID。
由于SecurityProperties被注解@ConfigurationProperties修饰，因此这里我们也可以通过外部配置文件修改默认用户信息，如下所示：

# application.properties
spring.security.user.name=whyn
spring.security.user.password=password

自定义配置入口

Spring Security 的自定义配置类入口是WebSecurityConfigurerAdapter，通常我们会自定义一个配置类，继承自WebSecurityConfigurerAdapter，然后覆写相应方法进行自定义配置，如下所示：

// Spring Security 自定义配置类
@Configuration
public class SpringSecurityConfig extends WebSecurityConfigurerAdapter {

    // 认证管理器配置方法
    @Override
    protected void configure(AuthenticationManagerBuilder auth) throws Exception {
        super.configure(auth);
    }

    // 核心过滤器配置方法
    @Override
    public void configure(WebSecurity web) throws Exception {
        super.configure(web);
    }

    // 安全过滤器链配置方法
    @Override
    protected void configure(HttpSecurity http) throws Exception {
        super.configure(http);
    }
}

WebSecurityConfigurerAdapter主要提供了三个配置方法：

configure(AuthenticationManagerBuilder auth)：认证管理器配置方法。主要用于配置认证管理器AuthenticationManager，使用参数AuthenticationManagerBuilder就可以构建出一个AuthenticationManager。简单来说，对于用户认证的地方就在这里配置，比如配置UserDetails、PasswordEncoder...
configure(WebSecurity web)：核心过滤器配置方法。该方法主要用于配置WebSecurity。该接口平常使用不多，因为它不走 Spring Security 过滤器链，因此不具备状态维持，请求都是无状态的。通常我们都在这里配置放行静态资源，具体配置见下文内容。

注：前文有提及，Spring Boot 中自动配置类WebSecurityEnablerConfiguration最终就是通过WebSecurity#build()生成一个默认的名称为springSecurityFilterChain的FilterChainProxyBean，所以该方法主要就是用于配置springSecuritFilterChain这个FilterChainProxy。
configure(HttpSecurity http)：安全过滤器链配置方法。主要用来配置HttpSecurity。HttpSecurity提供了很多配置方法，绝大多数数情况下，我们都会在这里对请求进行自定义配置安全访问策略。

注：前文有提及，Spring Boot 中自动配置类SpringBootWebSecurityConfiguration最终就是通过HttpSecurity#build()生成一个默认的名称为defaultSecurityFilterChain的SecurityFilterChainBean，但是在我们自定义了WebSecurityConfigurerAdapter或SecurityFilterChain时，就不会使用默认生成的SecurityFilterChain，而是使用我们自定义的。无论哪种，最终都会将该SecurityFilterChainBean 注入到核心过滤器springSecuritFilterChain中。所以该方法主要就是用于配置SecurityFilterChain。

接口放行

Spring Security 提供了两种放行策略：

通过配置WebSecurity，使用WebSecurity#ignoring()方法：

@Override
public void configure(WebSecurity web) throws Exception {
    web.ignoring().antMatchers("/css/**", "/js/**", "/index.html", "/img/**", "/fonts/**", "/favicon.ico", "/verifyCode");
}

WebSecurity通常只用于配置放行静态资源，原因上文有提及。

通过配置HttpSecurity，使用HttpSecurity#antMatcher/HttpSecurity#antMatchers方法：
```
@Override
protected void configure(HttpSecurity http) throws Exception {
    http.authorizeRequests()
            // 放行接口 login/**，/test/index
            .antMatchers("/login/**","/test/index").permitAll()
            // 其余所有请求都必须经过认证
            .anyRequest().authenticated()
            .and()
            // 使用 HTTP Basic 认证
            .httpBasic()
            .and()
            // 同时支持表单认证（Web端优先使用表单认证）
            .formLogin();
}
```
注：antMatchers中前缀 ant 是 Spring 参考的 apache ant 项目里的匹配风格！，简单来说，在 ant-style 中，存在如下几种匹配规则：
- ?：匹配一个字符
- *：匹配任意字符，所以，a/*/c可以匹配a/c、a/b/c、a/bd/c...
- **：匹配任意层级路径。a/**/c，可以匹配a/b/c、a/b/d/c...
- {spring:[a-z]+}：匹配路径变量spring满足正则表达式[a-z]+。比如，com/{filename:\\w+}.jsp可以匹配com/test.jsp，并且会将变量filename的值设为test。
注：Spring Security 的匹配规则是从上往下顺序匹配，一旦匹配到了就立即返回，因此antMatchers(..)放行必须放置在认证authenticated()之前。

现在我们就可以直接访问/login及其子接口和/test/index接口，其余接口都需要先进行认证。如果想放行所有接口，可以配置如下：
```
@Override
protected void configure(HttpSecurity http) throws Exception {
    http.authorizeRequests((request) ->
            request.anyRequest().permitAll());
}
```

关于上述两种放行策略差别更详细分析，可参考：Spring Security 两种资源放行策略，千万别用错了！

用户与密码配置

前面我们提及，自动配置类UserDetailsServiceAutoConfiguration会为我们生成一个默认用户User，该用户默认名为user，默认密码是一个随机UUID，运行时会打印在控制台上。

我们也可以自己手动创建一个User，然后注入给 Spring Security。注入用户步骤如下：

创建一个用户，首先需要创建一个可以对密码进行加密和验证的PasswordEncoder，其接口源码如下：
```
public interface PasswordEncoder {

    // 加密
    String encode(CharSequence rawPassword);

    // 验证
    boolean matches(CharSequence rawPassword, String encodedPassword);

    // 对加密字符串再次进行加密，提高安全性。
    // 一般设置为 false 即可，即无需二次加密
    default boolean upgradeEncoding(String encodedPassword) {
        return false;
    }
}
```
Spring Security 内置了几种PasswordEncoder，这里简单列举常见的几种：
- NoOpPasswordEncoder：明文存储密码。
- BCryptPasswordEncoder：其使用 bcrypt 强哈希函数，且自带加盐处理，安全且方便。当前 Spring Security 官方推荐使用该种加密算法。
- DelegatingPasswordEncoder：加密算法一直处于更新状态，我们永远不知道什么时候当前推荐的加密算法就不安全了。因此 Spring Security 官方提供了DelegatingPasswordEncoder，它可以确保一直使用最新的加密算法，并且兼容旧格式密码验证。
其余 Spring Security 提供的PasswordEncoder，可参考官网：Password Storage

综上，我们这里自定义一个配置类，注入一个BCryptPasswordEncoder或者DelegatingPasswordEncoder：
```
@Configuration
public class SecurityPasswordEncoder {
    @Bean
    public PasswordEncoder passwordEncoder() {
        // return new BCryptPasswordEncoder();
        return PasswordEncoderFactories.createDelegatingPasswordEncoder();
    } 
}
```

配置用户信息，并使用前面配置的PasswordEncoder对密码进行加密：

@Component
public class SpringSecurityConfig extends WebSecurityConfigurerAdapter {

    @Autowired
    private PasswordEncoder passwordEncoder;

    @Override
    protected void configure(AuthenticationManagerBuilder auth) throws Exception {
        // 加密
        String password = this.passwordEncoder.encode("123456");
        // 内存用户
        auth.inMemoryAuthentication()
                // 用户名
                .withUser("whyn")
                // 密码
                .password(password)
                // 权限 CRUD
                .authorities("Role_ADMIN",create","read","udpate","delete");
    }
}

这里我们在内存中创建了一个用户，其名称为whyn，密码为123456，角色是ADMIN，拥有create、read、update和delete权限。

此时运行程序，页面表单输入用户名和密码就可以成功访问。

除了在内存中创建用户外，Spring Security 还支持从其他一些存储数据源中获取用户：

In-Memory Authentication：即用户信息存在在内存中。Spring Security 内置的InMemoryUserDetailsManager实现了接口UserDetailsService，UserDetailsService可以通过用户名加载到相应的用户对象UserDetails，所以InMemoryUserDetailsManager可以在内存中加载用户对象。

对于基于用户名/密码认证的简单场景，可以通过这种方式创建一个自定义用户UserDetails，比如，前面的代码还可以更改为如下：

@Configuration
public class InMemoryUserDetailsServiceConfig {

    @Autowired
    private PasswordEncoder passwordEncoder;

    @Bean
    public UserDetailsService createUserDetailsService() {
        InMemoryUserDetailsManager manager = new InMemoryUserDetailsManager();
        // 创建 admin 用户
        manager.createUser(
                User.withUsername("whyn")
                        .password(this.passwordEncoder.encode("123456"))
                        .roles("admin")
                        .authorities("create", "read", "update", "delete")
                        .build()
        );
        // 创建 tourist 用户
        manager.createUser(
                User.withUsername("tourist")
                        .password(this.passwordEncoder.encode("guest"))
                        .roles("tourist")
                        .build());
        return manager;
    }
}

JDBC Authentication：用户存储在关系型数据库。Spring Security 提供了JdbcDaoImpl，它实现了UserDetailsService，可以从数据库中获取相应用户。
LDAP Authentication：LDAP 是跨平台身份验证，通常用于作为用户信息存储的中央仓库，并提供认证服务。

UserDetailsService：DaoAuthenticationProvider会从UserDetailsService中获取用户的名称、密码和其他一些属性用户认证。我们可以自定义一个UserDetailsService，自定义用户UserDetails加载逻辑：

@Service
public class CustomUserDetailsServiceImpl implements UserDetailsService {
    @Autowired
    private PasswordEncoder passwordEncoder;

    @Override
    public UserDetails loadUserByUsername(String username) throws UsernameNotFoundException {
        return User.withUsername("custom")
                .password(this.passwordEncoder.encode("123456"))
                .roles("tourist")
                .build();
    }
}

@Configuration
public class SpringSecurityConfig extends WebSecurityConfigurerAdapter {

    @Autowired
    private PasswordEncoder passwordEncoder;

    @Autowired
    private UserDetailsService userDetailsService;

    @Override
    protected void configure(AuthenticationManagerBuilder auth) throws Exception {
        auth.authenticationProvider(daoAuthenticationProvider());
    }

    // 自定义一个 DaoAuthenticationProvider，与我们自定义的 UserDetailsService 进行绑定
    @Bean
    public DaoAuthenticationProvider daoAuthenticationProvider() {
        DaoAuthenticationProvider provider = new DaoAuthenticationProvider();
        // 绑定到我们自定义的 UserDetailsService
        provider.setUserDetailsService(this.userDetailsService);
        provider.setPasswordEncoder(this.passwordEncoder);
        return provider;
    }
}

UserDetailsService的接口只有一个抽象方法loadUserByUsername，其根据用户名从存储系统中获取用户信息UserDetails，因此，自定义UserDetailsService形式非常灵活，我们可以自行选择加载用户的数据源，比如，可以从内存中获取，也可以从数据库中获取...

安全防护

Spring Security 提供了很多安全防护措施，其中一个主要的就是预防 CSRF 攻击。

CSRF：跨站请求伪造（Cross Site Request Forgery），即在其他域网站在访问当前网站时，浏览器会自动将当前网站的 Cookie 携带上，这样服务器就会认为是已登录用户的正常请求，导致用户数据被窃取。

默认情况下，Spring Boot 与 Spring Security 整合后，会自动开启 CSRF 预防，此时只有 GET、OPTIONS、HEAD、TRACE、CONNECTION 可以访问，POST 等请求会被拒接，错误码为403。

如果集成 Spring Security 后，发现只有 GET 能请求，POST、PUT 等方法无法请求，那基本上就是因为开启了 CSRF 原因。

注：在前后端分离项目中，无需开启 CSRF，建议直接关闭即可：csrf().diable()

更多安全预防详情，可参考官网：Protection Against Exploits

常见认证机制

常见的认证机制主要有：HTTP Basic Auth、Session-Cookie Auth、Token Auth、OAuth2 和 SSO...
下面简单介绍下这几种认证机制，以及在 Spring Security 中使能这些机制。

HTTP Baisc Auth

HTTP Basic 是 HTTP 协议中内置的最古老，最基础的身份认证机制，简单来说，使用 HTTP Basic 认证，每次在请求 API 的时候，都需要携带用户的username和password。

在 Spring Security 中，开启 HTTP Basic 认证配置方式如下所示：

@Configuration
public class SpringSecurityConfig extends WebSecurityConfigurerAdapter {

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        // 所有授权请求都必须先进行认证
        http.authorizeRequests((request) -> request.anyRequest().authenticated());
        // 开启 HTTP Basic 认证
        http.httpBasic();
    }
}

只需自定义一个配置类，然后通过HttpSecurity#httpBasic()方法开始 HTTP Baisc 认证机制即可。

假设现在我们有如下接口：

@RestController
@RequestMapping("/test")
public class TestApi {
    @GetMapping("/index")
    public String index() {
        return "welcome to Spring Security!";
    }
}

当我们在Web页（即网页端）端访问该接口时，浏览器就会弹出一个输入框，供用户输入用户名和密码，如下如所示：

Http Basic Auth

这里我们直接在终端进行访问，查看下访问详情：

$ curl -X GET 'localhost:8080/test/index' --user 'user:3ee0747f-3c0a-49d4-a50d-f60cdab0c5a1' -v
* Server auth using Basic with user 'user'
> GET /test/basic-auth HTTP/1.1
> Authorization: Basic dXNlcjozZWUwNzQ3Zi0zYzBhLTQ5ZDQtYTUwZC1mNjBjZGFiMGM1YTE=
>
< HTTP/1.1 200
< Set-Cookie: JSESSIONID=60364574CA3BE7AF0530999009F3BDE3; Path=/; HttpOnly
welcome to Sprign Security!%

上述数据去除了一些不重要内容，可以看到，请求成功了，一个注意的点就是，每次使用 HTTP Basic 请求，都会在请求头携带上Authorization: Basic xxx，其中，xxx是对username:password进行 base64 编码后的值，我们对上述请求头Authorization进行解码，如下所示：

# 解码
$ echo -n 'dXNlcjozZWUwNzQ3Zi0zYzBhLTQ5ZDQtYTUwZC1mNjBjZGFiMGM1YTE=' | base64 --decode
user:3ee0747f-3c0a-49d4-a50d-f60cdab0c5a1%

# 编码，-n 必须加上，否则会添加一个换行符
$ echo -n 'user:3ee0747f-3c0a-49d4-a50d-f60cdab0c5a1' | base64
dXNlcjozZWUwNzQ3Zi0zYzBhLTQ5ZDQtYTUwZC1mNjBjZGFiMGM1YTE=

注：在 zsh 中，无换行会以 % 百分号结尾，在bash中，命令提示符会直接跟在输出结果的后面，而 zsh 会强制转换。

HTTP Basic 的优点就是简单，而缺点就是明文传输私密信息，非常不安全。如果一定要使用 HTTP Basic 机制，那么建议在 HTTPS 环境，起码增添了一层加密，提高安全性。

Session-Cookie Auth

Session-Cookie 是 Web端用的比较多的认证机制，其实就是我们常说的表单认证，其认证流程为：第一次访问时，需要携带用户名和密码，服务端认证通过后，会将用户信息存储在一个 Session 中，然后将用户标识（通常为sessionId）下发给浏览器（通过Set-Cookie下发），后续该浏览器的其他请求，会自动携带身份标识 Cookie，服务器就可以认证通过，因此，Session-Cookie 是具备状态维护的。

注：对于 Session-Cookie 更详细介绍，可参考：简析 Cookie，Session 和 Token（JWT）

Spring Security 中配置 Session-Cookie 认证如下所示：

@Component
public class SpringSecurityConfig extends WebSecurityConfigurerAdapter {

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        // 所有授权请求都必须先进行认证
        http.authorizeRequests((request) -> request.anyRequest().authenticated());
        // 开启表单认证
        http.formLogin();
    }
}

此时，当我们在浏览器输入localhost:8080/test/index时，就会重定向到localhost:8080/login页面，如下图所示：

Form Login

输入用户名和密码就可以正常访问了。

注：Web端表单提交存在 CSRF 攻击漏洞，Spring Security 默认对 CSRF 攻击进行防御，其原理是在/login页面上的form表单上添加了一个隐式_csrf键值对，每次请求登录页面，Spring Security 都会生成一个随机的_csrftoken，这样只有在服务器端检测到该_csrf是合法时，才表示该次请求是合法请求。
而对于 Ajax 异步请求，前端就需要使用 JavaScritp 自己手动获取_csrftoken 并设置到请求头中。只要保证浏览器无法从 Cookie 中直接获取得到_csrf，那么就可以规避 CSRF 攻击。

Spring Seurity 中表单认证提供了很多配置细节，这里简单列举常用的一些配置：

自定义登录页面：默认情况下，Spring Security 生成的表单登录页面和登录接口都是/login，即存在如下两个接口：

GET http://localhost:8080/login：获取表单页面接口
POST http://localhost:8080/login：提交表单数据接口

要自定义登录页面，使用的是FormLoginConfigurer#loginPage方法，要自定义表单提交接口，使用的是AbstractAuthenticationFilterConfigurer#loginProcessingUrl，具体配置步骤如下：

首先配置 Spring Security，指定自定义登录页面和登录接口：

@Override
protected void configure(HttpSecurity http) throws Exception {
    http.authorizeRequests()
            // 所有请求都要先认证
            .anyRequest().authenticated()
            .and()
            // 启动表单验证
            .formLogin(form ->
                    // 登录页面，不拦截
                    form.loginPage("/login.html").permitAll()
                            // 表单登录提交接口（无需定义 doLogin 接口）
                            .loginProcessingUrl("/doLogin"))
            // 失能 CSRF
            .csrf().disable();
}

注：如果只配置了loginPage，那么此时loginProcessingUrl等同于loginPage，即登录页面和登录接口一样。

后端创建配置对应的登录接口：
```
@Controller
public class LoginApi {
    // 登录页面接口
    @GetMapping("/login.html")
    public String loginPage() {
        return "login";
    }
```
注：loginProcessingUrl的作用是为了告诉UsernamePasswordAuthenticationFilter用户名和密码获取地址，自己项目中无需声明一个对应的Controller接口，声明了也没用，因为不会走自己定义的接口。
建议不要配置loginProcessingUrl，让他默认跟loginPage一致即可，免得搞乱自己。

导入模板引擎 Thymeleaf：

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-thymeleaf</artifactId>
</dependency>

创建登录页面：resources/templates/login.html，内容如下：

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>Custom Login Page</title>
</head>
<body>
    <form action="/doLogin" method="post">
        <div>
            <!-- 用户名键值默认为 username -->
            <input type="text" name="username" placeholder="input username" required/>
        </div>
        <div>
            <!-- 密码键值默认为 password -->
            <input type="password" name="password" placeholder="input password" required/>
        </div>
        <input type="submit">
    </form>
</body>
</html>

注：表单中action接口地址必须与loginProcessingUrl一致。

以上，便已完成配置。初次访问时，就会重定向到我们自定义登录界面/login.html，认证成功后即可访问其余页面。

登录成功跳转：登录成功后，设置跳转页面，Spring Security 主要提供了三种配置方法：

successForwardUrl：登录成功后，一律跳转到指定位置，无论之前是访问哪个页面：

protected void configure(HttpSecurity http) throws Exception {
    http.authorizeRequests()
            .anyRequest().authenticated()
            .and()
            .csrf().disable()
            .formLogin()
            .successForwardUrl("/success");
}

@Controller
public class LoginApi {
    ...

    @PostMapping("/success")
    @ResponseBody
    public String loginSuccessForward() {
        return "login success";
    }
}

注：successForwardUrl采用服务端内部请求转发，因此跳转的接口方法要一致。比如表单登录使用的是Post方法，那么跳转接口也要支持Post请求。

defaultSuccessUrl：默认情况下，defaultSuccessUrl在登录成功后，会跳转会原先访问的页面。defaultSuccessUrl还有一个重载方法defaultSuccessUrl(String,boolean)，第二个参数默认值为fasle，如果设置为true，则其效果跟successForwardUrl一样：
```
protected void configure(HttpSecurity http) throws Exception {
    http.authorizeRequests()
            .anyRequest().authenticated()
            .and()
            .csrf().disable()
            .formLogin()
            .defaultSuccessUrl("/test/index");
}
```
注：defaultSuccessUrl在登录成功后，无论第二个参数是true还是fasle，采用的都是重定向跳转到指定页面。

successHandler：该方法可用于自定义登录成功处理器。当需要一些自定义操作跳转时，可以采用该方式。比如，我们自定义一个处理器，实现类似defaultSuccessUrl跳转功能：

public class AuthenticationSuccessHandlerImpl implements AuthenticationSuccessHandler {

    private String url;
    // 请求缓存
    private RequestCache requestCache = new HttpSessionRequestCache();

    public AuthenticationSuccessHandlerImpl(String destUrl) {
        if (!UrlUtils.isValidRedirectUrl(destUrl)) {
            throw new RuntimeException(String.format("'%s' is not a valid URL", destUrl));
        }
        this.url = destUrl;
    }

    @Override
    public void onAuthenticationSuccess(HttpServletRequest request, HttpServletResponse response, Authentication authentication) throws IOException, ServletException {
        SavedRequest savedRequest = this.requestCache.getRequest(request, response);
        if (savedRequest == null) {
            response.sendRedirect(this.url);
            return;
        }
        // 目标URL，即登录页面前访问的 URL
        String targetUrl = savedRequest.getRedirectUrl();
        response.sendRedirect(targetUrl);
    }
}

然后配置到表单选项上：

protected void configure(HttpSecurity http) throws Exception {
    http.authorizeRequests()
            .anyRequest().authenticated()
            .and()
            .csrf().disable()
            .formLogin()
            .successHandler(new AuthenticationSuccessHandlerImpl("https://www.baidu.com"));
}

实际使用中，defaultSuccessUrl、successForwardUrl和successHandler只需配置一个即可，建议优先使用defaultSuccessUrl，需要自定义配置时使用successHandler。

失败登录跳转：对于失败登录跳转，Spring Security 同样提供了三种配置：failureForwardUrl、failureUrl和failureHandler。

注：failureForwardUrl是基于服务器内转发，failureUrl是基于重定向（failureUrl配置后一直还会重定向到登录页面，原因目前未知-_-），failureHander可以实现自定义登录失败处理器。

这里简单列举下failureHander的配置方法：

创建一个登录失败接口：

@Controller
public class LoginApi {

    @RequestMapping("/failure.html")
    public String hahawaPage() {
        return "failure";
    }
}

创建登录失败显示页面：resources/templates/failure.html

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>Failure</title>
</head>
<body>
    <span>登录是失败，请重新<a href="/login">登录</a></span> 
</body>
</html>

配置登录失败处理：

@Override
protected void configure(HttpSecurity http) throws Exception {
    http.authorizeRequests()
            .antMatchers("/failure.html").permitAll()
            .anyRequest().authenticated()
            .and()
            .csrf().disable()
            .formLogin()
            .failureHandler(new AuthenticationFailureHandlerImpl("/failure.html"));
            // failure.html 需要支持 POST 请求
            //.failureForwardUrl("/failure.html");
            // .failureUrl("/failure.html");
}

表单参数：默认情况下，表单数据用户名默认名称为username、密码默认名称为password，可以通过如下方法配置表单参数：

protected void configure(HttpSecurity http) throws Exception {
    http.authorizeRequests(request ->
            request.anyRequest().authenticated())
            .formLogin((form) -> {
                // 设置登录页面，且不进行拦截
                form.loginPage("/login.html").permitAll()
                        // 配置用户名键值
                        .usernameParameter("name")
                        // 配置密码键值
                        .passwordParameter("pwd");
            }).csrf().disable(); 
}

然后对于登陆页面resources/templates/login.html，修改其 Form表单中的登录参数：

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>Custom Login Page</title>
</head>
<body>
<form action="/login.html" method="post">
    <div>
        <!-- 用户名键值默认为 username -->
        <input type="text" name="name" placeholder="input username" required/>
    </div>
    <div>
        <!-- 密码键值默认为 password -->
        <input type="password" name="pwd" placeholder="input password" required/>
    </div>
    <input type="submit">
</form>
</body>
</html>

退出登录：Spring Security 提供的用户退出登录配置大致有如下：

protected void configure(HttpSecurity http) throws Exception {
    http.authorizeRequests()
            .anyRequest().authenticated()
            .and()
            .csrf().disable()
            .formLogin()
            .and()
            .logout(logout -> {
                // doLogout 无需自己定义，可直接访问退出
                logout.logoutUrl("/doLogout")
                        // 修改注销 URL，可自定义请求方法...
                        // logout.logoutRequestMatcher(new AntPathRequestMatcher("/doLogout","POST"));
                        // 退出成功后跳转页面
                        .logoutSuccessUrl("/test/index").permitAll()
                        // 清除 cookie
                        .deleteCookies()
                        // 清除认证消息 (默认使能）
                        .clearAuthentication(true)
                        // 清除 Session（默认使能）
                        .invalidateHttpSession(true);
            });
}

注：logoutUrl可指定退出登录接口，我们无需自己在Controller内定义该接口，直接指定就可以使用。
logoutUrl和logoutRequestMatcher实际使用中任意设置一个即可。

Remember Me：Spring Security 支持 Remember Me 功能，其实就是给 Cookie 设置一个过期时间，这样浏览器就会持久化该 Cookie，在有效期间内就能一直起到登录作用。其配置方式大致如下：

protected void configure(HttpSecurity http) throws Exception {
    http.authorizeRequests()
            .anyRequest().authenticated()
            .and()
            .formLogin()
            .and()
            .rememberMe(rememberMe -> {
                // 用于生成 token 的密钥
                rememberMe.key("uniqueAndSecure")
                        // 表单参数名称
                        .rememberMeParameter("remember-me")
                        // Cookie 名称
                        .rememberMeCookieName("remember-me")
                        // 过期时间，默认是 2周
                        .tokenValiditySeconds((int) TimeUnit.DAYS.toSeconds(2));
            });
}

以上配置后，登录页面就是多出一个Remember Me的勾选框，其实就是添加了一个表单字段remember-me。

Session-Cookie 机制的优点是具备状态维持，缺点是由于移动端等缺省不直接支持 Cookie 机制，因此无法直接在移动端中使用，同时，由于 Session 集中存在在服务器端，限制了服务器的水平扩展能力。

由于 Session-Cookie 并不归属于 HTTP认证规范，因此它可以采用不同的实现机制。一个改进的方案就是将 Cookie 存放到本地存储仓库中，比如，浏览器将收到的 Cookie 存放到localStorage中，而移动端可以将 Cookie 存储到SharedPreferences或本地数据库中。每次请求时，就从本地仓库中获取到 Cookie（即sessionId），将其设置到请求头中或请求体中，由于数据不直接存放在 Cookie 中，因此浏览器端不存在 CSRF 风险。同时，服务器端可以将 Session 迁移到 Redis 等内存数据库中，将其作为 Session 共享服务器，速度快且一定程度上缓解了服务器水平扩展问题。

Token Auth

Token 是一种格式紧凑且具备自描述信息的安全认证机制，其存储了用户信息（明文）和对用户信息加密后生成的签名。其认证流程如下：

首次请求时，客户端会发送用户名和密码给到服务器，服务器认证通过后，会生成一个包含用户数据等信息的 Token，然后将该 Token 下发给客户端。
客户端收到 Token 后，将 Token 存储到本地存储仓库中，后续请求时，都要将该 Token 放置到请求头或请求体中。
服务器收到请求后，首先获取 Token，提取出用户信息和加密算法，结合自己的密钥对 Token 中的用户信息进行加密，得出签名，如果该签名与 Token 中的签名一样的话，说明用户信息没有被串改，认证成功。

注：对于 Token 更详细介绍，可参考：简析 Cookie，Session 和 Token（JWT）

在 Spring Security，配置 Token 认证方式的主要为如下两步：

下发 JWT Token：首次登录时，需要对用户身份进行验证，成功后生成一个 JWT token，下发给到客户端。

具体配置步骤如下所示：

导入依赖：当前主流的 token 实现格式为：JSON Web Token，这里我们采用 jjwt 库实现 jwt：

<dependency>
    <groupId>io.jsonwebtoken</groupId>
    <artifactId>jjwt-api</artifactId>
    <version>0.11.2</version>
</dependency>
<dependency>
    <groupId>io.jsonwebtoken</groupId>
    <artifactId>jjwt-impl</artifactId>
    <version>0.11.2</version>
    <scope>runtime</scope>
</dependency>
<dependency>
    <groupId>io.jsonwebtoken</groupId>
    <artifactId>jjwt-jackson</artifactId> <!-- or jjwt-gson if Gson is preferred -->
    <version>0.11.2</version>
    <scope>runtime</scope>
</dependency>

编写 Token 操作工具类：方便生成和解析 Token：

public class JwtTokenUtils {
    // 私钥
    private static final String PRIVATE_SECRET_KEY = "this_is_private_secret_key";
    // token 默认过期时间：14 天
    private static final long TOKEN_EXPIRATION = TimeUnit.DAYS.toMillis(14);
    // 下发 token 增加前缀
    public static final String TOKEN_PREFIX = "Bearer ";

    public static final String KEY_USER_NAME = "username";
    public static final String KEY_USER_AUTHORITIES = "authorities";

    // 解析 token
    public static Map<String, Object> parseToken(String token) {
        Map<String, Object> userDetails = new HashMap<>();
        try {
            token = validateToken(token);
            Jws<Claims> claimsJws = Jwts.parserBuilder()
                    .setSigningKey(getSecretKey()).build().parseClaimsJws(token);
            // 用户名
            String username = claimsJws.getBody().getSubject();
            // 用户权限
            List<Map<String, String>> authorities = (List<Map<String, String>>) claimsJws.getBody().get(KEY_USER_AUTHORITIES);
            Collection<? extends GrantedAuthority> userAuthorities = authorities.stream()
                    .map(item ->
                            new SimpleGrantedAuthority(item.get("authority")))
                    .collect(Collectors.toSet());
            userDetails.put(KEY_USER_NAME, username);
            userDetails.put(KEY_USER_AUTHORITIES, userAuthorities);
            return userDetails;
        } catch (JwtException e) {
            throw new IllegalStateException(String.format("invalid token: %s", token));
        }
    }

    // 生成token
    public static String generateToken(String username) {
        String token = Jwts.builder()
                .setSubject(username)
                .setIssuedAt(new Date())
                .setExpiration(new Date(System.currentTimeMillis() + TOKEN_EXPIRATION))
                .signWith(getSecretKey())
                .compact();
        return generateTokenWithPrefix(token);
    }

    // 生成 token，包含用户主体和其权限
    public static String generateToken(String username, Object authorities) {
        String token = Jwts.builder()
                // 用户名
                .setSubject(username)
                // payload
                .claim(KEY_USER_AUTHORITIES, authorities)
                // 发行时间
                .setIssuedAt(new Date())
                // 过期时间
                .setExpiration(new Date(System.currentTimeMillis() + TOKEN_EXPIRATION))
                // 私钥
                .signWith(getSecretKey())
                .compact();
        return generateTokenWithPrefix(token);
    }

    // token 添加前缀 Bearer
    private static String generateTokenWithPrefix(final String token) {
        return TOKEN_PREFIX + token;
    }

    // 生成签名私钥
    private static Key getSecretKey() {
        return Keys.hmacShaKeyFor(generateSecretKey());
    }

    // 加密要求至少 256 位，因此将私钥进行 sha256，只是单纯为了生存 256 个字节
    private static byte[] generateSecretKey() {
        byte[] hashKey = null;
        try {
            MessageDigest digest = MessageDigest.getInstance("SHA-256");
            hashKey = digest.digest(PRIVATE_SECRET_KEY.getBytes(StandardCharsets.UTF_8));
        } catch (NoSuchAlgorithmException e) {
            hashKey = fillBytes(PRIVATE_SECRET_KEY);
        }
        return hashKey;
    }

    // 循环字符串添加到 256 个字节
    private static byte[] fillBytes(String str) {
        if (str == null) {
            str = PRIVATE_SECRET_KEY;
        }
        byte[] bytes256 = new byte[256];
        int length = str.length();
        for (int i = 0; i < 256; ++i) {
            // 忽视精度缺失，只是为了添加到 256 个字节
            bytes256[i] = (byte) str.charAt(i % length);
        }
        return bytes256;
    }

    // 去除 token 前缀：Bearer
    private static String validateToken(String token) {
        String rawToken = token;
        if (rawToken.startsWith(TOKEN_PREFIX)) {
            rawToken = rawToken.substring(TOKEN_PREFIX.length());
        }
        return rawToken;
    }
}

注：上面的 Token 工具类内部硬编码了一些常量，这些自定义常量其实也可以通过配置文件进行配置，比如，以下定义了一个配置类：

@ConfigurationProperties(prefix = "jwt.token")
public class JwtTokenProperty {

    private String secretKey;
    private long expiration;
    private String tokenPrefix;

    // getters
    // setters
}

配置类JwtTokenProperty可以从配置文件application.yml中读取前缀为jwt.token的配置选项：

jwt:
  token:
    # 密钥
    secretKey: "this_is_private_secret_key"
    # 过期时间 14 天
    #  jshell> TimeUnit.DAYS.toMillis(14);
    #  $1 ==> 1209600000
    expiration: 1209600000
    # token 前缀
    tokenPrefix: Bearer

按上述配置，当程序运行时，JwtTokenProperty内部属性就会自动被赋予配置文件中定义的值，灵活度更高。

最后，要让配置类生效，还需显示使用注解@EnableConfigurationProperties进行使能：

@SpringBootApplication
// 使能配置类
@EnableConfigurationProperties({JwtTokenProperty.class})
public class SpringSecurityDemoApplication {
    ...
}

自定义验证过滤器：我们知道，在 Spring Security 中，负责验证用户登录的是UsernamePasswordAuthenticationFilter，但是它无法对 JSON 数据进行校验，因此，这里我们可以基于它实现一个可以识别并验证 JSON 数据登录请求：

public class JwtTokenUsernamePasswordAuthenticationFilter extends UsernamePasswordAuthenticationFilter {

    private final AuthenticationManager authenticationManager;

    public JwtTokenUsernamePasswordAuthenticationFilter(AuthenticationManager authenticationManager) {
        this.authenticationManager = authenticationManager;
    }

    @Override
    public Authentication attemptAuthentication(HttpServletRequest request, HttpServletResponse response) throws AuthenticationException {

        try {
            // 获取请求参数
            Map<String, String> userMap = new ObjectMapper().readValue(
                    request.getInputStream(), Map.class);
            // 获取用户名
            String username = userMap.get(this.getUsernameParameter());
            // 获取用户密码
            String password = userMap.get(this.getPasswordParameter());
            // 包装为一个 Authentication 对象，方便后面给 AuthenticationManager 进行验证
            UsernamePasswordAuthenticationToken authentication = new UsernamePasswordAuthenticationToken(username, password);
            // Allow subclasses to set the "details" property
            this.setDetails(request, authentication);
            // 进行验证
            return this.authenticationManager.authenticate(authentication);
        } catch (Exception e) {
            throw new AuthenticationServiceException("用户名或密码错误，认证失败!");
        }
    }

    @Override // 认证成功
    protected void successfulAuthentication(HttpServletRequest request,
                                            HttpServletResponse response,
                                            FilterChain chain,
                                            Authentication authResult) throws IOException, ServletException {
        // 生成 token
        String token = JwtTokenUtils.generateToken(authResult.getName(), authResult.getAuthorities());
        // 下发 token
        response.addHeader("Authorization", token);

        response.setCharacterEncoding("utf-8");
        response.getWriter().print("登录成功");
    }

    @Override // 认证失败
    protected void unsuccessfulAuthentication(HttpServletRequest request, HttpServletResponse response, AuthenticationException failed) throws IOException, ServletException {
        SecurityContextHolder.clearContext();
        response.setCharacterEncoding("utf-8");
        response.setStatus(HttpStatus.UNAUTHORIZED.value());
        response.getWriter().print(failed.getMessage());
    }
}

注：因为 Token Auth 常用于前后端分离项目，前后端基本上都是通过 JSON 数据进行通信，包含登录等操作，因此这里我们自定义JwtTokenUsernamePasswordAuthenticationFilter支持 JSON 格式登录验证，并且验证成功后会生成一个 JWT token，放置在响应头Authorization中，客户端只需提取出该 JWT token，后续请求时携带上即可访问服务器上的资源。

注册到SecurityFilterChain：最后还需要将自定义的JwtTokenUsernamePasswordAuthenticationFilter注册到 Spring Security 的SecurityFilterChain中，让其生效：

@Override
protected void configure(HttpSecurity http) throws Exception {
    http.authorizeRequests(request -> request.anyRequest().authenticated())
            // 关闭 CSRF 预防
            .csrf(csrf -> csrf.disable())
            .sessionManagement(sessionManager ->
                    // 无需创建 Session
                    sessionManager.sessionCreationPolicy(SessionCreationPolicy.STATELESS))
            // 添加自定义 token 认证过滤器（下发 token）
            .addFilter(new JwtTokenUsernamePasswordAuthenticationFilter(
                    this.authenticationManager()));
}

此时，项目就具备下发 token 能力了，我们进行登录，查看下效果：

$ curl -X POST 'localhost:8080/login' --header 'Content-Type: application/json; charset=utf-8' --data '{"username":"admin","password":"admin_password"}'  -v
> POST /login HTTP/1.1
> Content-Type: application/json; charset=utf-8
> Content-Length: 48
>
< HTTP/1.1 200
< Authorization: Bearer eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJhZG1pbiIsImF1dGhvcml0aWVzIjpbeyJhdXRob3JpdHkiOiJjcmVhdGUifSx7ImF1dGhvcml0eSI6ImRlbGV0ZSJ9LHsiYXV0aG9yaXR5IjoicmVhZCJ9LHsiYXV0aG9yaXR5IjoidXBkYXRlIn1dLCJpYXQiOjE2MzM5NzMwOTgsImV4cCI6MTYzNTE4MjY5OH0.lzdNOz2nIGZi4sJYgaJ7AFVKmA_PlyCd-HcTY7JDotA

可以看到，我们通过 JSON 进行登录，服务区验证通过后，成功下发了一个 token，将该 token 复制到 JWT 官网上，可以查看该 token 携带的信息，如下图所示：

JSON Web Token

验证 JWT Token：前面步骤完成了登录下发 JWT token，后续客户端每次请求时，都会携带该 token，因此我们需要对该 token 进行验证，成功则允许其访问资源。

具体配置步骤如下：

自定义 token 验证过滤器：需要自定义一个过滤器，对每次请求，将其 token 截取出来，并进行认证：

// OncePerReequestFilter 可以确保单次请求只会执行一次 Filter
public class JwtTokenVerifyFilter extends OncePerRequestFilter {
    @Override
    protected void doFilterInternal(HttpServletRequest request,
                                    HttpServletResponse response,
                                    FilterChain filterChain) throws ServletException, IOException {
        String token = request.getHeader("Authorization");
        if (null != token && token.startsWith(JwtTokenUtils.TOKEN_PREFIX)) {
            Map<String, Object> userDetails = JwtTokenUtils.parseToken(token);
            String username = (String) userDetails.get(JwtTokenUtils.KEY_USER_NAME);
            Collection<? extends GrantedAuthority> authorities =
                    (Collection<? extends GrantedAuthority>) userDetails.get(JwtTokenUtils.KEY_USER_AUTHORITIES);

            // 将 token 提取出来的用户信息封装到 Authentication 中
            Authentication authentication = new UsernamePasswordAuthenticationToken(
                    username,     // principal 用户名
                    null, // credentials 密码无法获取，直接置为空即可
                    authorities);
            // 认证成功，直接设置到 SecurityContextHolder 中，供后续 Filters 使用
            SecurityContextHolder.getContext().setAuthentication(authentication);
        }
        filterChain.doFilter(request, response);
    }
}

注册到SecurityFilterChain：将自定义的JwtTokenVerifyFilter注册到SecurityFilterChain中，且该Filter要在JwtTokenUsernamePasswordAuthenticationFilter后面，因为登录在先（生成 token），后续才是请求处理（验证 token）：

protected void configure(HttpSecurity http) throws Exception {
    http.authorizeRequests(request -> request.anyRequest().authenticated())
            .csrf(csrf -> csrf.disable())
            .sessionManagement(sessionManager ->
                    sessionManager.sessionCreationPolicy(SessionCreationPolicy.STATELESS))
            .addFilter(new JwtTokenUsernamePasswordAuthenticationFilter(
                    this.authenticationManager()))
            // 添加自定义 token 提取过滤器（提取并认证）
            .addFilterAfter(new JwtTokenVerifyFilter(),
                    JwtTokenUsernamePasswordAuthenticationFilter.class);
}

此时，我们就能对 JWT token 进行校验，校验通过则允许用户访问对应资源。比如，我们拿上面生成的 token，访问服务器资源，效果如下：

$ curl -X GET 'localhost:8080/user' --header 'Authorization: Bearer eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJhZG1pbiIsImF1dGhvcml0aWVzIjpbeyJhdXRob3JpdHkiOiJjcmVhdGUifSx7ImF1dGhvcml0eSI6ImRlbGV0ZSJ9LHsiYXV0aG9yaXR5IjoicmVhZCJ9LHsiYXV0aG9yaXR5IjoidXBkYXRlIn1dLCJpYXQiOjE2MzM5NzMwOTgsImV4cCI6MTYzNTE4MjY5OH0.lzdNOz2nIGZi4sJYgaJ7AFVKmA_PlyCd-HcTY7JDotA'
["David","Roy","Linda"]%

可以看到，访问成功。

以上，便完成了 Spring Security Token 认证配置。

注：如果想了解 Spring Security 认证和授权具体流程，可参考：

最后，Token 认证机制是对 Session 机制的一种改进做法，其优点如下：

规避 CSRF 攻击：Token 存储在客户端本地存储系统中，比如 Web端将 Token 存储到localStorage中（不要直接存储在 Cookie 中），从根本上规避了 CSRF 攻击。
可扩展性：相对于 Session 将用户信息保存到服务器中，Token 是将用户信息存储到客户端中，其由于其具备自验证功能，因此服务端无需存储用户状态，服务端可以轻松进行水平扩展。
丰富客户端类型：Session-Cookie 机制主要用于 Web端，限制了移动等原生客户端类型，而 Token 独立存在，只需请求时携带即可，对客户端类型没有限制。

Token 的缺点主要有两点：

体积大：由于用户信息都存储在 Token 中，因此 Token 字符串本身比较大。
无法回收 Token 权限：由于 Token 具备自验证功能，因此在生效时间内，就一直有效。典型的场景就是我们无法直接强制用户下线。

OAuth

OAuth，即 Open Authrization(（开放授权），它为用户资源的授权提供了一个安全的、开放而又简易的标准，允许用户让第三方应用访问用户存储在其他服务器上的私密资源，而无需将用户名和密码提供给第三方应用。

OAuth协议有 1.0 和 2.0 两个版本，但 OAuth1.0 存在许多安全漏洞，因此在 OAuth2.0 里面完全废弃了 OAuth1.0，且 OAuth2.0 整个授权验证流程更简单更安全。

OAuth 是一个开放的协议，任何服务提供商（私密资源服务器）都可以提供 OAuth 服务（开放 API），任何第三方都可以接入并使用 OAuth 认证服务。国内常见的提供 OAuth 认证服务的厂商有：微信、微博、支付宝...

常用于第三方登录场景，比如微信，微博登录。

OAuth 交互具体流程，可参考：几种常用的Web安全认证方式

::to be continued

SSO

SSO，即 单点登录（Single Sign On），指的是在公司内容搭建一个公共的认证中心，公司下的所有产品的登录都可以在认证中心里完成，一个产品在认证中心登录后，再去访问另一个产品，可以不用再次登录，即可获取登录状态。

SSO 单点登录比较适合中大型企业，内部拥有多个产品，可以实现统一登录逻辑。
OAuth第三方登录是 SSO单点登录的一种形式，其公共的认证中心是由第三方平台提供。中小公司可以借助这些大厂提供的第三方登录服务，完成登录流程。

SSO 交互具体流程，可参考：4种常规的登录认证方式

::to be continued

授权

当用户认证通过后，需要访问某些资源时，就可以进行授权操作。Spring Security 对用户授权组织模型为：角色（role） + 权限（authority）。

角色：可设置拥有某种角色的用户可访问某一类资源。

举个例子：比如角色为USER的用户可以访问/user/**接口，角色为ADMIN的用户可以访问接口/admin/**和/user/**接口。具体配置步骤如下：

首先创建对应角色的用户：

@Configuration
public class SpringSecurityConfig extends WebSecurityConfigurerAdapter {

    @Autowired
    private PasswordEncoder passwordEncoder;

    @Override
    @Bean
    protected UserDetailsService userDetailsService() {
        // 管理员
        UserDetails adminUser = User.withUsername("admin")
                .password(this.passwordEncoder.encode("admin_password"))
                .roles("ADMIN") // ROLE_ADMIN
                .build();

        // 普通用户
        UserDetails normalUser = User.builder()
                .username("user")
                .password(this.passwordEncoder.encode("user_password"))
                .roles("USER") // ROLE_USER
                .build();

        return new InMemoryUserDetailsManager(adminUser, normalUser);
    }
}

上述代码在内存中创建了两个用户：admin和user，其中，admin角色为ADMIN，user角色为USER。

创建相应接口，区分用户使用：

// 管理员接口：/admin/**
@RestController
@RequestMapping("/admin")
public class AdminApi {

    @GetMapping
    public String showUserDetails() {
        // 返回用户详细信息
        return SecurityContextHolder.getContext().getAuthentication().getPrincipal().toString();
    }
}

// 普通用户接口：/user/**
@RestController
@RequestMapping("user")
public class UserApi {

    private List<String> users = Arrays.asList("David", "Roy", "Linda");

    @GetMapping
    public List<String> getUsers() {
        return this.users;
    }
}

配置 Spring Security，对不同角色的用户指定不同的资源访问权限：

@Configuration
public class SpringSecurityConfig extends WebSecurityConfigurerAdapter {

    @Override
    @Bean
    protected UserDetailsService userDetailsService() {
        ...
    }

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http.authorizeRequests()
                // 角色为 ADMIN 的用户才能访问接口 /admin/**
                .antMatchers("/admin/**").hasRole("ADMIN")
                // 角色为 ADMIN 和 USER 的用户都可以访问接口 /user/**
                .antMatchers("/user/**").hasAnyRole("ADMIN", "USER")
                .anyRequest().authenticated()
                .and()
                // HTTP Basic 认证
                .httpBasic();
    }
}

以上，我们就配置了相应角色的用户访问不同资源的权限，这里我们在终端进行访问，如下所示：

# user 可以访问 /user/**
$ curl -X GET 'localhost:8080/user' --user 'user:user_password'
["David","Roy","Linda"]%

# user 不能访问 /admin/**，因为 user 没有 ADMIN 角色
$ curl -X GET 'localhost:8080/admin' --user 'user:user_password'
{"timestamp":"2021-10-10T08:21:59.815+00:00","status":403,"error":"Forbidden","path":"/admin"}%                                     

# admin 可以访问 /user/**
$ curl -X GET 'localhost:8080/user' --user 'admin:admin_password'
["David","Roy","Linda"]%                                           

# admin 可以访问 /admin/**，因为有 ADMIN 角色
$ curl -X GET 'localhost:8080/admin' --user 'admin:admin_password'
org.springframework.security.core.userdetails.User [Username=admin, Password=[PROTECTED], Enabled=true, AccountNonExpired=true, credentialsNonExpired=true, AccountNonLocked=true, Granted Authorities=[ROLE_ADMIN]]%

上面例子中，ADMIN权限显然包含USER权限，因此我们上面在配置访问/user/**接口时，使用的是hasAnyRole("ADMIN","USER")，即只有用户角色是ADMIN或者USER其中一个即可访问，但是这里不能体现包含关系，此时可以使用 角色继承，让上级角色自动具备下级角色所有权限，因此这里我们可以配置ADMIN包含USER权限，如下所示：

@Configuration
public class SpringSecurityConfig extends WebSecurityConfigurerAdapter {

    // 角色继承
    @Bean
    RoleHierarchy roleHierarchy() {
        RoleHierarchyImpl hierarchy = new RoleHierarchyImpl();
        hierarchy.setHierarchy("ROLE_ADMIN > ROLE_USER");
        return hierarchy;
    }

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http.authorizeRequests()
                .antMatchers("/admin/**").hasRole("ADMIN")
                // USER 能访问的，ADMIN 就可以访问
                .antMatchers("/user/**").hasRole("USER")
                .anyRequest().authenticated()
                .and()
                .httpBasic();
    }
}

权限：某些资源可以设置为具备特定权限的用户才能访问。

举个例子：比如员工系统中，拥有read权限的用户可以读取员工资料，拥有write或create或delete权限的用户可以读取和修改员工资料，配置步骤如下：

创建对应用户权限：

@Configuration
public class SpringSecurityConfig extends WebSecurityConfigurerAdapter {

    @Autowired
    private PasswordEncoder passwordEncoder;

    @Override
    @Bean
    protected UserDetailsService userDetailsService() {
        // 管理员
        UserDetails adminUser = User.withUsername("admin")
                .password(this.passwordEncoder.encode("admin_password"))
                // 权限
                .authorities("create", "read", "update", "delete")
                .build();

        // 普通用户
        UserDetails normalUser = User.builder()
                .username("user")
                .password(this.passwordEncoder.encode("user_password"))
                // 权限
                .authorities("read")
                .build();

        return new InMemoryUserDetailsManager(adminUser, normalUser);
    }
}

上述代码为用户admin添加了create、read、update和delete权限，为用户user添加了只读权限read。

创建员工资料访问接口：

@RestController
@RequestMapping("user")
public class UserApi {

    // 模拟数据库
    private List<String> users = Stream.of("David","Roy","Linda").collect(Collectors.toList());

    @GetMapping
    public List<String> getUsers() {
        return this.users;
    }

    @GetMapping("/{userId}")
    public String getUser(@PathVariable("userId") Integer userId) {
        return this.users.get(userId);
    }

    @PostMapping
    public List<String> createUser(@RequestParam("name") String username) {
        System.out.println("username = " + username);
        this.users.add(username);
        return this.users;
    }

    @PutMapping("/{userId}")
    public String updateUser(@PathVariable("userId") Integer userId) {
        return this.users.get(userId) + " update successfully!";
    }

    @DeleteMapping("/{userId}")
    public String removeUser(@PathVariable("userId") Integer userId) {
        String oldUser = this.users.remove(userId.intValue());
        return String.format("delete %s successfully！", oldUser);
    }
}

上述的UserApi是遵循 Restful 风格的 API，模拟了对员工数据的增、删、改、查操作。

配置 Spring Security：

@Configuration
public class SpringSecurityConfig extends WebSecurityConfigurerAdapter {

    @Override
    @Bean
    protected UserDetailsService userDetailsService() {
        ...
    }

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        // 关闭 CSRF
        http.csrf().disable()
                .authorizeRequests()
                // 拥有 create，或者 update，或者 delete 权限就可以访问 /admin/**
                .antMatchers("/admin/**").hasAnyAuthority("create", "update", "delete")
                // 只有拥有 read 权限才能访问：GET /user/**
                .antMatchers(HttpMethod.GET, "/user/**").hasAuthority("read")
                // 只有拥有 create 权限才能上传用户： POST /user/**
                .antMatchers(HttpMethod.POST,"/user/**").hasAuthority("create")
                // 只有拥有 update 权限才能更新用户： PUT /user/**
                .antMatchers(HttpMethod.PUT,"/user/**").hasAuthority("update")
                // 只有拥有 delete 权限才能删除用户： DELETE /user/**
                .antMatchers(HttpMethod.DELETE,"/user/**").hasAuthority("delete")
                .anyRequest().authenticated()
                .and()
                .httpBasic();
    }
}

上述代码配置了admin用户具备/user/**和/admin/**的完全访问权限，而用户user的权限只能读取/user/**：

# user用户可读，因为具备 read 权限
$ curl -X GET 'localhost:8080/user' --user 'user:user_password'
["David","Roy","Linda"]%

# user用户不可写
$ curl -X POST 'localhost:8080/user' --data 'name=whyn' --user 'user:user_password'
{"timestamp":"2021-10-10T11:02:57.644+00:00","status":403,"error":"Forbidden","path":"/user"}%

# admin用户可读，因为具备 read 权限
$ curl -X GET 'localhost:8080/user' --user 'admin:admin_password'
["David","Roy","Linda"]%

# admin用户可写，因为具备 write 权限
$ curl -X POST 'localhost:8080/user' --user 'admin:admin_password' --data 'name=whyn'
["David","Roy","Linda","whyn"]%

# admin用户可修改，因为具备 update 权限
$ curl -X PUT 'localhost:8080/user/1' --user 'admin:admin_password'
Roy update successfully!%

# admin用户可删除，因为具备 delete 权限
$ curl -X DELETE 'localhost:8080/user/0' --user 'admin:admin_password'
delete David successfully！%

最后，Spring Security 中的角色role和权限authority底层实现上其实是一样的，源码如下所示：

// org\springframework\security\core\userdetails\User.java
public UserBuilder roles(String... roles) {
    List<GrantedAuthority> authorities = new ArrayList<>(roles.length);
    for (String role : roles) {
        Assert.isTrue(!role.startsWith("ROLE_"),
                () -> role + " cannot start with ROLE_ (it is automatically added)");
        // role 会添加前缀 ROLE_
        authorities.add(new SimpleGrantedAuthority("ROLE_" + role));
    }
    return authorities(authorities);
}

public UserBuilder authorities(String... authorities) {
    return authorities(AuthorityUtils.createAuthorityList(authorities));
}

可以看到，本质上role就是authority，只是存储的时候增加了前缀ROLE_。

注：这里有一个点需要注意，否则有大坑，User#hasRole和User#authorities内部最终都调用了方法User#authorities(Collection)，其源码如下：

// org\springframework\security\core\userdetails\User.java
public UserBuilder authorities(Collection<? extends GrantedAuthority> authorities) {
    // 更改指向
    this.authorities = new ArrayList<>(authorities);
    return this;
}

可以看到，User#authorities(Collection)内部会创建一个新的权限集合，赋值给User.authorities，所以，创建自定义用户时，不能同时使用User#roles和User#authorities，否则会导致相互覆盖，比如，User.builder().roles("xxx").authorities("yyy")，后面的yyy会覆盖掉xxx，导致实际上没有声明角色。如果要同时声明角色和权限，那么建议使用User#authorities方法，然后手动为角色添加前缀ROLE_即可，比如：

# 声明了角色 xxx 和权限 yyy
User.builder().authorities(“ROLE_xxx","yyy")

参考

附录

本篇博文所有例子源码可查看：Spring Security Demos

Spring Security应用详解
一、Spring Security集成SpringBoot Spring Boot提供spring-boot-st...
Spring Boot 集成 Spring Security 实
本文介绍 Spring Boot 集成 Spring Security 实现账号认证。 1. 创建 Spring ...
Shiro、Spring Security整合
Shiro、Spring Security Spring Boot 整合 Spring Security 快速上⼿...
Spring Boot整合Spring Security
Spring Boot对Spring Security的支持 Spring Boot针对Spring Securi...
Spring Security 之 Spring Boot 环境
Spring Security 之 Spring Boot 环境自动配置 Spring Security 在 Sp...
8.6 Spring Boot集成Spring Security
8.6 Spring Boot集成Spring Security 开发Web应用，对页面的安全控制通常是必须的。比...
《Spring Boot极简教程》第16章 Spring Boo
第16章 Spring Boot安全集成Spring Security 开发Web应用，对页面的安全控制通常是必须...
锱铢必较：在spring boot中使用神器防止CSRF攻击
在一个spring boot项目中，需要防止CSRF攻击，按理说应该集成spring security才对。但是...
Spring Boot系列--集成Elasticsearch
Spring Boot系列--集成Elasticsearch集成方式 Spring Boot中集成Elastics...
Spring boot 集成 Spring Security
1. pom.xml 2. 配置文件config 3. service 4. controller 5 . 启动...