사용자 요청 -> DelegatingFilterProxy
사용자가 요청시 처음 요청을 받는 곳은 Sevlet Container(Was)
Was에서 스프링의 라이프사이클을 가질 수 없기에 스프링 빈에 접근을 못한다.
그래서 대리자 DelegaingFilterProxy에서 받아서.
FilterchainProxy에 전달을 하면 FilterChainProxy가 필터들을 호출 하면서 처리함
AuthenticationFilter
userNamePassword Authentication
가장 보편적이고 현업에서 많이 사용하는 위 방식 (Form Login)
Log Url로 요청하면 AuthenticationFilter가 받음
그리고 Authentication 구현체 만듬
아이디 패스워드 입력하면?(인증을 하면) 두개 에 정보를 저장
AuthenticationManager 호출 한다.
인증 처리를 실제적으로 처리할 수 있는 클래스를 찾아서 위임하는 역할
AuthenticationProvier -> 실제로 아이디와 pw 검증
위 클래스는 UserDetailsService 타입 class 사용
보통 UserDetailsService에서 아이디 추출 디비에서 조회
최종적으로 UserDetails 타입으로 만들어서 반환
그 다음으로 역순으로 반환
그리고 다시 패스워드 검증 . provider쪽에서 만 왓다갔다?
실패를 한다?
AuthenticationFilter 로
성공 하면? AuthenticationProvier는 Authentication 객체만듬
UserDetails 타입에 객체 권한을 저장
Authentication에 그리고 AuthenticationFilter에 저장하고
SecurityContext에 저장 -> 전역적으로 인증을 받았다는걸 보장 함.
언제든지 꺼내서 사용가능
ExceptionTranslationFilter
만약에 인증 인가 예외가 발생했을 때 처리 해주는 곳
FinterSecurityInterceptor ->
인가의 권한을 판단하는 곳
AccessDecisionManager -> Access DecisionVoter
접근을 허가 할 것인지 최종적 판단 -> 현재 사용자가 접근을 하고자하는 자원에 대한 권한을 투표( grant , deny , 보류 )
후속처리를 하게됨.
원래 더많은 클래스를 지나가지만 대충 흐름만 알수 있게 기록.
DelegatingFilterProxy: 이 필터는 서블릿 컨테이너에 의해 호출되지만, 실제 작업은 스프링의 FilterChainProxy에 위임합니다. 이렇게 함으로써, 스프링 빈들과의 상호작용이 가능해집니다.
AuthenticationFilter: 사용자가 로그인 시도를 할 때 이 필터가 동작합니다. 기본적으로 /login POST 요청을 가로챕니다. 사용자의 아이디와 패스워드를 추출하여 Authentication 객체를 만들고, 이를 AuthenticationManager에 전달합니다.
AuthenticationManager: AuthenticationManager는 인증을 처리하기 위한 AuthenticationProvider를 가지고 있습니다. AuthenticationProvider는 실제로 사용자의 아이디와 패스워드를 검증합니다.
UserDetailsService: 대부분의 인증 메커니즘에서 중요한 역할을 합니다. 데이터베이스나 다른 저장소에서 사용자 정보를 불러와서 UserDetails 객체로 반환합니다.
ExceptionTranslationFilter: 보안 관련 예외(인증 및 권한 관련)가 발생하면 이 필터가 동작합니다. 적절한 예외 처리(인증 요청 또는 에러 페이지 리다이렉트)를 수행합니다.
FilterSecurityInterceptor: 사용자의 요청이 특정 권한을 필요로 하는 리소스에 접근하려고 할 때 이 필터가 동작합니다.
AccessDecisionManager: 사용자가 요청한 리소스에 접근할 권한이 있는지 판단하는 역할을 합니다. 다양한 AccessDecisionVoter들을 통해 접근 허가, 거부, 보류 투표를 수행합니다.