[Spring] Spring Security의 웹 요청 처리 흐름

 Spring Security를 애플리케이션에 적용하는데 어려움을 겪는 가장 큰 이유 중 하나는 Spring Security의 아키텍쳐와 Spring Security의 컴포넌트들이 어떻게 인터랙션해서 인증, 권한 등의 보안 작업을 처리하는지 이해하지 못하기 때문이다. 그리고 이러한 Spring Security의 동작 방식을 조금 더 잘 이해하기 위해서는 보호된 웹 요청을 처리하는 일반적인 처리 흐름과 Spring Security에서 지원하는 Filter의 역할을 이해하는 것이 선행되어야 한다. 따라서 오늘은 Spring Seucrity의 웹 요청 처리 과정 중에서 가장 기본이 되는 웹 요청의 일반적인 흐름과 Spring Security에서 지원하는 Filter의 역할에 대해 알아보겠다.

보안이 적용된 웹 요청의 일반적인 처리 흐름

Spring Security의 웹 요청 처리를 이해하기 위해서 알아두어야 할 부분은 먼저 보안이 적용된 웹 요청의 일반적인 흐름이다.

[그림 1] 보안이 적용된 웹 요청의 일반적인 처리 흐름

보안이 적용된 웹 요청은 일반적으로 위와 같은 처리 흐름을 가진다.

(1)에서 사용자가 보호된 리소스를 요청한다.
(2)에서 인증 관리자 역할을 하는 컴포넌트가 사용자의 크리덴셜(Credential)을 요청한다. 사용자의 크리덴셜(Credential)이란 해당 사용자를 증명하기 위한 구체적인 수단을 의미한다. 일반적으로는 사용자의 패스워드가 크리덴셜에 해당한다.
(3)에서 사용자는 인증 관리자에게 크리덴셜(Credential)을 제공한다.
(4)에서 인증 관리자는 크리덴셜 저장소에서 사용자의 크리덴셜을 조회한다.
(5)에서 인증 관리자는 사용자가 제공한 크리덴셜과 크리덴셜 저장소에 저장된 크리덴셜을 비교해 검증 작업을 수행한다.
(6) 유효한 크리덴셜이 아니라면 Exception을 throw한다.
(7) 유효한 크리덴셜이라면 (8)에서 접근 결정 관리자 역할을 하는 컴포넌트는 사용자가 적절한 권한을 부여받았는지 검증한다.
(9) 적절한 권한을 부여 받지 못한 사용자라면 Exception을 throw한다.
(10) 적절한 권한을 부여 받은 사용자라면 보호된 리소스의 접근을 허용한다.

웹 요청에서의 서블릿 필터와 필터 체인의 역할

 [그림 1]에서 사용자의 웹 요청이 Controller 같은 엔드포인트를 거쳐 접근하려는 리소스에 도달하기 전에 인증 관리자나 접근 결정 관리자 같은 컴퍼넌트가 중간에 웹 요청을 가로채 사용자의 크리덴셜과 접근 권한을 검증하는 것을 볼 수 있다. 이처럼 서블릿 기반 애플리케이션의 경우에는 애플리케이션의 엔드포인트에 요청이 도달하기 전에 중간에서 요청을 가로챈 후 어떤 처리를 할 수 있는 적절한 포인트를 제공하는데 그것은 바로 서블릿 필터(Servlet Filter)이다. 서블릿 필터는 자바에서 제공하는 API이며, javax.servlet 패키지에 인터페이스 형태로 정의되어 있다. javax.servlet.Filter 인터페이스를 구현한 서블릿 필터는 웹 요청을 가로채어 어떤 처리(전처리)를 할 수 있으며, 또한 엔드포인트에서 요청 처리가 끝난 후 전달되는 응답을 클라이언트에게 전달하기 전에 어떤 처리(후처리)를 할 수 있다. 서블릿 필터는 하나 이상의 필터들을 연결해 필터 체인(Filter Chain)을 구성할 수 있다.

[그림 2] Servlet Filter Chain의 구성도

