뚭

인텔리제이를 엽니다. 

database텝 클릭후 '+' 버튼 클릭 

여기서 사용할 database를 사용합니다. 저는 이번에  postrgerSQL을 이용할겁니다. 

아래는 Name는 일단 인텔리제이에서 사용하 이름

host는 aws에서의 database 엔드포인트

user: rds에서 식별자 아이디

pw: 비밀번호

database: rds에서 만든 database 이름 

test connection하면 success가 생기죠.

apply 클릭하면 아래와 같이 인텔리제이와 연결된걸 볼수 있습니다.

그렇다면 이번엔 spring boot에서 rds에 잇는 databse를 연결해줘야 겟죠.

그리고 yml은 

datasource:
    #initialization-mode: always
    url:  jdbc:postgresql://엔드포인트/데이터베이스
    driver-class-name: org.postgresql.Driver 
    username: 식별자
    password: 비밀번호
    type: com.zaxxer.hikari.HikariDataSource

postgersql gradle 추가 

implementation 'org.postgresql:postgresql:42.2.15'

이후 실행해보니 !! 오류 발생을 했습니다.

java.sql.SQLFeatureNotSupportedException: Method org.postgresql.jdbc.PgConnection.createClob() is not yet

그래서 이를 해결하기 위해서 

추가적으로 

jpa:
    show-sql: true
    format_sql: true
    use_sql_comments: false
    properties:
      hibernate:
        jdbc:
          lob:
            non_contextual_creation: true
        temp:
          use_jdbc_metadata_defaults: false

추가해줬습니다.

일단 위의 기능은 제가 아직 정확히는 몰라서 찾은후에 작성을 따로 하도록 하겠습니다.

그리고 결과 

결과는 잘 연결되었습니다.

잘 나왓습니다!!

EC2는 잇다는 가정하에 

대략 형태는 이거입니다.

RDS 생성 및  EC2를 연결 해보겠습니다.

먼저 aws에서 rds 검색 

데이터베이스 생성

여기서 표준생성

저는 postgreSQL를 선택했습니다.

저는 프리티어로 돈이 읍습니다 ㅎㅎ ㅠㅠ 

식별자와 마스터 사용자 이름 암호 

디폴트로 설정해주고요.

범용SSD 스토리지 자동조정 비활성화 괜히 체크 해두면 요금나올수도 잇다고하네요.

미리 생성해둔 EC2 자동연결 

VPC 새로 생성 VPC관련해서 찾아보세요.

나머지 디폴트 설정후 생성 

하시면 

완료!!

이전글:

2023.12.10 - [웹/Spring] - Spring Security 구조에 대해서 - Handling Security Exceptions

이전글은 예외처리에 대해서 확인해봤는데요.

이번엔 인증사이에 요청 저정하기.. 즉 인증하는 요청을 저장하는 것같습니다. 일단 내용을 확인해보겠습니다.

보안 예외처리에서 설명된 바와같이, 요청에 인증이 없고 인증이 필요한 리소스에 대한 요청을 할때, 인증이 성공한 후 인증된 리소스에 대한 요청을 다시 요청하기 위해 요청을 저장할 필요가 있습니다.(즉 같은  요청을 보내고 다시 요청할때 미리 저장하겠다는것 같네요)  Spring Security 에서는 HttpServletRequest를 RequstCache 구현을 저장함으로써 이를 수행합니다.(캐시저장같네요)

RequstCache

HttpServletRequest는 RequestCache에 저장됩니다. 사용자가 성공적으로 인증할때. RequestCache는 원래 요청을 재생하는데 사용됩니다. (Request 재사용인듯합니다.) RequetsCacheAwarerFilter는 HttpServletRequest를 저장하기 위해 RequestCache를 사용하는것입니다.

기본적으로 HttpSessionRequestCache가 사용됩니다. 아래 코드는 continue라는 이름의 매개변수가 존재할 경우 HttpSession에서 저장된 요청을 확인하기 위해 사용되는 RequestCache 구현을 사용자 지정하는 방법을 보여줍니다.

아래 코드를 보죠.

