[스프링 시큐리티] 3. Form Login 인증 방식 파악 계속 : AuthenticationManager, Provider와 SecurityContext
1. 인증 로직 파악(계속)
이 부분도 FomrLogin의 인증 과정을 대략적으로 살펴본 내용일 뿐, 자세한 내용은 뒤에서 다루게 되므로 간단히 훑어보기만 하자.
1. 이어지는 과정과 Authentication 객체
지난 글에서 파악한 부분은 AntPathRequestMatcher까지였다. 서버에서 requestMap형태로 url과 권한 정보를 갖고 있고, 클라이언트가 요청한 url과 비교하는 부분이였다. 여기서 실패하면 chain.doFilter를 통해 다른 필터로 넘어가게 되지만, 일단 성공하게 되면 사용자의 입력 정보를 바탕으로 Authentication 객체를 생성하게 된다.
2. AuthenticationManager -> AuthenticationProvider
생성된 Authentication 객체는 AuthenticationManager에 전달된다. AuthenticationManager는 앞서 살펴봤던 UsernamePasswordAuthenticationFilter가 상속받고 있는 AbstractAuthenticationProcessingFilter에서 의존하고 있는 것을 확인할 수 있다.
ProviderManager
AuthenticationManager를 구현하고 있는 ProviderManager는 <AuthenticationProvider> 타입의 provider들을 리스트로 갖고 있다.
이 provider는 마치 스프링 MVC의 HandlerAdapter와 같이 providers중 요청의 종류에 맞는 provider인지를 판단하는 supports와 인증을 처리해주는 authenticate 메서드로 구성되어 있다.
다시 말해 Authentication 객체의 종류를 보고 알맞는 인증 처리기(provider)를 반환해주는 부분인 것이다.
이제 AuthenticationProvider를 구현하는 AbstractUserDetailsAuthenticationProvider에서 createSuccessAuthentication 메서드를 실행하여 성공적으로 로그인 처리를 한다. 이때 반환되는 Authentication은 사용자에게 부여된 권한(Authorities) 정보들을 포함한 인증 정보 객체이다.
3. SecurityContext 처리
그림상으로는 처음 UsernamePasswordAuthenticationFilter에서 SecurityContext쪽으로 이동한 것 같지만, 사실 Filter 내부에서 SecurityContext를 만든다고 보면된다. 이제까지의 흐름은 아래와 같다.
UsernamePasswordAuthenticationFilter extends AbstractAuthenticationProcessingFilter
-> Matcher에서 url, 권한 비교 -> AuthenticationManager -> AuthenticationProvider
-> 다시 AuthenticationManager -> AbstractAuthenticationProcessingFilter
즉 Filter가 인증 처리를 담당하는 AuthenticationProvider에 인증 정보를 넘기고, 인증 결과를 다시 filter로 받아오는 구조인 것이다. 이제 이 인증 결과를 SecurityContext에 저장한다. SecurityContext는 나중에 세션에 담겨서 클라이언트에서 로그인 정보를 유지할 수 있게 된다.
인증방식 파악은 이 정도까지만하고 마무리하면 될 것 같다. API들을 모두 훑어보고 나중에 전체 구조에 대해 살펴볼 때 지금껏 공부했던 내용이 도움이 될 것이다. 우선 API들을 살펴보면서 스프링 시큐리티가 어떤 기능들을 제공하는지 보자.
참조