저번 강의에서의 주제를
계속 이어나가겠습니다
다음으로 Angular UI 애플리케이션 내부에서
변경할 것은
원래 있었던
interceptor 파일을 제거하는 것입니다
원래는 interceptor 파일이 있어서
authorization header와
CSRF 토큰 값에
들어가 있었습니다
그 interceptor는 완전히 없앴습니다
왜냐하면 이 Keycloak Angular library에는
내부적인 interceptor가 있기 때문입니다
그러므로 별도의 interceptor는
더 이상 필요가 없어졌습니다
다음으로 중요한 변경사항은
라우팅 관련 파일 내부에 있습니다
app-routing.module.ts를 열면
이 라우팅 파일 내부에는
원래는 누군가가
로그인 경로를 실행했을 때
로그인 페이지를 띄우는
LoginComponent를
이용했었습니다
하지만 지금은
이 로그인 경로를 호출하지 않을 것입니다
header.component.html로 가면
path/login 대신
Keycloak 함수를 호출하고 있습니다
그러므로 저희가 이전에 사용하던
로그인 페이지는
호출이 되지 않을 것입니다
그 대신 이 로그인 함수가 호출하는
Keycloak 로그인 페이지를
보게 될 것입니다
다음으로 여기 있는 라우팅 정보입니다
dashboard, myAccount
myBalance, myLoans, myCards 같은 정보들을
이 class의 도움을 받아
안전하게 지키려고 합니다
AuthKeyCloakGuard입니다
이 class 내부에는
제가 로직을 작성해 놨습니다
여기를 보시면
이 클래스는 KeyCloakAuthGuard를 연장합니다
KeyCloakAuthGuard가 연장되면
여기 보이시듯이
user와
userProfile과 같은 변수를 선언했고
이 class의 constructor에게는
라우터 정보와
KeycloakService를 주었습니다
그 후에는
Angular 프레임워크가 호출할
메소드인
isAccessAllowed가 있습니다
이 로직이
실사용자가 이 보안 경로에 접근하도록
허용해도 되는지
판단하는 데 사용됩니다
이 메소드 안에는
저희가 확인했던 변수
authenticated가 있습니다
authenticated 변수는
KeyCloakAuthGuard에 있습니다
인증이 성공적으로 이루어졌다면
library 는 이 값을 true로 설정할 겁니다
인증이 완료된 후에는
이 else 블록이 실행됩니다
이렇게 하지 않으면 if 아래를 보시면
유저가 로그인 페이지로
리다이렉트될 것입니다
인증이 성공적이었다면
이 else 블록 아래에
먼저 이 userProfile 객체를 정의하고
authStatus를 AUTH로 정의하려 합니다
그리고 name에는
userProfile.firstName 값을 줘서
이 이름을 대시보드에 표시할 수 있도록 하고 있습니다
또한 email 역시
Keycloak 인증 서버로부터 받은
사용자 프로필 정보로부터
가져오고 있습니다
이 모든 사용자 정보는
세션 저장소에는
userdetails라는 이름으로 저장됩니다
그리고 마지막으로 라우팅 모듈 class에서
dashboard, myAccount 같은 보안 path마다
roles라는 데이터도
주고 있습니다
data가 비어 있다면
그건 그 보안 경로를 통과하는 데는
역할 값이 필요 없다는 뜻입니다
dashboard는 역할에 대한 요구사항이 없습니다
myAccount로 와서
역할이 user인 사람만이
접근할 수 있습니다
myBalance는
실사용자가 사용자가
관리자 중 하나의 역할이라도 있다면
myBalance에 접근할 수 있습니다
myLoans는 역할이 필요 없으며
myCards는 사용자 역할이 요구됩니다
이렇게 하면
Angular 애플리케이션에서의
역할 기반 액세스도 강화하는 게 됩니다
물론 누군가 JavaScript 코드를 수정하여
이 역할 정보를 없애서
보안된 API에 접근을 시도할 수도 있습니다
그래도 보안의 첫 단계는
완성된 겁니다
또한 누군가 코드를 건드린다면
SpringBoot 애플리케이션에서
같은 인증 방식이
적용되어 있습니다
그리고 그것은 백엔드 코드이기 때문에
누구도 수정할 수 없습니다
같은 역할 정보를 또한
AuthKeycloakGuard가 정의된
authroute.ts에서 활용하였습니다
아래로 스크롤하면
실사용자가 로그인된 것을
제가 확인하였으며
이 정보가 채워졌으면 보신다면
우선 여기서
사용자가 접근하려 하고 있는
특정 경로에 필요한
역할이 무엇인지 알아봅니다
이 경로로부터
저희는 이 데이터 객체를 호출하고
객체의 내부에서는
역할 값을 읽으려 하고 있습니다
역할 요구사항이 비었다면
실사용자는 역할이 별도로 필요 없으며
보안 경로를 그냥 통과하면 된다는 겁니다
True값이 반환되는 이유입니다
하지만 역할 요구사항에
어떤 데이터가 들어 있다면
사용자에게 Keycloak 서버에서 할당된
역할을 확인하고
경로에 대해 요구되는 역할이
무엇인지 보는 겁니다
이 코드
this.roles는
Keycloak library로부터 옵니다
제가 지금 표시하고 있는
이 역할 정보에 대한
변수는
Keycloak 인증 서버에서 설정한
역할 값입니다
여기서는 실사용자가 인증 서버에서
가지고 있는 모든 역할을 확인하고
requiredRoles에 있는 것과
일치하는 게 있다면
True를 반환하는 겁니다
그렇지 않으면
실사용자는 이 경로에 접근하지 못할 것입니다
app-routing.module.ts와
auth.route.ts에서
작성한
모든 로직이었습니다
이 둘도 아주 중요한 파일입니다
이 파일들을 분석해 보세요
질문이 있으시다면
이 파일에 대해 제가 변경한
모든 것들은
큰 틀에서는 모두 다루었습니다
그 다음으로
dashboard.service.ts로 가면
이전에 저희는 백엔드 서버에
입력으로 고객 ID를 보냈었지만
지금은 SpringBoot 애플리케이션이
대출, 계좌, 계정, 카드에 관련된
REST API 서비스에 대해
이메일만을 받을 것입니다
그래서 요청 파라메터 이름을
id에서 email로 변경하였으며
사용자의 이메일을
넘기려고 합니다
그리고 보시다시피
이런 method들이
component class
예를 들어 계정 정보에 대해 호출되면
component class가 이걸 호출할 겁니다
그러면 account.components.ts로 가겠습니다
components 폴더에 있습니다
accounts.component.ts를 열면
보시다시피
dashboardService의
getAccountDetails를 호출하기 전에
user 객체 내부의
email 데이터를 넘기고 있습니다
그리고 이 이메일이 user 객체 내부에
어떻게 존재하냐면
저번에 라우팅에 대해 이야기했을 때를
생각해 보세요
라우팅 내부를 보면
저희는 이 class를 사용하고 있습니다
AuthKeyCloakGuard입니다
이 class에서는
인증이 성공할 때마다
이 email 값을
Keycloak 인증 서버로부터 받은
userProfile로부터
가져오고 있습니다
이것과 비슷한 모든 변경사항들
에를 들면 cards.component가 있습니다
cards.component 내부 역시
email이 이런 방식으로 정의됩니다
dashboardService 내부의
함수가 호출될 때마다 말이죠
이는 loans와
balance에도 해당됩니다
balance class 역시 보면
email 값을
dashboardService의 함수를 호출할 때마다
변수가 설정됩니다
Keycloak Angular library를 받아들이기 위해
Angular UI 애플리케이션 내부에서 적용한
모든 변경 사항입니다
이 library가 매우 강력하다는
생각이 드셨을 수도 있습니다
저희는 그렇게 많은 걸 바꾸지 않았습니다
어디서도 실사용자를
직접 인증 서버 로그인 페이지로 리다이렉트하거나
PKCE flow를
직접 실행한다거나 하지 않습니다
code verifier와 code challenge에 관한
로직도 어디에도 없습니다
모든 것은
Keycloak Angular library가 처리해 줄 겁니다
이걸로 Angular UI 애플리케이션은
준비가 완료되었습니다
백엔드 변경사항은 없습니다
이렇게 정리하고
다음 강의부터는
EazyBank 애플리케이션 내부에서
PKCE 인증 flow의 테스트를 시작해 봅시다
들어주셔서 감사하며 다음 강의에서 뵙겠습니다
수고하셨습니다