TIL

Architecture

• 서블릿 기반 애플리케이션에서 스프링 시큐리티의 고수준 아키텍처를 다룬다.
• 인증, 인가, 취약점 공격 방어

A Review of Filters

• 스프링 시큐리티는 서블릿 Filter를 기반으로 서블릿을 지원한다.
• 클라이언트가 요청을 보내면 컨테이너는 URI 요청에 기반으로HttpServletRequest를 처리하기 위해 Filter와 Servlet 인스턴스로 구성된 FilterChain을 생성한다.
  • 스프링 MVC에서의 Servlet은 DispatcherServlet이다.
  • 하나의 Servlet에 여러 Filter를 사용할 수 있다.
• Filter 사용
  • 다운스트림의 Servlet과 Filter 실행을 막는다.
  • 다운스트림의 Servlet과 여러 Filter가 사용할 HttpServletRequest나 HttpServletResponse를 수정한다.

public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) {
	// do something before the rest of the application
    chain.doFilter(request, response); // invoke the rest of the application
    // do something after the rest of the application
}

• Filter는 다운스트림의 다른 Filter나 Servlet에멘 영향을 줄 수 있기에 Filter 순서는 중요하다.

DelegatingFitlerProxy

• 스프링부트는 DelegatingFilterProxy라는 Filter 구현체를 사용한다.
• 서블릿 컨테이너 생명주기와 스프링의 ApplicationContext를 연결한다.
  • 서블릿 컨테이너 자체에서 Filter를 등록할 수도 있지만 스프링 빈으로는 인식되지는 못한다.
  • DelegatingFilterProxy를 사용함으로써 모든 처리를 Filter를 구현한 스프링 빈으로 위임해준다.
  • 표준 서블릿 컨테이너 메커니즘으로 등록할 수도 있다.
• DelegatingFilterProxy는 ApplicationContext에서 빈 필터를 찾아 실행한다.

    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) {
        // Lazily get Filter that was registered as a Spring Bean
        // For the example in DelegatingFilterProxy delegate is an instance of Bean Filter0
        Filter delegate = getFilterBean(someBeanName);
        // delegate work to the Spring Bean
        delegate.doFilter(request, response);
    }
  

  • Filter 빈 인스턴스 참조를 지연시킬 수도 있다.
    • 이는 중요한 장점인데 보통 Filter는 서블릿 컨테이너가 시작할 때 미리 다 참조가 연결된다.
    • 하지만 스프링은 ContextLoaderListener로 빈을 찾는데 이는 Filter 인스턴스가 다 등록된 이후에 등록된다.

      FilterChainProxy

• 스프링 시큐리티가 제공하는 FilterChainProxy는 서블릿을 지원하는 특별한 Filter다.
• SecurityFilterChain을 통해 여러 Filter 인스턴스로 처리를 위임할 수 있다.
• FilterChainProxy는 빈이기 때문에 DelegatingFilterProxy로 감싸져 있다.

SecurityFilterChain

• SecurityFilterChain은 FilterChainProxy가 현재 요청에 어떤 Security Filter 인스턴스를 사용할지 결정하는데 사용된다.

• SecurityFilterChain에 있는 스피링 시큐리티 Fitler들은 빈이지만 DelegatingFilterProxy가 아닌 FilterChainProxy로 등록한다.
• FilterChainProxy을 직접 서블릿 컨테이너에 등록하거나 DelegatingFilterProxy에 등록할 때 장점
  • 스프링 시큐리티가 서블릿을 지원할 수 있는 시작점이 되어준다.
    • 시큐리티 적용에 문제가 생기면 FilterChainProxy부터 디버깅하는 것이 좋다.
  • 스프링 시큐리티의 중심점이기 때문에 필수적인 작업을 수행할 수 있다.
    • ex) SecurityContext를 비워 메모리 누수를 방지하거나 HttpFirewall을 적용해서 특정 공격 유형을 방어할 수도 있다.

  • 어떤 SecurityFilterchain을 사용할지 결정하는 데에도 유연함을 제공한다.

    

    • 서블릿 컨테이너에선 URL로만 사용할 Filter를 결정한다.
    • FilterChainProxy는 RequestMatcher 인터페이스로 HttpServletRequest에 있는 어떤 것으로도 실행 여부를 결정할 수 있다.
• 위에서 봤던 것처럼 SecurityFilterChain은 여러 개가 있을 수 있다.
  • 각각의 SecurityFilterChain은 고유하고 격리된 보안 설정을 가질 수 있다.

Security Filters

• Security Filter들은 SecurityFilterChain API를 통해 FilterChainProxy에 추가된다.
  • 등록되는 순서가 중요하다.
• 전체 SecurityFilter 순서는 링크를 클릭하면 볼 수 있다.

Handling Security Exception

• ExceptionTranslationFilter는 AccessDeniedException을 해석하고 AuthenticationException을 HTTP 응답으로 바꾼다.
• ExceptionTranslationFilter는 Security Fitler 중 하나로 FilterChainProxy에 등록된다.

ExceptionTranslationFilter는 애플리케이션에서 AccessDeniedException이나 AuthenticationException이 발생했을 때만 동작한다.

try {
	filterChain.doFilter(request, response);
} catch (AccessDeniedException | AuthenticationException ex) {
	if (!authenticated || ex instanceof AuthenticationException) {
		startAuthentication();
	} else {
		accessDenied();
	}
}

RequestCache

• 스프링 시큐리티는 RequestCache 구현체에 HttpServletRequest를 저장해 놓는다.
  • 인증을 성공적으로 끝낸 후 재요청 하기 위해 요청을 저장할 필요가 있다.
• RequestCacheAwareFilter는 RequestCache를 사용해서 인증이 성공하면 저장해둔 요청을 재실행하는데 사용된다.