[Spring Security] What is Spring Security?

서론

Java 애플리케이션의 보안을 위한 강력하고 확장 가능한 프레임워크인 Spring Security가 무엇인지 알아보고 어떻게 돌아 가는지 알아보고자 한다.

 

---

개념

Spring 기반 애플리케이션의 핵심 보안 기능인 인증(Authentication)과 인가(Authorization)를 돕는 프레임워크

• 필터 기반 아키텍처로 동작한다.
• 클라이언트의 요청은 일련의 보안 필터들로 구성된 필터 체인(Filter Chain)을 순차적으로 통과하며 처리
• 이러한 필터들은 요청이 최종 목적지인 컨트롤러에 도달하기 전에 인증 및 인가와 관련된 다양한 보안 작업을 수행

 

Filter & Interceptor

• Spring Security는 Spring MVC의 Dispatcher Servlet 보다 앞인 Servlet Container 내부에 존재하는 Filter에서 시작한다.
• 클라이언트가 애플리케이션으로 요청을 보내면 컨테이너는 요청 URI 경로를 따라 HttpSevletRequest를 처리해야 하는 필터 인스턴스와 서블릿을 포함하는 FtilerChain을 생성한다.

Filter

HTTP 요청 ➜ WAS ➜ 필터 ➜ 서블릿( DispatcherServlet ) ➜ Controller

 

Filter는

• 다운 스트림 필터 인스턴스(Downstream Filter Instance) 또는 서블릿이 호출되지 않도록 한다. 이 경우 필터는 일반적으로 HttpServletResponse를 작성한다.
• 다운 스트림 필터 인스턴스 및 서블릿에서 사용하는 HttpServletRequest 또는 HttpServletResponse를 수정한다.

 => Filter는 DispatcherServlet으로 가기 전에 호출되며, 필터가 적절하지 못한 요청이라고 판단하면 서블릿 호출 X

 

필터는 다운 스트림 필터 인스턴스와 서블릿에만 영향을 미치므로 각 필터가 호출되는 순서는 매우 중요

 

Interceptor

HTTP 요청 ➜ WAS ➜ 필터 ➜ 서블릿 ➜ 스프링 인터셉터 ➜ Controller

Intercepter는 Spring이 제공하는 기술이고, Spring MVC의 시작점이 DispatcherServlet 이기 때문에 서블릿 뒤에서 호출

 

인증 (Authentication)

• 해당 사용자가 본인인지 확인하는 절차
• 요청을 보낸 접근 주체가 누구인지, 즉 사용자의 진본성 여부를 확인하는 것
• 사용자는 주로 비밀번호와 같은 자격 증명을 제공
• Spring Security는principal(인증 요청 주체) - credential(증명) 패턴으로 구성

인가 (Authorization)

• 인증된 사용자가 요청한 자원(리소스)에 접근 가능한지 결정하는 절차
• 사용자의 신원이 증명된 이후 해당 사용자가 특정 동작이나 리소스에 접근할 수 있는 권한이 있는지 확인하는 과정
• 웹 요청 권한, 메서드 호출 및 도메인 인스턴스에 대한 접근 권한 부여 영역이 있음

---

Spring Security의 구성 요소

[ 필터 체인 (Filter Chain) ]

• 클라이언트의 요청은 여러 보안 필터로 구성된 체인을 순서대로 통과하며 처리
• 각 필터는 특정 보안 작업을 담당하며, 요청이 최종 목적지에 도달하기 전에 인증 및 인가 관련 처리를 수행
• 스프링 시큐리티의 필터 체인은 다중으로 설정하여 URL 패턴별로 별도 구성이 가능

[ Authentication 객체 ]

• 인증 절차는 사용자가 넘긴 이 객체를 통해 진행되며, 인증 요청 정보(예: 아이디/패스워드)를 담고 있음
• 인증 절차 전반에 걸쳐 참조되고 수정되며, 인증 성공 시 결과 Authentication 객체가 반환
• Principal(인증된 사용자), Credentials(자격 증명), Authorities(권한 목록), Authenticated status(인증 여부) 등의 정보를 포함

[ AuthenticationManager ]

• 스프링 시큐리티 인증 절차의 중추
• 클라이언트로부터 전달받은 인증용 객체(Authentication)를 가지고 인증 처리를 위임
• 등록된 여러 개의 AuthenticationProvider를 가지고 인증을 시도(authenticate() 메서드를 통해 인증을 수행)
• 주로 ProviderManager를 사용

[ ProviderManager ]

•  AuthenticationManager의 일반적인 구현체
• 자신이 가진 AuthenticationProvider들을 순회하며 인증을 시도
• 다른 AuthenticationManager를 부모로 가질 수 있어 자신이 처리할 수 없는 인증 요청은 부모에게 위임

