초기화 과정 이해
1. SecurityBuilder, SecurityConfigurer
스프링 시큐리티 초기화 과정에서 SecurityBuilder , SecurityConfigurer 가 작동함
스프링 시큐리티는 Filter 기반 프레임워크(모든 보안 처리를 필터에서 함)
1.1 SecurityBuilder
SecurityBuilder는 웹 보안 관련된 빈 객체를 초기화하고 설정 클래스들을 생성하는 역할을 함
대표적으로 HttpSecurity, WebSecurity가 있음
1.2 SecurityConfigure
http 요청과 관련해서 보안 처리를 하는 필터를 생성하는 역할
인증 및 인가 초기화 작업을 수행한다.
1.3 의존관계
SecurityBuilder는 SecurityConfigure를 참조하여 사용하고 있다.
1.4 동작 원리
처음에는 스프링의
AutoConfigure가build()를 호출하여SecurityBuilder클래스를 생성한다.SecurityBuilder클래스는SecurityConfigure클래스를 생성한다.(SecurityConfigure라는 이름의 설정 클래스를 생성하는 것임)SecurityConfigure는 내부에init(B Builder),configure(B Builder)메서드가 있어서 이를 통해 초기화를 진행함이때 각 메소드 안에 들어 있는 파라미터인
B Builder는SecurityBuilder클래스가 들어간다.→
HttpSecurity또는WebSecurity등등SecurityBuilder클래스 타입
1.4.1 예시가 있는 동작 원리
SecurityBuilder가HttpSecurity를 생성HttpSecurity는 설정 클래스를 생성한다(SecurityConfigure)SecurityConfigure가init()과configure()를 통해서 초기화 작업을 수행한다.이때 여러 보안과 관련된
Filter들이 생성된다.
2. WebSecurity, HttpSecurity
스프링 부트가 시작되면서
SecurityAutoConfiguration이 동작합니다. 이는 스프링 부트의 자동 설정 메커니즘의 시작점입니다.SecurityAutoConfiguration은HttpSecurityConfiguration을 로드합니다. 이 클래스는HttpSecurity객체를 생성하고 스프링 컨테이너에 빈으로 등록하는 역할을 합니다.HttpSecurity객체가 생성될 때 내부적으로SecurityBuilder패턴을 사용합니다. 이는 보안 설정을 단계적으로 구축하기 위한 빌더 패턴의 구현체입니다.그 다음 우리가 정의한
SecurityConfig클래스(SecurityConfigurer의 구현체)가 실행됩니다. 여기서 앞서 생성된HttpSecurity객체를 받아서 우리가 원하는 보안 설정을 추가합니다.마지막으로 이 모든 설정이
build()메서드를 통해 실제SecurityFilterChain으로 변환됩니다. 이 필터 체인이 실제로 요청을 처리하게 됩니다.
2.1 HttpSecurity

HttpSecurityConfiguration에서HttpSecurity를 생성하고 초기화를 진행HttpSecurity는 보안에 필요한 설정 클래스와 필터를 생성하고build()를 통해서SecurityFilterChain생성
2.2 SecurityFilterChain
SecurityFilterChain 은 인터페이스이고 하위 구현체로는 DefaultSecurityFilterChain 있다.
2.2.1 내부 메서드
boolean matches(HttpServlcetRequest request)현재 요청이
SecurityFilterChain에 의해서 처리 되어야 하는지 결정true를 반환하면 해당 요청을 이 필터 체인에서 수행해야함. false면 다른 필터 체인이나 로직에서 수행되어야함
특정 요청에 대한 적절한 보안 필터링이 적용되어진다.
List<Filter> getFilters()현재
SecurityFilterChain에 있는 모든Filter객체를 가져옴어떤 필터들이 필터 체인에 있는지 확인 가능
각 필터는 요청에 대해서 역할을 수행한다.(인증, 권한부여, 로깅)
2.2.2 SecurityFilterChain의 동작 과정

클라이언트가 요청이
SecurityFilterChain에 있는RequestMatcher를 통해 요청을 수행할 수 있는 필터가 있는지 확인한다.URL 패턴과 일치하는지 확인
http
.authorizeRequests()
.antMatchers("/public/**").permitAll()
.antMatchers("/admin/**").hasRole("ADMIN")
.anyRequest().authenticated();
- 있으면
chain.doFilter()를 실행하여 요청을 처리한다.
2.3 WebSecurity

WebSecurityConfiguration에서WebSecurity객체 생성하고 초기화WebSecurity에HttpSecurity가 만든SecurityFilterChain을 자기 자신 내부의SecurityBuilder에 저장WebSecurity는build()를 실행하면SecurityBuilder내부에 있는SecurityFilterChain을 꺼내서FilterChainProxy를 만듬
결국 WebSecurity는 HttpSecurity의 상위 호환이다.
2.3.1 WebSecurity 시뮬레이션
HttpSecurity가 생성SecurityFilterChain생성WebSecurityConfigruration에서WebSecurity생성이 때
WebSecurity내부에 있는SecurityBuilder에HttpSecurity가 만든SecurityFilterChain을 집어 넣음그걸 build하면
FilterChainProxy가 만들어짐. 이때FilterChainProxy내부에는SecurityFilerChains가 있다.
3. Filter(Servlet)
웹 애플리케이션에서 클라이언트의 요청과 서버의 응답을 가공하거나 검사하는데 사용되는 구성 요소
클라이언트의 요청이 서블릿에 도달하기 전이나 서블릿이 응답을 클라이언트에게 보내기 전에 특정 작업을 수행할 수 있음
서블릿 컨테이너(WAS)에서 생성, 실행, 종료 됨.
4. DelegatingFilterProxy

스프링에서 사용되는 특별한 서블릿 필터
서블릿 컨테이너와 스프링
ApplicationContext사이의 연결고리 역할을 하는 필터서블릿 필터의 기능을 수행하는 동시에 스프링의 의존성 주입 및 빈 관리 기능과 연동되도록 설계된 필터
springSecurityFilterChain이라는 이름으로 생성된 스프링 Bean을ApplicationContext에서 찾아 요청을 스프링 쪽으로 넘긴다.실제 보안 처리는 하지 않음
4.1 시뮬레이션
클라이언트의 요청이 서블릿 컨테이너에 들어옴
요청이 Filter를 통해야하는데, 그 중에
DelegatingFilterProxy를 반드시 거쳐 지나가야함DelegatingFilterProxy는springSecurityFilterChain을 스프링 컨테이너에서 찾음만약 찾았다면 스프링 컨테이너에 요청을 위임함
5. FilterChainProxy

springSecurityFilterChain이라는 이름으로 생성된 Filter Bean임DelegatingFilterProxy으로 부터 요청을 위임 받고 보안 처리를 함내부적으로 하나 이상의
SecurityFilterChain을 가지고 있음요청 URL 정보를 기준으로 적절한
SecurityFilterChain을 선택하여 호출함HttpSecurity를 통해 API 추가 시 관련 필터들이 추가됨사용자의 요청을 필터 순서대로 호출함으로써 보안 기능을 동작 시키고, 필요 시 직접 필터를 생성해서 기존의 필터 전, 후로 추가 가능함
5.1 동작
FilterChainProxy는 0번째 필터부터 마지막 필터까지 위에서 순서대로 호출하면서 요청을 처리함맨 마지막 인가 처리를 하는 필터까지 특별한 예외나 오류가 없으면 성공적으로 요청이 서블릿으로 넘어감