거의 일주일 반 정도를 내내 스프링 시큐리티에 발목을 잡혀있었다. 스프링 시큐리티 자체가 너무나 추상적이어서 진~짜 멀리 돌아온 것 같다.

공식문서에 적힌 아키텍쳐를 상세히 보기도 했고, 그걸로도 부족해서 스프링 시큐리티 인 액션이라는 책의 도움을 받아 완벽하다고는 할 수 없겠지만 큰 그림을 제대로 파악할 수 있었다.

공식문서는 너무 세세해서, 큰 그림을 파악하기 어려웠는데, 스프링 시큐리티 인 액션이라는 책을 보고 큰 그림을 파악할 수 있었고, 그 후 다시 공식문서를 봤을 때는 더욱 더 이해하기가 쉬웠던 것 같다.

스프링 시큐리티 아키텍처의 큰 그림은 위와 같다.

나는 책을 읽기 전에는 스프링 시큐리티 아키텍처를 구성하는 객체들의 각자의 역할이 무엇인지, 그 역할로 인해 발생하는 흐름이 어떠한지를 놓치고 있었던 것 같다. 그래서, 내 것으로 만들고자 이번 회고 때 다시 한번 개념들을 돌이키며 정리해보기로 했다.

인증 필터

• 공식문서에 따르면, 스프링 시큐리티의 인증 필터들은 위와 같이 Proxy로 감싸져 있다.
  • 그렇기 때문에 서블릿은 시큐리티 필터 체인의 구성을 알 수 없다고 한다.
• 서버로 보낸 요청을 가로채는 역할을 한다.
• 가로챈 요청에 대한 인증은 해당 필터에 연관된 AuthenticationManager에 위임한다.

인증 관리자

• AuthenticationManager라고 한다.
  • 대표적인 구현체는 ProviderManager이다.
• AuthenticationManager는 여러개의 자식 인증 관리자를 둘 수 있다.
  • AuthenticationManager들은 각각 다른 인증 메커니즘을 가질 수 있다.
  • 요청에 맞는 AutheticationManager가 요청을 처리한다.
• AuthenticationManger는 요청에 대해,
  • 인증 성공 || 인증 실패 || 결정을 내릴 수 없음 → 세 가지 중 하나의 응답을 반드시 하도록 설계되었다.
  • 인증이 실패하거나 결정을 내릴 수 없는 경우, 다운 스트림의 AuthenticationProvider가 결정하도록 한다.
  • AuthenticationProvider가 전부 인증하지 못하면 → ProviderNotFound 예외를 발생시킨다.
• AuthenticationManager는 여러개의 AuthenticationProvider를 가질 수 있다.
• 필터로부터 인증을 위임받고, 인증 관리자는 AuthenticationProvider로 인증을 위임한다.
• 기본적으로 ProviderManager는 인증 성공 시, 반환 받은 Authentication 객체에 있는 모든 민감한 credential 정보를 지운다.