@Bean
DefaultSecurityFilterChain springSecurity(HttpSecurity http) throws Exception {
	// HttpSessionRequestCache의 인스턴스를 생성합니다. 이 클래스는 HTTP 요청을 세션에 저장하는 데 사용됩니다.
    HttpSessionRequestCache requestCache = new HttpSessionRequestCache();
    // 'continue'라는 매개변수가 있는 요청만을 HttpSessionRequestCache에 저장하도록 설정합니다.
	requestCache.setMatchingRequestParameterName("continue");
	http
		 // 다른 HttpSecurity 설정들...
        .requestCache((cache) -> cache
            // 사용자 정의 RequestCache를 HttpSecurity 설정에 적용합니다.
            .requestCache(requestCache)
        );
    // 설정된 HttpSecurity 객체를 DefaultSecurityFilterChain 객체로 빌드하고 반환합니다.
	return http.build();
}

Prevent the Request From Being Saved

요청 저장 방식이라는데요.

세션에서 사용자의 인증되지 않는 요청을 저장하지 않으려는 여러가지 이유가 잇을수 있습니다.

사용자의 브라우져에 그 저장소를 옮기거나 db에 저장하고 싶을수 있습니다. 또는 로그인 전에 방문하려고 했던 페이지 대신 항상 사용자를 홈페이지로 리다이렉트하고 싶어 이기능을 없애고 싶을수 있습니다.

그래서 이렇게 하고 싶은 경우에는 NullRequestCache 사용합니다.

@Bean
SecurityFilterChain springSecurity(HttpSecurity http) throws Exception {
    RequestCache nullRequestCache = new NullRequestCache();
    http
        // ...
        .requestCache((cache) -> cache
            .requestCache(nullRequestCache)
        );
    return http.build();
}

Logging

로그를 남기는 로깅입니다.

Spring Security는 모든 보안 관련 이벤트를 Debug및 Trace레벨에서 포괄적으로 기록합니다.보안 조치로 인해 Spring Security는 요청이 거부된 이유를 응답 본문에 추가하지 않기 때문에, 애플리케이션 디버깅 시 이 기능이 매우 유용할 수 있습니다. 401 또는 403 오류를 만나면, 발생한 상황을 이해하는 데 도움이 될 로그 메시지를 찾을 가능성이 매우 높습니다.

예를 들어, 사용자가 CSRF 토큰 없이 CSRF 보호가 활성화된 리소스에 POST 요청을 시도하는 경우를 생각해봅시다. 로그가 없으면 사용자는 요청이 거부된 이유에 대한 설명 없이 403 오류를 보게 됩니다. 그러나 Spring Security의 로깅을 활성화하면 다음과 같은 로그 메시지를 볼 수 있습니다:"(기회되면 csrf에 대해서 간단히 정리해보겠습니다. 자주 언급되네요 생각보다 )

로깅:

2023-06-14T09:44:25.797-03:00 DEBUG 76975 --- [nio-8080-exec-1] o.s.security.web.FilterChainProxy        : Securing POST /hello
2023-06-14T09:44:25.797-03:00 TRACE 76975 --- [nio-8080-exec-1] o.s.security.web.FilterChainProxy        : Invoking DisableEncodeUrlFilter (1/15)
2023-06-14T09:44:25.798-03:00 TRACE 76975 --- [nio-8080-exec-1] o.s.security.web.FilterChainProxy        : Invoking WebAsyncManagerIntegrationFilter (2/15)
2023-06-14T09:44:25.800-03:00 TRACE 76975 --- [nio-8080-exec-1] o.s.security.web.FilterChainProxy        : Invoking SecurityContextHolderFilter (3/15)
2023-06-14T09:44:25.801-03:00 TRACE 76975 --- [nio-8080-exec-1] o.s.security.web.FilterChainProxy        : Invoking HeaderWriterFilter (4/15)
2023-06-14T09:44:25.802-03:00 TRACE 76975 --- [nio-8080-exec-1] o.s.security.web.FilterChainProxy        : Invoking CsrfFilter (5/15)
2023-06-14T09:44:25.814-03:00 DEBUG 76975 --- [nio-8080-exec-1] o.s.security.web.csrf.CsrfFilter         : Invalid CSRF token found for http://localhost:8080/hello
2023-06-14T09:44:25.814-03:00 DEBUG 76975 --- [nio-8080-exec-1] o.s.s.w.access.AccessDeniedHandlerImpl   : Responding with 403 status code
2023-06-14T09:44:25.814-03:00 TRACE 76975 --- [nio-8080-exec-1] o.s.s.w.header.writers.HstsHeaderWriter  : Not injecting HSTS header since it did not match request to [Is Secure]

