스프링 시큐리티 - 스프링 시큐리티 란

스프링 시큐리티에 관하여 알아보기 전, 스프링 부트(이하 스프링)의 동작 과정에 대해 먼저 알아야한다.

 

Spring Security의 Servlet은 Servlet Filter에 기반을 두고있다. 

그러니 우선 스프링 시큐리티를 이해하기 위해서는 서블렛과 필터에 관한 이해가 선행되어야한다.

 

Servlets&Filter의 흐름

일반적으로 웹 환경에서 클라이언트(브라우저)가 HTTP 혹은 HTTPS 로 요청(Request)을 보낸다고 하자.

여기서 클라이언트가 요청을 보낼때, 그 요청을 자바는 이해할 수 없다.

왜냐하면 자바는 자바 객채에 관한 것을 처리할 수 있지만, 클라이언트가 바로 보내는 요청에 관해서는 처리할 수 없기 때문이다.

 

이 문제를 해결하기 위해 서블릿 컨테이너가 필요하다.

 

웹(혹은 앱)서버에 배포된 서블릿 컨테이너(ex. tomcat)는,  요청이 들어왔다면 그것을 ServletetRequest 객체로 변환 시키는 것이 서블릿 컨테이너의 역할이다.

 

그렇게 변환된 데이터는 이제 자바가 읽을 수 있으니, 해당 데이터를 통해 실제 비지니스 로직(혹은 컨트롤러)를 호출한다.

 

즉, 실제 비지니스 로직은 서블릿에서 호출이 된다는 뜻이다.

 

그렇다면 백엔드에서 응답을 보낼때는?

우선 자바의 응답(Response)은 ServletResponse 객체에게로 전달된다.

 

여기서는 또 반대로 클라이언트(브라우저)는 해당 Response를 바로 읽을 수 없다.

그렇기에 다시 서블릿 컨테이너가 이러한 요청을 HTTP또는 HTTPS 요청으로 변환해준다.

 

그렇다면 Servlet 앞에 있는 필터는 무엇인가? 

서블릿에 실제 요청이 가기전에 자바 내의 필터가 클라이언트와 실제 서블릿 사이를 모든 요청을 가로채 사용한다.

Restful API나 MVC에 접근시 요청을 가로채 사용자의 인증되었는지 등을 식별하여 그것이 정당한 요청인지를 검사한다.

 

Spring Security의 내부 동작 구조

 

스프링 시큐리티는 보안을 강제하기 위해 모든 요청을 가로채기에, 모든 보안 로직은 필터의 도움으로만 구현된다.

(필터가 먼저. 그리고 서블릿이나 실제 비지니스 로직이 실행되는 순서에 주의)

 

필터는 최로 스프링 시큐리티 필터에 닿는다.

여기서 cors.csrf등의 공격에 대비하고, 특정 권한이 필요한 보호된 API요청등에 관하여 검사를 진행한다.

수십개의 필터를 거치며 그 중 하나라도 걸린다면 401, 혹은 403 에러를 반환 받는다.

 

요청 내에 올바른 구성 및 요청을 한다면, Authentication이 두번째로 작동한다.

사용자의 자격증명에 대한 내용으로, 로직에서 HTTP 서블릿 요청 객체는 자격 증명 객체로 변환하는 작업을 진행한다.

그렇게 생성된 인증객체는 프레임워크 내부에 모든 구성 요소가 이해할 수 있는 공통의 자격증명을 나타낸다.

 

인증 객체가 채워지면 요청을 관리자(Authentication Manager)에게 전달한다.

 

관리자는 인증 여부에 관계없이 인증을 완료하고, 결과를 필터로 다시 보내는 역할을 수행한다.

즉, 필터가 사용자의 정보가 포함된 인증객체를 주면, 다른 구성 요소의 도움을 받아 인증을 책임 지겠다는 것이다.

그리고 모든 인증 로직이 실행되면, 그 결과를 돌려준다.

 

인증 관리자는 인증을 완료하는 책임만 지며, 실제 인증은 하지 않는 것에 유의하자.

 

그럼 실제 인증은 누가 하는가? 

 

바로 Authctication Provider이다.

여기서 Authctication Provider는 Manager에게 전달받은 정보를 토대로

UserDetailsService, Password Encoder등의 도움을 받아 실제 인증을 처리한다.

 

그리고 모든 인증이 완료된 정보를 Security Context에 넣는 것으로 일련의 과정이 진행된다.