Spring Security 아키텍처

늘 그렇듯 아키텍처를 이해하는 게 모든 커스터마이징의 기본이다. 현재 프로젝트의 세션 관리는 전부 was내에서 처리한다. 나중에 서비스가 커져서 was를 분산하거나, 한 was에 모든 세션을 저장하기 부담스러운 상황이 온다면? redis를 이용해 세션을 was에서 분리하는 목표를 세웠다.

 

그전에, servlet으로 가기 이전인 filter기반으로 동작하는 스프링 시큐리티 아키텍처를 이해해보자.

 

 

 

스프링 WAS의 큰 그림

클라이언트의 요청이 오면 요청은 FilterChain으로 이루어진 Filter를 하나씩 거치게 된다. 모든 Filter를 거친 후 최종적으로 servlet에 요청을 위임한다. 이때 spring security는 servlet에게 요청을 위임하기 전에 인증, 인가만 따로 처리하는 하나의 Filter로 등록되어 사용한다

 

 

spring과 Filter의 조합

Filter 자체는 spring과 무관한 WAS의 스펙이다. 즉, Filter에서 아무 조건 없이 spring의 기능을 사용할 수 없다. 이때, spring과 Filter를 연결하는 spring전용 Filter를 spring은 제공해준다. 그게 바로DelegatingFilterProxy다. spring이 한 번 감싼 Filter인 DelegatingFilterProxy는 ApplicationContext에 접근할 수 있다.(내부적으로 컨텍스트를 필드로 갖고 있다) 그 말은 인증, 인가를 위한 클래스를 빈으로 등록하고 사용할 수 있다는 의미다.

 

DelegatingFilterProxy는 인증, 인가 프로세스를 내부에 등록한 FilterChainProxy에 위임한다.

그리고 인증, 인가를 위해 등록한 내부 필터를 FilterChain과 같은 방식으로 순차적으로 진행한다.(대략 32개)

 

 

인증 인가 예외 처리

security의 ExceptionTranslationFilter는 예외를 처리하는 필터다. 이전 filter에서 요청이 인증 또는 인가에 실패하게 된다면 throw를 이용해 Exception을 던지게 된다. 이때 이 Exception을 처리하기 위해 등록한 AccessDeniedHandler를 작동시킨다.

 

 

인증

SecurityContextHolder.

SecurityContext를 관리하는 spring security의 핵심 객체다. SecurityContextHolder는 기본적으로Authentication 객체를 ThreadLocal에서 관리한다. 즉, 같은 요청에 대해서는 어떤 위치에서 객체를 꺼내든지 항상 동일한 Authentication객체를 반환한다.

 

여기서, SecurityContextHolder는 본인이 저장되는 방식에는 관심이 없다는 점이 중요하다. 기본 저장소는 HttpSessionSecurityContextRepository로 HttpSession을 WAS의 메모리에 저장하는 방식이다. (여기서 레파지토리를 Redis로 커스터마이징하는 게 목표다.) 소름인 건 spring security라는 프레임워크를 빼지 않는 한 인증객체를 가져오기 위한 기존 코드는 저장소가 바뀌어도 전혀 손댈필요가 없다는 점이다.

(다만, 이또한 변경에 유연하지 못한 거고 과연 비지니스 로직에서 직접 Authentication을 꺼내는 게 맞을까? => 아규먼트리졸버 또는 인터셉터로 문제 해결)

 

 

큰그림

- 사용자 인증요청

- AbstractAuthenticationProcessginFilter에서 템플릿 콜백을 이용해 인증 시작

- 내부적으로 AuthenticationManager(구현체로 ProviderManager)를 이용해 본격적인 인증 시작

- 인증에 성공하면 잘 세팅된 Authentication을 반환하고 실패하면 예외를 던진다.