1. 개요
현재 프로젝트는 업무구분에 따라 WAS를 다르게 운용하고 있다.
이로 인해 WAS1 환경에서 캐싱처리를 하고 세션 내용을 수정하더라도, WAS2 환경에 반영이 안되는 현상이 발생하였다.
트래픽이나 여러 부분들을 고려하였을때 인메모리나 sticky session을 활용하여, 세션처리의 원자성도 보장할 수 있고 간편하게 세션의 정합성을 확보할 수 있겠지만 이미 오픈을 한 이후의 시점에서 해당 결함이 발견되었기에 best practice가 아니지만 안정성을 그나마 확보할 수 있는 방안을 마련하기 위해 고심하였다.
이 고민의 과정에서 배웠던 부분들을 기록하여 남긴다.
2. 스프링 시큐리티 실행 구조
인증, 인가와 같은 전역처리를 이해하기 위해 가장 먼저 알아야할 것은 "was"의 실행 구조이다.
이와 관련하여 자세하게 정리를 하였다.
was 구조 1
was 구조 2
이 과정을 이해한 후, 스프링 시큐리티 프레임워크를 바라보면 어느 시점에 전역적인 인증, 인가 과정을 넣어야 할 지 안목이 생긴다.
일단 개괄을 하면, 스프링 시큐리티의 doFilterInternal이나 doFilterChain, 즉 스프링 시큐리티 필터(체인)에 의한 인증/인가 처리는 WAS 관할의 필터 단계에서 연쇄적으로 함께 발생하는 전처리라 할 수 있겠다. 따라서 서블릿의 기술만 사용할 수 있고, 스프링에서 제공하는 기술은 사용할 수 없다.
DelegatingFilterProxy가 Servlet Container 로 전달하기 전, 전역 필터 단계에서 사용자 요청을 전달 받는다.
이때 DelegatingFilterProxy는 SpringSecurityFilterChain 이름으로 생성된 Bean 을 ApplicationContext(root spring container)에서 찾는데, 이게 쉽게 말하면 SpringSecurityConfig에서 빈으로 설정한 customFilter, filterChain 등을 실행한다는 의미이다.
인증처리 후에는 요청을 리다이렉트하는데, 현재 프로젝트에서는 genericFilterBean으로 설정되어 있으므로 이러한 리다이렉트가 일어나면서 인증요청이 또 발생한다.
이에 대한 중복요청을 방지할 수 있는 방안이 oneceperrequestfilter이라 하는데, 추후 자세히 알아보고자 한다.
3. 시큐리티 필터 실행 과정
- securityconfig에서 필터에 대한 빈설정을 한다.
- 빈이라는 것은 스프링 컨테이너가 실행되면서 같이 만들어지는데, 실행 또한 해당 빈객체를 생성하게 된다. 이 객체를 생성하는 시점에서 빈으로 등록한 필터를 실행하는데, 처음 프로그램을 실행하거나 요청이 들어와 생명주기를 거치게 되면 필터 로직을 실행한다. 따라서 빈에서 어떠한 필터를 실행할지 정의해야 한다.
- 스프링 시큐리티 설정 시 enablewebsecurity 설정을 해주어야 하며, 이후 필터링 로직 설정 시 BasicAuthenticationFilter 등 추상클래스를 상속받아 doFilter를 오버라이드하여 구성해주면 된다.
- 설정정보와 필터링 정보에 따라 전역 혹은 서블릿 컨테이너 상의 인증 및 인가처리가 진행된다.
4. 필터에 의한 전역처리를 할 것인가, 인터셉터에 의한 전역처리를 할 것인가
필터와 인터셉터는 실행시점, 관할이 다르므로 차이점을 잘 생각해가면서 인증처리를 구성해야겠다.
특히 필터는 was관할이긴 하지만 서블릿 컨테이너 이전의 시점이므로 사용자 요청에 대한 정보(httpservletrequest)를 얻을 수 없다.
사용자 요청 정보가 필요한가, 전역적으로 필요한가 등에 대해 생각하면서 전역처리를 구성해주는 것이 좋을 것이다.
5. 참고자료
스프링 시큐리티 체인 필터 - https://velog.io/@choidongkuen/Spring-Security-Spring-Security-Filter-Chain-%EC%97%90-%EB%8C%80%ED%95%B4
필터와 인터셉터 - https://velog.io/@zooyeop/Spring-Dispatcher-ServletFilterInterceptor-1
