Spring Security 아키텍처

Filter

• Spring Security는 Sevlet Filter에서 동작함
• Servlet Filter를 먼저 확인해야 함
  • Client → FilterChain
  • FilterChain = Filter + Servlet
  • 요청을 받으면 서블릿 컨테이너에서 Filter, Servlet을 포함하고 있는 FilterChain을 생성
  • 위 그림에서 Servlet은 DispatcherServlet
  • HttpServletRequest의 URI에 의해서 처리됨
  • Filter의 역할
    • 다음 차례의 Filter, Serlvet이 동작하는 것을 막고 HttpServletResponse에 응답을 씀
    • HttpServletRequest, HttpServletResponse를 변경하여 다음 차례의 FilterChain에서 변경된 사항을 사용할 수 있도록 함
    • 따라서 Filter가 등록된 순서가 매우 중요함

  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
  }
  

DelegatingFilterProxy

• Servlet Container의 라이프 사이클과 Spring ApplicationContext 사이의 Bridge 역할을 수행
• Servlet Container는 자신의 기준에 따라서 Filter를 등록을 수행함. 이 과정에서 Spring에서 정의한 Bean에 대해서는 몰라도 됨
• DelegatingFilterProxy는 servlet 필터의 동작 방식에 따라서 등록되지만, 모든 기능을 Spring의 Filter를 구현한 Bean에 위임함

수도 코드

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);
}

1. 스프링 빈으로 등록된 필터를 Lazy하게 조회
   1. Lazy하게 조회 :
      1. 서블릿 컨테이너는 컨테이너가 시작되기 전에 Filter를 등록해야 한다
      2. Spring의 Filter Bean을 로딩할 때 ContextLoaderListener를 사용한다
      3. 그런데 ContextLoaderListener는 서블릿 컨테이너의 FIlter가 등록된 이후에 사용할 수 있다
      4. 즉, 서블릿 컨테이너가 시작될 때는 Spring Bean이 등록되어있지 않기 때문에 FilterChain을 가져올 수 없다. 그래서 일단 서블릿 컨테이너에 필터가 등록되게 하고, DelegatingFilterProxy를 최초 사용하는 타이밍에 Spring Bean으로 등록된 FilterChain을 가져온다.
2. 빈 이름으로 delegator를 조회해서 수행을 위임

실제 코드

@Override
public void doFilter(ServletRequest request, ServletResponse response, FilterChain filterChain)
		throws ServletException, IOException {

	// Lazily initialize the delegate if necessary.
	Filter delegateToUse = this.delegate;
	if (delegateToUse == null) {
		synchronized (this.delegateMonitor) {
			delegateToUse = this.delegate;
			if (delegateToUse == null) {
				// 1. 애플리케이션 콘텍스트를 생성하고
				WebApplicationContext wac = findWebApplicationContext();
				if (wac == null) {
					throw new IllegalStateException("No WebApplicationContext found: " +
							"no ContextLoaderListener or DispatcherServlet registered?");
				}
				// 2. delegator를 초기화한다
				delegateToUse = initDelegate(wac);
			}
			this.delegate = delegateToUse;
		}
	}

	// Let the delegate perform the actual doFilter operation.
	invokeDelegate(delegateToUse, request, response, filterChain);
}

