前言
最近存在这样的一个问题, 大致的复现方式是 访问 /oauth/token 接口, 然后不携带任何参数, 结果 服务器抛出了一个 "401 Unauthorized"
针对这个 401, 这里 梳理一下这个流程, 也会衍生出一些其他的问题
测试用例
客户端这边大致的情况是 构造参数, 然后发送请求, 上面两个 参数封装到查询字符串的请求是可以正常处理
后面两个 未携带参数 的请求发送, 报错 "401 Unauthorized"
我们这里主要关心 这里的未携带参数 的异常场景, 以及 造成这个问题的整个流程
3. 具体的 ignore-urls 的业务层面的使用
主要是在 FilterSecurityInterceptor, 这里面我们核心需要关注几个部分
3.1 this.obtainSecurityMetadataSource().getAttributes(object) 根据当前 request 获取认证属性
3.2 Authentication authenticated = authenticateIfRequired(); 根据请求头里面拿到的 token, 访问 auth 服务, 获取用户以及关联信息, 封装 Authentication
3.3 accessDecisionManager.decide 结合 认证属性 和 Authentication 来判断是否有权限
/*** Test11TestRestClient** @author Jerry.X.He* @version 1.0* @date 2022/5/19 17:44*/
public class Test11TestRestClient {/// Test11TestRestClientpublic static void main(String[] args) {String username = "xxx";String password = "xxx";String grantType = "password";Map<String, String> queryParams = new LinkedHashMap<>();queryParams.put("username", username);queryParams.put("password", password);queryParams.put("grant_type", grantType);queryParams.put("scope", "server");queryParams.put("client_id", "xxx");queryParams.put("client_secret", "xxx");RestTemplate restTemplate = new RestTemplate();String queryString = Tools.encapQueryString(queryParams);// String loginUrl = "http://10.60.50.50:9999/auth/oauth/token?" + queryString;
// Map result = restTemplate.postForObject(loginUrl, null, Map.class);
// Map result = restTemplate.getForObject(loginUrl, Map.class);String loginUrl = "http://10.60.50.50:9999/auth/oauth/token";Map result = restTemplate.postForObject(loginUrl, null, Map.class);// todo, getForObject 的时候 查询字符串 未拼接 到 uri 中
// Map result = restTemplate.getForObject(loginUrl, Map.class, queryParams);int x = 0;}}
问题的调试
来到认证被拒绝的地方, 可以看到的是 /oauth/token 请求是需要 fullyAuthenticated 的
fullyAuthenticated 的条件是 不是匿名用户 并且 xxx, 这里我们的 authentication 因为没有携带参数信息, 然后 匿名过滤器填充了一个 匿名的 authentication
假设是在客户端正常携带了参数的场景下面, 是怎么过验证的呢?
这里走的是 ClientCredentialsTokenEndpointFilter 走的一个 自定义的处理, 获取认证信息, 这里能够正常的拿到认证信息, 因此能够正常认证通过
我准备临时处理一下, 去掉 /oauth/token 的需要认证的处理, 于是在 WebSecurityConfigurer 中增加了 antMatchers("/oauth/token").permitAll() 但是, 从 this.obtainSecurityMetadataSource().getAttributes(object) 拿到的 attributes 还是 fullyAuthenticated, 而不是我这里配置的 permitAll
我们这里会出现几点疑问
- 为什么 /oauth/token 配置的是 fullyAuthenticated
- 为什么 我配置了 antMatchers("/oauth/token").permitAll(), 但是没有生效
为什么 /oauth/token 配置的是 fullyAuthenticated
AuthorizationServerSecurityConfiguration 中 init 的时候初始化的时候配置 /oauth/token 为 fullyAuthenticated
AuthorizationServerSecurityConfiguration 是继承自 SecurityConfigurer, 是 spring-security 中自带的 XXConfiguration, 业务上面的限定 一般还存在一个 WebSecurityConfigurer
为什么 我配置了 antMatchers("/oauth/token").permitAll(), 但是没有生效
这里 AuthorizationServerSecurityConfiguration 的限定的是 "/oauth/token", "/oauth/token_key", "/oauth/check_token"
WebSecurityConfigurer 限定的是 其他的业务上的大部分的请求, 我这里添加了一个 /oauth/token -> permitAll 但是没有生效
这里需要 回溯一下 FilterSecurityInterceptor 的这一系列的整个流程
这里 正向剖析一下这个流程, 反向回溯的过程 着实开销不小
WebSecurityConfiguration.springSecurityFilterChain 创建了一个 FilterChainProxy, 注册于 spring 容器中
并且添加到了 tomcat 的 applicationFilterChain, 因此和具体的 http 请求处理 的 TokenEndpoint 处理的过程关联起来
向 tomcat 的 applicationFilterChain 添加 filterDef 的地方来自于 SecurityFilterAutoConfiguration.securityFilterChainRegistration, 增加了一个 DelegatingFilterProxyRegistrationBean
这里 FilterChainProxy 内部组合了三个 filterChain, 然后根据 request 获取实际处理的 filterChain, 构建 filter 责任链来处理 请求, 构建了一个 VirtualFilterChain, 在 tomcat 的 filter 责任链的基础上, 又嵌套了一层 filter责任链
这里 我们的 /oauth/token, 匹配到了 第二个 filterChain, oauth/token 对应的策略为 fullyAuthenticated
第一个 filterChain 对应的是 WebSecurityConfigurer 中 构建的一个 ignoring 的策略
第二个 filterChain 对应的是 AuthorizationServerSecurityConfiguration 构建的一个 filterChain , 其中 /oauth/token 对应的策略为 fullyAuthenticated
第三个 filterChain 对应的是 业务系统中自定义的 WebSecurityConfigurer 构建的一个 filterChain, 其中 /oauth/token 对应的策略为 permitAll
构建这个 FilterChainProxy 的过程是在 WebSecurity. performBuild 的过程中, 先添加的 ignoring, 然后再添加的 各个 WebSecurityConfigurer 构建的 securityFilterChainBuilder
梳理一下构建 FilterChainProxy 的整个流程
- WebSecurityConfiguration.springSecurityFilterChain 中创建了 WebSecurity, WebSecurity.build 创建了 tomcat 这边接入的 FilterChainProxy
- 这个 WebSecurity 组合了 applicationContext 中的 SecurityConfigurer, SecurityConfigurer 生成一个 HttpSecurity, HttpSecurity.build 会创建一个 DefaultFilterChain, 对应于 FilterChainProxy 组合的多个 DefaultFilterChain
- 在 WebWecurity init 的过程中, 各个 SecurityConfigurer 构建了相应的 HttpSecurity 然后注册到 WebWecurity 中, 这个过程会回调 SecurityConfigurer.configure(HttpSecurity http)
- 在 WebWecurity configure 的过程中, 会回调各个 SecurityConfigurer 的 configure(WebSecurity web)
- 在 WebWecurity performBuild 的过程中, 会构建 FilterChainProxy, 它组合了一系列的 DefaultFilterChain, 这个过程参见 WebWecurity.performBuild, 具体的方式是 组合 WebWecurity 下面的 HttpSecurity 来构建 DefaultFilterChain
3.1 HttpSecurity performBuild 的过程中, 是直接根据已经采集的 filter 列表, 构建 DefaultFilterChain
3.2 HttpSecurity 的已经采集的 filter 是来自于 HttpSecurity 下面的 configurers 在 init, configure 的过程中处理进去的
3.3 HttpSecurity 下面的各个 configurers 来自于 SecurityConfigurer 的 configure(HttpSecurity http) 的过程中的相关业务处理, 诸如 '.authorizeRequests().antMatchers("/token/**", "/actuator/**", "/sso/**", "/test/**", "/oauth/token").permitAll()', '.formLogin().loginPage("/token/login").loginProcessingUrl("/token/form")', ".authorizeRequests()" 的相关是配置的就是请求认证的相关配置
以上一系列流程主要的目的是 为 FilterSecurityInterceptor 中的 this.obtainSecurityMetadataSource().getAttributes(object) 服务
- 请求来了之后, 走 FilterChainProxy, FilterChainProxy 选择当前 request 需要使用的 DefaultFilterChain
- DefaultFilterChain 中组合了一个责任链, 其中 FilterSecurityInterceptor 包含了如下认证步骤, 也是认证的相关问题核心需要关注的地方
引用自 "20220321_01 配置了 security.oauth2.client.ignore-urls 但是访问配置的服务依然 "用户信息已过期或已更新，请重新登录" 问题"
3. 具体的 ignore-urls 的业务层面的使用
主要是在 FilterSecurityInterceptor, 这里面我们核心需要关注几个部分
3.1 this.obtainSecurityMetadataSource().getAttributes(object) 根据当前 request 获取认证属性
3.2 Authentication authenticated = authenticateIfRequired(); 根据请求头里面拿到的 token, 访问 auth 服务, 获取用户以及关联信息, 封装 Authentication
3.3 accessDecisionManager.decide 结合 认证属性 和 Authentication 来判断是否有权限
另外还有一个细节是 可以看到拿到的 filterChain, 相比于我们 SecurityConfigurer 的 configure(HttpSecurity http) 中配置的处理会多一些
这部分 filter 来自于 SecurityConfigurer.getHttp 的过程中初始化的一部分 Configurer, 诸如 AnonymousAuthenticationFilter, ExceptionTranslationFilter 等等
getForObject 的时候 查询字符串 未拼接 到 uri 中
这个是 对于 getForObject 的 uriVariables 的理解存在问题
这里的 uriVariables 对应于 uri 中的一部分模板, 而不是 我们常规理解的 get 请求中交互的参数
完
