[Spring Security] 스프링 시큐리티의 인증/인가 처리 흐름

들어가기전에.

2023.11.07 - [Spring🕸️] - [Spring Security] 스프링 시큐리티 기본 - 1

이전의 Security 기본을 통해서 어떠한 방식으로 보안작업 처리하는지 알아보았다. 하지만 내부에서 어떤 식으로 처리가 되는지는 자세하게 알아보지 못했다. 그럼 내부의 흐름을 한번 알아보자.

인증 vs 인가

인증(Authentication)

사이트에 접근하는 사람이 누구인지 시스템이 알아야 한다. 익명사용자(anonymous user)를 허용하는 경우도 있지만, 특정 리소스에 접근하거나 개인화된 사용성을 보장 받기 위해서는 반드시 로그인하는 과정이 필요하다. 로그인은 보통 username / password 를 입력하고 로그인하는 경우와 sns 사이트를 통해 인증을 대리하는 경우가 있다.

• UsernamePassword 인증 (세션, 토큰 관리)
• Sns 로그인 (소셜 로그인) : 인증 위임

인가 / 권한 (Authorization)

사용자가 누구인지 알았다면 사이트 관리자 혹은 시스템은 로그인한 사용자가 어떤 일을 할 수 있는지 권한을 설정한다. 권한은 특정 페이지에 접근하거나 특정 리소스에 접근할 수 있는 권한여부를 판단하는데 사용된다. 개발자는 권한이 있는 사용자에게만 페이지나 리소스 접근을 허용하도록 코딩해야 하는데, 이런 코드를 쉽게 작성할 수 있도록 프레임워크를 제공하는 것이 스프링 시큐리티 프레임워크(Spring Security Framework) 이다.

• Secured : deprecated
• PrePostAuthorize
• AOP

 

일반적인  요청의 흐름

서블릿 컨테이너

• 톰캣같은 웹 어플리케이션(WAS)를 서블릿 컨테이너라고 부른다. 이러한 웹 어플리케이션은 기본적으로 필터와 서블릿으로 구성된다.
• 필터는 체인처럼 엮여있어 필터체인이라고도 불린다. 모든 request는 이러한 필터체인을 거쳐야지 서블릿 서비스에 도착할수있다.

그림과 같이 DispatcherServlet에 클라이언트의 요청이 전달되기 전에 필터체인이 구성되어있다. 서블릿 필터는 각각의 필터들이 doFilter() 라는 메서드를 구현해야한다. doFilter() 메서드의 호출을 통해 필터체인을 형성한다. 

 

 

Spring Security 요청의 흐름

스프링 시큐리티에서의 적용

그림을 먼저 살펴보자. 시큐리티는 DelegatingFiterProxy 라는 필터를 만들어 메인 필터체인에 끼워넣고, 그아래에 다시 SecurityFilterChain 그룹을 등록하는 방식으로 동작한다.

• 이러한 필터체인은 반드시 한개 이상으로 구성된다.
• url 패턴에 따라 적용되는 필터체인을 다르게 구성할수있다.
• web resource의 경우 패턴을 따르더라도 필터를 무시하고 통과시킬수도 있다.

아래 그림으로 조금 더 자세하게 살펴보자.

서블릿필터에 SpringSecurityFilter가 추가된 모습이다. 빨간 점선으로 된 영역을 보면 2개의 Proxy가 보인다. DelegatingFilterProxy와 FilterChainProxy도 Filter 인터페이스를 구현하고 있는 서블릿 필터이다. 그럼 두가지 필터의 역할을 알아보자.

 

 

1. DelegatingFilterProxy

• 보안에 관련된 작업을 처리하지는 않음
• ApplicationContext에 Bean으로 등록된 Spring Security의 필터를 사용하는 시작점
• 서블릿 컨테이너 영역의 필터와 ApplicationContext에 Bean으로 등록된 필터들을 연결해 주는 브리지 역할

2. FilterChainProxy