[ AuthenticationProvider ]

• 실제로 인증을 수행하는 주체
• 전달받은 Authentication 객체를 처리 가능한지 supports() 메서드로 확인, 처리 가능하다면 authenticate() 메서드를 호출하여 인증을 시도
• 인증에 성공하면 결과 Authentication 객체를 반환, 실패하면 AuthenticationException을 발생
• 해당 Provider가 핸들링할 수 없다면 다음 Provider가 이를 수행

[ UserDetailsService ]

• AuthenticationProvider가 사용자의 상세 정보를 가져오기 위해 사용하는 인터페이스
• 사용자 이름(username)을 인자로 받아 DB 등에서 사용자 정보를 조회하여 UserDetails 타입으로 반환

[ UserDetails ]

• 사용자의 상세 정보(비밀번호, 권한 등)를 담는 인터페이스로, 개발자가 직접 상속받아 사용 가능
•  프로젝트의 회원 정보에 관한 다른 정보(이메일, 나이, 주소 등)를 추가하여 사용 가능

[ SecurityContextHolder ]

• 인증에 성공하여 얻은 Authentication 객체를 저장하고 제공하는 Spring Security의 핵심
• 현재 인증된 사용자와 관련된 보안 정보를 저장
• 애플리케이션의 현재 스레드에서 SecurityContext 객체를 유지하여 인증 정보에 접근 가능 하도록 함
• SecurityContext: 현재 인증된 사용자와 관련된 정보를 담고 있으며 Authentication 객체를 포함

[ ThreadLocal ]

• SecurityContextHolder는 기본적으로 ThreadLocal을 사용하여 현재 요청을 처리하는 스레드의 메모리에 SecurityContext 객체를 저장
• 요청별 독립성을 보장, 스레드 풀 사용 시 이전 요청 정보가 남아 있는 것을 방지
• 요청이 끝나면 메모리에서 자동으로 제거

[ 인가 구현 ]

• 인가는 주로 FilterSecurityInterceptor나 AuthorizationFilter와 같은 필터에 의해 처리
• SecurityContextHolder에 저장된 인증된 사용자 정보(Authentication 객체)와 리소스에 정의된 보안 규칙을 기반으로 사용자가 해당 리소스에 접근할 권한이 있는지 확인

---

Spring Security의 주요 흐름

Spring Security는 Servlet Filter 기반으로 동작하며, HTTP 요청이 웹 애플리케이션으로 들어올 때부터 응답이 나갈 때까지 다양한 보안 검사를 수행한다. 이 모든 과정은 FilterChainProxy라는 핵심 컴포넌트가 관리하는 여러 SecurityFilterChain에 의해 이루어진다.

 

1. 요청 수신 및 진입점 (DelegatingFilterProxy & FilterChainProxy)

• HTTP 요청 수신: 사용자의 웹 브라우저나 클라이언트로부터 HTTP 요청(예: GET /home, POST /login)이 서블릿 컨테이너(Tomcat, Jetty 등)로 들어옴
• DelegatingFilterProxy: 모든 HTTP 요청은 서블릿 컨테이너에 의해 가장 먼저 DelegatingFilterProxy로 전달          (이 프록시 필터는 서블릿 컨테이너와 Spring 애플리케이션 컨텍스트를 연결하는 다리 역할).
• FilterChainProxy로 위임: DelegatingFilterProxy는 실제 Spring 애플리케이션 컨텍스트에 Bean으로 등록된 FilterChainProxy에게 요청 처리를 위임
• FilterChainProxy의 역할
  •  FilterChainProxy는 들어온 HTTP 요청의 URL 패턴을 기반으로, 미리 설정된 여러 SecurityFilterChain 중에서 가장 먼저 매칭되는 SecurityFilterChain 하나를 선택
  • 각 SecurityFilterChain은 특정 경로(RequestMatcher)에 대한 보안 규칙과 필터들의 집합
  • 이 시점에서 다른 SecurityFilterChain들은 더 이상 검사되지 않음

2. 선택된 SecurityFilterChain 내부의 필터 순서 및 역할

선택된 SecurityFilterChain 내의 필터들은 다음과 같은 일반적인 순서로 실행되며, 각 필터는 특정 보안 기능을 담당

• DisableEncodeUrlFilter
  • URL에 세션 ID가 포함되어 노출되는걸 방지하기 위해 URL 인코딩을 비활성화(세션 고정 공격 방지)
• ForceEagerSessionCreationFilter
  • 세션이 필요할 때 바로 세션을 생성하도록 강제
• ChannelProcessingFilter
  • HTTP 요청의 프로토콜(HTTP/HTTPS)을 확인하고, 필요한 경우 강제로 전환하거나 접근을 차단
  • ex) 민감한 정보 전송 시 HTTPS를 강제
