Spring Security에서 발생한 예외가 ControllerAdvice에서 핸들링되는 문제

Spring Security에서 발생한 예외가 ControllerAdvice에서 핸들링되는 문제

 

애플리케이션에서 발생한 Exception이 ControllerAdvice에 핸들링되는 것이 뭐가 문제일까요?

 

 

최근에 Client에게 전달하는 error 메세지를 공통화하기 위해 Rest Controller Advice에 다음과 같은 메서드를 코드를 추가하였습니다.

@RestControllerAdvice
public class GlobalExceptionHandler extends ResponseEntityExceptionHandler {

	... 
	
	@ExceptionHandler(Exception.class)
	public ResponseEntity<ErrorResponse> handleException(HttpServletRequest request, Exception exception)
		return ResponseEntity.internalServerError()
			.body(ErrorResponse.badRequest(exception.getMessage(), request.getRequestURI()));
	}
	
}

예상치 못한 예외 발생으로 해당 Exception과 일치하는 시그니처로 정의된 메서드가 없을 경우, 공통적으로 호출되게될 메서드입니다.

 

 

목표하던 error 메세지는 공통화 할 수 있었지만 다른 문제가 발생하였습니다. Security에서 발생하는 인증, 인가 오류가 해당 메서드에 캐치되어 500 에러를 전달한 다는 것입니다.

status code

모두가 아시다시피 인증에 실패했을 경우에는 401 에러코드를, 인가에 실패했을 때는 403 에러코드를 전달해야 합니다.

 

 

Spring Security는 Filter 단에서 동작하기 때문에 예외가 발생하더라도 Spring Context 내부에 있는 ControllerAdvice까지 전파되지 않는다고 생각했는데 어째서 해당 메서드에 캐치되어 이러한 문제가 발생한걸까요?

 

Spring Security의 동작 위치

💡 해당 게시물에서는 Spring Security에 관한 자세한 동작원리를 설명하고 있지 않습니다! 🙅‍♂️

 

spring security architecture

 

위는 Spring Security Architecture 이미지입니다. 서버로 들어온 Http Request가 Controller에 도달하기 전 AuthenticationFilter가 해당 요청을 가로채 인증 로직을 수행하고 그 결과를SecurityContextHolder에 저장합니다.

그 후 요청이 컨트롤러에 도달하기 전 SecurityInterceptor가 실행되어 보안 규칙에 따라 요청을 검사하고 사용자의 권한을 확인합니다. 인가 로직을 수행하는 거죠.

 

 

Filter의 위치

 

그렇다면 인증, 인가 모두 Controller 밖에서 실행되는데 어떻게 ControllerAdvice에 캐치가 된 걸까요?

 

그 이유는 SecurityInterceptor 구현체에 있습니다.

SecurityInterceptor의 구현체는 FilterSecurityInterceptor 와 MethodSecurityInterceptor로 나뉘는데, FilterSecurityInterceptor는 Servlet 필터의 형태로 동작하지만 MethodSecurityInterceptor는 Spring의 AOP를 사용하여 스프링 어플리케이션 안에서 동작하기 때문입니다.

 

• FilterSecurityInterceptor
  • HTTP 요청에 대한 접근 제어를 위해 사용
  • 보통 Spring Security의 보안 필터 체인에서 사용됩니다.
  • URL 패턴과 권한 정보를 기반으로 사용자의 요청을 인터셉트하고 접근을 허용하거나 거부합니다. antMatchers() 메서드를 사용하여 URL 패턴과 권한을 지정할 수 있습니다. 이 인터셉터는 보통 Spring Security의 XML 또는 Java Config를 통해 설정됩니다.
• MethodSecurityInterceptor
  • 메소드 호출에 대한 접근 제어를 위해 사용됩니다.
  • 주로 메소드 수준의 보안을 처리합니다.
  • @PreAuthorize, @PostAuthorize, @Secured 어노테이션을 사용하여 메소드 수준의 보안을 설정합니다.

 

즉, 우리가 흔히 사용하는 어노테이션을 사용한 권한 선언은 Filter가 아닌 Spring 애플리케이션 내에서 처리되게 되는 것입니다.

 

 

 

해결 방법

다시 문제로 돌아와 Spring Security Exception을 어떻게 처리하면 될까요?

 

ControllerAdvice에서 캐치가 된다면 다른 예외들과 동일하게 Exception과 시그니처가 동일한 메소드를 구현하면 되겠다 생각할 수 있지만 Spring Context 내에서 발생한 Exception(AccessDeniedException)은 아래 이미지와 같이 ExceptionTranslationFilter에 의해서 인증 예외(AuthenticationException)와 인가 예외(AccessDeniedException)로 분기되기 때문에 Filter를 타기전에 Exception을 처리할 경우 원하는 에러 상태코드을 받지 못 할 수 있습니다.

 

 

 

제가 해결한 방법은 해당 Exception이 기존 로직대로 Filter에서 분기될 수 있도록 던지는 것(throw)입니다.

@ExceptionHandler(AccessDeniedException.class)
public ResponseEntity<ErrorResponse> handleException(AccessDeniedException exception) {
    throw exception;
}

 

 

spring-projects Github에 동일한 이슈를 찾았는데 마찬가지로 rethrow하기를 권장하는 것 같습니다.

https://github.com/spring-projects/spring-security/issues/6908

AccessDeniedHandler and AuthenticationEntryPoint does not work Because of the global exception handler · Issue #6908 · spring-

 

 

 

마무리

너무 허무한 결론일까요?ㅎㅎ

예외를 그냥 던져야하는게 찝찝할 수는 있지만 Security의 기본 로직을 수행한 뒤에 custom filter를 등록하여 응답 메세지를 공통화하는게 좋겠다는 결론을 내렸습니다.

 

해결 방법은 단순 했지만 Spring Security가 Filter에서만 동작하는게 아니라는 것을 알게되었습니다.

더 좋은 해결방법을 알고 계시거나 잘못된 내용이 있다면 댓글 남겨주세요. 끝까지 봐주셔서 감사합니다 :)

 

 

 

Spring MVC 패턴과 Filter에 대한 설명이 궁금하다면 아래 게시글을 참고해주세요. 
[Spring] Spring MVC : https://clipcode.tistory.com/62   
[Spring] Filter와 Interceptor 차이 : https://clipcode.tistory.com/65

 

 

 

Reference.

https://ugo04.tistory.com/169