52일차 회고

이제 스프링 시큐어리티 작동 원리에 대해서 좀 알아보겠다.

 

일단 우선 
사용자---> 리소스요청---> 크리덴셜요구---> 사용자 크리덴셜 확인--->없을시(예외),있으면 ---> 인가확인(권한)---> 확인되면 리소스 OK 아니면 (예외)

 

서블릿 기반 어플리케이션일 경우, 애플리케이션의 앤드포인트에 요청이 도달하기 전에 중간에 요청을 가로챈 후 어떤 처리를 할 수 있는 포인트를 제공하는데 그것이 서블릿 필터입이다.

즉 서블릿 필터는 하나 이상의 필터들을 연결해 필터 체인(Filter Chain)을 구성할 수 있다.

Spring Security도 마찬가지로 서블릿 필터를 사용하고, DelegatingFilterProxy가  서블릿 컨테이너 영역의 필터와 ApplicationContext에 Bean으로 등록된 필터들을 연결해주는 브리지 역할을 한다.

 

FilterChainProxy는 Spring Security의 Filter를 사용하기 위한 진입점이 바로 FilterChainProxy이다.

 

do filter()를 구현해 놓았다면 endpoint로 가기전에 전 후 처리를 할 수 있다.

Encoder에는

PasswordEncoder passwordEncoder = PasswordEncoderFactories.createDelegatingPasswordEncoder();

선언을 이런 형식으로하고, 
encode하는 방식은 정말 여러가지가 있다. 각각 장점이 있기떄문에 상황에 맞게 쓰는게 맞다. 

 

1. 사용자가 login form을 통해서 id,password가 포함한 request를 Spring Security가 적용된 애플리케이션에 전송하면.

spring security의 filter chain에서 UsernamePasswordAutenticationFilter가 해당 요청을 받습니다.

2. UsernamePasswordAuthenticationFileter는 Authentication인터페이스를 구현한 클래스이며, 
username과 passowrd를 사용하여 UsernamePassowrdAuthenticationToken을 생성합니다.

3. AuthenticationManager에게 Authentication을 전달합니다.

4. AuthenticationManger을 구현한 ProviderManger가 이것을 받고 , 이것을 AuthenticationProvider에게 준후 UserDetailsServie를 사용하여 UserDetails를 조회합니다. 
저희가 앞서 만들었던 것이 UserDetails를 구현한 저희만에 UserDeatilsService와 UserDetails를 만들었던것이 여기서 사용됩니다.

 

5.UserDetails를 전달받은 AuthenticationProvider는 PasswordEncoder를 이용해 비밀번호를 확인한후 , 다시 거꾸로 Authentication을 전달합니다. 

 

이렇게 로그인을 성공한 이후에는 

AuthorizationFilter는

@Nullable
	AuthorizationDecision check(Supplier<Authentication> authentication, T object);

 filter는 Security contextHolder를 통해서 Authenication을 획득하고 , SecurityContextHolder로부터 획득한 Authentication과 HttpServletRequest를 AuthorizationManager에게 전달합니다.

check라는 메서드를 통해 확인한다.

• check() 메서드의 내부에서 (1)과 같이 루프를 돌면서 RequestMatcherEntry 정보를 얻은 후에 (2)와 같이 RequestMatcher 객체를 얻습니다.
• (3)과 같이 MatchResult.isMatch()가 true이면 AuthorizationManager 객체를 얻은 뒤, 사용자의 권한을 체크합니다.