[Spring Boot] Spring Security Basic - Spring Security 주요 아키택쳐 이해하기

이 글은 인프런 -  Spring Boot 기반으로 개발하는 Spring Security를 학습하면서 정리한 내용 입니다.

 

 

GIT HUB 주소 : https://github.com/junyharang-coding-study/spring-security

 

 

 

 

🗂 목차

● [Spring Boot] Spring Security Basic - 기본 API 및 Filter 이해편 
● [Stpring Boot] Spring Security Basic - Spring Security 주요 아키텍처 이해편
● [Stpring Boot] Spring Security 실전 프로젝트 - 인증 프로세스 Form 인증 구현(1)   
● [Stpring Boot] Spring Security 실전 프로젝트 - 인증 프로세스 Form 인증 구현(2)
● [Stpring Boot] Spring Security 실전 프로젝트 - 인증 프로세스 Ajax 인증 구현

 

 

 

 

 

🚀 Spring Security 주요 아키텍처

    🔽  위임 필터 및 필터 Bean 초기화

        📦 DelegationProxyChain

 

1. Servlet Filter는 Spring에서 정의된 Bean을 주입해서 사용 불가.
2. 특정 이름을 가진 Spring Bean을 찾아 해당 Bean에게 요청 위임 방식으로 사용 가능.

   • springSecurityFilterChain 이름으로 생성된 Bean을 ApplicationContext에서 찾아 요청 위임.
   • 실제 보안처리는 하지 않음. 요청을 위임하는 역할만 수행.

 

Servlet Filter는 Servlet Spac에 정의된 기술로 2.3 Vesion부터 도입이 되었습니다.
이 친구는 어떤 요청이 들어왔을 때, Servlet이 요청에 대한 작업을 처리하게 되는데, Servlet에 가기전에 이 친구에게 해당 요청이 먼저 들어오게 됩니다. 어떤 요청이 왔을 때, 처리하고, 처리된 내용을 Servlet에게 전달해 주게 됩니다.

Servlet에서 요청 처리 작업이 다 끝나게 되면 최종적으로 Client에게 응답값이 전달되게 됩니다. 이 응답값을 전달하기 전에 Servlet Filter가 다시 처리된 내용을 받아 또 다른 작업을 처리해야 할 시 작업을 처리하고, 응답값을 최종적으로 전달하게 됩니다.

Servlet Filter는 Servlet Container에서 생성이 되고, 실행이 되게 됩니다. 
이러한 이유로 Spring 기술에서 주입 등을 해서 사용할 수가 없습니다.

Spring에서는 위의 문제를 해결하기 위해 Spring Bean을 만들고, Servlet Filter를 구현하게 됩니다.
그렇게 되면 Bean으로 생성된 객체는 Filter Type의 객체를 가지게 됩니다.

이용자가 요청을 보내게 되면 현재는 Servlet 기반으로 작동하기 때문에 모든 요청은 Servlet Filter로 전달되게 됩니다.
즉, Spring Bean이 바로 받지 못하는 문제가 생겨 버립니다. WAS에서 Tomcat이 올라가고, WAS에서 실행된 Servlet Filter가 요청을 받게 되는 것 입니다.

Spring Bean에서 해당 요청을 받게 하기 위해서 DelegatingFilterProxy를 이용할 수 있는데, 이 Class는 Servlet Filter인데, 이용자 요청이 Servlet Filter로 들어오게 되면 DelegatingFilterProxy는 이 요청을 Spring Bean에서 관리하는 Filter Bean에게 위임하는 역할을 하게 됩니다.

 

 

        📦 FilterChainProxy

1. springSecurityFilterChain 이름으로 생성되는 Filter Bean.
2. DelegatingFilterProxy로 요청을 위임 받고, 실제 보안 처리.
3. Spring Security 초기화 시 생성되는 Filter들 관리 및 제어 역할.

   • Spring Security가 기본적으로 생성하는 Filter.
   • Config(설정) Class에서 API 추가 시 생성되는 Filter.

4. 이용자 요청을 Filter 순서대로 호출하여 전달.
5. 개발자 정의 Filter를 생성하여 기존 Filter 전, 후로 추가 가능. (Filter 순서를 잘 정의해야 함.)
6. 마지막 Filter까지 인증 및 인가 예외가 발생하지 않으면 보안적 문제가 없다고 판단하고, Servlet에 전달.

 

이번에는 위에서 언급한 두개의 Proxy에 대해 전체적 흐름을 공부해 볼게요.

Servelet Container와 Spring Container는 완전 다른 영역입니다.
Servelet Container는 Servelet Spac을 구현하는 영역이고, Spring Container는 Spring Container에서 생성되는 Bean들을 관리하는 영역이라고 정리할 수 있습니다.

최초 이용자가 처음 요청을 하게 되면 Servelet Container가 가장 먼저 요청을 받게 되고, 요청에 대해 각각의 Servlet Filter들이 작업을 하게 되고, 처리 작업 중 DelegatingFilterProxy는 요청을 받게 되면 특정 이름을 가진 Bean을 찾아 Delegate Request를 보내게 되는데, 그 이름을 가진 Bean이 바로 springSecurityFilterChain이에요.

 

💡 참고 사항

실제로는 DelegatingFilterProxy가 Filter로 등록될 때, springSecurityFilterChain이름으로 등록이 됩니다.
내부적으로는 springSecurityFilterChain이름으로 등록된 Filter Chain을 찾게 되는 것입니다.

springSecurityFilterChain이라는 이름을 가진 Bean이 바로 FilterChainProxy입니다.

 

FilterChainProxy는 들어온 요청에 대해서 각각의 Filter들을 호출하여 작업 즉, 보안 처리를 하게 되고, 보안 처리 작업이 다 되고 나면 Spring MVC, DispatcherServlet에 요청을 전달해 줍니다. 그렇게 되면 DispatcherServlet이 요청에 대한 추가 작업들을 처리하게 됩니다.

 

 

 

 

 

    🔽  Filter 초기화와 다중 보안 설정

