Spring Security의 Filter 🔒

Jimin Lim·2022년 6월 27일

Spring

목록 보기

2/17

어떠한 요청이 들어왔을 때, 헤더에 담긴 jwt의 유효성 판별을 하는 로직이 공통적으로 필요로 한다. Spring security의 경우에는 Filter chain을 제공해 이와 같은 로직을 처리한다.
이때 요청이 들어오면서 유효성을 검사하는 위치가 어디인지, 구체적으로 파악하고자 하였다.

✅ DispatcherServlet

Front Controller 로써, 클라이언트로부터 요청이 온다면 모든 요청을 먼저 받고 그 요청들을 세부 컨트롤러로 위임한다.

요청이 들어왔을 때의 순서는 아래와 같다.

클라이언트 요청을 디스패처 서블릿이 받는다.
Handler Mapping이 request를 처리하기에 적절한 handler를 찾는다.
컨트롤러로 위임할 handler adapter를 찾아서 전달한다.
handler adapter가 컨트롤러로 요청을 위임한다.
비지니스 로직 처리한다.
컨트롤러가 값을 반환한다.
handler adapter가 반환 값을 처리한다.
서버의 응답을 클라이언트로 반환한다.

여기서 바로 controller를 호출하지 않고, handler adapter라는 것을 통해 controller를 호출한다. 그 이유는 @RequestParam, @RequestBody 등을 처리하기 위한 ArgumentResolver들과, 응답 시에 ResponsEntity의 Body를 json으로 직렬화하는 ReturnValueHandler들이 어댑터를 통해 처리되기 때문이다.

✅ Filter vs Interceptor

공통 관심사를 처리한다는 점에서 interceptor와 유사해 함께 정리해 보았다.

필터는 DispatcherServlet 이전에 실행이 되며, Spring 범위 밖에서 처리가 되는 것이다. 즉, 스프링 컨테이너가 아닌 웹 컨테이너에 의해 관리가 되는 것이다.

인터셉터는 Spring이 제공하는 기술로, Dispatcher Servlet이 컨트롤러를 호출하기 전과 후에 처리를 할 수 있다. 위에서 Dicpoatcher Servlet은 핸들러 매핑을 통해 적절한 컨트롤러를 찾도록 요청한다고 하였는데, 이때 찾은 후 실행 체인이라는 것을 돌려준다. 이 실행 체인은 1개 이상의 인터셉터가 등록되어 있다면 순차적으로 인터셉터들을 거쳐 컨트롤러가 실행되도록 하고, 인터셉터가 없다면 바로 컨트롤러가 실행되도록 한다.

🔗 사용 용도

필터는 스프링과 무관하게 전역적으로 처리해야 하는 작업들을 처리할 때 사용 한다. 인터셉터보다 앞단에서 동작하므로 전역적으로 해야하는 보안 검사를 해, 올바른 요청이 아닐 경우 차단을 할 수 있으며 이는 스프링 컨테이너까지 요청이 전달되지 못하고 차단되어 안정성을 높일 수 있다.

인터셉터는 컨트롤러로 넘어가기 전, 검사해야하는 로직을 처리하기에 적합하다. 또한 스프링과 연관이 많은 작업을 하기 쉬우며 주로 빈 호출에 대한 로깅이 있다.

✅ Spring Security에서의 Filter

위의 내용을 요약하자면 dispatcher servlet에 도달하기 전, 필터를 거쳐야한다는 것이다.
spring security는 필터들을 체인으로 엮는 구조를 가지며, DelegatingFilterProxy라는 필터를 만들어 메인 Filter Chain에 끼워 넣고 그 아래 SecurityFilterChain 그룹을 등록하도록 한다.

WebSecurityConfigurerAdapter 클래스를 상속받아 Filter Chain을 구성할 수 있으며, configure(HttpSecurity http)를 override해 특정 url 매핑을 통한 권한 설정, filter 세팅 등을 수행할 수 있다.