위 로그는 CSRF 토큰이 누락되어 있어서 요청이 거부되는 내역입니다.

아래 이벤트 기록을 볼수 있게 해주는 spring boot 와 xml입니다.

spring security logging :spring boot

logging.level.org.springframework.security=TRACE

spring security loggin : xml

<configuration>
    <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
        <!-- ... -->
    </appender>
    <!-- ... -->
    <logger name="org.springframework.security" level="trace" additivity="false">
        <appender-ref ref="Console" />
    </logger>
</configuration>

이로써  spring security 구조에 대해서 확인해봤습니다. 개인 프로젝트에 jwt나 auth2를 구현해보고 관련해서 또 작성해보겠습니다.

참조:

https://docs.spring.io/spring-security/reference/servlet/architecture.html#servlet-authorization-filtersecurityinterceptor

이전글:

2023.12.10 - [웹/Spring] - Spring Security 구조에 대해서 - Adding a CustomFilter to the FilterChain

security filter도 예외처리를 다뤄주는게 필요하겠죠. 그래서 spring  security 구조에 대해서도 다루고 있습니다.

ExceptionTranslationFilter는 'AccessDeniedException' 및 'AuthenticaitonException' 을 적절한 HTTP 응답으로 변환하는 Spring Security의 구성요소 입니다. 

ExceptionTranslationFilter는 Security Filter 중 하나로써 FilterChainProxy에 삽입됩니다.

아래 이미지를 확인하겠습니다.

1) 첫번쨰로는  ExceptionTranslationFilter는 애플리케이션의 FilterChain.doFilter(Request,Response) 호출하여 나머지 부분을 실행합니다.

2) 만약 유저가 인증되지 않았거나 AuthenicationException인 경우 인증을 시작합니다.

•    SecurityContextHolder가 초기화 됩니다.
•   HttpServletRequest는 저장되어 인증이 성공한후 원래 쵸엉을 다시 실행한느데 사용될수 있습니다.
•  AuthenticationEntryPoint는 클라이언트로부터 자격 증명을 요청하는데 사용될수 있습니다. 예를들어 로그인 페이지로 리다이렉트 하거나 WWW-Authenticate 헤더를 보낼수 있습니다.

3)  그렇지 않고 3번으로 진행되면 AccessDeniedException인경우 접근이 거부됩니다. 접근거부처리 되면서 AccessDeniedHander가 호출됩니다.

ExceptionTranlationFilter에 대허서 코드로 확인해보겠습니다.

try {
	filterChain.doFilter(request, response);//(1)
} catch (AccessDeniedException | AuthenticationException ex) {
	if (!authenticated || ex instanceof AuthenticationException) {
		startAuthentication();//(2)
	} else {
		accessDenied();//(3)
	}
}

(1) A review of  Filter에서 설명한 바와 같이 'FilterChain.doFilter(request,response)'를 호출하는 것은 애플리케이션의 나머지 부분을 호출하는것과 같습니다. 이는 다른부분의 애플리케이션(예:FilterSecurityInterceptor 또는 메소드 보안)이 'AuthenticationException' 또는 'AccessDeniedException' 을 발생시킬 경우, 여기서 처리하는을 의미합니다.

(2) 사용자가 인증되지 않았거나 'AuthenticationException'인경우, 인증을 시작합니다.

(3)그렇지 않으면  접근을 거부합니다.

https://docs.spring.io/spring-security/reference/servlet/architecture.html#servlet-authorization-filtersecurityinterceptor

이전글:

2023.12.10 - [웹/Spring] - Spring Security 구조에 대해서 - Printing the Security Filters

이전엔 securityFilter Print해주는걸 확인했는데요. 이번엔 filterChain에 CustomFilter를 추가하는것에 대해서 작성해보려합니다.

아래 코드를 보시면 

import java.io.IOException;

import jakarta.servlet.Filter;
import jakarta.servlet.FilterChain;
import jakarta.servlet.ServletException;
import jakarta.servlet.ServletRequest;
import jakarta.servlet.ServletResponse;
import jakarta.servlet.http.HttpServletRequest;
import jakarta.servlet.http.HttpServletResponse;

import org.springframework.security.access.AccessDeniedException;