• WebAsyncManagerIntegrationFilter
  • 웹에서 비동기 작업이 수행될 때, 현재 요청 스레드의 SecurityContext가 비동기 스레드에서도 유지되도록 통합
  • 비동기 호출에서도 사용자 인증 정보가 손실되지 않도록 보장
• SecurityContextHolderFilter (Spring Security 6의 기본, 이전 버전의 SecurityContextPersistenceFilter)
  • SecurityContextHolder와 HTTP 세션 간의 SecurityContext 동기화를 담당.
    • 요청 시작 시: HTTP 세션에서 SecurityContext를 조회하여 SecurityContextHolder (기본적으로 ThreadLocal 사용)에 설정, 만약 세션에 없으면 새로운 SecurityContext를 생성
    • 요청 완료 시: SecurityContextHolder에 있는 SecurityContext를 HTTP 세션에 저장하거나 업데이트, SecurityContextHolder를 초기화(다음 요청에 영향을 주지 않도록 하기 위해)
  • 이후 처리: SecurityContextHolder에 저장된 인증 정보는 이후 인가 절차나 애플리케이션의 비즈니스 로직에서 현재 인증된 사용자의 정보를 가져와 활용하는 데 사용
• HeaderWriterFilter
  • HTTP 응답 헤더에 보안 관련 정보를 추가
  • ex) X-Frame-Options (클릭재킹 방지), X-Content-Type-Options (MIME 스니핑 방지), HSTS (HTTP Strict Transport Security) 등의 헤더를 설정
• CsrfFilter
  • CSRF(Cross-Site Request Forgery) 공격을 방어
  • POST, PUT, DELETE와 같은 상태 변경 요청에 대해 CSRF 토큰 유효성을 검증
• LogoutFilter
  • 미리 설정된 로그아웃 요청 URL(예: /logout)을 감시
  • 요청이 해당 URL로 들어오면 사용자의 세션을 무효화하고, SecurityContext를 초기화하며, 필요한 경우 쿠키를 삭제하는 등 로그아웃 처리를 수행
• 인증 관련 필터 (Authentication Filters)
  • UsernamePasswordAuthenticationFilter
    • 폼 기반 로그인(사용자 이름과 비밀번호) 요청을 처리
    • 설정된 로그인 URL(기본 /login)로 POST 요청이 오면, 요청에서 사용자 이름과 비밀번호를 추출하여 UsernamePasswordAuthenticationToken과 같은 Authentication 객체를 생성
  • BasicAuthenticationFilter
    • HTTP Authorization 헤더에 담긴 Base64 인코딩 된 사용자 이름과 비밀번호를 추출하여 기본 인증(Basic Authentication)을 처리
  • OAuth2LoginAuthenticationFilter / Saml2WebSsoAuthenticationFilter / JwtAuthenticationConverter 관련 필터 등
    • 각각 OAuth 2.0/OpenID Connect, SAML 2.0 SSO, JWT(JSON Web Token) 등 다양한 인증 방식을 처리하는 필터
    • 이들도 자신의 방식에 맞는 Authentication 객체를 생성하여 AuthenticationManager에게 인증을 위임
• RememberMeAuthenticationFilter
  • "Remember Me" 기능을 구현(사용자가 브라우저를 닫고 다시 열어도 로그인 상태가 유지)
  • 세션이 만료된 후에도 RememberMeServices를 사용하여 저장된 토큰을 기반으로 사용자를 자동으로 재인증  (기본 유효 기간 2주)
• ConcurrentSessionFilter
  • 동일한 사용자 계정으로 여러 세션에서 동시에 로그인하는 것을 제어하는 동시 세션 제어를 담당
  • 특정 세션을 만료시키거나 새로운 로그인을 거부할 수 있음
• RequestCacheFilter
  • 인증이 필요한 리소스에 접근하려 했으나 아직 로그인되지 않은 사용자가 로그인 페이지로 리다이렉트될 경우, 원래 접근하려던 요청 정보를 캐시에 저장
  • 로그인 성공 후 해당 캐시된 요청으로 다시 리다이렉트하여 UX을 향상
• ServletApiRequestFilter
  • 서블릿 API에 HttpServletRequest의 보안 관련 메서드(예: isUserInRole(), getUserPrincipal())를 통합
  • SecurityContextHolder에 저장된 인증 정보를 활용
• AnonymousAuthenticationFilter
  • SecurityContextHolder에 인증 정보가 없는 사용자에게 임시로 "익명" 사용자 (AnonymousAuthenticationToken)를 할당
  • 인증되지 않은 사용자도 특정 리소스에 대해 최소한의 접근 권한을 가지도록 함
    (기본 name: anonymousUser, role: ROLE_ANONYMOUS)
