[이론정리] 스프링 시큐리티의 체인 구조 및 동작 방식

필터 체인 부터 설명을 하자면, 스프링에는 많은 필터가 존재한다.

출처 : http://atin.tistory.com/590

이를 하나씩 훑어보자.

• SecurityContextPersistenceFilter - 요청(request)전에, SecurityContextRepository에서 받아온 정보를 SecurityContextHolder에 주입한다.
• LogoutFilter - 유저의 로그아웃을 진행한다. 
• UsernamePasswordAuthenticationFilter - 주어진 아이디와 비밀번호로 로그인 인증을 진행한다.
• DefaultLoginPageGeneratingFilter - 추가된 로그인 방식이 없다면, 스프링 기본으로 로그인을 처리한다.
• BasicAuthenticationFilter - HTTP 요청의 (BASIC)인증 헤더를 처리하여 결과를 SecurityContextHolder에 저장한다.(로그인 방식은 jwt를 만들며 정리해야겠다)
• RememberMeAuthenticationFilter - SecurityContext에 인증객체가 있는지 확인 하고 RememberMeServices를 구현한 객체의 요청이 있을 경우, Remember-Me를 인증 토큰으로 컨텍스트에 주입한다.
• AnonymousAuthenticationFilter - SecurityContextHolder에 인증(Authentication) 객체가 있는지 확인하고, 필요한 경우 Authentication 객체를 주입한다.
• SessionManagementFilter - 요청이 시작된 이 후 인증된 사용자 인지 확인하고, 인증된 사용자일 경우SessionAuthenticationStrategy를 호출하여 세션 고정 보호 메커니즘을 활성화하거나 여러 동시 로그인을 확인하는 것과 같은 세션 관련 활동을 수행한다.
• ExceptionTranslationFilter - 필터 체인 내에서 발생(Throw)되는 모든 예외(AccessDeniedException, AuthenticationException)를 처리한다.
• FilterSecurityInterceptor - HTTP 리소스의 보안 처리를 수행한다.

해당 내용들에 대해서 후에 코드를 쓸 때 링크를 삽입해 수정할 계획이다. 

 

시큐리티의 체인이 존재할 때, 각 체인에 대해 @Bean을 통해 기능을 주입하거나, 수정하는 방식으로 처리할 수 있다. 

기본적으로 로그인 요청이 온다고 가정해보자. 해당 그림이 정확하게 이해되는 그 순간 이 글을 수정하겠지만, 지금 내가 가진 지식을 기준으로 머리속을 정리해보아야 겠다. 

1. http프로토콜 요청이 들어온다. 
2. 이를 UsernamePasswordAuthenticationFilter에서 토큰이 있는지 확인한다. 만약 이미 로그인을 했고 토큰이 있다면, 인증이 된 것이므로 바로 요청한 값을 주면 되지만, 없다면 인증을 진행해야 한다. 
3. Filter에서 AuthenticationManager에게 정보를 주고, 이는 주입이 계속되어 그림 6번까지 이어진다. 
4. UserDetailsService에서 해당 값들중에 토큰으로 만들 값들을 가져가 AuthenticationFilter까지 간다. 
5. 여기에서 토큰의 타입(jwt, bearer등), 토큰에 사용할 내용 종합, 암호화를 거친다.
6. 거친 토큰을 사용자에게 주고, 이를 서버또한 가지고 있는다. 
7. 후에 다른 요청이 들어올 때 토큰을 비교해 권한을 인증해준다.