public class TenantFilter implements Filter {

    @Override
    public void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain filterChain) throws IOException, ServletException {
        HttpServletRequest request = (HttpServletRequest) servletRequest;
        HttpServletResponse response = (HttpServletResponse) servletResponse;

        String tenantId = request.getHeader("X-Tenant-Id"); (1)
        boolean hasAccess = isUserAllowed(tenantId); (2)
        if (hasAccess) {
            filterChain.doFilter(request, response); (3)
            return;
        }
        throw new AccessDeniedException("Access denied"); (4)
    }

}

이코드는 예시 보안필터 코드입니다.

(1) 요청 헤더에서 tenant id를 가져옵니다.

(2) 현재 사용자가 해당 tenant id에 접근할수 잇는지 확인합니다.

(3) 사용자에게 접근 권한이 있다면, 필터체인의 나머지 필터들을 호출합니다.

(4) 사용자에게 접근 권한이 없다면 AccessDeniedException을 발생시킵니다.

그렇다면 이 TenantFilter 필터 코드를 security Filter chain을 추가 할겁니다.

@Bean
SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
    http
        // ...
        //TenantFilter 코드 추가 
        .addFilterBefore(new TenantFilter(), AuthorizationFilter.class);(1)
    return http.build();
}

(1) HttpSecurity .addFilterBefore를 사용하여 AuthorizationFilter 이전에 TenantFilter를 추가합니다.

•    이방식으로 TenantFilter가 인증 필터들 이후에 호출되도록 확실하게 합니다.
•   또한, HttpSecurity .addFilterAfter를 사용하여 특정 필터 이후에 필터를 추가하거나 , HttpSecurity addFilterAt를 사용하여    필터 체인의 특정 위치에 필터터를 추가할수 있습니다.

'TenantFilter'가 필터 체인에서 호출되어 현재 사용자가 TenentID에 접근할수 있는지를 확인합니다.

Spring bean으로 필터를 선언할 때 주의해야 할점이 있습니다. 필터를 @Component로 주석처리하거나 구성에서 Bean으로 선언하면, Spring Boot가 내장 컨테이너에 자동으로 등록합니다.

이것은 필터가 컨테이너와 Spring Security에 의해 각각 한번씩, 그리고 다른순서로 두번홀출될수 있을 의미합니다.

ex)

의존성 주입의 장점을 활용하며넛 중복 호출을 피하려면  Spring boot에서 켄터이너에 필터를 등록하지 말라고 지시할수 있습니다.

이를 위해 FilterRegistrationBean  을 bean을 선언하고 enabled 속성을 false로 설정합니다.

@Bean
public FilterRegistrationBean<TenantFilter> tenantFilterRegistration(TenantFilter filter) {
    FilterRegistrationBean<TenantFilter> registration = new FilterRegistrationBean<>(filter);
    registration.setEnabled(false);
    return registration;
}

참조:

https://docs.spring.io/spring-security/reference/servlet/architecture.html#servlet-print-filters

이전글:

2023.12.09 - [웹/Spring] - Spring Security 구조에 대해서 -Security Filters

이전 글엔   spring filters에 대해서 작성해봤는데요.

백엔드는 프론트엔드와 달리 무언가를 확인하는게 쉽지않습니다.

그래서 filter에 대한 log를 확인하기 위한 기능이 필요하기 때문에 원서에더 그부분에 대해서 설명하고 있습니다.

아래 로그는 특정 요청에 의한 securoty filter 요청시 아래와 같이 보여집니다. 이벤트로그도 잇어서 관련해선 추후 설명하겠습니다.

