[Spring Security] docs: Architecture(5) - ExceptionTranslationFilter, RequestCache, logging

🔻 Spring Security docs  게시글 목차  

1. [Spring Security] docs : Getting Started

[Spring Security] docs : Getting Started

 

 

 

2. [Spring Security] docs : Architecture (1) - Filter

[Spring Security] docs : Architecture (1) - Filter

 

 

 

3. [Spring Security] docs: Architecture (2) - DelegatingFilterProxy

[Spring Security] docs: Architecture (2) - DelegatingFilterProxy

 

 

 

4. [Spring Security] docs: Architecture (3) - FilterChainProxy & SecurityFilterChain

[Spring Security] docs: Architecture (3) - FilterChainProxy & SecurityFilterChain

 

 

 

5. 2024.08.30 - [Spring Boot] - [Spring Security] docs : Architecture(4) : FilterChain의 역할과 순서, 커스텀 필터

[Spring Security] docs : Architecture(4) : FilterChain의 역할과 순서, 커스텀 필터

 

 

 

 

🌱 Spring Security docs 바로가기

Architecture :: Spring Security

 

 

ExceptionTranslationFilter

`ExceptionTranslationFilter`는 보안 필터들 중하나로, FilterChainProxy에 들어있다. `ExceptionTranslationFilter`는 `AccessDeniedException` 과 `AuthenticationException` 을 HTTP 응답으로 변환시킬 수 있다. 

 

1. `ExceptionTranslationFilter`가 애플리케이션의 나머지를 호출하기 위해 `FilterChain.doFilter(request, response)`를 호출한다. 

 

2. 만약 유저가 인증되지 않았거나, `AuthenticationException`에 해당하면 인증을 시작한다. 

• `SecurityContextHolder`가 삭제된다. 
• `HttpServletRequest`가 저장되는데, 인증이 성공하면 원래의 요청을 재실행하는 데에 쓰인다. 
• `AuthenticationEntryPoint`는 클라이언트로부터 credential을 요청하는 데 사용된다. 예를 들어, 로그인 페이지나 `WWW-Authenticate` 헤더로 리다이렉트 시킬 수 있다. 

3. 반면에 `AccessDeniedException`인 경우에는, 접근이 거부되고, 이를 처리하기 위해 `AccessDeniedHandler`가 호출된다. 

 

✅ 만약 애플리케이션이 `AccessDeniedException`이나 `AuthenticationException`을 던지지 않으면 `ExceptionTranslationFilter`가 아무것도 하지 않는다. 

 

`ExceptionTranslationFilter` 수도 코드

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

 

1. `FilterChain.doFilter(request, response)`를 호출하는 것은 나머지 애플리케이션을 호출하는 것과 동일한 역할을 한다. 즉, 애플리케이션의 다른 부분 (`FilterSecurityInterceptor`이나 method security)이 `AuthenticationException`이나 `AccessDeniedException`을 던지면 여기서 잡히고 처리된다. 

2. 유저가 인증되지 않았거나 `AuthenticationException`에 해당하면 인증이 시작된다. 

3. 접근 거부

 

 

 

 

---

 

 

인증 사이에 요청 저장하기

요청에 인증이 없고 인증이 필요한 리소스에 대한 요청인 경우, 인증이 성공한 후 인증 리소스를 재요청하기 위해 요청을 저장해두어야 한다.

이를 위해 Spring Security에서는 `RequestCache` 구현을 통해 `HttpServletRequest`를 저장할 수 있다. 

 

RequestCache

`HttpServletRequest`는 `RequestCache`에 저장된다.`RequestCacheAwareFilter`와 `ExceptionTranslationFilter`는 모두 `RequestCache`를 사용하지만, 사용하는 시점과 목적이 다르다. 

`RequestCacheAwareFilter`: 유저가 인증에 성공한 뒤에  RequestCache에 저장된 원본 요청이 있는지 확인하고, 만약 있다면 그 요청을 원래 요청을 복원하여 인증 성공 후의 경로로 리다이렉트한다. 즉, 이미 저장된 요청을 검색하여 처리하는 필터이다. 

`ExceptionTranslationFilter`: 인증이 필요한 요청을 저리하는 과정에서 인증 예외 (`AuthenticationException`)가 발생한 경우, 유저가 로그인 엔드포인트로 리다이렉트되기 전에 `HttpServletRequest`을 `RequestCache`에 저장한다.

 

 

✅ 기본값으로 `HttpSessionRequestCache`를 사용하여 `HttpSession`에 요청을 저장한다. 

 

 

커스터마이징된 RequestCache 구현

아래의 코드는 `HttpSessionRequestCache`가 `continue` 라는 특정 파라미터가 있을 때만 요청을 저장하도록 커스터마이징한 것이다.

@Bean
DefaultSecurityFilterChain springSecurity(HttpSecurity http) throws Exception {
	HttpSessionRequestCache requestCache = new HttpSessionRequestCache();
	requestCache.setMatchingRequestParameterName("continue");
	http
		// ...
		.requestCache((cache) -> cache
			.requestCache(requestCache)
		);
	return http.build();
}

 

 

 

 

 

`NullRequestCache` 구현을 통해 요청이 저장되는 것을 방지하기 