• SessionManagementFilter
  • 인증된 사용자의 세션과 관련된 전반적인 관리를 수행
  • 새로운 세션 ID 부여, 유효하지 않은 세션 처리, 세션 타임아웃, 동시성 제어 등의 정책을 시행
• ExceptionTranslationFilter
  • 필터 체인에서 발생하는 AuthenticationException(인증 실패) 또는 AccessDeniedException(인가 실패) 예외를 캐치하여 적절히 처리
    • AuthenticationException 발생 시: AuthenticationEntryPoint를 호출, 일반적으로 로그인 페이지로 리다이렉트 하거나 WWW-Authenticate 헤더를 포함한 401 Unauthorized 응답을 반환
    • AccessDeniedException 발생 시: AccessDeniedHandler를 호출, 일반적으로 403 Forbidden 응답을 반환하거나 접근 거부 페이지로 리다이렉트
• AuthorizationFilter (Spring Security 6의 기본 권한 부여 필터)
  • 필터 체인의 가장 마지막에 위치하여, 실제 리소스(URL, 메서드 등)에 대한 권한 부여(Authorization)를 담당
  • SecurityContextHolder에 저장된 Authentication 객체(인증된 사용자 정보)를 기반으로 AuthorizationManager를 호출하여 현재 사용자가 요청된 리소스에 접근할 권한이 있는지 최종적으로 확인

3. 응답 반환

• 모든 필터 처리가 완료되고, 필요한 경우 AuthorizationFilter를 통해 권한까지 부여되었다면, HTTP 요청은 최종적으로 컨트롤러나 REST 엔드포인트로 전달되어 비즈니스 로직을 수행
• 비즈니스 로직 처리 후 생성된 응답은 필터 체인을 역순으로 다시 거치며, 각 필터는 응답 헤더 추가
• (HeaderWriterFilter), 세션 정리(SecurityContextHolderFilter) 등의 작업을 수행한 후 클라이언트에게 최종적으로 전달

---

인증 과정(Form Login 예시)

1. 요청 수신: 사용자의 로그인 정보(아이디, 비밀번호 등)가 담긴 HTTP 요청을 수신
   
   
2.  필터에 의한 요청 가로챔: AuthenticationFilter가 이 요청을 가로챔
   
   
3. Authentication 객체 생성: 요청으로부터 사용자의 자격 증명 정보를 추출하여 인증용 객체(Authentication)를 생성(UsernamePasswordAuthenticationToken의 인증용 객체를 생성)
   
   
4.  AuthenticationManager에게 위임: 생성된 Authentication 객체는 AuthenticationManager에게 전달되어 인증 처리가 위임 (ProviderManager는 이 객체를 인자로 받아 인증 절차를 시작)
   
   
5. AuthenticationProvider 선택 및 인증 시도: AuthenticationManager는 자신이 가진 여러 AuthenticationProvider들 중 해당 Authentication 객체를 처리할 수 있는 Provider를 찾아 인증 처리를 다시 위임
   
   
6. UserDetailsService를 통한 사용자 정보 조회: 선택된 AuthenticationProvider는 UserDetailsService를 통해 사용자의 username을 기반으로 DB 등에서 사용자 상세 정보(UserDetails)를 조회
   
   
7. 자격 증명 비교 및 인증 수행: AuthenticationProvider는 클라이언트가 보낸 자격 증명과  UserDetails의 정보를 비교
   
   
8. 인증 성공/실패 처리
   
   • 성공: 인증에 성공하면 AuthenticationProvider는 인증된 사용자 정보를 담은 Authentication 객체를 반환
     • 이 객체는 ProviderManager를 거쳐 최종적으로 성공 결과로 처리
   • 실패: 인증에 실패하면 AuthenticationProvider는 AuthenticationException을 발생, ProviderManager를 거쳐 예외 처리
     • ExceptionTranslationFilter가 이러한 예외를 처리하여 로그인 페이지로 리다이렉트하는 등의 적절한 응답을 반환
   • 만약 모든 Provider가 핸들링에 실패하거나 처리할 수 없는 경우, ProviderNotFoundException이 발생
9. SecurityContextHolder에 저장: 인증이 완료되면 결과로 반환된 Authentication 객체는 SecurityContextHolder에 저장 SecurityContextHolder는 기본적으로 ThreadLocal을 사용하여 현재 요청 스레드의 SecurityContext에 이 정보를 추가
   
   
10. 이후 처리: SecurityContextHolder에 저장된 인증 정보는 이후 인가 절차나 애플리케이션의 비즈니스 로직에서 현재 인증된 사용자의 정보를 가져와 활용하는 데 사용