2023-06-14T08:55:22.321-03:00  INFO 76975 --- [           main] o.s.s.web.DefaultSecurityFilterChain     : Will secure any request with [
org.springframework.security.web.session.DisableEncodeUrlFilter@404db674,
org.springframework.security.web.context.request.async.WebAsyncManagerIntegrationFilter@50f097b5,
org.springframework.security.web.context.SecurityContextHolderFilter@6fc6deb7,
org.springframework.security.web.header.HeaderWriterFilter@6f76c2cc,
org.springframework.security.web.csrf.CsrfFilter@c29fe36,
org.springframework.security.web.authentication.logout.LogoutFilter@ef60710,
org.springframework.security.web.authentication.UsernamePasswordAuthenticationFilter@7c2dfa2,
org.springframework.security.web.authentication.ui.DefaultLoginPageGeneratingFilter@4397a639,
org.springframework.security.web.authentication.ui.DefaultLogoutPageGeneratingFilter@7add838c,
org.springframework.security.web.authentication.www.BasicAuthenticationFilter@5cc9d3d0,
org.springframework.security.web.savedrequest.RequestCacheAwareFilter@7da39774,
org.springframework.security.web.servletapi.SecurityContextHolderAwareRequestFilter@32b0876c,
org.springframework.security.web.authentication.AnonymousAuthenticationFilter@3662bdff,
org.springframework.security.web.access.ExceptionTranslationFilter@77681ce4,
org.springframework.security.web.access.intercept.AuthorizationFilter@169268a7]

https://docs.spring.io/spring-security/reference/servlet/architecture.html#servlet-print-filters

2023.12.09 - [웹/Spring] - Spring Security 구조에 대해서 - SecurityFilterChain

Security Filter들은 SecurityFilterChain API를 통해 FilterChainProxy에 삽입됩니다.

이 filter들은 인증,권한 부여, 취약점 보호 등 다양한 목적을 사용될수 있습니다.

filter들은 올바른 시간에 호출되도록 보장하기 위해 특정 순서로 실행됩니다.

예를들어, 인증을 수행하는 필터는 권한 부여를 수행하는 fiter보다 먼저 호출되어야 합니다.

일반적으로 Spring Security의 필터 순서를 알 필요는 없습니다. 그러나 필터의 순서를 알고 싶다면 FilterOrderRegistration 코드를 확인이 가능합니다.

코드를 한번 보겠습니다.

@Configuration
@EnableWebSecurity
public class SecurityConfig {

    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        http
            //1.csrf 보호
            .csrf(Customizer.withDefaults())
             //2.인증필터
            .authorizeHttpRequests(
              //3.사용자 권한 확인
                 authorize -> authorize 
                .anyRequest().authenticated() 
            )      
            .httpBasic(Customizer.withDefaults())
            .formLogin(Customizer.withDefaults());
        return http.build();
    }

}

보면 

코드를 보면

첫번째는 CsrfFilter는 CSRF 공격을 보호하기 위해 호출합니다.

CSRF 이란?(사이트간의 위조 요청)

csrf공격은 사용자가 자신의 의지완느 무관하게 웹 어플리케이션에서 의도하지 않는 동작을 수행하도록 하는 보안 취약점을 말합니다. 간단히 말해서 공격자는 사용자가 이미 로그인한 웹사이트에 대해 악의적인 요청을 전송하도록 유도합니다.

(ex 피싱 이메일)

두번째 는 authenitcation filter(인증 필터)는 이 필터는 보내는 사용자의 신원을 확인하는 역할을 합니다.

세번째 는  authenitcation filter인증후 , 이 필터는 사용자가 요청한 작업을 수행할 권한이 있는지 검사합니다.

(ex 어드민 계정, 고객 계정)

참조:

https://docs.spring.io/spring-security/reference/servlet/architecture.html#servlet-print-filters

2023.12.09 - [웹/Spring] - Spring Security 구조에 대해서 - FilterChainProxy

이전에는 FilterChainProxy에 대해서 간단히 작성해봤는데요.

솔직히 이전 내용이 이해가 어려운 내용이었습니다. 일단 FilterChainProxy가 SecurityFilterChain에게 역할 위임한다는걸로 이해를 했습니다.

이번엔 SecurityFilterChain에 대해서 작성해보려고 합니다.

SecurityFilterChain은 요청에 대해 호출되어야하는 Spring Security Filter 인스턴스를 결정하기 위해 FilterChainProxy에서 사용됩니다.

즉 FitlterChainProxy를 사용하여 SecurityFilterChain을 요청한다는 말인듯합니다.

구조를 확인해보겠습니다.

그림에서도 보시면 FilterChainProxy에서 

SecurityFilterChain안에 SecurityFilter는 Bean들이 있습니다.

보시면 DelegatingFilterProxy대신에 FilterChainProxy로 등록됩니다.

 FilterChainProxy는 결국 SecurityFilter Bean을 등록해주는 역할이라고 생각하면 좀 편할것 같습니다(맞겟죠? 제가 이해한게 ㅎㅎ 틀리면 지적 부탁드립니다 ㅠ )

