들어가기 전에
공통 프로젝트 개발을 앞두고, 보안은 어떻게 할 것인가? 에 대한 고민을 해보았다. 이 고민은 온라인 플랫폼을 운영하는 기업이라면 모두 할 고민이다. 로그인, 관리자 등에 따라 권한을 다르게 줘야 하기 때문이다. 권환 관리의 정교함이 중요해짐에 따라, 홈페이지에 인증 및 권한 기능을 빠르게 부여해 인증 및 권한 보호 기능을 쉽게 추가할 수 있는 Spring Security 가 부상하고 있다.
여기서는 Spring Security가 무엇인지, 왜 사용하는지, 특징은 무엇인지, Spring Security의 아키텍처까지 알아볼 것이다.
Spring Security 란?
스프링 시큐리니란, 스프링 기반의 애플리케이션의 보안을 담당하는 스프링 하위 프레임워크이다. 주로 인증(Authentication), 인가(Authorization) 부여 및 데이터 보호 기능을 제공한다.
개발자는 회원가입, 로그인, 로그아웃, 세션 관리, 권한 관리 까지 사용자 관리 기능에 많은 시간을 쏟게 되는데, 이 프레임워크를 사용하면 보안 관련 기능을 쉽고 빠르게 구현 할 수 있게 도와준다. 보안 관련 로직을 일일이 작성하지 않아도 된다는 것이다.
인증과 인가
- 인증(Authentication)
- 증명
- 해당 사용자가 본인이 맞는지를 확인하는 절차이다.
- 로그인
- 인가(Authorization)
- 권한부여, 허가
- 인증된 사용자가 요청된 자원에 접근가능한가를 결정하는 절차이다.
Spring Security 특징
- Filter를 기반으로 동작하여, MVC와 분리되어 관리하고 동작할 수 있다.
- 어노테이션을 통해 간단하게 설정할 수 있다.
- 기본적으로 세션 & 쿠키 방식으로 인증한다.
- 인증 관리자(Authentication Manager)와 접근 결정 관리자(Access Decision Manager)를 통해 사용자의 리소스 접근을 관리한다.
- 인증 관리자는 UsernamePasswordAuthenticationFilter, 접근 결정 관리자는 FilterSecurityInterceptor가 수행한다.
Spring Security 필터
클라이언트가 요청을 보내면, 스프링 MVC에서는 DispatcherServlet이 가장 먼저 요청을 받는다. 이거에 관련해서는 MVC 패턴에 대해 배울 때 열심히 공부했으니 패스한다. 이 요청을 받기 전 다양한 필터가 존재할 수 있다.
필터는 클라이언트와 자원 사이에 요청과 응답 정보를 이용해 다양한 처리를 한다. Spring Security는 다양한 기능을 가진 필터들을 10개 이상 제공한다. 이 필터들을 Security Filter Chain 이라고 한다.
SecurityContextPersistenceFilter | SecurityContextRepository에서 SecurityContext를 가져오거나 저장한다. |
LogoutFilter | 설정된 로그아웃 URL로 오는 요청을 감시하며, 해당 유저를 로그아웃 처리 |
(UsernamePassword) AuthenticationFilter |
(아이디와 비밀번호를 사용하는 form 기반 인증) 설정된 로그인 URL로 오는 요청을 감시하며, 유저 인증 처리 [AuthenticationManager 통한 인증 처리] - 인증 성공 → 얻은 Authentication 객체를 SecurityContext에 저장 후 AuthenticationSuccessHandler 실행 - 인증 실패 → AuthenticationFailureHanlder 실행 |
DefaultLoginPageGeneratingFilter | 폼기반 또는 OpenID기반 인증에 사용하는 가상 URL에 대한 요청을 감시하고 로그인 폼 기능을 수행하는데 필요한 HTML을 생성 |
BasicAuthenticationFilter | HTTP 기본 인증 헤더를 감시하여 처리 |
RequestCacheAwareFilter | 로그인 성공 이후, 원래 인증 요청에 의해 가로채어진 사용자의 원래 요청을 재구성 |
SecurityContextHolderAwareRequestFilter | HttpServletRequestWrapper를 상속한 SecurityContextHolderAwareRequestWapper 클래스로 HttpServletRequest 정보를 감싼다. SecurityContextHolderAwareRequestWrapper 클래스는 필터 체인상의 다음 필터들에게 부가정보를 제공 |
AnonymousAuthenticationFilter | 이 필터가 호출되는 시점까지 사용자 정보가 인증되지 않았다면 인증토큰에 사용자가 익명 사용자로 나타남 |
SessionManagementFilter | 인증된 주체를 바탕으로 세션 트래킹을 처리해 단일 주체와 관련한 모든 세션들이 트래킹되도록 도움 |
ExceptionTranslationFilter | 보호된 요청을 처리하는 중에 발생할 수 있는 예외의 기본 라우팅과 위임, 전달하는 역할 |
FilterSecurityInterceptor | AccessDecisionManager 로 권한부여 처리를 위임함으로써 접근 제어 결정을 도움 |
Spring Security 인증 아키텍처
1. Http Request 수신
사용자가 로그인 정보와 함께 인증 요청을 한다.
2, 유저 자격을 기반으로 인증토큰 생성
AuthenticationFilter가 요청을 가로채고, 가로챈 정보를 통해 UsernamePasswordAuthenticationToken의 인증용 객체를 생성
3. Filter를 통해 AuthenticationToken을 AuthenticationManager로 위임
AuthenticationManager의 구현체인 ProviderManager에게 생성한 UsernamePasswordToken 객체를 전달한다.
4. AuthenticationProvide의 목록으로 인증 시도
AuthenticationManager는 등록된 AuthenticationProvider들을 조회하며 인증을 오구한다.
5. UserDetailsService의 요구
실제 데이터베이스에서 사용자 인증정보를 가져오는 UserDetailsService에 사용자 정보를 넘겨준다.
6. UserDetails를 이용해 User 객체에 대한 정보 탐색
넘겨받은 사용자 정보를 통해 데이터베이스에서 찾아낸 사용자 정보인 UserDetails 객체를 만든다.
7. User 객체의 정보들을 UserDetails가 UserDetailsService(LoginService)로 전달
AuthenticationProvider들은 UserDetails를 넘겨받고 사용자 정보를 비교한다.
8. 인증 객체 or AuthenticationException
인증이 완료되면 권한 등의 사용자 정보 담은 Authentication 객체를 반환한다.
9. 인증 끝
다시 최초의 AuthenticationFilter에 Authentication 객체가 반환된다.
10. SecurityContext에 인증 객체를 설정
Authentication 객체를 Security Context에 저장한다.
결과적으로, Spring Security는 인메모리 세션저장소인 SecurityContextHolder에 UserDetails정보를 저장한다.
그후 클라이언트에게 session ID(JSESSION ID)와 함께 응답을 하게 된다. 이후 요청에서는 요청 쿠키에서 JSESSION ID정보를 통해 이미 로그인 정보가 저장되어 있는지 확인한다. 이미 저장되어 있고 유효하면 인증처리를 해준다.
=> 세션 - 쿠키 인증 방식 사용
마치며
Spring Security에 대해 알아봤으니, 이제 실습을 해야할 시간이다. 다음주에는 로그인 기능을 구현해보고, 기회가 된다면 실제 프로젝트에 적용까지 해보고 글을 쓰고 싶다.
'Spring' 카테고리의 다른 글
[Spring Security] 다중 UserDetailsService 사용하기 (1) | 2024.08.04 |
---|---|
[Security] Spring Security 이모저모 정리 (2) | 2024.07.28 |
스프링내맘대로정리하기 1-2편 (환경 구성, 연관 관계) (0) | 2024.07.28 |
몽수의 Spring Scheduler (0) | 2024.07.28 |
바닥부터 알아보는 Spring Data JPA with MySQL (3) | 2024.07.14 |