• 보안을 위한 작업을 처리하는 필터의 모음
• Spring Security의 Filter를 사용하기위한 진입점
• FiterChainProxy부터 시큐리티에서 제공하는 보안필터들이 필요한 작업을 수행

이렇게 등록된 FiterChainProxy에서 사용할수있는 필터의 종류는 아래에서 살펴보자.

 

 

Spring Security 필터의 종류

모든 필터들은 각기 자신의 역할이 있다. 이런 역할을 정리해서 알아보자.

 

• HeaderWriterFilter : Http 해더를 검사한다. 써야 할 건 잘 써있는지, 필요한 해더를 더해줘야 할 건 없는가?
• CorsFilter : 허가된 사이트나 클라이언트의 요청인가?
• CsrfFilter : 내가 내보낸 리소스에서 올라온 요청인가?
• LogoutFilter : 지금 로그아웃하겠다고 하는건가?
• UsernamePasswordAuthenticationFilter : username / password 로 로그인을 하려고 하는가? 만약 로그인이면 여기서 처리하고 가야 할 페이지로 보내 줄께.
• ConcurrentSessionFilter : 여거저기서 로그인 하는걸 허용할 것인가?
• BearerTokenAuthenticationFilter : Authorization 해더에 Bearer 토큰이 오면 인증 처리 해줄께.
• BasicAuthenticationFilter : Authorization 해더에 Basic 토큰을 주면 검사해서 인증처리 해줄께.
• RequestCacheAwareFilter : 방금 요청한 request 이력이 다음에 필요할 수 있으니 캐시에 담아놓을께.
• SecurityContextHolderAwareRequestFilter : 보안 관련 Servlet 3 스펙을 지원하기 위한 필터라고 한다.(?)
• RememberMeAuthenticationFilter : 아직 Authentication 인증이 안된 경우라면 RememberMe 쿠키를 검사해서 인증 처리해줄께
• AnonymousAuthenticationFilter : 아직도 인증이 안되었으면 너는 Anonymous 사용자야
• SessionManagementFilter : 서버에서 지정한 세션정책을 검사할께.
• ExcpetionTranslationFilter : 나 이후에 인증이나 권한 예외가 발생하면 내가 잡아서 처리해 줄께.
• FilterSecurityInterceptor : 여기까지 살아서 왔다면 인증이 있다는 거니, 니가 들어가려고 하는 request 에 들어갈 자격이 있는지 그리고 리턴한 결과를 너에게 보내줘도 되는건지 마지막으로 내가 점검해 줄께.
• 그 밖에... OAuth2 나 Saml2, Cas, X509 등에 관한 필터들도 존재.
• 필터의 순서는 굉장히 중요하다. 기본필터의 순서는 정해져있고, 그에 따라 작성 되야 한다.

자 그럼 이제 스프링 시큐리티에서의 인증처리 흐름을 알아보자!

 

Spring Security 인증 처리 흐름

(1) 사용자가 로그인 폼을 이용해 Username, Password를 포함한 request를 시큐리티가 적용된 애플리케이션에 전송한다. 즉 로그인 요청이 들어왔을때, Filter들 중에 usernamePasswordAuthenticationFilter가 해당 요청을 전달 받는다.

 

(2) 이때 사용자의 요청을 전달받은 UsernamePasswordAuthenticationFilter가 Username, Password를 이용해 UsernamePasswordAuthenticationToken을 생성한다. 이 Token은 Authentication 인터페이스를 구현한 구현 클래스이며, 여기에서 Authentication은 아직 인증되지 않은 Authentication이다.

 

(3) 인증되지 않은 Authentication을 가지고 있는 UsernamePasswordAuthenticationFilter가 Authentication을 AuthenticationManager에게 전달한다. AuthenticationManager는 인증처리를 총괄하는 매니져역할을 하는 인터페이스로, AuthenticationManager를 구현한 클래스가 ProviderManager이다. 즉 ProviderManager가 인증이라는 작업을 총괄하는 실질적인 매니져인 것이다.

 

