[스프링 시큐리티 주요 아키텍쳐 이해] DelegatingFilterProxy, FilterChainProxy

서블릿 스펙에 정의된 Fliter는 Servlet Container에서 생성되고 실행된다.

따라서 Filter는 Spring Bean을 Injection받아 사용할 수 없다.

 

 

 

아래의 배경에 따라 DelegatingFilterProxy와 FilterChainProxy가 등장하게 된다.

1. Filter도 Spring Bean으로 편하게 등록하고 주입하고 싶다!
2. Filter도 Spring의 기술을 활용하고 싶다.

---

DelegatingFilterProxy - 서플릿 필터, FilterChainProxy - 필터 빈

두가지 클래스를 통해 두가지 요구사항을 충족할 수 있게 된다.

 

DelegatingFilterProxy는 서플릿 필터로써 약속된 이름 (springSecurityFilterChain)이라는 이름의 SpringBean을 ApplicationContext에서 찾아서 요청을 위임한다.

---

FilterChainProxy은 필터 빈으로써 internal class인 VirtualFilterChain을 통해 빈으로 등록된 Filter를 chain으로 엮어 관리한다.

 

FilterChainProxy.VirtualFilterChain의 additionalFilters

1.springSecurityFilterChain 의 이름으로 생성되는 필터 빈

 

2.DelegatingFilterProxy 으로 부터 요청을 위임 받고 실제 보안 처리

 

3.스프링 시큐리티 초기화 시 생성되는 필터들을 관리하고 제어

•스프링 시큐리티가 기본적으로 생성하는 필터

•설정 클래스에서 API 추가 시 생성되는 필터

 

4.사용자의 요청을 필터 순서대로 호출하여 전달

 

5.사용자정의 필터를 생성해서 기존의 필터 전.후로 추가 가능

•필터의 순서를 잘 정의

 

6.마지막 필터까지 인증 및 인가 예외가 발생하지 않으면 보안 통과

 

 

Proxy 패턴으로 구현된 Filter보안 처리

---

애플리케이션이 로딩되면

SecurityFilterAutoConfiguration은 DelegatingFilterProxy를 Bean으로 등록한다 이때 DelegatingFilterProxy가 요청을 위임할 targetBean의 이름 - springSecurityFilterChain을 생성자로 전달한다.

또한 WebSecurityConfiguration은 FilterChainProxy를 springSecurityFilterChain라는 이름의 빈으로 등록한다. 

 

위와같은 초기화 과정을 거친 후 요청이 들어오면 DelegatingFilterProxy가 요청을 받아 WebApplicationContext로부터 targetBeanName의 이름을 가진 빈을얻어 요청을 위임합니다.

 

이후에는 요청을 위임받은 FilterChainProxy가 FilterChain에 따라 보안처리를 진행합니다.