첫번째는 Spring Security의 모든 서블릿 지원에 대한 시작점을 제공합니다.

그 이유로는 만약에 Spring Security  서블릿 지원시 트러블 슈트(문제해결) 시도 한다면 FilterChainProxy에 디버그 포인트를 추가하는것이 시작히기에는 좋은 방법이다.

라고 하는데요. 즉 문제 해결을 위해서 Spring Security  서블릿 지원에 관련해서는 시작점에서 제공한다는 얘기 같습니다.

두번째는 FilterChainProxy는 Spring Security 사용되는건 필수적이기 때문에 필수적으로 보이지 않는 작업들도 수행할수 있습니다.

즉 Spring Security는 사용되는건 무조건인데 별로 필요없는것들도 함께 작업이 수행될수 있다는 의미인듯합나다.

예를들어 메모리를 leak(부족)을 회피하기 위해 SecurityContext를 비웁니다. 또한 특정 유형의 공격으로부터 애플리케이션을 보호하기 위해서 HttpFirewall을 적용합니다.

(여기서 HttpFirewall은 Spring Security에서 웹 애플리케이션을 다양한 웹 기반 공격으로부터 보호하기 위해 요청을 필터링하는 보안 기능입니다. 나중에 HttpFirewall 에 대해서도 작성해보도록 하겠습니다 지금은 보안해주는 역할정도로만 이해하도록 하겠습니다.)

또한, SecurityFilterChain이 언제 호출될지 결정하는데 더 큰 유영성을 제공합니다. 서블릿 컨터이너에서, 필터 인스턴스는 URL에만 근거하여 호출이 됩니다. 그러나 FilterChaingProxy는 RequestMatchr 인터페이스를 사용하여 HttpServletRequet내의 어떤 것에 근거하여 호출을 결정할수 있습니다.

(여기서 RequestMatchr는 특정 조건에 따라 보안처리를 결정하는데 사용된다고 합니다. 저도 정확한건 찾아보고나서 따로 설명해도록 하겠습니다.)

이번에 Multiple SecurityFilterChain 인스턴스들 이미지 입니다.

Multiple SecurityFilterChaind보시면 FilterChainProxy는 SecurityFilterChain을 사용하는데 결정합니다.

 매칭되는 첫번째는 SecurityFilterChain만 호출됩니다. 만약 api/message/url 요청딘다면, 이는 /api/ 패턴의 securityFilterChain0과 먼저 매칭되므로, SecurityFilterChain과도 매칭되더라도 오직 SecurityFilterChain(0)만 호출됩니다.

/message/url이 요청되면, 이는 /api/패턴의 SecurityFilterChain (0) 와 매칭되지 않으므로, FilterChainProxy는 다른 모든 SecurityFilterChain 을 시도합니다. 다른 어떤 SecurityFilterChain 인스턴스가 매칭되지 않는다면 SecurityFilterChain(n)이 호출됩니다.

그림을 보면

SecurityFilterChain(0)는 단 3개의 보안 필터 인스턴스만 설정되어 있음을 유의합니다. 그러나 SecurityFilterChain(n) 은 4개의 보안피러 인스턴스가 설정되어 있습니다. 각 SecurityFilterChain 은 고유할수 있으며, 독립적으로 구성할수 있습니다.

(즉  SecurityFilterChain 은 각각 역할로 url을 나눠서 필터링을 할수 있다는의미 같네요.)

실제로 어플리케이션이 특정 요청을 Spring Security가 무시하기를 원한다면 SecurityFilterChain 은 보안 필터 인스턴스 없이 구성할수 있습니다.

(음 보안 필터 없이 구성할수 있지만 왠만한 서비스는 전부 있어야는걸로 알고 잇어서 ㅎㅎ 악의적인 공격에 의해서 자칫하면 서버비 감당이 안되겟죠 ㅎㅎ) 

대략 정리하면 DelegatingFilterProxy(FilterChainProxy)=>호출=> URL 매칭 SecurityFilterChain 선택-> SecurityFilterChain(0)..... SecurityFilterChain  (N)  이런 느낌이네요.

다음엔 Securyt Filters에 대해서 알아보도록 하겠습니다.

참조:

https://docs.spring.io/spring-security/reference/servlet/architecture.html#servlet-print-filters