이전 강의에서
우리는 Spring Boot 웹 애플리케이션과
REST 서비스를 빌드했습니다
하지만 우리는 애플리케이션이
보호되지 않은 사실이 불만족스럽습니다
아무나 제 REST 서비스를 호출 할 수 있고
그들이 응답을 받을 수도 있습니다
이것은 프로덕션 애플리케이션 관점에서
좋지 않은 기준입니다
그래서 이번 강의에서는
웹 애플리케이션을 보호할 수 있는 법이나
이때까지 빌드한 REST API 경로를
안전하게 확보하는 법에 대해서 배워봅시다
브라우저로 가보겠습니다
현재까지로는 제가 여러 번 호출해도
제대로 된 답변을 받았으며 애플리케이션은
제 REST 서비스를 접근하는데에 있어 자격을 요구하고 있지 않습니다
우리의 애플리케이션을 한 번 개선해봅시다
start.spring.io 으로 가게 되면
Security 이름의 dependency를 찾을 수 있습니다
새로운 종류의 Security로
Spring Security dependency가 있다는 것을 확인할 수 있습니다
자 이제 이 Spring Security dependency를 선택합시다
이 dependency를 추가하면
프로젝트를 한 번 더 생성할 필요가 없습니다
대신에 우리가 할 수 있는 것은
Explore button을 눌러
제 Maven 애플리케이션의 pom.xml 을 확인하는 것입니다
이 pom.xml을 전체 복사하여 제 IDEA로 갈 수 있습니다
이제 제 프로젝트인 springsecuritybasic에서
pom.xml 을 열어
간단히 제가 복사한 콘텐츠로
대체할 것입니다
그걸 하자마자 제 IntelliJ IDEA안에
Maven 새로 고침 옵션이 생긴 것을 확인할 수 있습니다
Maven 변경 사항을 불러보겠습니다
이렇게 하면 Spring Security와 관련된
dependencies들이 다운로드 될 것입니다
pom.xml에서 가능한
스타터 프로젝트들을 살펴보면
우리는 이미 이전 강의에 추가한
spring-boot-starter-web에 대해서 알고 있습니다
spring-boot-devtools에도 똑같이 적용됩니다
새로 추가한 dependency는
spring-boot-starter-security입니다
자 이것은 우리의 웹 애플리케이션을 보호할
Spring Security의 dependency 입니다
이제 웹 애플리케이션 내에
새로운 dependencies 를 추가했으니
애플리케이션을 재시작 해보겠습니다
이런 이유로 DevTools에 의존할 수 없습니다
제가 할 수 있는 것은 여기다 빌드를 만드는 것입니다
빌드가 완성된 후
현재 실행 중인 인스턴스를 중지할 수 있습니다
웹 애플리케이션을 디버그 포트에서 시작해보겠습니다
이번에 애플리케이션이 성공적으로 시작하면
마법이 일어날 것을 곧 목격할 수 있습니다
그 마법을 보여드리겠습니다
그리고 이 마법은
Spring Security 프레임워크가 지원하는 것입니다
여러분 브라우저에서
localhost:8080/welcome을 접근하려고 하면
지금은 아무런 반응도 받지 않을 것입니다
대신에 제 Spring Security 프레임워크는
제 자격증명을 요구하고 있습니다
개발자로서 저는 방금 Spring Security dependency만
추가했을 뿐 이 로그인 페이지 관련
또는 REST API 보호 관련하여
그 어떤 코드도 변경하지 않았습니다
이런 모든 기능은
기본적으로 Spring Security 프레임워크에서 제공하는 것입니다
앞으로의 강의들에서
이 모든 내용을 세세하게 다룰 것입니다
하지만 현재 저희에게 문제가 있습니다
바로 입력해야하는
유저네임과 비밀번호가 무엇일까요?
Spring Security 프레임워크에서 기본으로 제공하는 유저네임은
user 그 자체입니다
따라서 유저를 입력하고 나면
비밀번호도 입력해야 합니다
기본 비밀번호 값이 없습니다
비밀번호는 스타트업 동안 생성이 되어
여러분의 콘솔에 표시될 것입니다
자 이제 콘솔에서 비밀번호를 찾아 봅시다
제 콘솔에서
이번 세션에서
Spring Security 프레임워크에서 생각하고 있는
비밀번호를 찾을 수 있습니다
만약에 재시작하면 당연히 새로운 비밀번호를 받을 것입니다
자 이제 이 비밀번호를 가져가 봅시다
여기에 비밀번호를 입력하고
sign in 버튼을 눌러봅시다
Sign In 버튼을 누르자마자
제가 제대로 된 답변인 "Welcome to Spring Security without Security"을 받는 것을 확인할 수 있습니다
받는 것을 확인할 수 있습니다
따라서 이것은 우리 애플리케이션으로 부터 오는
예전 메시지인 것입니다
애플리케이션이 보호 받지 못할 때
이 메시지를 전송했습니다
이제 애플리케이션이 보호를 받고 있으니
답변이 조금 더
이해가 되도록 업데이트를 해봅시다
이제 WelcomeController에서
이 부분을 삭제할 것입니다
그렇게 하면 제 반환되는 응답은
"Welcome to Spring Application with Security" 이 됩니다
저장 후 빌드 작업을 진행하겠습니다
그리고 DevTools의 도움으로
제 애플리케이션은 자동으로 재시작 됩니다
이제 바로 브라우저로 가서
페이지를 새로고침 해보겠습니다
자 이제 저는 페이지를 새로고침 해보고 있습니다
업데이트 된 응답이 나타나는 것을 확인할 수 있습니다
강조하고 싶은
Spring Security 프레임워크의 마법 또는 매력은
새로고침을 몇 번이나 해도
또는 여러 번 응답 요청을 해도
프레임워크는 매번
자격 증명 정보 입력을 요구하지 않습니다
단지 첫 번째 요청 때만
로그인 페이지를 보여주며
자격 증명 정보를 요구할 것입니다
그리고 뒷면에서 Spring Security 프레임워크는
세션 ID나 토큰 세부 정보를 저장해주어
동일한 브라우저를 사용하는 한
계속해서 자격 증명을 묻지 않게 됩니다
앞으로의 강의에서
이것을 세부하게 다루어질 예정이지만
여러분이 이 기능에 대해서 알고 있기를 바라며
강조하고 싶었습니다
하지만 우리는 이 애플리케이션에 만족하나요?
당연히 아닙니다
우리는 이 애플리케이션을 실제 환경에 갖고 갈 수 없습니다
왜냐하면 유저 이름은 항상 기본 값이며
비밀번호는 매번 새롭게 생성되기 때문입니다
즉 재시작을 할 때마다
새로운 비밀번호를 받게 될 것이고
이것은 가장 낮은 CVRT 애플리케이션에서는 작동하지 않을 수 있습니다
추가적인 개선안으로
우리는
우리 고유의 유저이름과 비밀번호를 설정하여
매번 이 자격증명 정보를 쓸 수 있게 할 수 있습니다
몰론 이것은
운영 환경에서 권장하지 않는 접근 방식입니다
운영 환경에서 권장하는 접근 방식은
자격증명을 불러오거나
저장 시스템에 자격증명 정보를 보관하는 것입니다
그리고 데이터베이스와 같은 저장 시스템의 도움으로
우리는 최종 사용자를 인증해야 합니다
우리는 데이터베이스의 도움
또는 두 프레임워크를 사용하여
인가 서버의 도움을 받아
최종 사용자를 인증하는 법에 대해서 추후 다룰 예정입니다
본 수업 과정을 통해 더 많은 내용과
더 많은 마법같은 것들을 확인할 것입니다
하지만 지금은
이것이 웹 애플리케이션을 보호하는
가장 간단한 방법인 점을 강조하고 싶었습니다
그리고 여러분은 이러한 접근 방식을
웹 애플리케이션을 보호하는 여러분의 여정 속에서
작은 애플리케이션을 빌드하고 싶을 때 언제든지 사용할 수 있습니다
이 모든 정보가 여러분한테 명확했으면 좋겠습니다
감사합니다 다음 강의 때 뵙겠습니다
수고하셨습니다