세션에 유저의 인증되지 않은 요청을 저장하고싶지 않을 수 있다. 해당 스토리지를 사용자의 브라우저로 오프로드하거나, 데이터베이스에 저장할 수 있다. 또는 로그인 전에 방문하려고 했던 페이지 대신, 항상 특정 페이지(ex. 홈 페이지)로 사용자를 리디렉션하고 싶다면 요청을 저장해두지 않고 싶을 수 있다. 그럴 때에는 `NullRequestCache`를 구현하면 된다. 

 

@Bean
SecurityFilterChain springSecurity(HttpSecurity http) throws Exception {
    RequestCache nullRequestCache = new NullRequestCache();
    http
        // ...
        .requestCache((cache) -> cache
            .requestCache(nullRequestCache)
        );
    return http.build();
}

 

정리하자면, `NullRequestCache`는 요청을 캐싱하지 않는다. 따라서 사용자가 로그인 페이지로 리다이렉트된 후, 원래 요청을 다시 실행할 필요가 없는 상황에 적합하다.

 

---

 

로깅

Spring Security는 보안 이벤트에 대한 종합적인 로그를 DEBUG와 TRACE 레벨에서 제공한다. 401이나 403 에러가 뜬다면, 현재 어떤 상황이 벌어졌는지에 대한 로그 메시지를 찾을 수 있을 확률이 높다. 

 

csrf 보호가 된 리소스를 csrf 토큰이 없이 POST 요청을 보내면, 로그가 없이는 유저가 아무 설명도 없이 403에러를 마주칠 것이다. 하지만, Spring Security의 로깅을 허용하면 다음과 같은 메시지를 볼 수 있다. 

 

2023-06-14T09:44:25.797-03:00 DEBUG 76975 --- [nio-8080-exec-1] o.s.security.web.FilterChainProxy        : Securing POST /hello
2023-06-14T09:44:25.797-03:00 TRACE 76975 --- [nio-8080-exec-1] o.s.security.web.FilterChainProxy        : Invoking DisableEncodeUrlFilter (1/15)
2023-06-14T09:44:25.798-03:00 TRACE 76975 --- [nio-8080-exec-1] o.s.security.web.FilterChainProxy        : Invoking WebAsyncManagerIntegrationFilter (2/15)
2023-06-14T09:44:25.800-03:00 TRACE 76975 --- [nio-8080-exec-1] o.s.security.web.FilterChainProxy        : Invoking SecurityContextHolderFilter (3/15)
2023-06-14T09:44:25.801-03:00 TRACE 76975 --- [nio-8080-exec-1] o.s.security.web.FilterChainProxy        : Invoking HeaderWriterFilter (4/15)
2023-06-14T09:44:25.802-03:00 TRACE 76975 --- [nio-8080-exec-1] o.s.security.web.FilterChainProxy        : Invoking CsrfFilter (5/15)
2023-06-14T09:44:25.814-03:00 DEBUG 76975 --- [nio-8080-exec-1] o.s.security.web.csrf.CsrfFilter         : Invalid CSRF token found for http://localhost:8080/hello
2023-06-14T09:44:25.814-03:00 DEBUG 76975 --- [nio-8080-exec-1] o.s.s.w.access.AccessDeniedHandlerImpl   : Responding with 403 status code
2023-06-14T09:44:25.814-03:00 TRACE 76975 --- [nio-8080-exec-1] o.s.s.w.header.writers.HstsHeaderWriter  : Not injecting HSTS header since it did not match request to [Is Secure]

 

CSRF 토큰이 missing 상태이고, 그래서 요청이 denied되었음을 알 수 있다. 

 

다음과 같이 설정할 수 있다. 

 

application.properties

logging.level.org.springframework.security=TRACE

 

application.yml

logging:
  level:
    org.springframework.security: DEBUG
    org.springframework.security.web: TRACE

 

logback.xml

<configuration>
    <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
        <!-- ... -->
    </appender>
    <!-- ... -->
    <logger name="org.springframework.security" level="trace" additivity="false">
        <appender-ref ref="Console" />
    </logger>
</configuration>

 

🔻 로깅 프레임워크 Logback

`logback.xml`은 Logback 이라는 로깅 프레임워크의 설정 파일이다. 

1. 로깅 출력 대상 (Appenders) 설정

`Appender`는 로깅 메시지를 출력하는 대상이다. 위의 코드에서는 `STDOUT이`라는 이름의 콘솔이 정의되어 있다. 이 콘솔은 `ConsoleAppender`클래스를 사용하여 로그 메시지를 표준 출력에 기록한다. 

 

2. 로깅 레벨 및 로거 정의
`logger`는 특정 패키지나 클래스의 로그 출력을 관리한다. `name` 속성은 로거의 이름을 지정하며, 보통 특정 패키지나 클래스 이름을 사용한다. 
`level` 속성은 로깅 레벨을 정의한다. `trace`, `debug`, `info`, `warn`, `error` 등이 있다. 위 코드에서는 `trace` 레벨로 설정되었고, `trace`는 가장 상세한 로그레벨이다. 추가적으로 `additivity="false"`는 이 로거가 상위 로거에 로그 메시지를 전달하지 않도록 하여, 불필요한 중복 로그를 방지해준다. 

 

3. 로깅 메시지의 포맷과 필터링
`logback.xml`을 사용하면 각 로그 메시지의 포맷을 정의하거나, 특정 조건에 따라 로그 메시지를 필터링할 수 있다.