웹 어플리케이션을 사용하다 보면 로그인, 로그아웃을 하게 된다. 이렇게 아이디와 암호를 이용해서 로그인 하는 과정을 인증(Authentication)이라고 한다.
네이버 카페를 사용해보면 로그인을 했다 하더라도, 특정 카페는 회원가입을 하고 어느정도 이상의 등급이 되지 않을 경우 이용을 못하기도 한다. 이를 인가(Authorization)라고 한다.
Spring Security를 사용하면 편리하게 인증/인가를 구현할 수 있다.
Spring Security란?
- 스프링 시큐리티는 스프링 기반 어플리케이션의 보안(인증과 권한)을 담당하는 프레임워크이다.
- 만약 스프링 시큐리티를 사용하지 않았다면, 자체적으로 세션을 체크하고 리다이렉트 등을 해야 할 것이다.
- 스프링 시큐리티는 보안과 관련해서 체계적으로 많은 옵션들을 지원준다.
- 스프링 시큐리티는 Filter 기반으로 동작하기 때문에 Spring MVC 와 분리되어 관리 및 동작한다.
보안 용어
| 보안 용어 | 의미 |
|---|---|
| 접근 주체(Principal) | 보호된 대상에 접근하는 유저 |
| 인증(Authentication) | 인증은 '증명하다'라는 의미로 예를 들어, 유저 아이디와 비밀번호를 이용하여 로그인하는 과정을 말한다. |
| 인가(Authorization) | '권한부여'나 '허가'와 같은 의미로 사용된다. 즉, 어떤 대상이 특정 목적을 실현하도록 허용(Access)하는 것을 말한다. |
| 권한 | 인증된 주체가 어플리케이션의 동작을 수행할 수 있도록 허락되었는지 결정할 때 사용한다. |
Spring Security Filter
- 클라이언트(보통 브라우저)는 요청을 보내고, 그 요청을 서블릿이나 JSP등이 처리한다.
- Spring MVC에서는 요청을 가장 먼저 받는 것이 DispatcherServlet이다. 이 DispatcherServlet이 요청 받기 전에 다양한 Filter들이 있을 수 있다.
- Filter가 하는 역할은 클라이언트와 자원 사이에서 요청과 응답 정보를 이용해 다양한 처리를 하는 것이다. 어떤 Filter는 요청을 받은 후, 클라이언트가 원래 요청한 자원이 아닌 다른 자원으로 redirect 시킬 수도 있다. 또 어떤 Filter는 다음 Filter에게 요청과 응답을 전달하지 않고, 바로 클라이언트에게 응답하고 끝낼 수도 있다.
Security Filter Chain
- Spring Security는 다양한 기능을 가진 Filter를 10개 이상 기본적으로 제공한다. 이렇게 제공되는 Filter를 Security Filter Chain이라고 한다.
- 위의 그림은 Security Filter Chain과 각각의 Filter에서 사용하는 객체들(Repository, Handler, Manager등)에 대해 잘 표현하고 있다.
- 먼저, Spring Security가 제공하는 Filter들이 어떤 역할을 담당하는지 정리해보자.
| Filter | 역할 |
|---|---|
| SecurityContextPersistenceFilter | SecurityContextRepository에서 SecurityContext를 가져오거나 저장하는 역할을 한다. |
| LogoutFilter | 설정된 로그아웃 URL로 오는 요청을 감시하며, 해당 유저를 로그아웃 처리 |
| (UsernamePassword)AuthenticationFilter | (아이디와 비밀번호를 사용하는 form 기반 인증) 설정된 로그인 URL로 오는 요청을 감시하며, 유저 인증 처리한다. 1. AuthenticationManager를 통한 인증 실행 2. 인증 성공 시, 얻은 Authentication 객체를 SecurityContext에 저장 후 AuthenticationSuccessHandler 실행 3. 인증 실패 시, AuthenticationFailureHandler 실행 |
| DefaultLoginPageGeneratingFilter | 인증을 위한 로그인폼 URL을 감시한다. |
| BasicAuthenticationFilter | HTTP 기본 인증 헤더를 감시하여 처리한다. |
| RequestCacheAwareFilter | 로그인 성공 후, 원래 요청 정보를 재구성하기 위해 사용된다. |
| SecurityContextHolderAwareRequestFilter | HttpServletRequestWrapper를 상속한 SecurityContextHolderAware RequestWapper 클래스로 HttpServletRequest 정보를 감싼다. Security ContextHolderAwareRequestWrapper 클래스는 필터 체인상의 다음 필터들에게 부가정보를 제공한다. |
| AnonymousAuthenticationFilter | 이 필터가 호출되는 시점까지 사용자 정보가 인증되지 않았다면 인증토큰에 사용자가 익명 사용자로 나타난다. |
| SessionManagementFilter | 이 필터는 인증된 사용자와 관련된 모든 세션을 추적한다. |
| ExceptionTranslationFilter | 이 필터는 보호된 요청을 처리하는 중에 발생할 수 있는 예외를 위임하거나 전달하는 역할을 한다. |
| FilterSecurityInterceptor | 이 필터는 AccessDecisionManager 로 권한부여 처리를 위임함으로써 접근 제어 결정을 쉽게 해준다. |
Spring Security 인증관련 아키텍처
- 아이디와 암호를 입력했을 때 이를 처리하는 Filter는 AuthenticationFilter이다.
- 해당 Filter는 다음 그림과 같은 순서로 동작한다.
위의 그림을 보며 어떤 일이 일어나는지 보자
- 클라이언트(유저)가 로그인을 시도한다.
- AuthenticationFilter는 AuthenticationManager, AuthenticationProvider(s), UserDetailsService를 통해 DB에서 사용자 정보를 읽어온다. 여기서 중요한 것은 UserDetailsService가 인터페이스라는 것이다. 해당 인터페이스를 구현한 Bean을 생성하면 스프링 시큐리티는 해당 Bean을 사용하게 된다. 즉, 어떤 DB로부터 읽어들일지 스프링 시큐리티를 이용하는 개발자가 결정할 수 있게 된다.
- UserDetailsService는 로그인한 ID에 해당하는 정보를 DB에서 읽어들여 UserDetails를 구현한 객체로 반환한다. 개발자는 UserDetails를 구현한 객체를 만들어야 할 필요가 있을 수 있다. 따라서 UserDetails 정보를 세션에 저장한다.
- 스프링 시큐리티는 인메모리 세션저장소인 SecurityContextHolder에 UserDetails 정보를 저장한다.
- 클라이언트(유저)에게 session ID(JSESSION ID)와 함께 응답을 한다.
- 이후 요청에서는 요청 쿠키에서 JSESSION ID정보를 통해 이미 로그인 정보가 저장되어 있는 지 확인한다. 이미 저장되어 있고 유효하면 인증 처리를 해준다.
reference
https://youmekko.github.io/2018/04/26/2018-04-26-Filter/
https://atin.tistory.com/590
https://springbootdev.com/2017/08/23/spring-security-authentication-architecture/
Enjoy to study