이 강의에서는
SecurityFilterChain bean을 활용해
맞춤형 보안 설정을 정의해보겠습니다
보시다시피 이전 강의 내용을 기억하신다면
현재
우리 Spring Boot 웹 애플리케이션에는
6개의 각기 다른 API가 있습니다
이 API들 중 4개
myAccount, myBalance, myLoans, myCards
이 API들은 보호하고
나머지 API인 문의하기와 공지사항은
누구나 호출할 수 있도록 보호하지 않길 원합니다
이것이 우리 웹 애플리케이션에 대한
우리의 맞춤형 요구사항입니다
그럼 우리의 맞춤형 요구사항을
어떻게 정의해야 할지 살펴보겠습니다
맞춤형 요구사항을 정의하고자 할 때마다
우리는 requestMatches라는 메소드를 호출해야 합니다
이 requestMatches 메소드는
API 경로를 무제한으로 받아들입니다
여러분의 API 경로를 정의했다면
API를 보호하기 위해 authenticated라는
메소드를 호출합니다
아니면 API가 보호되지 않도록 하는
permitAll 메소드를 호출합니다
그러면 모두가 접근할 수 있습니다
화면에 보시다시피
이것이 우리가 작성할 샘플 코드입니다
이 지식을 가지고
이것을 우리 Spring Boot 애플리케이션에
적용해보겠습니다
현재 우리 Spring Boot 웹 애플리케이션에는
anyrequest.authenticate가 있는데
모든 요청이 디폴트로 보호된다는 뜻입니다
우리는 이걸 원하지 않습니다
그러니 이걸 삭제하고 다음 줄로 가보겠습니다
여기 authorizeHttpRequest 다음에
requestMatches라는 메소드를 호출하겠습니다
이 requestMatches 메소드는
무제한의 API 패턴을 받아들일 겁니다
일단은
myAccount, myBalance, myLoans, myCards
네 가지 API 패턴을 입력해보겠습니다
이 API들은 모두 보호되길 원합니다
그래서 authenticated 메소드를 호출해야 합니다
우리가 authenticated 메소드를 호출할 때마다
Spring Security 프레임워크에
이 API 경로들을 보호하고 싶다는 표시가 됩니다
여기를 자세히 보시면
올바른 경로를 정확히 입력했습니다
필요하다면 거부 패턴도 입력할 수 있습니다
**를 입력한다면
myAccount가 기본 경로인 모든 경로는
보호된다는 뜻입니다
따라서 정확한 경로명을 정의할지
거부 패턴을 활용할지는
우리에게 달렸습니다
다음으로 나머지 API 경로의 경우
아무런 보안 없이 접근 가능하길 원합니다
그러기 위해
requestMatches를 한 번 더 호출해야 합니다
이번에는
공지사항과 문의하기의 API 경로를 입력하겠습니다
이 경로들 다음에는
permitAll이라는 메소드를 호출해야 합니다
메소드의 이름과 같이
모든 사람에게 이 API 경로들을
접근할 권한을 준다는 게 명확합니다
그 다음 세미콜론을 입력하겠습니다
이 설정으로
우리의 맞춤형 요구사항을 정의했습니다
그 다음으로
formLogin과 httpBasic이 있습니다
이 formLogin과 httpBasic을
위에서 했던 설정과
결합할 수 있습니다
그렇게 해보겠습니다
여기서는 and라는 메소드를 호출하겠습니다
and는 Spring Security의 여러 설정을
결합하는 메소드입니다
이 and 메소드 다음으로
formLogin을 호출하겠습니다
그 다음
and 메소드를 한 번 더 호출하고
httpBasic을 호출합니다
이건 우리가 앞에서 본 것과 아주 유사합니다
이렇게 하면
우리가 여기에서 정의한 맞춤형 보안 요구사항으로
충분합니다
빌드하겠습니다
빌드가 완료되면
API 경로로 가서
우리의 설정에 따라
잘 작동하는지 확인할 수 있습니다
브라우저에서
먼저 공지사항 API를 호출하겠습니다
공지사항 API는 보안 API가 아닙니다
그래서 제대로 된 응답을 받아야 합니다
이 API를 호출해봤지만 안타깝게도
여전히 로그인 페이지가 보입니다
무엇이 문제인지 살펴보겠습니다
뒤에서 문제를 디버깅합니다
문제는 EasyBankBackendApplication 안에
우리가 ComponentScan을 정의했다는 것입니다
이 ComponentScan에
우리가 controller 이름의 패키지를 전달했지만
이 ProjectSecurityConfig 이름의 패키지는
전달하지 않았습니다
그 이유로 이 bean이 생성되지 않은 것입니다
이전 강의에서
아무런 문제도 없었던 이유는
우리가 이 bean 안에 어떤 코드를 정의했든지
프레임워크 안에 무엇이 있든지
두 가지가 동일하기 때문입니다
그래서 이전 강의에서
아무런 문제도 없었던 것입니다
하지만 지금은
이 ComponentScan 안에도
config 패키지 이름을 정의하면 되는데
새로운 패키지를 생성할 때마다
이렇게 해야 할까요?
당연히 아닙니다
여길 보시면 해당 패키지가 여기 있습니다
제 Spring Boot의 메인 애플리케이션은
com.eazybytes 안에 있는데
이 config, controller
이 패키지들은 상위 패키지인
com.eazybytes의
하위 패키지입니다
이런 시나리오에서
ComponentScan을 언급할 필요가 없지만
한 패키지에서 언급하기 시작했다면
다른 패키지에서도 동일 내용을 반복해야 합니다
그러니 여기서 선택할 수 있는 간단한 해결법은
이 ComponentScan을 삭제하고
Spring Boot가 제 애플리케이션의 모든 하위 패키지를
스캔하는 마법을 부리도록 하는 것입니다
이 수정 사항들을 저장하고 빌드하겠습니다
이 수정 사항들로 인해 이번에는 여기
SecurityFilterChain 타입으로 생성한 저의 맞춤형 bean이
생성되었을지도 모릅니다
그럼 브라우저로 가서 공지사항 API를 호출하겠습니다
보시다시피 이번에는 성공적인 응답을 받았습니다
문의하기에도 똑같이 하겠습니다
문의하기에서도 로그인 페이지 없이 응답을 받습니다
이번에는 보안 API중 하나인
접근해보겠습니다
myAccount는 보안 API이므로 당연히
로그인 페이지가 나와야 합니다
좋습니다 로그인 페이지가 보입니다
eazybytes라고 자격 증명을 입력하겠습니다
그리고 비밀번호는 12345입니다
로그인을 클릭하자마자
제대로 된 응답을 받습니다
하지만 그 전에
모든 중단점을 비활성화하고
이 중단점을 해제하겠습니다
보시다시피
저의 로그인 페이지에 보안 정보를 입력하자
적절한 응답을 받습니다
이렇게
이 SecurityFilterChain bean의 도움으로
우리만의 보안 맞춤형
요구사항을 정의했습니다
물론 우리가 한 것은 간단한 설정입니다
우리가 이 과정을 나아가는 동안
Spring Security 프레임워크 안의
더 많은 옵션들을 알아볼 것입니다
더 많은 것을 배울테니 마음의 준비를 하시기 바랍니다
감사합니다
다음 강의에서 뵙겠습니다 수고하셨습니다