如何讓 Spring Security 「少管閒事」

mzlogin發表於2021-12-26

記兩種讓 Spring Security「少管閒事」的方法。

遇到問題

一個應用對外提供 Rest 介面,介面的訪問認證通過 Spring Security OAuth2 控制,token 形式為 JWT。因為一些原因,某一特定路徑字首(假設為 /custom/)的介面需要使用另外一種自定義的認證方式,token 是一串無規則的隨機字串。兩種認證方式的 token 都是在 Headers 裡傳遞,形式都是 Authorization: bearer xxx

所以當外部請求這個應用的介面時,情況示意如下:

這時,問題出現了。

我通過 WebSecurityConfigurerAdapter 配置 Spring Security 將 /custom/ 字首的請求直接放行:

httpSecurity.authorizeRequests().regexMatchers("^(?!/custom/).*$").permitAll();

但請求 /custom/ 字首的介面仍然被攔截,報瞭如下錯誤:

{
  "error": "invalid_token",
  "error_description": "Cannot convert access token to JSON"
}

分析問題

從錯誤提示首先可以通過檢查排除掉 CustomWebFilter 的嫌疑,自定義認證方式的 token 不是 JSON 格式,它裡面自然也不然嘗試去將其轉換成 JSON。

那推測問題出在 Spring Security 「多管閒事」,攔截了不該攔截的請求上。

經過一番面向搜尋程式設計和原始碼除錯,找到丟擲以上錯誤資訊的位置是在 JwtAccessTokenConverter.decode 方法裡:

protected Map<String, Object> decode(String token) {
    try {
        // 下面這行會丟擲異常
        Jwt jwt = JwtHelper.decodeAndVerify(token, verifier);
        // ... some code here
    }
    catch (Exception e) {
        throw new InvalidTokenException("Cannot convert access token to JSON", e);
    }
}

呼叫堆疊如下:

從呼叫的上下文可以看出(高亮那一行),執行邏輯在一個名為 OAuth2AuthenticationProcessingFilter 的 Filter 裡,會嘗試從請求中提取 Bearer Token,然後做一些處理(此處是 JWT 轉換和校驗等)。這個 Filter 是 ResourceServerSecurityConfigurer.configure 中初始化的,我們的應用同時也是作為一個 Spring Security OAuth2 Resource Server,從類名可以看出是對此的配置。

解決問題

找到了問題所在之後,經過自己的思考和同事間的討論,得出了兩種可行的解決方案。

方案一:讓特定的請求跳過 OAuth2AuthenticationProcessingFilter

這個方案的思路是通過 AOP,在 OAuth2AuthenticationProcessingFilter.doFilter 方法執行前做個判斷

  1. 如果請求路徑是以 /custom/ 開頭,就跳過該 Filter 繼續往後執行;
  2. 如果請求路徑非 /custom/ 開頭,正常執行。

關鍵程式碼示意:

@Aspect
@Component
public class AuthorizationHeaderAspect {
    @Pointcut("execution(* org.springframework.security.oauth2.provider.authentication.OAuth2AuthenticationProcessingFilter.doFilter(..))")
    public void securityOauth2DoFilter() {}

    @Around("securityOauth2DoFilter()")
    public void skipNotCustom(ProceedingJoinPoint joinPoint) throws Throwable {
        Object[] args = joinPoint.getArgs();
        if (args == null || args.length != 3 || !(args[0] instanceof HttpServletRequest && args[1] instanceof javax.servlet.ServletResponse && args[2] instanceof FilterChain)) {
            joinPoint.proceed();
            return;
        }
        HttpServletRequest request = (HttpServletRequest) args[0];
        if (request.getRequestURI().startsWith("/custom/")) {
            joinPoint.proceed();
        } else {
            ((FilterChain) args[2]).doFilter((ServletRequest) args[0], (ServletResponse) args[1]);
        }
    }
}

方案二:調整 Filter 順序

