좋습니다
이제 우리는 자체적으로 AuthenticationProvider를
실행할 수 있게 되었습니다
우리는 UserDetailService에 영향을 주고 싶지 않습니다
따라서 이러한 변화를 시험해보기 전에
우리가 소유하고 있는 클래스를 지워야 합니다
클래스는 유저 세부 사항에 대한 실행입니다
DaoAuthenticationProvider에 영향을 미치고 싶지 않기 때문에
우리만의 authentication 로직을 작성하였습니다
이러한 이유로 이 클래스를 제거해도 됩니다
더 이상 필요가 없기 때문입니다
이 시점에서는 우리의 애플리케이션을 시작해도 될 것입니다
여기에서 빌드를 하도록 하겠습니다
빌드가 성공적으로 끝났다면
디버그 옵션을 선택하여
웹 애플리케이션을 시작할 수 있습니다
이것이 port 8080에서 웹 애플리케이션이 시작하도록 합니다
이 상황에서는 우리가 단일
실행시킨 것을 볼 수 있습니다
하지만 원한다면 당신의 애플리케이션에
원하는 수량의 AuthenticationProviders를 실행시킬 수 있습니다
하지만 프로덕션 웹 애플리케이션에서는
그런 상황을 흔히 접하지는 못했습니다
단일 AuthenticationProvider가
그 어떤 종류의 authentication 로직도 모을 수 있기 때문입니다
하지만 만약 클라이언트에게 특이한 조건이 있다면
예를 들어 다양한 인증을 서포트하고 싶다던지 등
그럴 경우에는 AuthenticationProviders의 수량에
선호하는 숫자를 입력해도 됩니다
이제 제 서버가 시작되었고 브라우저 창에 가서
보안된 API에 접속을 시도할 수 있습니다
이전에는 authentication 메소드에 우리가 반납했던
중단점을 삽입할 수 있습니다
또 supports 메소드에도 중단점을 삽입할 수 있습니다
브라우저 창에서는 localhost:8080/my account라는
경로에 접속할 수 있습니다
my account를 입력하기 전에
공공 API에 접속을 시도해야 합니다
contact에는 인증이 요구되지 않기 때문에
이 부분에 대해서는 상관이 없습니다
이제 보안된 API 즉 my account에 접속할 수 있습니다
제 인증 정보에 대해서 묻고 있는 것을 볼 수 있습니다
제가 사용하고자 하는 인증 정보는
john@example.com이고 비밀번호도 입력할 텐데
비밀번호는 1,2,3,4,5 입니다
로그인 버튼을 누르면 보시다시피
ProviderManager가 AuthenticationProvider 내에
supports 메소드를 주입시키려고 하는 것을 볼 수 있습니다
이 ProviderManager를 클릭하면
이런 상황이 벌어지고 있는 것을 볼 수 있습니다
이제 자체적으로 제작했던 AuthenticationProvider 내에서
authenticate 메소드의 실행이 중단되었습니다
그리고 여기서 이 유저 이름은
엔드 유저에 의해서 작성됩니다
줄 별로 디버그를 시도해보겠습니다
이것이 비밀번호이며
엔드 유저에 의해 작성되었고 유저 이름을 바탕으로 지정됩니다
제 경우에는 john@example.com입니다
유저 세부 사항을 불러오려고 합니다
record가 있기 때문에 이 리스트의 사이즈는 1입니다
이어서 if 블록으로 넘어가겠습니다
여기서 비밀번호에 대한 확인이 이루어집니다
확인되었다면 if 블록으로
들어가게 됩니다
authorities 세부 사항을 모을 것입니다
이로써 저는 유저명 비밀번호 authentication token에
도달하게 됩니다
따라서 이 step out 옵션을 클릭하여
되돌아가보도록 하겠습니다
보시다시피 ProviderManager 속에서
결과가 도출되었습니다
ProviderManager에게서 결과를 받으면
하우스키핑(housekeeping) 활동을 진행할 것입니다
제가 선호하는 하우스키핑 활동 중 하나는
당신이 넘기는 인증 정보를 제거하는 것입니다
Spring Security 내에서 비밀번호가
더 이상 필요없기 때문입니다
인증이 성공적이기 때문에 더 이상 필요가 없습니다
이것이 제 ProviderManager가
authentication 객체로부터 비밀번호를 제거하는 이유입니다
우리의 비밀번호가 프레임워크 내에서
돌아다녀서 보안 문제로
우려할 필요가 없도록 하기 위해서 입니다
중단점을 뛰어넘으면
if 로그로 들어가게 되는 것을 볼 수 있습니다
이곳에서 credentials를 제거하려고 하는 것입니다
지금은 results 객체 내에서
자격 증명이 존재하는 것을 볼 수 있습니다
만약 이 plus를 클릭하면 다른 자격 증명를 볼 수 있습니다
만약에 이 코드가 실행된 후에
eraseCredentials 메소드를 실행한다면
authentication 객체을 강조하려고 한다면
결과 값은 이것이고 plus를 누르면
credentials가 null로 설정되어있는 것을 볼 수 있습니다
하지만 이 authenticated가 true로 나타나기 때문에
Spring Security 프레임워크가
authentication의 성공 여부를 이해할 수 있기에는
충분하다고 볼 수 있습니다
그 이후에 ProviderManager가 해야 할 것이
더 남아있습니다
예를 들어 인증이 성공적으로 게재되었음을 알리고
이벤트를 게재할 것입니다
만약 엔드 유저에게 성공적으로 인증이 발생했다고
이메일을 보내려고 한다면
Spring Security 프레임워크에서 게재하는
이벤트에 귀를 기울이고 있어야만 합니다
그리고 이에 따라 이메일을 보낼 수 있습니다
이번 강의를 통해 ProviderManager 내에서 발생하는 코드에 대해
완벽하게 이해하게 되셨으면 좋겠습니다
여기서 중단점을 해제하겠습니다
이제 저는 브라우저 창으로 이동할 수 있습니다
그리고 브라우저에서 성공적인 답변을
받았다는 것을 볼 수 있습니다
이로써 웹 애플리케이션 내에서
자체적으로 AuthenticationProvider를 실행해보았습니다
이러한 유연성을 통해서
authenticate 메소드 내에서 줄의 개수를 상관하지 않고
로직을 작성할 수 있습니다
모든 조건이 충족되었다고 느낄 때
UsernamePasswordAuthenticationToken에 대한
객체를 생성할 수 있습니다
이것이 Spring Security의 아름다움입니다
모든 상황에 적용될 수 있다는 점이 가장 아름답습니다
유연하게 대처할 수 있기 때문에
모든 종류의 Security 시나리오를 적절하게 대처할 수 있습니다
이것이 단체 내에서 자체적으로 프레임워크를 쓰는 것보다
Spring Security를 사용하는 것이
가장 현명한 선택지인 이유입니다
이번 강의에서 나누었던 이야기들을
모두 이해하셨길 바랍니다
감사합니다 다음 강의에서 뵙겠습니다