(4) ProviderManager로 부터 Authentication을 AuthenticationProvider에게 전달한다. 이처럼 ProviderManager가 직접 인증을 처리하는것이 아닌 AuthenticationProvider에게 인증처리를 맡기는 것이다.

 

(5) AuthenticationProvider는 UserDetailsService를 이용해 UserDetails를 조회한다.

 

(6) 데이터 베이스등의 저장소에서 조회한 사용자의 크레덴셜을 포함한 사용자의 정보를 가지고 온다.

 

(7) 가지고온 사용자의 정보를 기반으로 UserDeatails를 생성한다.

 

(8) 생성된 UserDetails를 다시 AuthenticationProvider에게 전달한다.

 

(9) UserDetails를 전달받은 AuthenticationProvider는 PasswordEncoder를 이용해 UserDetails에 포함된 암호화된 Password와 인증을 위한 Authentiation 안에 포함된 Password가 일치하는지 검증한다. 그리고 검증에 성공을 하면, UserDetails를 이용해 인증된 Authentication을 생성한다. 여기서 검증에 성공하지 못하면 Exception을 뱉고, 인증처리를 중단한다.

 

(10) AuthenticationProvider는 인증된 Authentication을 ProviderManager에게 전달한다. 이때 ProviderManager에게 전달한 Authentication은 인증에 성공한 사용자 정보(Principal, Credential, GrantedAuthorities)를 담고있다.

 

(11) ProviderManager는 인증된 Authentication을 다시 UsernamePasswordAuthenticationFilter에게 전달한다.

 

(12) 마지막으로  UsernamePasswordAuthenticationFilter는 SecurityContextHolder를 이용해 SecurityContext에 인증된 Authentication을 저장한다. 

 

이후, SpringSecurity의 세션정책에 따라서, HttpSession에 저장되어 사용자의 인증상태를 유지하기도하고,, HttpSession을 생성하지 않고 무상태를 유지하는 등의 정책을 넣어줄수있다.(JWT 참고)

 

Spring Security의 권한 처리 흐름

다음으로 권한처리의 흐름에 대해서 알아보자.

권한처리는 로그인 등의 인증에 성공한 이후의 흐름이다. 인증이 성공한 이후, 인증된 사용자에게 Spring Security에서 어떻게 권한을 부여하는지 알아보자.

 

Spring Security Filter Chain에서 URL을 통해 사용자의 엑세스를 제한하는 권한 부여 Fitler는 AuthorizationFilter이다.

 

(1) AuthorizationFilter는 SecurityContextHolder로 부터 Authentication을 획득한다. (인증이 완료된 Authentication)

 

(2) SecurityContextHolder로 부터 획득한 Authentication과 HttpServletRequest를 AuthorizationManager에게 전달한다. AuthorizationManager는 권한 부여 처리를 총괄하는 매니져 역할의 인터페이스이고, RequestMatcherDelegatingAuthorizationManager는 AuthorizationManager를 구현하는 구현체중 하나이다. RequestMatcherDelegatingAuthorizationManager는 RequestMatcher 평가식을 기반으로 해당 평가식에 매칭되는 AuthorizationManager에게 권한 부여 처리를 위임하는 역할을 한다. 즉, RequestMatcherDelegatingAuthorizationManager가 직접 권한을 부여하는 것이 아닌, RequestMatcher 를 통해 매칭되는 AuthorizationManager 구현 클래스에게 위임을 한다.

 

(3) RequestMatcherDelegatingAuthorizationManager 내부에서 매칭되는 AuthorizationManager 구현 클래스가 있으면, 해당 AuthorizationManager 구현 클래스가 사용자의 권한을 체크한다.

 

(4) 적절한 권한이면 다음으로 요청된 프로세스로 이동한다.

 

(5) 적절한 권한이 아니라면, AccessDeniedException이 throws 되고, ExceptionTranslationFilter가 AccessDeniedException을 처리한다.