둔필승총

보안 용어

인증(authentication)

인증(authentication)은 사용자가 누구인지 확인하는 단계이고 보통 로그인을 의미한다.
사용자는 아이디와 패스워드를 입력하면 로그인은 데이터베이스에 등록되어있는지 일치 여부를 확인하고, 서버는 응답으로 사용자에게 토큰(token)을 전달한다.

인가(authorization)

인가(authorization)은 사용자가 애플리케이션 내부의 리소스에 접근할 때 사용자가 해당 리소스에 접근할 권리가 있는지를 확인하는 과정을 의미한다. 로그인한 사용자가 게시판에 접근해서 글을 보려고 하는 경우 게시판 접근 등급을 확인해서 접근을 허가하거나 거부하는 것이 인가이다.
인증 단계에서 발급받은 토큰이 인가 내용을 포함하고 있으며, 사용자가 리소스에 접근하면서 토큰을 함께 전달하는 식으로 진행하여 서버는 토큰을 통해 권한 유무 등을 확인해서 인가를 수행한다.

접근 주체(principal)

접근 주체는 애플리케이션 기능을 사용하는 주체를 의미한다. 인증과 인과 과정을 거쳐서 접근 주체에게 부여된 권한을 확인하는 과정을 거친다.

스프링 시큐리티 (Spring Security)

스프링 시큐리티도 일종의 보안 프레임워크이기 때문에 공부가 필요했다.

동작 구조

스프링 시큐리티는 서블릿 필터(Servlet Filter)를 기반으로 동작하며, 스프링이 가지는 서블릿 컨테이너인 DispatcherServlet 앞에, 필터가 배치되어 있다.

필터체인이라는 것이 Dispatcher Servlet 앞에 존재해서 클라이언트가 request를 보내면 먼저 맞닥뜨리게 된다.

필터체인

필터 체인(Filter Chain)은 웹 애플리케이션에서 요청을 처리하는 과정에서 여러 개의 필터가 순차적으로 실행되는 구조를 말한다. 필터 체인은 클라이언트로부터의 요청이 서블릿에 도달하기 전과 응답이 클라이언트에게 전달되기 전에 요청과 응답을 가공하거나 검증하는 역할을 수행한다.

필터 체인 동작 순서

클라이언트로부터의 요청이 서블릿 컨테이너에 도달하면, 요청은 필터 체인의 시작 지점인 필터 체인의 진입점으로 전달되어서 필터 체인의 첫 번째 필터부터 순차적으로 실행된다. 마지막 필터가 실행되고 나면 요청이 서블릿에 도착해서 실제 작업을 수행하고 응답도 똑같이 필터 체인의 뒤에서부터 전달된다.

스프링 시큐리티의 사용 이유

ApplicationFilterChain은 서블릿 컨테이너에서 기본적으로 제공되는 필터 체인의 구현이다. 물론, Spring Security를 사용하지 않고도 ApplicationFilterChain을 통해 보안과 관련된 인증과 인가를 처리할 수 있다. 

 보안과 관련된 인증과 인가 작업은 일반적으로 서블릿 필터를 사용하여 처리할 수 있다. 예를 들어, 사용자의 인증 정보를 확인하고 세션 관리를 수행하는 필터를 구현하여 인증 작업을 처리할 수 있다. 또한, 요청에 따라 특정 리소스에 대한 접근 권한을 확인하는 필터를 구현하여 인가 작업을 처리할 수도 있다.

ApplicationFilterChain은 필터 체인 내에서 필터들을 연결하여 원하는 순서로 실행할 수 있기 때문에, 보안 관련 필터들을 적절히 구성하면 보안 요구사항을 처리할 수 있지만 직접 필터를 구현하고 관리해야 한다는 점에서 Spring Security와 비교하면 개발 및 유지보수의 복잡성이 높아질 수 있기 때문에 Spring Security를 사용하게 된다. (프레임워크의 장점!)

Spring Security는 보안에 특화된 기능과 설정을 제공하여 보다 쉽고 강력한 보안 솔루션을 제공한다. Spring Security를 사용하면 인증, 인가, 세션 관리, CSRF 방어, XSS 방어 등의 보안 기능을 편리하게 구현하고 관리할 수 있다.

