요청에 따른 접근 구조
참고 : https://docs.spring.io/spring-security/reference/servlet/architecture.html
스프링 시큐리티를 사용하지 않는 경우
클라이언트로부터 요청이 들어오면 서버는 바로 서블릿을 응답하는 대신, 중간의 서블릿 필터들을 거친다. 이 필터들로부터 인증과 인가의 과정이 포함되고, 필터들은 거친 후에야 서블릿을 제공할지 결정하게 된다.
이 방식에서는 각각의 필터 호출 여부가 오로지 URL만을 기반으로 결정된다.
스프링 시큐리티를 사용하는 경우
스프링 시큐리티를 사용하면, 서블릿 필터 중간에 DelegatingFilterProxy 필터가 존재한다. DelegatingFilterProxy는 WAS의 서블릿 컨테이너와, 스프링 컨테이너 간의 연결고리가 된다.
DelegatingFilterProxy 내부에는 스프링 빈으로 등록되는 FilterChainProxy가 있다. FilterChainProxy는 스프링 시큐리티 필터들을 사용하기 위해 SecurityFilterChain에 위임할 수 있게끔 한다.
SecurityFilterChain는 FilterChainProxy가 현재 요청으로부터 어떤 시큐리티 필터를 호출할지 결정할 때 사용된다. SecurytiyFilterChain 내부의 Security Filter들은 일반적으로 FilterChainProxy가 등록될 때 함께 빈으로 등록된다.
시큐리티 필터를 바로 서블릿 필터 체인에 등록할 수도 있지만 그렇게 하지 않는 이유는, 스프링 빈으로 관리될 수 없기 때문이다.
서블릿 필터들 중 하나인 DelegatingFilterProxy 역시 스프링 빈으로 관리될 수 없기 때문에, 이 안에 스프링 빈으로 관리될 수 있는 FilterChainProxy를 둔다. 그리고 FilterChainProxy에 의하여 SecurityFilterChain이 관리된다.
FilterChainProxy 사용 상 이점
- 스프링 시큐리티의 모든 서블릿 지원의 시작점이 된다.
스프링 시큐리티의 서블릿 지원 오류 발생 시, 디버그 지점을 FilterChainProxy로 잡으면 된다. (스프링 빈으로 관리되기 때문에 가능함) - FilterChainProxy가 스프링 시큐리티 사용의 중심이 되기 때문에, 이와 관련된 작업들은 부가적인 것이 아닌 반드시 거치야 하는 작업들로 간주된다.
시큐리티 컨텍스트의 메모리 누수를 방지할 수 있고, 어플리케이션이 어떤 종류의 공격에서든 보호받을 수 있도록 HttpFirewall을 적용해주기도 한다.
추가적으로, 언제 SecurityFilterChain이 호출될 지 결정하는 것과 관련하여 큰 유연성을 제공한다. 서블릿 컨테이너에서는 필터는 URL만을 기반으로 적용 여부가 결정됐다. 하지만 FilterChainProxy는 HttpServletRequest 내부의 무엇이든 기반으로 해서 필터 적용 여부를 결정할 수 있다. 이때 RequestMatcher 인터페이스를 사용한다.
