Spring Security Oauth2 无法访问到资源服务接口问题分析

最新推荐文章于 2024-09-10 16:16:38 发布

oPeiJie1

最新推荐文章于 2024-09-10 16:16:38 发布

阅读量1.8k

点赞数

分类专栏： Security 文章标签： spring boot 后端 java

本文链接：https://blog.csdn.net/oPeiJie1/article/details/130087477

版权

Security 专栏收录该内容

8 篇文章 1 订阅

订阅专栏

文章详细介绍了在SpringSecurityOauth2环境下，如何配置资源服务，包括采用RemoteTokenService进行token验证，以及资源服务测试接口的设定。在测试过程中遇到的问题是未授权的接口被Oauth2拦截，通过调整过滤器链匹配规则和添加Security配置，解决了这个问题。重点强调了资源路径配置和过滤器链顺序对授权的影响。

摘要由CSDN通过智能技术生成

1.情况说明

在搭建认证服务器，完成Spring Security Oauth2的四种模式的获取token的测试后，预示着我们已经将认证服务器搭建成功，紧接着我们搭建了一个用于测试的资源服务。相关的配置和测试接口如下。

1.1.资源服务配置

配置当前资源服务的信息；
配置当前资源服务验证token的方式。

@Configuration
@EnableResourceServer
//激活方法上的PreAuthorize注解
@EnableGlobalMethodSecurity(prePostEnabled = true, securedEnabled = true)
public class ResourceServerConfig extends ResourceServerConfigurerAdapter {
    //公钥
    private static final String RESOURCE_ID = "eden-life";


    /**
     * 资源服务的安全配置
     *
     * @param resources
     * @throws Exception
     */
    @Override
    public void configure(ResourceServerSecurityConfigurer resources) throws Exception {
        resources
                .resourceId(RESOURCE_ID)
                .tokenServices(tokenServices())
                .stateless(true);
    }

    /***
     * 配置资源服务的令牌验证服务
     * @return
     */
    @Bean
    public ResourceServerTokenServices tokenServices() {
        RemoteTokenServices tokenServices = new RemoteTokenServices();
        tokenServices.setCheckTokenEndpointUrl("http://localhost:9949/oauth/check_token");
        tokenServices.setClientId("eden");
        tokenServices.setClientSecret("eden");
        return tokenServices;
    }
}

这里采用RemoteTokenService请求远端认证服务器的方式进行token的校验。因为我们资源服务和认证服务并不是在同一个服务里，而是分开的；我们也没有使用JWT来生成token，token只是随机的UUID字符串，没有包含用户信息等。

如果在一起，那我们可以使用DefaultTokenService的token服务方式。

1.2.资源服务的测试接口

我们提供两个测试接口，第一个是需要经过鉴权才可以访问的；第二个没有设置访问权限。

@RestController
@RequestMapping
public class TestController {

    @GetMapping("/life/test/test1/{str}")
    @PreAuthorize("hasAnyAuthority('admin')")
    public String test(@PathVariable String str) {
        return str;
    }

    @GetMapping("/life2/test/test2/{str}")
    public String test2(@PathVariable String str) {
        return str;
    }
}

1.3.问题

按照正常理解，上面两个接口应该分别如此访问：

第一个接口，请求头需要携带token，且用户的权限里应该包含admin 权限；
第二个接口，可以直接访问，无需任何授权。

我们来测试一下。

2.测试

2.1.接口一

和猜测的一样，我们携带token顺利请求到了资源接口。

2.2.接口二

是不是有些意外？我们被Oauth2拦截了。

2.2.1.增加安全访问的限制策略

这里增加的配置的意思是，当前资源服务只有与/life/**路径相匹配的请求才会由Oauth2的过滤器链进行处理，其他请求路径不由Oauth2的过滤器链进行处理。

    /**
     * Http安全配置，对每个到达系统的http请求链接进行校验
     *
     * @param http
     * @throws Exception
     */
    @Override
    public void configure(HttpSecurity http) throws Exception {
        http
                //限制资源服务直接管/life/**匹配的路径
                .requestMatchers().antMatchers("/life/**")
                .and()
                .authorizeRequests()
                .antMatchers("/life/**").authenticated()
                .anyRequest().permitAll();
    }

再次进行测试：

因为经过我们上一步的配置，Oauth2的过滤器链并不处理/life2的请求，所以这次使用的过滤器链其实是Security的过滤器链，在这个过滤器链中，抛出了AccessDeniedException。所以这一次，我们是被Security拦截了。既然如此，那我们就增加Security的配置。

正常配置资源服务一般是需要Security配置的，我们只是为了引出来这个知识点，所以在一开始并未做这个配置。

2.2.2.增加Security配置

@Configuration
@EnableGlobalMethodSecurity(prePostEnabled = true)
public class LifeWebSecurityConfig extends WebSecurityConfigurerAdapter {

    /**
     * 配置http安全拦截机制
     *
     * @param http
     * @throws Exception
     */
    @Override
    public void configure(HttpSecurity http) throws Exception {
        http.csrf().disable()
                .authorizeRequests()
                // /life/**的请求必须认证通过
                .antMatchers("/life/**").authenticated()
                .anyRequest().permitAll();
    }
}

再次测试，我们发现已经可以访问到资源接口了。

为什么加了一个Security的配置就可以访问资源接口了呢？我们就来分析这个。

3.Debug分析

我们配置security和Oauth2的配置时，分别继承了一个Adapter，即WebSecurityConfigurerAdapter与ResourceServerConfigurerAdapter。下面借用一下一篇博文中的片段。

他们其实本质就是Adapter，只是二者所属的功能模块不同，而且二者的加载顺序是不一样的。

ResourceServerConfigurerAdapter是优先于WebSecurityConfigurerAdapter(这个特点要记住后面会用到，当然了这个顺序也是可以修改的！这个默认加载顺序情况下先加载的Adapter在处理相同路径情况下会覆盖后续加载的路径，造成后加载的失效！)，那么我们这里WebSecurityConfigurerAdapter和ResourceServerConfigurerAdapter都存在那么我们系统中就会有两个Adapter，我们每声明一个*Adapter类，都会产生一个filterChain。

一个request（匹配url）只能被一个filterChain处理，这就解释了为什么二者Adapter同时在的时候处理相同请求路径时，后者默认为什么会失效的原因。我们可以在FilterChainProxy中的getFilters(HttpServletRequest request)方法中可以看到有哪些filter chain，并处理哪些url。

当发出接口二的请求时，我们可以在FilterChainProxy中看到有两个过滤器链。第一个是Oauth2的，第二个是security的，并且第一个可以拦截处理的路径为/life/**，第二个是拦截所有请求。Oauth2的过滤器链是在前面的。