그림은 Spring Framework의 DispatcherServlet에 클라이언트의 요청이 전달되기 전에 필터 체인(Filter Chain)을 구성한 예이다. 서블릿 필터는 각각의 필터들이 doFilter()라는 메서드를 구현해야 하며, doFilter() 메서드 호출을 통해 필터 체인을 형성하게 된다.

Spring Security에서의 필터 역할

[그림 3] Servlet Filter Chain에 Spring Seucrity Filter가 추가된 모습

 위 그림은 서블릿 필터에 Spring Security Filter가 추가된 모습이다. 위 그림에서 DelegatingFilterProxy 와 FilterChainProxy 클래스는 Filter 인터페이스를 구현하기 때문에 서블릿 필터로써의 역할을 한다. 그런데 이 DelegatingFilterProxy 와 FilterChainProxy 는 조금 특별한 필터라고 볼 수 있다.

DelegatingFilterProxy

 Spring에서 DI의 핵심은 바로 Spring 컨테이너인 ApplicationContext이다. Spring Security 역시 Spring의 핵심인 ApplicationContext를 이용한다. 서블릿 필터와 연결되는 Spring Security만의 필터를 ApplicationContext에 Bean으로 등록한 후에 이 Bean들을 이용해서 보안과 관련된 여러가지 작업들을 처리하게 된다. 이 때 DelegatingFilterProxy가 Bean으로 등록된 Spring Security의 필터를 사용하는 시작점이다. 이름에서 알 수 있듯이 DelegatingFilterProxy는 서블릿 컨테이너 영역의 필터와 ApplicationContext에 Bean으로 등록된 필터들을 연결해주는 브릿지 역할을 한다.

[그림 4] FilterChainProxy에 Spring Seucrity Filter Chain이 추가된 모습

FilterChainProxy

 위 그림은 [그림 3]에서 끊어진 FilterChainProxy에 Spring Security에서 지원하는 Filter Chain을 연결한 모습이다. Spring Security의 Filter Chain은 말 그대로 Spring Security에서 보안을 위한 작업을 처리하는 필터의 모음이다. 이 Spring Security의 Filter를 사용하기 위한 진입점이 바로 FilterChainProxy이다. 즉 FilterChainProxy부터 Spring Seucrity에서 제공하는 보안 필터들이 필요한 작업을 수행한다.
Spring Security의 Filter Chain은 URL 별로 여러개 등록할 수 있으며, Filter Chain이 있을 때 어떤 Filter Chain을 사용할지는 FilterChainProxy가 결정하며, 가장 먼저 매칭된 Filter Chain을 실행한다. 예시를 들면

/api/** 패턴의 Filter Chain이 있고, /api/message URL 요청이 전송하는 경우:

/api/** 패턴과 제일 먼저 매칭되므로, 디폴트 패턴인 /**도 일치하지만 가장 먼저 매칭되는 /api/** 패턴과 일치하는 Filter Chain만 실행한다.

/message/** 패턴의 Filter Chain이 없는데 /message/ URL 요청을 전송하는 경우:

매칭되는 Filter Chain이 없으므로 디폴트 패턴인 /** 패턴의 Filter Chain을 실행한다.

Spring Security에서 지원하는 Filter 종류

 Spring Security는 보안을 위한 특정 작업을 수행하기 위한 다양한 Filter를 지원하는데 그 수가 굉장히 많다. 그리고 Spring Security의 Filter 항상 모든 Filter가 수행되는 것이 아니라 프로젝트 구성 및 설정에 따라 일부의 Filter만 활성화 되어 있기 때문에 직접적으로 개발자가 핸들링할 필요가 없는 Filter들이 대부분이다. 따라서 개발자가 Custom Filter를 작성하고 등록할 경우 기존 필터들 사이에서 우선 순위를 적용해 수행되어야할 필요가 있는 경우에 참고해서 적용하면 된다.

Spring Security에서 지원하는 Filter 목록

https://docs.spring.io/spring-security/reference/servlet/architecture.html#servlet-security-filters