protected Filter initDelegate(WebApplicationContext wac) throws ServletException {
	// 설정된 빈 이름으로 ("springSecurityFilterChain")
	String targetBeanName = getTargetBeanName();
	Assert.state(targetBeanName != null, "No target bean name set");
	// 애플리케이션 컨텍스트에서 빈을 가져온다
	Filter delegate = wac.getBean(targetBeanName, Filter.class);
	// 스프링 컨테이너에 의해서 관리되는 필터 빈의 라이브사이클을 서블릿 컨테이너에서 초기화돠 파괴자를 호출할지 여부 (default false)
	if (isTargetFilterLifecy[c](<https://www.notion.so/Architecture-006f54b214744da397e5febdf24c6319?pvs=21>)le()) {
		delegate.init(getFilterConfig());
	}
	return delegate;
}

protected void invokeDelegate(
		Filter delegate, ServletRequest request, ServletResponse response, FilterChain filterChain)
		throws ServletException, IOException {
	// SpringSecurity FilterChain을 수행
	delegate.doFilter(request, response, filterChain);
}

FilterChainProxy

위에서 DelegatingFilterProxy에서 설명한 delegate가 로딩되는 과정을 자세히 들여다보자.

• targetBeanName은 SpringSecurityFilterChain으로 지정되었고
• 조회된 delegate는 FilterChainProxy 타입의 객체가 할당되었다.

DelegatingFilterProxy도 스프링의 Filter Bean이지만, DelegatingFilterProxy가 생성되는 타이밍과 FilterChainProxy가 생성되는 타이밍에 차이가 있어서 lazy 로딩 되었다.

SecurityFilterChain

FilterChainProxy가 가지고 있는 FilterChain은 SecurityFilter로 구성되어 있습니다. SecurityFilterChain는 어떤 요청이 들어왔을 때 어떤 Filter가 호출되어야 하는지에 대한 정보를 결정합니다.

아래의 사진을 보면 pattern가 있는데, 여기에 매칭될 때 어떤 Filters가 호출되는지가 지정되어 있습니다.

여러 가지 SecurityFilterChain들이 FilterChainProxy 객체로 묶여 있는 것은 두 가지 장점이 있습니다.

1. Spring Security가 관여하는 최초의 진입점 역할을 합니다.
2. SecurityFilterChain은 시스템의 목적이나 사용자의 요청 정보에 따라서 적용될 수도 있고 아닐 수도 있습니다. FilterChainProxy는 어떤 상황에서든 항상 존재하고 invoke되는 위치로서 존재하기 때문에 관리와 분석을 용이하게 해주는 역할을 합니다.

게다가 FilterChainProxy는 어떤 SecrityFilterChain을 사용할지 결정할 수 있는 특징도 있습니다. Servlet Filter는 request URI만 사용해서 Filter를 실행할지 말지를 결정할 수 있는 반면에 FilterChainProxy는 HttpServletRequest에 포함된 모든 정보를 사용해서 어떤 SecurityFilterChain를 사용할지 결정할 수 있습니다. Request 경로에 따라서 서로 다른 SecurityFilterChain을 적용하려고 할 때 아래 그림과 같이 Multiple SecurityFilterChain 기능을 사용할 수 있습니다.

여러 개의 SecurityFilterChain이 등록된 경우, request URI에 첫 번째로 매칭되는 SecurityFilterChain만 적용됩니다.

SecurityFilter

SecurityFilterChain에 포함되는 SecurityFilter의 목록입니다. 사용자의 인증 과정은 대부분 UsernamePasswordAuthenticationFilter에서 일어납니다.

UsernamePasswordAuthenticationFilter는 오른쪽 그림에서 AbstractAuthenticationProcessingFilter에 해당됩니다. 인증 과정에서 오류가 발생하면 (AuthenticationManager에서 AuthenticationException 발생)하면 ExceptionTranslationFilter가 처리합니다.

 

ExceptionTranslationFilter

ExceptionTranslationFilter는 SecurityFilterChain의 가장 마지막 단계로 생각하면 됩니다. 가장 마지막 단계에서 인증 오류가 발생하는 경우에 대한 예외처리가 되어 있습니다.

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

ExceptionTranslationFilter는 인증이 안되어 있어서 인증을 해야하는지(Start Authentication), 접근이 거부되었는지 (AccessDenied)되었는지를 판단한다. 인증이 안되었고 인증을 해야하면 SecurityContextHolder를 초기화한다. HttpSevletRequest는 RequestCache에 저장된다. 정상적으로 인증이 성공되었을 때 RequestCache에 들어있는 HttpServletRequest로 사용자가 원래 접근하려고 했던 요청을 수행한다. 특정 페이지 접근 시도 → 로그인 페이지 → 로그인 → 원래 페이지로 다시 연결되는 방식이다. 이 때 AuthenticationEntryPoint가 어떤 페이지로 연결될지를 결정한다. (로그인 페이지 등)