如果能讓請求先到達我們自定義的 Filter,請求路徑以 /custom/ 開頭的,處理完自定義 token 校驗等邏輯,然後將 Authorization Header 去掉(在 OAuth2AuthenticationProcessingFilter.doFilter 中,如果取不到 Bearer Token,不會拋異常),其它請求直接放行,也是一個可以達成目標的思路。

但現狀是自定義的 Filter 預設是在 OAuth2AuthenticationProcessingFilter 後執行的,如何實現它們的執行順序調整呢?

在我們前面找到的 OAuth2AuthenticationProcessingFilter 註冊的地方,也就是 ResourceServerSecurityConfigurer.configure 方法裡,我們可以看到 Filter 是通過以下這種寫法新增的:

@Override
public void configure(HttpSecurity http) throws Exception {
    // ... some code here
    http
        .authorizeRequests().expressionHandler(expressionHandler)
    .and()
        .addFilterBefore(resourcesServerFilter, AbstractPreAuthenticatedProcessingFilter.class)
        .exceptionHandling()
            .accessDeniedHandler(accessDeniedHandler)
            .authenticationEntryPoint(authenticationEntryPoint);
}

核心方法是 HttpSecurity.addFilterBefore,說起 HttpSecurity,我們有印象啊……前面通過 WebSecurityConfigurerAdapter 來配置請求放行時入參是它,能否在那個時機將自定義 Filter 註冊到 OAuth2AuthenticationProcessingFilter 之前呢?

我們將前面配置放行規則處的程式碼修改如下:

// ...
httpSecurity.authorizeRequests().registry.regexMatchers("^(?!/custom/).*$").permitAll()
        .and()
        .addFilterAfter(new CustomWebFilter(), X509AuthenticationFilter.class);
// ...

注: CustomWebFilter 改為直接 new 出來的,手動新增到 Security Filter Chain,不再自動注入到其它 Filter Chain。

為什麼是將自定義 Filter 新增到 X509AuthenticationFilter.class 之後呢?可以參考 spring-security-config 包的 FilterComparator 裡預置的 Filter 順序來做決定,從前面的程式碼可知 OAuth2AuthenticationProcessingFilter 是新增到 AbstractPreAuthenticatedProcessingFilter.class 之前的,而在 FilterComparator 預置的順序裡,X509AuthenticationFilter.class 是在 AbstractPreAuthenticatedProcessingFilter.class 之前的,我們這樣新增就足以確保自定義 Filter 在 OAuth2AuthenticationProcessingFilter 之前。

做了以上修改,自定義 Filter 已經在我們預期的位置了,那麼我們在這個 Filter 裡面,對請求路徑以 /custom/ 開頭的做必要處理,然後清空 Authorization Header 即可,關鍵程式碼示意如下:

@Override
public void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain filterChain) throws IOException, ServletException {
    HttpServletRequest request = (HttpServletRequest) servletRequest;
    if (request.getServletPath().startsWith("/custom/")) {
        // do something here
        // ...
        final String authorizationHeader = "Authorization";
        HttpServletRequestWrapper requestWrapper = new HttpServletRequestWrapper((HttpServletRequest) servletRequest) {
            @Override
            public String getHeader(String name) {
                if (authorizationHeader.equalsIgnoreCase(name)) {
                    return null;
                }
                return super.getHeader(name);
            }

            @Override
            public Enumeration<String> getHeaders(String name) {
                if (authorizationHeader.equalsIgnoreCase(name)) {
                    return new Vector<String>().elements();
                }
                return super.getHeaders(name);
            }
        };
        filterChain.doFilter(requestWrapper, servletResponse);
    } else {
        filterChain.doFilter(servletRequest, servletResponse);
    }
}

小結

經過嘗試,兩種方案都能滿足需求,專案裡最終使用了方案一,相信也還有其它的思路可以解決問題。

經過這一過程,也暴露出了對 Spring Security 的理解不夠的問題,後續需要抽空做一些更深入的學習。

參考

相關文章