그래서 스프링 프레임워크에서 필터 체인을 활용하여 다양한 기능을 구현할 수 있으며, Spring Security의 SecurityFilterChain은 그 중 하나의 예이다.

두 FilterChain은 서로 다른 목적을 가지고 있다. ApplicationFilterChain은 서블릿 컨테이너에서 일반적인 필터 체인을 관리하고 실행하는 역할을 수행하며, SpringFilterChain은 Spring Security에서 보안 관련 필터 체인을 관리하고 실행하는 역할을 수행하게 된다.

스프링 시큐리티 동작

클라이언트가 애플리케이션에 request를 보내면 서블릿 컨테이너가 필터와 서블릿을 매칭해버린다. 스프링 시큐리티는 사용하고자 하는 필터체인을 서블릿 컨테이너의 필터 사이에서 동작시키기 위해 DelegatingFilterProxy를 사용한다.

DelegatingFilterProxy는 서블릿 컨테이너의 생명주기와 스프링 애플리케이션 컨텍스트 사이에서 다리 역할을 수행하는 필터 구현체이다. 표준 서블릿 필터를 구현하고 있으며, 역할을 위임할 필터체인 프록시를 내부에 가지고 있다. 필터체인 프록시는 스프링부트의 자동 설정에 의해 자동 생성된다.

DelegatingFilterProxy

DelegatingFilterProxy는 Spring Framework에서 제공하는 필터의 대리자(Delegate) 역할을 수행하는 클래스이다.

일반적으로 서블릿 필터(Filter)는 서블릿 컨테이너에서 직접 관리된다. 근데, Spring Framework에서는 DelegatingFilterProxy를 사용하여 필터의 관리를 Spring의 ApplicationContext로 위임할 수 있다.
(위임의 이유는 스프링의 의존성 주입할 수 있고, 스프링의 여러 기능을 사용할 수 있기 때문이다)

DelegatingFilterProxy를 사용하면 이후에 클라이언트의 요청이 들어오면 DelegatingFilterProxy가 요청을 가로채서 등록된 필터 빈(Bean)을 찾아서 실행한다.

즉, DelegatingFilterProxy는 서블릿 필터의 대리자 역할을 수행하여 Spring ApplicationContext 내에서 등록된 필터 빈을 실행시키는 역할을 한다. 이를 통해 Spring의 의존성 주입(Dependency Injection)이 가능하며, 필터가 Spring 관리 빈으로 선언되어 다른 Spring 구성 요소와 함께 사용될 수 있게 되는 것이다. 

DelegatingFilterProxy는 Spring Security 필터 체인을 연결하는 데 사용된다. Spring Security에서는 보안 필터 체인을 구성하고, DelegatingFilterProxy를 통해 이를 등록하여 필터 체인을 관리하는 것이다.

필터체인 프록시는 스프링 시큐리티에서 제공하는 필터로서 보안 필터체인(SecurityFilterChain)을 통해 많은 보안 필터(Security Filter)를 사용할 수 있다. 필터체인 프록시에서 사용할 수 있는 보안 필터체인은 List 형식으로 담을 수 있게 설정되어있어서 URI 패턴에 따라 특정 보안필터 체인을 선택해서 사용하게 된다.

보안 필터체인에서 사용하는 필터는 여러가지가 있고, 필터마다 실행되는 순서가 다르다.
보안 필터체인은 WebSecurityConfigurerAdapter 클래스를 상속받아서 설정할 수 있다. 필터체인 프록시는 여러 보안 필터체인을 가질 수 있고, 여러 개의 보안 필터체인을 만들기 위해서는 WebSecurityConfigurerAdapter 클래스를 상속받는 클래스를 여러 개 생성하면 된다.

스프링 시큐리티에서는 디폴트로는 SecurityFilterChain에서 사용하는 필터 중 UsernamePasswordAuthenticationFilter를 통해 인증을 처리한다.

SecurityFilterChain
SecurityFilterChain은 보안 필터의 체인이다. Spring Security는 필터 기반 아키텍처를 사용하여 요청에 대한 인증 및 인가 작업을 처리한다. SecurityFilterChain은 다양한 필터를 포함하고 있으며, 각 필터는 특정한 보안 작업을 수행한다.

