이 강의에서는
지난 번에 말했듯이
유저를 인증할 때
Spring Security 프레임워크에서
사용하는 내장필터를
보여드리겠습니다
이러한 필터를 로그
또는 콘솔에서 확인하려면
웹 애플리케이션 내에서 두 가지 사항을 변경해야 합니다
첫 번째는
Spring Boot 애플리케이션의 주 클래스 내에서
@EnableWebSecurity 라는 주석을
추가해야 합니다
이 주석에서는 (debug = true) 로 설정하는
구성을 전달해야 합니다
두 번째 변경 사항은
application.properties 파일 내에서
디버그 로깅을 가능하게 하는
FilterChainProxy 클래스를 활성화해야 합니다
이 FilterChainProxy는
Spring Security 프레임워크 내부에서
내장 필터를 연결하는 데 사용되는 로직을 가지고 있습니다
하지만 이러한 변경 사항은
실제 웹 애플리케이션 내에서
수행하지 마십시오
왜냐하면 내부 필터 세부 정보 뿐 아니라
엔드 유저의 민감한 정보(세션 ID)까지
로그에 기록되어
보안 위협을
초래할 수 있습니다
여러 가지 보안 문제를 일으킬 수 있습니다
부디 제발 이 문제를 피하시기 바랍니다
이 점은 슬라이드에서도 강조하고 있습니다
우리의 이해를 위해
이러한 변경 사항을 일단 웹 애플리케이션에 적용하겠습니다
이 섹션에서
필터 관련 사항을 작업하려면
섹션 8에 특화된 새로운 Maven 프로젝트를 생성해야 합니다
이를 위해 이전 섹션 프로젝트를 복사하여
동일한 폴더에 붙여넣고
프로젝트 이름을
springsecsection8으로 변경하겠습니다
이 프로젝트의 target 폴더 내용을 삭제하고
pom.xml 파일을 열어서
artifact ID 및 이름을
springsecsection8 으로
변경합니다
이러한 변경 사항을 저장하고 pom.xml을 닫습니다
이로써 우리는 이 새로운 프로젝트를
IntelliJ IDEA 로 불러올 수 있습니다
가지고 오려면 File 옵션을 누르고
New 그리고 Module from Existing Sources
그리고 springsecsection8 의 pom.xml을 클릭합니다
그리고 똑같이 선택합니다
이렇게 하면 새로운 Maven 프로젝트가 워크스페이스에 가져와 집니다
이제 모든 dependencies가 다운 되도록
모든 Maven 프로젝트를 리로드해보겠습니다
모든 dependencies가 다운 되면
이 모듈을 만들어 보려면 우클릭해서
Build Module 'springsecsection8'을
선택합니다
이제 제 프로젝트를 빌드할 수 있고
컴파일 오류는 다행이 없습니다
이제 프로젝트 내의
Spring Boot 메인 클래스로 이동합니다
메인 클래스의 이름은 'EasyBankBackendApplication'입니다
이 클래스 상단에
@EnableWebSecurity라는
주석을 추가합니다
그리고 이 주석에
디버그를 활성화하는 구성인 (debug = true) 를 전달합니다
기본적으로 false 으로 설정되어있어 이를 활성화할 것입니다
이것이 첫 번째 변경사항 입니다
두 번째로
해야 할 것은
application.properties로 이동하여
Spring Security 프레임워크 내에 있는
filterChainProxy 클래스의 디버그 로깅을
활성화하는
속성을 추가해야 합니다
자 그러면 여기 FilterChainProxy에
무엇이 있는지 살펴봅시다
이와 관련하여 여기서 열어보겠습니다
이것은 Spring Security 프레임워크 내에 존재하는 클래스입니다
이 클래스 내에서 VirtureFilterChain 이라는 이름으로
내재된 클래스를 찾습니다
이것이 Spring Security 프레임워크로 인해
유지될 VirtureFilterChain 입니다
이 필터 내부를 살펴보면
doFilter라는 메소드가 있고
메소드 안에는 내 Spring Security 필터 체인 내에서
사용 가능한 모든 필터를 반복하는 로직이 있습니다
currentPosition이 어디인지를
추적할 수 있습니다
만약 currentPosition이 필터의 총 size와 같다면
다음 필터는 호출되지 않습니다
대신에 originalChain.doFilter를 부릅니다
그것이 아니라면 이 체인 내에
가능한 다음 필터를 불러옵니다
그리고 다음 필터를 사용할 때
doFilter 메소드를 호출합니다
이렇게 하면 Spring Security 프레임워크가
활성화된 모든 내부 필터를
하나씩 반복하면서
각각의 필터 내부의 로직이 실행됩니다
이제 우리가 할 것은 필터 체인을 실시간으로 보기 위해
여기에 중단점을 만드는 것입니다
이제 이러한 변경 사항이 모두 완료되었습니다
빌드를 수행하고
마무리 되고 나면
EasyBankBackendApplication 인
Spring Boot 메인 클래스로 가서
디버깅 모드를 실행해보겠습니다
이제 백엔드 서버가 성공적으로 시작되었습니다
디버그 콘솔을 열면
'Security debugging is enabled'라는
메시지가 표시되는 것을 볼 수 있습니다
민감한 정보를 포함하고 있기에
실제 운영 서비스에서 실행되면 안됩니다
이는 이전 강의에서 강조한 부분입니다
이러한 설정은 제발
프로덕션 웹 애플리케이션에서 사용하지 마십시오
추후 로그를 분석할 때를 위해
콘솔을 깨끗이 하겠습니다
그리고 애플리케이션에 로그인 하겠습니다
여기서는 happy@example.com 과
비밀번호 12345입니다
로그인을 누르자마자
FilterChainProxy 안에 가능한 VirtualFilterChain에서
중단점이 멈춘 것을 볼 수 있습니다
여기서 현재 필터의 총 size는
17이며 이는 Spring Security 프레임워크가
약 17개의 필터를 실행할 것을 의미합니다
currentPosition은 무엇일까요?
currentPosition은 0이기 때문에
그래서 현재 이 if 블록 안으로 들어가지 않을 것입니다
이 줄들을 하나씩 실행하면
Spring Security 내장 필터를 볼 수 있습니다
여기서 볼 수 있듯이 추가 필터 목록을 열면
Spring Security 프레임워크에서
실행되는
모든 필터입니다
각 필터는 doFilter
메소드를 호출하여
하나씩 반복됩니다
이 중단점을 해제하고면
17번을 멈출 것이기 때문에
이 중단점을 제거할 수 있습니다
이제 콘솔을 확인하면
여기에서 Spring Security가
로깅하는
민감한 정보를 볼 수 있습니다
따라서 유저 이름 및
비밀번호의 base-64로 인코딩된 값과
함께 인증 헤더를 기록하고 있습니다
그래서 이것은 프로덕션 웹 애플리케이션에서
활성화하는 것이 권장되지 않는 이유입니다
이제 스크롤하여
엔드 유저 인증 중에 실행된
내부 Spring Security 필터들을 볼 수 있습니다
따라서 인증 중에
Spring Security의 많은 내부 필터가
실행되고 있음을
확인할 수 있으며
각각은 자체적인 역할과 책임이 있습니다
이해가 되었길 바랍니다
다음 강의에서는 커스텀 필터를
정의하는 옵션에 대해 탐색하고
커스텀 필터를 정의하고 나면
우리의 요구사항을 기반으로
커스텀 로직을 실행하기 위해서
이러한 것들을 security 필터 체인 내에 삽입하는 것을 살펴보겠습니다
모든 내용이 명확하게 전달 되었길 바랍니다
감사합니다 다음 강의에서 뵙겠습니다