1. 설정 Class 별로 보안 기능 각각 작동.
2. 설정 Class 별로 RequestMatcher 설정.

   • http.antMatcher("/admin/**)

3. 설정 Class 별로 Filter 생성.
4. FilterChainProxy가 각각 Filter 보유.
5. 요청에 따라 RequestMatcher와 매칭되는 Filter가 작동하도록 처리.

개발자는 WebSecurityConfigurerAdapter를 이용해서 HttpSecurity를 통해 보안 설정을 하게 됩니다.
이 때, 보안 API를 설정하게 되면 Spring Security가 초기화되면서 각각의 Filter가 생성되게 됩니다.

위의 그림에서 SecurityConfg 1과 SecurityConfig 2는 각각 보안 기능이 따로 작동하도록 할 수 있어요.

만약 SecurityConfig 1에서 RequestMatcher를 통해 /admin/**에 대한 보안 설정을 했다면 해당 요청이 들어왔을 때, SecurityConfig 1만 참조하고, SecurityConfig 2로 넘어가진 않아요.

최초 다중 설정 Class를 만들고, Spring Security가 초기화가 되면 SecurityFilterChain Class가 있는데, 이 객체 안에 HttpSecurity를 통해 설정한 설정된 Filter가 SecurityFilterChain 객체 안 변수로 담기게 되고, http.antMatcher를 통해 입력한 URI는 RequestMacher라는 객체 Type의 변수에 담기게 됩니다.

위의 내용을 담은 SecurityFilterChain 객체가 각각 설정값에 따라 만들어지게 됩니다.

이렇게 각각 생성된 객체를 FilterChainProxy가 Filter Type의 List 변수에 저장을 하게 됩니다.

결국 다중 설정 Class로 만들어진 다 중의 설정 Filter들을 FilterChainProxy가 가지고 있게 되는 것이에요.

만약 이용자가 /admin 으로 요청을 보내게 되면 FilterChainProxy가 요청을 받게 되고, 각 SecurityConfig 내용 중 하나를 선택해서 해당 객체 Filter에 작업을 요청하게 됩니다. 

위의 그림에서는 /admin URI에 대한 RequestMacher가 SecurityConfig 1에 있어요.
그렇다면 FilterChainProxy는 SecurityConfig 1에 SecurityFilterChain 객체가 가지고 있는 Filters 변수들을 가지고 온 뒤 인증 / 인가 처리를 하게 되는 방식입니다.

728x90

위의 그림을 보면서 공부를 해 볼게요.

이용자가 최초 GET 방식으로 /admin URI에 접근 요청을 보냈어요.

그러면 FilterChainProxy가 해당 요청을 받게 되고, 해당 요청을 처리할 Filter를 선택해야 하는데, 요청 URI와 Magching이 되는 즉, matches에서 True값이 나오는 Config Filter를 가져와야 해요.

이 때, FilterChainProxy가 저장하고 있는 각각의 SecurityFilterChain 객체들 중 RequestMatcher 내에 Matching이 되는 것을 찾게 됩니다.

(SecurityConfig 2의 RequestMacher는 anyRequest 입니다.)

그렇게 되면 SecurityConfig 1 내에 SecurityFilterChain이 가지고 있는 RequestMacher와 매칭이 됩니다.
그럼 해당 객체 안에 Filter가 동작하도록 선택하게 됩니다.

그런 뒤 인증 / 인가 처리를 하게 되는 것이에요.

/admin이 아닌 다른 URI로 오는 요청에 대해서는 SecurityConfig 2 내용을 가져오고, 동작하게 될 것이에요.

이 전에 작성했던 Code와 다른 새로운 Config Code를 작성했어요.

이렇게 하고, Server를 기동하면 아래와 같은 문제가 발생할 거에요.

반응형

Error starting ApplicationContext. To display the conditions report re-run your application with 'debug' enabled.
2022-08-16 16:22:00.129 ERROR 2702 --- [           main] o.s.boot.SpringApplication               : Application run failed

org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.springframework.security.config.annotation.web.configuration.WebSecurityConfiguration': Injection of autowired dependencies failed; nested exception is java.lang.IllegalStateException: @Order on WebSecurityConfigurers must be unique. Order of 100 was already used on com.junyharang.spring.security.config.SecurityMultiConfig$$EnhancerBySpringCGLIB$$941cc1dd@21c815e4, so it cannot be used on com.junyharang.spring.security.config.SecurityMultiConfig2$$EnhancerBySpringCGLIB$$21af67c3@7342e05d too.
	at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor.postProcessProperties(AutowiredAnnotationBeanPostProcessor.java:405) ~[spring-beans-5.3.20.jar:5.3.20]
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1431) ~[spring-beans-5.3.20.jar:5.3.20]
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:619) ~[spring-beans-5.3.20.jar:5.3.20]
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:542) ~[spring-beans-5.3.20.jar:5.3.20]
	at org.springframework.beans.factory.support.AbstractBeanFactory.lambda$doGetBean$0(AbstractBeanFactory.java:335) ~[spring-beans-5.3.20.jar:5.3.20]
	at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:234) ~[spring-beans-5.3.20.jar:5.3.20]
	at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:333) ~[spring-beans-5.3.20.jar:5.3.20]
	at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:208) ~[spring-beans-5.3.20.jar:5.3.20]
	at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:953) ~[spring-beans-5.3.20.jar:5.3.20]
	at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:918) ~[spring-context-5.3.20.jar:5.3.20]
	at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:583) ~[spring-context-5.3.20.jar:5.3.20]
	at org.springframework.boot.web.servlet.context.ServletWebServerApplicationContext.refresh(ServletWebServerApplicationContext.java:147) ~[spring-boot-2.7.0.jar:2.7.0]
	at org.springframework.boot.SpringApplication.refresh(SpringApplication.java:734) ~[spring-boot-2.7.0.jar:2.7.0]
	at org.springframework.boot.SpringApplication.refreshContext(SpringApplication.java:408) ~[spring-boot-2.7.0.jar:2.7.0]
	at org.springframework.boot.SpringApplication.run(SpringApplication.java:308) ~[spring-boot-2.7.0.jar:2.7.0]
	at org.springframework.boot.SpringApplication.run(SpringApplication.java:1306) ~[spring-boot-2.7.0.jar:2.7.0]
	at org.springframework.boot.SpringApplication.run(SpringApplication.java:1295) ~[spring-boot-2.7.0.jar:2.7.0]
	at com.junyharang.spring.security.JunyharangSpringSecutiryApplication.main(JunyharangSpringSecutiryApplication.java:10) ~[classes/:na]
Caused by: java.lang.IllegalStateException: @Order on WebSecurityConfigurers must be unique. Order of 100 was already used on com.junyharang.spring.security.config.SecurityMultiConfig$$EnhancerBySpringCGLIB$$941cc1dd@21c815e4, so it cannot be used on com.junyharang.spring.security.config.SecurityMultiConfig2$$EnhancerBySpringCGLIB$$21af67c3@7342e05d too.
	at org.springframework.security.config.annotation.web.configuration.WebSecurityConfiguration.setFilterChainProxySecurityConfigurer(WebSecurityConfiguration.java:165) ~[spring-security-config-5.7.1.jar:5.7.1]
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:na]
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) ~[na:na]
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:na]
	at java.base/java.lang.reflect.Method.invoke(Method.java:568) ~[na:na]
	at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor$AutowiredMethodElement.inject(AutowiredAnnotationBeanPostProcessor.java:724) ~[spring-beans-5.3.20.jar:5.3.20]
	at org.springframework.beans.factory.annotation.InjectionMetadata.inject(InjectionMetadata.java:119) ~[spring-beans-5.3.20.jar:5.3.20]
	at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor.postProcessProperties(AutowiredAnnotationBeanPostProcessor.java:399) ~[spring-beans-5.3.20.jar:5.3.20]
	... 17 common frames omitted

대상 VM에서 연결 해제되었습니다. 주소: '127.0.0.1:50961', 전송: '소켓'

종료 코드 1(으)로 완료된 프로세스

이것은 WebSecurityConfigurers에 unique한 Annotation @order가 있는데, Spring Security Config를 N개 만들 경우 설정에 따라서 순서를 정의해 줘야 해요.

그래서 그 순서를 정의하기 위한 Annotation @order를 이용해서 순서를 정의해 달라는 거에요.

이렇게 위와 같이 수정을 해주고 다시 기동을 하면 아래와 같이 정상 기동이 됩니다.

 

 

 

    🔽  인증 개념 이해

        📦 Authentication

Authentication이란? 인증 즉, 이용자가 누구인지 증명하는 것이에요.

1. 이용자의 인증 정보를 저장하는 Token 개념.
2. 인증 시 ID, Password를 담고 인증 검증을 위해 각 Class 마다 전달 되어 사용.
3. 인증 뒤 최종 인증 결과 (USER 객체, 권한 정보)를 담고 SecurityContext에 저장되어 전역적으로 참조 가능.

   • Authentication authentication = SecurityContextHolder.getContext().getAuthentication()

4. 구조 (Authentication은 Interface).

   • principal(Spring Secutiry가 아닌 JAVA가 지원) : 이용자 ID 혹은 USER 객체 저장.
   • credntials : 이용자 Password.
   • authorities : 인증된 이용자 권한 목록.
   • details : 인증 부가 정보.
   • Authenticated : 인증 여부.

 

최초 이용자가 Login을 시도할 때, ID와 Password를 Server에 넘겨주게 됩니다.
그러면 UsernamePasswordAuthenticationFilter(인증 Filter)가 ID(Username)와 Password 정보를 추출한 뒤 Authentication Type 객체를 하나 만들게 됩니다.

이 때, princlpal에는 이용자 ID를 넣고, credentials에는 비밀번호를 담고, 전달되게 됩니다.

AntuehticationManager가 인증 객체를 가지고, 인증 처리를 하게 되고, 인증이 실패하게 되면 예외가 발생하게 되고, 실패에 대한 후속 처리를 하게 되고, 성공하게 되면 Authentication Type에 객체를 만들게 되는데, princlpal에는 이용자 ID를 넣고, credentials에는 비밀번호를 담는데, 보안상 비어두기도 합니다.
Authorities에는 권한 정보 목록을 담게 됩니다.

그러고 난 뒤 SecurityContextHolder 안에 SecurityContext 객체에 해당 인증 객체(Authentication)을 담게 되고, 이 인증 객체를 전역적으로 사용할 수 있게 해 줍니다.

 

 

 

    🔽  인증 저장소

최초 이용자가 Login을 시도합니다.

Server가 Login 요청을 받게 되면 Server는 해당 이용자에 대한 Thread 하나를 생성하게 됩니다.
이 때, ThreadLocal이라는 Thread 전역 저장소가 Thread 마다 할당이 됩니다.

해당 Thrad는 인증을 처리하게 되는데, 이 때, 인증 Filter인 UsernamePasswordAuthenticationFilter가 동작하게 됩니다. 최초 Authentication 객체를 만드는데, ID와 Password만 담기 위해 principal에는 ID 값을 Credentials에는 Password값을 담게 되고, 나머지는 담지 않습니다.

그런 뒤 인증을 시도해서 인증이 실패하게 되면 SecurityContextHolder.clearContext()를 호출하여 SecurityContext값을 Null로 초기화하는 작업을 하고, 인증이 성공했다면 UsernamePasswordAuthenticationFilter가 SecurityContextHolder안에 SecurityContext 객체 안에 최종 인증 성공한 인증 객체를 담는 처리를 하게 됩니다.

이 때, 이용자에게 할당된 권한이 담기게 되고, 인증 여부가 True로 바뀌게 됩니다.

좀 더 세부적으로 이야기 하자면 SecurityContextHolder는 ThradLocal 객체를 가지고 있게 되고, ThradLocal 객체가 SecurityContext 객체를 담고 있다고 말하는게 더 정확합니다.

그런 뒤 최종적으로 SecurityContext 객체가 HttpSession 객체에 저장이 됩니다. 이 때, 이름은 SPRING_SECURITY_CONTEXT로 저장되요.

 

 

        📦 SecurityContextHolder

1. SecurityContext 객체 저장 방식.

   • MODE_THREADLOCAL : Thread 당 SecurityContext 객체 할당 (Default Value).
   • MODE_INHERITABLETHREADLOCAL : Main Thread와 자식 Thread에 관하여 동일 SecurityContext 유지.
   • MODE_GLOBAL : 응용 프로그램에서 단 하나의 SecurityContext 저장.

2. SecurityContextHolder.clearContext() : SecurityContext 기존 정보 초기화.

 

 

        📦 SecurityContext

1. Authentication 객체가 저장되는 보관소. 필요 시 언제든지 Authentication 객체를 꺼내 쓸 수 있도록 제공되는           
    Class.

2. ThreadLocal에 저장되어 아무 곳에서나 참조가 가능하도록 설계.

   • Thread는 Thread마다 고유하게 할당된 저장소가 있는데, 그 저장소를 Thread Local이라고 한다.
   • 해당 저장소에는 주인 Thread만 접근 및 Data 저장이 가능.
   • Set, Get Method 등 통해 Data Handling 가능.
   • Data를 Set으로 저장한 뒤, Get으로 참조가 가능한데, 저장 이 후 Get으로 참조를 할 때, 장소에 구애 받지 않는다.
      예를 들어 A라는 Method안에서 Thread Local이 Set으로 저장을 하고, 다른 장소인 B Method에서 Get을 통해
      A Method에서 저장한 Data를 가져올 수 있다.

3. 인증 완료 시 HttpSession에 저장되어 Application 전반에 걸쳐 전역 참조 가능.

 

 

 

 

    🔽  인증 저장소 Filter

        📦 SecurityContextPersistenceFilter

1. SecurityContext 객체의 생성, 저장, 조회

   • 익명 이용자
      - 새로운 SecurityContext 객체 생성 뒤 SecurityContextHolder에 저장.
      - AnonymousAuthenticationFilter에서 AnnonymousAuthenticationToken(익명 이용자용 인증 객체) 
         객체를 SecurityContext에 저장.

   • 인증 시
      - 새로운 SecurityContext 객체 생성 뒤 SecurityContextHolder에 저장.
      - UsernamePasswordAuthenticationFilter 에서 인증 성공 뒤 SecurityContext에
         UsernamePasswordAuthenticationToken 객체를 SecurityContext에 저장.
      - 인증이 최종 완료 되면 응답 하는 시점에 Session에 SecurityContext 저장.

   • 인증 뒤
      - Session에서 SecurityContext 객체를 꺼내 SecurityContextHolder에서 저장.
      - SecurityContext 안 Authentication 객체가 존재하면 계속 인증 유지.

   • 최종 응답 시 공통
     - SecurityContextHolder.clearContext()

최초 이용자가 인증을 요청합니다.

SecurityContextPersistenceFilter는  매 요청마다 해당 요청을 처리하게 됩니다.
인증을 요청하는 이용자, 인증을 받은 이용자, 익명 이용자 등 모두  SecurityContextPersistenceFilter가 요청을 처리하게 됩니다.

SecurityContextPersistenceFilter 안에는 HttpSecurityContextRepository Class가 있는데, 실제 HttpSecurityContextRepository가 SecurityContext 객체를 생성하고, 조회 등을 하는 역할을 합니다.

이제 이용자가 인증을 받았는지 여부를 판단하게 됩니다.
이 때, Session에 SecurityContext가 있는지를 확인하게 되는데, 당연히 인증 전이거나, 익명 이용자가 접근하게 되면
SecurityContext가 존재하지 않을거에요.

그래서 인증을 받기 전이고, 인증을 요청하고 있다면 새로운 SecurityContext를 생성하게 됩니다.
이는 익명 이용자, 인증을 받기 시점에 이용자든 동일해요.
이 때는 Authentication (인증 객체)가 Null인 상태에요.

요청은 그 다음 Filter로 이동(chain.doFilter)되게 됩니다.

AuthFilter 예를 들어 Form 인증의 경우 UsernamePasswordAuthenticationFilter가 될 것인데, 해당 인증 Filter가 인증을 처리하게 됩니다.

인증이 완료가 되면 해당 인증 Filter가 SecurityContextHolder 안에서 SecurityContext 객체 안에  인증에 성공한 결과물인 Authentication(인증 객체)를 저장하게 됩니다.

결국 SecurityContextPersistenceFilter는 인증 요청이 왔을 때,SecurityContext 객체 생성만 담당하고, 다음 Filter로 넘기는 작업만 하는 것이에요.

요청은 그 다음 Filter로 이동(chain.doFilter)되게 됩니다.

최종적으로 인증 결과를 Client에게 응답하려 할 때, Session 안에 SecurityContext 객체를 저장하게 됩니다.
이 작업은 인증 Filter가 아닌 SecurityContextPersistenceFilter가 작업을 하게 됩니다.

그런 다음 SecurityContextHolder안에 SecurityContext 객체를 제거합니다.
제거하는 이유는 매 요청시 마다 SecurityContextPersistenceFilter는 새로운 SecurityContext 객체를 SecurityContextHolder안에 생성하게 될텐데, 이미 Session에 해당 객체가 저장되었기 때문에 같은 값을 계속 누적해서 가지고 있을 필요가 없기 때문이에요.

그런 다음 최종적으로 Client에게 응답을 보내게 됩니다.


인증이 성공한 뒤 이용자는 어떤 자원에 접근 요청을 보낼 수 있습니다.

이 때에도 역시 SecurityContextPersistenceFilter가 요청을 받게 되고, HttpSecurityContextRepository가 요청을 실제로 처리하게 됩니다.

이 때에는 인증을 성공한 뒤이기 때문에 Session에 SecurityContext 객체가 존재할 거에요.
왜냐하면 인증 시점에 Session에 SecurityContext를 저장했기 때문이에요.

이제는 Session에 저장된 SecurityContext 객체를 꺼내서 SecurityContextHolder에 SecurityContext 객체 안에 Authentication(인증 객체)를 저장 합니다.

그런 뒤 그 다음 Filter로 이동(chain.doFilter)되게 됩니다.

조금 더 내용을 요약해 보자면 SecurityContextPersistenceFilter는 인증 받기 전이라면 새로운 SecurityContext를 생성하게 되는데, 구조를 보면 SecurityContextHolder 안에 ThreadLocal이 있고, 그 안에 SecurityContext를 생성하게 되는데, 인증을 받기 전이기 때문에 Null인 상태로 만들게 됩니다.

인증을 받은 뒤라면 새로운 SecurityContext를 생성하게 되는데, 구조를 보면 SecurityContextHolder 안에 ThreadLocal이 있고, 그 안에 SecurityContext를 생성하게 되는데, 인증 성공한 Authentication (인증 객체)를 저장하게 됩니다.

인증을 받은 뒤 자원 접근과 같은 요청이 오게 되면 Session에 SecurityContext 객체를 꺼내 SecurityContextHolder 안에 담는 방식으로 처리가 됩니다.

    🔽  인증 흐름 이해

        📦 Authentication Flow

 

이용자가 Form 인증 방식의 인증 요청을 보냈을 때, 어떤일이 벌어지는지 알아볼게요.

UsernamePasswordAuthenticationFilter(Form 인증 처리 Filter)는 최초 이 요청을 받게 됩니다.
이 친구는 가장 먼저 ID와 Password를 받아 인증 객체 Authentication을 만들게 됩니다.

UsernamePasswordAuthenticationFilter는 AuthenticationManager에게 해당 객체를 전달하면서 인증 처리를 전달하게 됩니다.

여기까지가 Filter가 인증 처리를 하는 첫번째 단계입니다.

AuthenticationManager는 인증의 전반적인 관리는 하지만, 실제 인증 역할은 하지 않고, 적절한 AuthenticationProvider에 작업을 위임하는 역할을 합니다. 즉, ID, Password값이 정상인지 확인하는 과정에 개입하지 않아요.

관리자 Manager닌까 일을 시키기만 해요.

AuthenticationManager에는 List 변수가 있는데, 한 개 이상의 AuthenticationProvider 객체를 담을 수 있게 되어 있습니다. 해당 List 안에 있는 AuthenticationProvider 객체들 중 현재 인증 처리에 적합한 객체를 찾아 해당 AuthenticationProvider에게 인증 작업을 위임하게 됩니다.

AuthenticationProvider는 Manager로 부터 인증 객체인 Authentication을 전달 받았고, ID, Password 검증 작업에 돌입하게 됩니다.

최초 ID(Spring Security에서는 ID를 username 변수명으로 처리)를 검증할 때, loadUserByUsername()을 호출하면서 이용자 ID를 전달해주게 되요.

이 친구는 실제 인증 처리를 하고, 이용자 유효성 검증(Password 확인 등)을 담당하고 있어요.

만약 해당 username으로 된 ID값이 Data Base에 존재하면 인증 객체를 생성하게 되고, 존재하지 않으면 UsernameNotFoundException이 터지게 될거에요.
이렇게 예외가 발생하면 그 즉시 인증 실패 처리가 되어버리는데, UsernamePasswordAuthenticationFilter가 이 예외를 받아서 처리하게 됩니다. 즉, FailHandler가 받아서 후속 처리를 진행하게 되요.

만약 ID에 해당하는 username이 존재한다면 AuthenticationProvider에게 반환을 하게 되는데, UserDetails 객체 Type으로 반환하게 됩니다.

User 객체 Type으로 Repository가 넘겨주더라도 UserDetails Type으로 형변환을 해서 반환해야 합니다.

그런 뒤 AuthenticationProvider는 ID는 검증이 끝난 상태이기 때문에 Password를 검증하는 단계를 거치게 되요.
이용자가 입력한 Password 값과 Data Base에 저장된 Password 값이 일치하는지 검증을 하게 됩니다.

만약 Password가 일치하지 않으면 BadCredentialsException이 터지게 되요. 결국 인증은 실패하게 됩니다.

Password가 일치한다면 인증이 모두 성공하게 된 것이고, Authentication 객체를 만들어서 UserDetails(이용자 정보) 객체와 권한 정보를 담은 authorities 객체를 담은 Token 객체를 생성하게 됩니다.

해당 객체를 AuthenticationManager에게 다시 전달해주게 되고, AuthenticationManager는 AuthenticationProvider가 전달해 준 Authentication 객체를 UsernamePasswordAuthenticationFilter에게 다시 반환해 줍니다.

UsernamePasswordAuthenticationFilter는 마지막으로 SecurityContextHolder 안에 SecurityContext에 해당 인증 객체 Authentication 객체를 저장하게 되고, Client에게 응답해 줍니다.

    🔽  인증 관리자

        📦 AuthenticationManager

1. AuthenticationProvider 목록 중에서 인증 처리 요건에 맞는 AuthenticatonProvider를 찾아 인증 처리 위임.
2. 부모 ProviderManager를 설정 AuthenticationProvider 계속 탐색 가능.

AutenticationManager는 UsernamePasswordAuthenticationFilter(Form 인증 처리 Filter)로 부터 인증 처리를 첫번째로 위임 받는 친구에요. AutenticationManager는 Interface로 되어 있어요.
이를 구현한 구현체가 ProviderManager에요. 또한, 실제적으로 인증 처리를 하지는 않고, ProviderManager에게 위임하는 역할만 해요.

최초 이용자가 인증 요청을 할 때, Spring Security는 여러개의 인증 처리 방식이 있어요.
예를 들어 이용자가 Form 인증 방식으로 인증 요청을 한다고 가정했을 때, UsernamePasswordAuthenticationFilter가 ProviderManager를 호출하게 되요. 호출할 때, Authentication(인증 객체)를 함께 전달해 줍니다.

ProviderManager는 Authentication 객체를 받으면 AuthenticationProvider에게 전달하는 역할만 해요.

이 때, 여러 AuthenticationProvider가 있는데,선택 기준은 Form 인증인지 RememberMe 인증 인지 등등에 맞는 AuthenticationProvider를 선택하게 되어 있어요.

만약 Form 인증 방식일 때는, DaoAuthenticationProvider를 찾아 인증 처리 위임을 하게 됩니다.
또한, RemeberMe 인증 방식일 때는, RememberMeAuthenticationProvider를 찾아 인증 처리 위임을 하게 됩니다.

이용자가 만약 Oauth 인증을 요청했을 때는 ProviderManager가 가지고 있는 AuthenticationProvider 중에 Oauth 인증을 처리할 객체가 없어요. 이 때는 ProviderManager가 parent 속성이 있는데, 이는 AuthenticationManager Type의 속성을 저장할 수 있는 속성이고, ProviderManager Type에 객체를 저장할 수 있어요.

Spring Security가 초기화 될 때, parent 속성에 부모 격인 ProviderManager 객체를 저장하게 되요.
또한, ProviderManager객체 안에는 OauthAuthenticationProvider 객체가 있고, 저장할 수 있어요.
그리고 나서  OauthAuthenticationProvider 인증 처리를 위임하게 됩니다.

    🔽  인증 관리자

        📦 AuthenticationProvider

AuthenticationProvider는 인증 처리를 할 때, 가장 핵심적인 역할을 하고 있는 친구입니다.

AuthenticationProvider를 통해서 ID, Password 외에 추가 인증에 관련 검증을 처리할 수 있어요.
AuthenticationProvider 또한, Interface로 만들어져 있어요.

AuthenticationProvider 안에는 두 개의 추상 Method가 제공 되는데, authenticate(Authentication authentication)와 supports(Authentication authentication)가 있어요. 두 개 Method는 모두 매개 변수로 Authentication 즉, 인증 객체를 받도록 되어 있어요.

authenticate(Authentication authentication)는 실제 인증처리를 담당하고 있고, supports(Authentication authentication)는 현재 Form 인증, RememberMe 인증과 같은 인증을 처리할 수 있는 조건 혹은 기준 등을 검증하는 역할을 하고 있어요.

authenticate(Authentication authentication)은 매개 변수로 전달 받은 Authentication 인증 객체 (ID, Password 등이 담김)를 가지고, ID, Password, 추가 검증을 하고 있어요.

ID 검증을 할 때는 UserDetailsService Interface에서 Data Base 등에 저장된 ID 값이 존재하는지 검증하는 역할을 하고, 있다면 해당 이용자의 USER 객체를 생성해서 UserDetails 객체 Type으로 변환해서 AuthenticationProvider에게 전달 하고 있어요.

Password 검증은 UserDetailsService에게 반환 받은 UserDetails 객체 Type의 객체 안에 Password 값이 있는데, authenticate(Authentication authentication)에서 전달 받은 Authentication 객체 안에 있는 Password 값과
서로 비교하는 작업을 하는데, Password Encoder를 통해 암호화를 하는데, Hash 함수로 암호화된 Password를 복호화하는 것이 아닌 서로 같은지 비교만 하게 됩니다.

만약 다르다면 BadCredentialException이 터지게 되고, ID 검증이 실패하면 UserNotFoundException이 터지게 됩니다.

모든 검증이 정상적으로 끝나게 되면 AuthenticationProvider는 최종적으로 Authentication 인증 객체를 생성하는데, 이용자가 인증에 성공한 USER 객체와 권한 목록이 담긴 authorities List형 객체를 저장하여 AuthenticationProvider에게 인증 처리를 위임한 AuthenticationManager에게 전달하게 됩니다.

    🔽  인가 개념 및 Filter 이해

인가란? 이용자에게 무엇이 허가 되었는지 증명하는 것. (권한)

        📦 Authorization

최초 인증 처리를 하고, 인가 처리를 하게 되는데, 사용자가 어떤 자원에 접근하기 위한 요청을 할 때, Authenticated 즉, 사용자가 인증을 받았는지 받지 않았는지를 먼저 확인하게 되고, 인증을 받은 사용자가 다시 어떤 자원에 접근하려고 할 때, 해당 사용자가 가진 권한이 요청하는 자원이 가지고 있는 권한에 접근할 수 있는 자격이 있는지를 확인하여 최종 접근 여부를 판단하게 됩니다.

Spring Security는 어떤 권한 계층을 지원하고 있을까요?

1. Web Layer (웹 계층)

   • URI 요청에 따른 Menu, 화면 단위 Level 보안.
   • 이용자가 특정 URI에 접근 요청을 보냈을 때, 해당 URI에 권한과 이용자 권한 비교하여 접근 여부 판단.

2. Service Layer (서비스 계층)

   • 화면 단위가 아닌 Method와 같은 기능 단위 Level 보안.
   • 이용자가 특정 Method(Method 위에 권한 설정)에서 제공하는 Service에 접근 요청을 보냈을 때,
      해당 Method 권한과 이용자 권한 비교 접근 여부 판단.

2. Domain Layer (도메인 계층 - Access Control List, 접근 제어 목록)

   • 객체 단위 Level 보안.
   • 이용자가 File, Data Base와 같은 Application에 쓰기 작업을 하려고 할 때,
      해당 Domain에 설정된 권한과 이용자 권한 비교 접근 여부 판단.

 

 

 

 

        📦 FilterSecurityInterceptor

1. 마지막에 위치한 Filter 인증된 이용자에 대하여 특정 요청의 승인 / 거부 여부를 최종 결정.
2. 인증 객체(Authentication) 없이 보호 자원에 접근 시도 시 AuthenticationException 발생.
3. 인증 뒤 자원 접근 가능 권한이 존재하지 않을 경우 AccessDeniedException 발생.
4. 권한 제어 방식 중 HTTP(URI 방식) 자원 보안 처리 담당.
5. 권한 처리를 AccessDecisionManager에게 위임.

최초 이용자가 특정 자원 접근을 위해 요청을 보내고 있어요.

FilterSecurityIntercetptor는 이 요청을 받아 인증 여부를 확인하게 됩니다.
인증 여부를 확인할 때, 인증 객체(Authentication)가 존재하는지 확인하게 되고, 인증 객체가 없다면 AuthenticationException 즉, 인증 예외를 발생 시키게 되요. 해당 Exception은 ExceptionTranslationFilter가 받아 후속 작업 예를 들어 Login Page로 다시 이동을 시키는 등에 작업을 처리하게 되요.

인증 객체는 SecurityContext 안에 인증을 받았을 때, 저장이 되는 것을 우리는 공부했어요.
그렇기 때문에 해당 이용자가 인증을 받았다면 인증 객체는 존재하게 될 것이에요.

인증 객체가 존재한다면 SecurityMetadataSource 객체에서 이용자가 USER라는 URI로 접근했을 때, 해당 URI에 접근 가능 권한이 있을 거고, 해당 URI에 등록된 권한 정보를 가져오는 역할을 합니다.

즉, 이용자가 요청한 URI에 필요한 권한 정보 조회를 한 뒤 전달하는 역할을 합니다.

만약 해당 URI에 권한 정보가 Null일 경우 권한 심사를 하지 않고, 자원에 접근을 허용 시켜줍니다.

URI에 권한 정보가 있다면 SecurityMetadataSource는 해당 URI에 권한 정보를 AccessDecisionManager에게 전달을 해주게 되요.

AccessDecisionManager(최종 심의 결정자)는 인가 처리를 하게 되는데, 내부적으로 AccessDecisionVoter(심의자) 객체에 인가 관련 비교를 요청하게 됩니다.

AccessDecisionVoter는 해당 URI에 이용자가 접근할 권한이 있는지 여부를 판단하고, 승인 혹은 거부에 대한 의사 결정을 하여 AccessDecisionManager에게 전달해 주게 됩니다.

AccessDecisionManager는 전달 받은 결과값을 가지고, 최종적으로 해당 이용자가 해당 URI에 접근을 허용할지 말지를 판단하게 되는데, 접근을 거부하게 되면 AccessDeniedException을 터트리게 되고, 이 Exception을 ExceptionTranslationFilter에게 전달하게 됩니다.

접근이 허용되었다면? 이용자는 자원에 접근을 할 수 있게 될 거에요.

 

인가 처리 공부를 위에 위와 같이 SecurityConfig CODE를 작성해 주었어요.
/user 라는 URI에 접근 가능한 권한은 USER 이고, 나머지는 모두 접근 가능하게 처리가 되었습니다.

 

 

USER 권한을 가진 user 계정으로 인증을 받고, /user로 접근했을 때, 위와 같이 정상 접근 되는 것을 확인할 수 있어요.

 

 

하지만, /admin/pay는 ADMIN 권한만 접근이 가능한데, user 계정으로 접근을 하려고 했을 때 위와 같이 접근이 불가한 것을 확인할 수 있어요.

 

💡 참고 사항

403 Forbidden

HTTP 403 Forbidden 클라이언트 오류 상태 응답 코드는 서버에 요청이 전달되었지만, 권한 때문에 거절되었다는 것을 의미합니다.

 

 

 

 

    🔽  인가 결정 심의자

 

최초 FilterSecurityInterceptor(권한 처리 담당자)가 AccessDecisionManager에게 인가 처리에 대한 작업을 위임합니다. 위임할 때, authentication - 인증 정보, object(FilterInvocation) - 요청 정보, configAttributes - 권한 정보를 함께 넘겨줍니다.

AccessDecisionManager는 자신이 보유한 Voter들에게 authentication - 인증 정보, object(FilterInvocation) - 요청 정보, configAttributes - 권한 정보를 전달하면서 각 Voter들 즉, AccessDecisionVoter에게 권한 판단 심사를 위임합니다.

각각의 AccessDecisionVoter 매개 변수로 전달된 값들을 가지고, 접근 여부를 판단하고, 접근 허용(ACCESS_GRANTED), 접근 거부(ACCESS_DENIED), 접근 보류(ACCESS_ABSTAIN) 값을 반환하게 됩니다.

AccessDecisionManager는 반환된 결과값을 가지고, 이용자의 요청에 접근을 허용할지 말지를 결정하게 됩니다.
최종적으로 승인이 판단되면 FilterSecurityInterceptor에게 ACCESS_GRANTED 값을 반환하고, 거부가 되면
AccessDeniedException을 터트려 ExceptionTranslationFilter에게 전달하게 됩니다.

 

 

        📦 AccessDecisonManager

1. 인증 정보, 요청 정보, 권한 정보(매개 변수로 전달)를 이용, 이용자의 자원 접근 여부를 최종 결정하는 주체.
2. 여러 Voter 들을 가질 수 있으며, Voter 들로부터 접근 여부(허용, 거부, 보류)에 값을 반환받고, 판단 및 결정.
3. 최종 접근 거부 시 Exception 발생.
4. 접근 결정 세가지 유형. AccessDecisonManager는 Interface로 아래 3가지 구현체 보유.

   • AffirmativeBased : 여러개의 Voter Class 중 하나라도 접근 허가로 결론나면 접근 허가 처리.

   • ConsensusBased : 다수표(투표 방식 - 승인 및 거부)에 의해 최종 결정 판단.
      - 투표에서 결과가 동일할 경우 기본은 접근 허가이나, allowIfEqualGrantedDeniedDecisions를 false로 설정할
          경우 접근 거부로 처리.

   • UnanimousBased : 모든 Voter가 만장일치로 접근을 승인해야하며, 그렇지 않은 경우 접근 거부.

 

 

 

 

        📦 AccessDecisonVoter

1. 판단을 심사하는 위원. 이용자에 요청을 접근 여부를 판단.
2. Voter가 권한 부여 과정에서 판단하는 자료.

   • Authentication - 인증 객체 즉, 인증 정보(USER).
   • FilterInvocation - 요청 정보 (antMatcher("/user)).
   • ConfigAttributes - 권한 정보 (hasRole("USER")).

3. 결정 방식

   • ACCESS_GRANTED : 접근 허용(1).
   • ACCESS_DENIED : 접근 거부 (-1).
   • ACCESS_ABSTAIN : 접근 보류 (0).
      - Voter가 해당 Type의 요청에 대해 결정을 내릴 수 없는 경우.

 

 

 

    🔽  Spring Security Filter 및 아키텍처 정리

 

지금까지 공부한 내용을 한번 정리하는 시간을 가져볼게요.

검은색으로 표시된 각 Filter들을 기준으로 위쪽은 Spring Security가 초기화하는 과정이고, 아래쪽은 각 Filter들이 어떤 작업을 하는지 나타내고 있는 부분이에요.

최초 Spring Security가 초기화 될 때, 개발자가 작성한 SecurityConfig (WebSecurityConfigurerAdapter extens) Class들에서 여러가지 API를 정의하고, 각각의 API들이 요청을 받아 처리를 하게 구성을 합니다.

Spring Security가 초기화 될 때, SecurityConfig에 설정한 내용과 구성대로 각각의 Filter들을 생성하게 됩니다.
실제로 Filter가 요청을 처리하는 역할을 하며, 이 Filter들은 HttpSecurity가 생성합니다.

위의 그림처럼 두개의 SecurityConfig를 만들게 되면 개발자가 작성한대로 API 설정들이 만들어지게 됩니다.

해당 Filter 목록들은 WebSecurity 객체에 전달이 됩니다.
WebSecurity는 FilterChainProxy Bean 객체를 생성하게 되는데, 이 때, 생성자에 filter 목록들을 전달하게 되요.

FilterChainProxy는 전달 받은 각각의 Filter들을 가지고 있게 되겠습니다.

DelegatingFilterProxy 객체는 Sevlet Filter인데, Spring Secutiry가 초기화 될 때, 이미 FilterChainProxy는 Bean 객체로 생성된 상태이고, springSecurityFilterChain이라는 이름을 가진 Bean 객체를 찾게 되는데, 그 친구가 바로 FilterChainProxy에요.

DelegatingFilterProxy는 이용자의 요청이 들어왔을 때, 요청을 받아 springSecurityFilterChain이름을 가진 Bean 객체 즉, FilterChainProxy에게 해당 요청 처리를 위임하게 됩니다.

여기까지가 Spring Security가 초기화 될 때 일어나는 일이에요.

초기화 과정이 끝나고, 이용자가 인증 요청을 보내게 됩니다.

DelegatingFilterProxy가 최초 이용자 인증 요청을 받게 됩니다. 그런 뒤 FilterChainProxy에게 해당 요청에 대한 처리를 위임하게 됩니다.

FilterChainProxy는 위에서도 언급했듯이 초기화 과정이 일어나게 되면 Filter 목록들을 가지고 있게 됩니다.
그리고, 각각의 Filter들에게 차례대로 해당 요청 정보를 보내면서 호출을 하게 됩니다.

각각의 Filter들은 Chain 형식으로 자기 자신의 과업이 끝나면 다음 Filter에게 작업 처리를 위임하게 됩니다.

최초 SecurityContextPersistenceFilter가 호출이 됩니다.
SecurityContextPersistenceFilter는 HttpSessionSecurityContextRepository를 가지고 있어요.
HttpSessionSecurityContextRepository는 SecurityContext 객체를 생성하고, SecurityContext를 Session에 저장하고,저장된 SecurityContext를 초기화 하고,참조 하는 역할을 하고 있어요.

loadContext()에서는 이 이용자가 이전에 SecurityContext 객체가 생성되어 Session에 저장한 이력이 있는지 확인을 합니다.
인증 과정이기 때문에 이용자에 대한 Session 저장 이력은 없을거에요. 그렇기 때문에 Create SecurityContext를 하여 새로운 SecurityContext 객체를 만들게 됩니다.

인증 요청 이용자, 익명 이용자의 경우 SecurityContext 객체를 만들어 SecurityContextHolder 안에 저장하는 역할을 SecurityContextPersistenceFilter가 담당합니다.

그런 뒤 다음 Filter로 작업 순서가 넘어갑니다.

Logout  Filter는 Logout을 처리하는 Filter인데, 현재는 인증 요청이지 Logout 요청이 아니기 때문에 바로 다음 Filter로 작업 순서를 넘겨줍니다.

UsernamePasswordAuthenticationFilter가 Form 인증 처리를 하는 인증 Filter인데, 최초 Authentication (인증 객체)를 만들어 이용자가 요청 때 보낸 ID, Password값을 저장합니다.

그런 뒤 AuthenticationManager 인증 처리를 위임하게 되고, AuthenticationManager는 다시 AuthenticationProvider에게 인증 처리 작업을 위임합니다.

AuthenticationProvider는 UserDetailsService와 같은 Class를 이용하여 ID, Password를 검증합니다.
인증이 완료가 되면 SecurityContextHolder안에 SecurityContext 안에 Authentication을 저장하는데, 이 때, 이용자의 ID, Password, 권한 목록과 인증 여부 값 등을 저장합니다.

SecurityContextPersistenceFiler가 처음에 SecurityContextHolder와 SecurityContext 객체를 만들었는데, 이를 꺼내와서 저장하는 것이에요.

기억해야 하는 것은 UsernamePasswordAuthenticationFilter가 인증 처리가 완료가 되면 바로 SessionManagementFilter가 동작하여서 ConcurrentSession 동시 Session 접속 여부를 확인하게 되는데, 이전 인증 처리가 있었는지 허용되는 Session 개수가 얼마인지를 확인하여 만약 동시 접속 가능 개수가 한 개라고 설정했다고 가정했을 때, 이 전에 인증이 되지 않았다면 별다른 조치없이 통과가 되고, SessionFixation을 통해 인증을 성공한 시점에 새롭게 Cookie가 발급되게 됩니다.

인증을 시도하기 전에 Cookie는 사라지게 되고, 다시 Session과 Cookie가 생성, 발급되도록 처리가 됩니다.

Register SessionInfo 이제 Session 정보가 Server에 하나 등록되게 되는 겁니다.

이 처리가 인증 처리가 일어날 때 일어나는 작업이에요.

인증이 성공된 이후 SuccessHandler가 후속 작업을 할 때, 인증을 성공하게 되면 이용자가 요청한 Page로 이동하게 되어 있습니다.

이 때, SecurityContextPersistenceFilter가 Client에게 응답을 보내기 전에 Session에 SecurityContext 객체를 저장하도록 처리를 합니다. 그런 뒤 Clear SecutiryContext를 이용하여 SecurityContext 객체를 초기화 하는 작업을 진행해요.

여기까지가 인증을 요청했을 때, 일어나는 작업이에요.

이번에는 이용자가 요청한 Page로 이동될 때, 어떤 일이 발생하는지 알아볼게요.
DelegatingFilterProxy가 최초 그 요청을 받게 되고, FilterChainProxy에게 해당 요청에 대한 처리를 위임하게 됩니다.

FilterChainProxy는 자신에게 등록된 Filter들에게 차례대로 요청에 대한 작업 처리를 위임하게 됩니다.

SecurityContextPersistenceFilter가 다시 호출이 되는데, loadContext()에서 요청을 보낸 이용자가 이용자 Session에 SecurityContext 객체를 저장한 적이 있는지 없는지를 판단합니다.

현재는 인증을 성공했기 때문에 Session에 SecurityContext가 저장이 되어 있는 상태에요.
그렇기 때문에 새로운 SecurityContext 객체는 생성하지 않습니다.
그런 뒤 다음 Filter로 이동하는데, 이번에도 Logout 요청이 아니기 때문에 또 다시 다음 Filter로 작업이 이동됩니다.

UsernamePasswordAuthenticationFilter 역시도 인증 요청이 아니기 때문에 또 다시 다음 Filter로 작업이 이동됩니다.

이번에는 ConcureentSessionFilter(동시적 Session 제어 처리)가 동작하게 되요.
이 전에 인증을 받은적이 있는지를 확인하는데, 이 전에 인증을 받은 적이 없기 때문에 다음 Filter로 작업이 이동됩니다.

이번에는 RememberMeAuthenticationFilter를 알아볼게요.
현재 요청 이용자가 Session이 만료 혹은 무효화 되었을 때, Session안에 SecurityContext 객체 안에 Authentication 인증 객체가 Null일 경우 호출이 됩니다.

요청 이용자가 Request Header에 remember-me Cookie를 담아 보냈다면 인증 처리를 시도하게 됩니다.

AnonymousAuthenticationFilter로 작업이 넘어가게 되는데, 인증 혹은 권한 없이 어떤 자원에 바로 접속을 시도할 경우 동작하게 됩니다.

AnonymousAuthenticationFilter는 AnonymousAuthenticationToken 객체를 만들어 SecurityContext 객체 안에 저장하는 역할을 합니다.

SessionManagementFilter는 인증을 받을 당시 위에서 같이 처리된다고 언급을 했는데, 동작 조건은 요청 이용자 Request Header에 Session 안에 SecurityContext가 없거나, Null일 경우 동작해요.
이용자의 Session이 만료되었을 경우일텐데, 다른 우회적 방법으로 접근하는지 여부를 확인하게 됩니다.

ExceptionTranslationFilter와 FilterSecurityInterceptor가 인증 이후 자원 요청이 들어왔을 때, 가장 많은 역할을 하는 친구들이에요.

ExceptionTranslationFilter는 인증 혹은 인가에 대해 문제가 생겨 Exception이 터졌을 경우 동작하게 되는데, 
try catch로 감싼 chain.dofilter를 통해 그 다음 Filter인 FilterSecurityInterceptor를 호출해 버려요.

FilterSecurityInterceptor(인가 처리)는 먼저 요청 이용자에 Request에 인증 객체(Authentication)이 있는지 여부를 확인합니다. 없으면 AuthenticationException을 터트리고, ExceptionTranslationFilter에게 전달합니다.

그 다음은 인가 처리를 하는데, 이를 AccessDecisionManager에게 위임하게 됩니다.
AccessDecisionManager는 내부적으로 AccessDecisionVoter를 가지고, 인가 처리 여부를 결정하고, 결과값을 FilterSecurityInterceptor에게 반환합니다.

만약 인가 처리에 문제가 있다면 AccessDeniedException을 FilterSecurityInterceptor가 터트리게 되고, 이를 ExceptionTranslationFilter에게 전달합니다.

ExceptionTranslationFilter는 이 두가지 Exception을 처리하는 역할을 합니다.

이번에는 이미 인증이 되어 있는 상태에서 또 다른 브라우저 등으로 인증을 요청할 때 발생하는 작업에 대해 다시 한번 공부해 볼게요.

이용자가 인증 요청을 보내게 되고, DelegatingFilterProxy가 최초 요청을 받아 FilterChainProxy에게 요청 처리를 위임하고, FilterChainProxy는 Filter 목록에 있는 Filter들에게 작업을 위임 합니다.

SecurityContextPersistenceFilter, LogoutFilter, UsernamePasswordAuthenticationFilter는 첫번째 이용자가 인증 요청했을 때와 동일하게 작업이 처리 되고, 인증은 일단 성공 처리가 됩니다. 그래서 SecurityContextHolder 안에 SecurityContext 객체 안에 Authentication 인증 객체가 담기게 되고, 이를 Session에 저장하는 처리까지 완료 합니다. 이 때, SessionManagementFilter의 ConcurrentSession에서 동일 계정에 Session은 하나만 생성하도록 허용하는데, ConcurrentSession에서 두 가지 전략에 의해 처리가 됩니다.

첫번째는 현재 이용자 인증 시도를 차단 (SessionAuthenticationException)을 하게 되고, 
두번째는 이전 이용자 Session을 만료 (Session.expireNow) 처리를 하게 됩니다.

만약 두번째 처리를 한다면 해당 이용자는 첫번째 이용자와 동일하게 요청한 URI나, 정해져있는 URI로 이동하게 될 거에요. 해당 작업은 첫번째 인증 처리와 동일하게 처리가 되요.

이 때, 첫번째 인증 처리를 받은 이용자가 특정 URI 접근 요청을 보내게 되면 모든 Filter에 작업을 동일하게 처리한 뒤 ConcurrentSessionFilter가 요청을 받게 됩니다.

이 때, ConcurrentSessionFilter는 session.isExpired()를 통해 현재 이용자가 Session이 만료되었는지를 판단하게 됩니다.

첫번째 이용자는 이전 이용자 Session 만료 정책에 의해 Session은 만료가 되었고, session.isExpired()이 True로 반환되게 되는데, 그렇게 되면 해당 이용자를 바로 Logout 처리를 해 버리고, 응답으로 Errror Message를 주게 됩니다.
그러면 다음 Filter를 호출하지 않고, 작업은 종료 됩니다.





이전 글 : [Spring Boot] Spring Security Basic - 기본 API 및 Filter 이해편 

다음 글 : [Stpring Boot] Spring Security 실전 프로젝트 - 인증 프로세스 Form 인증 구현