예를 들어, UsernamePasswordAuthenticationFilter는 사용자 이름/암호 인증을 처리하고, AccessDecisionManager는 권한 검사를 수행한다.

이제 개념적인 부분을 공부해보았으니 직접 구현을 하면서 로그인, 회원가입에 적용해봐야겠다. 

웹은 기본적으로 클라이언트가 요청하면 서버에서 데이터를 내려주는 식으로 동작한다. 여러 방식에 따라 어떤 언어와 프레임워크를 선택할지 다르다.
클라이언트(브라우저)가 서버에서 html, css, js 모든 것을 받아서 보여줄 수도 있고, html, css를 서버에서 받은 js를 이용하여 보여줄 수도 있다.
그리고 동적인 정보, 정적인 정보 어떤 정보를 받느냐에 따라서 달라질 수 있다.

간단한 웹 서비스를 개발하려면 동적인 것이 필요없을 수 있다. 그냥 html, css, js를 서버로부터 받아와서 보여주기만 하면 되고, 클라이언트가 클릭하거나 하는 동적인 활동이 필요없는 웹 화면일 수 있다. 하지만 웹 서비스에 동적인 리소스가 필요없을 수가 없다.

처음에는 WAS 하나로 모든 것을 해결해주었다. 서버에서 정적인 파일인든, 동적인 파일이든 애플리케이션 로직과 분리도 되어있지 않고 모든 것을 포함하는 것이다. 그치만 이렇게 하면 WAS가 너무 많은 역할을 담당하게 된다. 그래서 WAS를 나눈다.

웹 애플리케이션 서버(WAS)

WAS는 제일 큰 개념이라고 생각하면 된다.

WAS는 Web Server랑 서블릿 컨테이너 그리고 데이터베이스 연결 등등이 있지만, Web Server와 서블릿 컨테이너를 위주로 보겠다.

Web Server

웹 서버를 정적인 리소스를 이용하여 전달해주는 것이다. 웹 서버의 예시로는 Apache HTTP Server나 NginX같은 것이 있다.

서블릿 컨테이너

서블릿 컨테이너는 서블릿을 실행하기 위한 환경을 제공하고 서블릿의 생명주기를 관리한다. 그럼 서블릿이란 뭘까?

서블릿

이전에 동적인 동작을 처리하기 위해서 서블릿이 필요하다. 서블릿은 클라이언트의 요청을 담당하고 동적인 웹 콘텐츠를 생성하고 전송한다. 서블릿은 Java Servlet API에 정의되어 있는 인터페이스를 구현하여서 개발된다. 즉, WAS는 서블릿 컨테이너를 내장하고 있어서 서블릿을 실행할 수 있게 되는 것이다.

서블릿은 HTTP 요청을 받고 HTTP 응답을 JSON 형식으로 내려줄 수 있다. 서블리의 예시로는 톰캣이나 Jetty가 있다. 여기서 톰캣을 가지게 되는 서블릿 컨테이너의 이름이 Apache Tomcat이다.

Spring, Apache Tomcat

Spring Framework 자체적으로는 Apache Tomcat을 내장하고 있지 않아서 만약 Spring 애플리케이션을 실행하기 위해서는 별도로 Tomcat을 설치하고 설정해야 한다. 이 과정이 복잡하고 어렵기 때문에 Spring Boot를 프로젝트를 시작할 때 사용하게 된다.

Spring Boot 사용 이유

Spring Boot 프로젝트를 사용할 경우에는 내장 서블릿 컨테이너로 Tomcat, Jetty, Undertow 중 하나를 선택하여 사용할 수 있다. Spring Boot는 웹 애플리케이션을 실행하는 데 필요한 내장 서버를 자동으로 제공하므로 별도의 서버 설정이 필요하지 않다.

Spring Framework는 서블릿 컨테이너와 통합되어 웹 애플리케이션 개발을 지원하지만, Spring 자체적으로 Apache Tomcat을 내장하고 있는 것은 아니고, Apache Tomcat은 Spring 애플리케이션을 실행하기 위한 선택적인 서블릿 컨테이너 중 하나이고 Spring Boot에서 자체적으로 제공한다고 생각하면 된다.