[Spring Security] 새로 알게된 것

프로젝트의 스프링 시큐리티에 대해서 강의를 들으며 궁금증이 생겨 블로그를 찾아보며 공부 하던 도중 새로 알게 된 정보를 써보고자 합니다

HttpSecrity, WebSecurity

공부를 하면서 WebSecurity에 대해서 접해 찾아보니 기존에 사용했던 HttpSecurity 차이점은 아래와 같다고 한다.

• 실무에서 HttpSecurity의 permitAll이 설정된 endpoint에 잘못된 BearerToken 값이 들어오면 Security Filter Chain를 거치면서 에러를 반환하지만, WebSecurity는 ignoring이 설정된 잘못된 BearerToken 값이 들어와도 통과된다.
• 그래서 WebSecurity는 인증, 인가 서비스가 필요하지 않은 정적자원("/favicon.ico", "/resources/**", "/error")이나 로그인 페이지, public페이지에 사용한다.
  이외에는 HttpSecurity를 사용하는 것이 좋다.

Delegating FilterProxy, FilterChainProxy

Delegating FilterProxy라는 것이 어떻게 작동 되는지 확인하고자 하여 검색을 해보았다

일단 기본적인 필터, 필터 체인의 흐름은 아래와 같다
필터의 흐름

HTTP 요청 -> WAS -> 필터 -> 서블릿 -> 컨트롤러

필터체인

HTTP 요청 -> WAS -> 필터 1 -> 필터 2 -> 필터 3 -> 서블릿 -> 컨트롤러

• Delegating Filter proxy는 서블릿 스펙에 있는 기술이기 때문에 서블릿 컨테이너에서만 생성되고 실행된다.
• DelegatingFilterProxy는 springSecurityFilterChain 이름으로 생성된 빈을 ApplicationContext에서 찾아 요청을 위임한다. 실제로 보안 처리는 하지 않고 위임만 하는 Servlet Filter다.
• DelegatingFilterProxy는 이 Servlet 컨테이너와 Spring의 Ioc 컨테이너를 연결해주는 필터라고 생각하면 된다.
• 서블릿 필터라 스프링 빈과는 다르게 관리된다. ( DI, AOP 등 스프링 기능을 사용할 수 없음 )

• 1. HTTP요청이 들어오면 Servlet 컨테이너에서 요청을 받는다.

2. Servlet 컨테이너 내의 필터들이 동작하는 중간에 DelegatingFilterProxy Filter가 요청을 받으면 springSecurityFilterChain 이름으로 생성된 빈을 AnnotationConfigServletWebServerApplicationContext 객체에서 찾는다.
3. 이 찾은 Filter Bean이 바로 FilterChainProxy다.
   그 후에 FilterChainProxy Bean에 요청을 전달한다.
4. 이제 FilterChainProxy에서 필터들을 이용하여 보안처리를 진행한 후 최종적으로 SpringMVC의 DeispatcherServlet에 전달하여 요청에 대한 Servlet 처리를 하게 된다.

AuthenticationManager, AuthenticationProvider

• AuthenticationManager
  인증 처리하는 필터로부터 인증처리를 지시받는 첫번쨰 클라스
  id,와 password를 Authentication 인증 객체에 저장하고
  AuthenticationManager에게 전달하여 인증에 대해 관리를 한다고 한다.
• AuthenticationProvider
  ID와 Password가 검증하는 실질적인 클래스다. 위의 ProviderManager가 적절한 Provider 선택후 아래와 같은 로직이 동작 한다고 한다
  
  시큐리티는 깊게 파고들면 파고 들수록 알아야 할게 많은거 같아서 더 학습이 필요할거 같습니다

참고
https://soojae.tistory.com/55?category=1004847#AuthenticationManager-1