3. MFA 및 Adaptive Authentication 구현

 

 

이번 게시글은 WSO2 서버에서 Google Mail API와 Vonage SMS API를 IDP(Identity Providers)로 등록하여

MFA(Multi-Factor Authentication)와 Adaptive Authentication을 구현하고 이해하는 과정입니다.

 

사전 준비 요구 사항

- JDK 1.8

- Apache Tomcat 8.5

- WSO2 Identity Server 5.11.0

- Gmail API(Client ID, Secret)

 

<그림 1> 등록한 Gmail API Oauth2/OIDC 페이지에서 클라이언트 ID, Secret 메모

- Vonage SMS API(API Key, Secret)

<그림 2> 등록한 VONAGE SMS API에서 API Key, Secret 메모

 

 

1. Authentication

다중 인증(MFA), 적응형 인증(Adaptive Authentication)에 대해 알아보기 전에 먼저 인증(Authentication)에 대해 이야기를 해보도록 하겠습니다.

 

인증 : 네트워크나 서버에 접속할 때, 본인 여부와 정규 이용자 여부를 확인하는 방법. 일반적으로 사용자 아이디와 패스워드의 조합으로 본인을 특정한다.

 

즉 인증이란, 유저(사용자)가 누구인지 확인하는 절차이며 인증 방법에는 세 가지 요소가 사용됩니다.

요소의 구분	특징	예시	장단점
지식 기반(Knowledge)	사용자만 알고 있는 정보	패스워드, PIN번호 등	편리하지만 유출 가능성이 높음
소유 기반(Possession)	사용자만 소유하고 있는 것	휴대폰 SMS인증, 보안카드, OTP 등	도난 혹은 분실 가능성, 소유하고 있지 않으면 인식 불가
속성 기반(Inherence)	사용자만의 신체적 고유특성	지문, 음성, 홍채, 정맥, 얼굴 인식 등	인식 오류 위험

세 가지 요소 중 한 가지 인증 기법만을 사용한다면 SFA(Single-Factor Authentication)라고 부르는 인증 방법으로 보통

아이디, 패스워드를 통한 단일 인증 로그인 방식이 이에 해당합니다.

 

 

 

2. MFA(Multi-Factor Authentication)

이 게시글에서 구현해볼 MFA(Multi-Factor Authentication, 다중 인증)는 위 요소 중 2 가지 이상의 인증 기법을 사용하는 인증 방법입니다. MFA는 2 가지 이상의 인증 요소를 사용하기 때문에 보안성이 강화된다는 장점이 있지만, 사용자 편의성이 낮아진다는 단점도 가지고 있습니다.

 

2-1 Identity Providers 등록

2-1-1 Gmail API

<그림 3> WSO2 서버 Identity Providers에서 GoogleIDP 등록 예시

먼저, WSO2의 콘솔로 접근하여 좌측 Identity Providers의 Add 버튼을 이용하여

Identity Providers에 IDP Name을 입력해주고 하단으로 이동합니다.

 

<그림 4> 그림 1에서 메모해 놓은 ID와 SECRET을 이용

Add 페이지 하단 Federated Authenticators 탭의 Google Configuration를 클릭한 뒤

사전에 발급받았던 Gmail API의 Client ID와 Secret, Url을 입력해주고 Enable 체크박스를 선택해준 후 Update 버튼을 눌러

WSO2 서버에 GoogleIDP를 등록해주도록 합니다.

 

2-1-2 SMSOTP

<그림 5> WSO2 서버 Identity Providers에서 SMSOTP 등록 예시

GmailAPI와 같은 방식으로 SMSOTP를 등록해주도록 합니다.

<그림 6> 그림 2에서 메모해 놓은 KEY, SECRET 이용

Federated Authenticators 탭의 SMS OTP Configuration을 클릭한 뒤

Enable 활성화와 SMS URL, HTTP Method를 입력해주고 Update 버튼을 눌러

WSO2 서버에 SMSOTP를 등록해주도록 합니다.

 

<그림 7> SMS URL 양식

SMS URL 양식은 이러하며 Vonage SMS API 등록 시 발급받은 API_KEY와 API_SECRET을 이용해 <ENTER_API_KEY>값과 <ENTER_API_SECRET>값 대신 입력해주면 됩니다.

 

 

2-2 Service Providers 등록

<그림 8> Service Providers에서 pickup-dispatch 등록

좌측 Service Providers Add 버튼을 이용하여 Service Provider Name값을 입력해주고 하단으로 이동합니다.

 

<그림 9>&nbsp;OAuth/OpenID Configuration (좌) / <그림 10> OAuth/OpenID Configuration (우)

Inbound Authentication Configuration의 Oauth2/OpenID Connect Configuration 탭의 Configuration 버튼을 클릭하여 

기본 설정은 변경하지 않고 Callback Url에 "http://localhost.com:8080/pickup-dispatch/oauth2client" 값을 입력해 주었습니다.

 

<그림 11> dispatch.properties 설정 예시

다음으로, 샘플 어플리케이션인 Pickup-dispatch 어플의 dispatch.properties 값을 수정해주어야 합니다.

/tomcat/webapps/pickup-dispatch/WEB-INF/classes 경로 dispatch.properties파일의

consumerKey값과 Secret값을 WSO2서버에서 발급받은 Key와 Secret값을 이용해 수정해주도록 합니다.

 

 

2-3 Service Providers 수정

<그림 12>&nbsp;Local & Outbound Authentication Configuration

위에서 등록한 Service Provider인 Pickup dispatch의 Local & Outbound Authentication Configuration에서 

Advanced Configuration 타입을 클릭하여 WSO2 로그인 방식을 수정해주도록 합니다.

 

<그림 13> Advanced Configuration 로그인 방식 설정 예시

Step 1은 첫 번째 로그인 방식을 설정하는 것이고 로그인에 성공하면 나올 두 번째 로그인 방식이 Step 2가 되게 됩니다.

먼저 Step 1은 Local Authenticators의 basic을 선택 후 Add Authenticator를 해주도록 합니다. basic은 WSO2 서버에 내장되어있는 기본 로그인 방식입니다.

Step 2에서는 Federated Authenticators에서 기존에 IDP로 등록해주었던 GoogleIDP와 SMSOTP를 추가해주고 

마지막으로 하단의 업데이트 버튼을 눌러주어 Pickup-dispatch 페이지의 로그인 방식을 변경해주었습니다.

 

 

 

2-4 MFA를 통한 로그인

<그림 14> PICKUP-DISPATCH 페이지 화면

PICKUP DISPATCH 페이지로 이동해 Login 버튼을 클릭해줍니다.

 

<그림 15> Step 1에 설정해 놓은 1차 인증 방식 (좌)&nbsp; /&nbsp; <그림 16> Step2에 설정해 놓은 2차 인증 방식 (우)

Step 1에 설정해주었던 기존 로그인 방식이 나오게 되고 로그인에 성공하면, Step 2에 설정해주었던 GoogleIDP와 SMSOTP를 통한 로그인 방식이 나오게 됩니다. 그 후 두 번째 인증까지 성공하면 PICKUP DISPATCH 애플리케이션을 사용할 권한을 가지게 됩니다.

 

 

 

 

 

 

3. Adaptive Authentication

Adaptive Authentication(적응형 인증)이란 사용자의 프로필 및 행동을 기반으로 인증 강도를 조정하는 것입니다.

 

<그림 17> WSO2 서버에서 제공하는 Adaptive Authentication 목록

WSO2 데모 버전에서 제공하는 적응형 인증은 약 10가지 정도의 방식이 있으며, 그중 WSO2 서버에서 제공하는 Role-Based와 New-Device-Based 인증을 사용해서 적응형 인증에 대해 알아보도록 하겠습니다.

 

 

3-1 Role-Based Adaptive Authentication

<그림 18> 역할 기반 적응형 인증

• 역할 기반 적응형 인증은 일반 계정보다 높은 권한을 가지고 있는 특정 역할(Admin, Manager 등)을 할당받은 User에게만 로그인 시 다중 인증을 요청하여 보안성을 높이는 적응형 인증 기법 중 하나입니다.

 

 

<그림 19> Pickup-dispatch의 Advanced Configuation 수정

WSO2 서버 내에 만들어두었던 SP인 pickup-dispatch를 이용해서 진행해보도록 하겠습니다.

MFA때와 마찬가지로 Service Providers의 Local & Outbound Authentication Configuration에서

Advanced Configuration 타입을 클릭하여 WSO2 로그인 방식을 수정해주도록 합니다.

 

<그림 20> Role-Based Script 설정 및 로그인 방식 설정

Script Based Adaptive Authentication을 열어준 뒤, 우측에 있는 Templates에서 Role Based를 선택해줍니다.

위 화면과 같이 'admin', 'manager' 역할을 가지고 있는 유저에게는 pickup-dispatch페이지로 로그인 시

Step 1 로그인과 Step 2 로그인을 진행시키는 Script가 생성되고, Step 1과 Step 2의 로그인 방식은 MFA때와 동일하게 설정해주면 됩니다.

 

<그림 21> 역할 부여 화면

실제로 Identity탭의 Add User를 통해 새로운 계정을 생성하고 manager라는 Roles를 부여하면 Pickup-dispatch 페이지 로그인 시 2차 인증을 요구하는 것을 확인할 수 있습니다. 

반면, 관리자 역할이 부여되지 않은 계정으로 로그인 시에는 Step 1의 로그인만으로 애플리케이션에 접근할 수 있는 것을 확인할 수 있습니다.

 

 

 

3-2 New-Device-Based Adaptive Authentication

<그림 22> 새 장치 기반 적응형 인증

• New-Device-Based 적응형 인증은 사용자가 새 장치나 새 브라우저를 사용하여 애플리케이션에 로그인하면 사용자에게 다중 인증을 요청하여 보안성을 높이는 적응형 인증 기법 중 하나입니다. 

즉 한번 로그인해두면 동일한 기기에서는 2차 인증을 할 필요가 없습니다. 하지만 새로운 Device 또는 새 브라우저에서 로그인 할 경우 또는 쿠키가 만료될 경우 2차 인증을 다시 받아야 합니다.

 

이번 예제에서는 Firefox와 Chrome 브라우저를 사용하여 실습을 진행해보도록 하겠습니다.

 

 

<그림 23> New-Device Script 설정 및 로그인 방식 설정

3-1의 과정과 마찬가지로 Script Based Adaptive Authentication에 접근 후 New-Device-based 스크립트를 선택해줍니다.

새 장치 또는 새 브라우저(쿠키에 의해 식별)에서 로그인하는 사용자인 경우에 인증을 강화하는 스크립트가 생성되고, Step 1과 Step 2의 로그인 방식을 설정해준 후 Update 버튼을 눌러줍니다. 

 

<그림 24> Step 1에 설정해 놓은 1차 인증 방식 (좌)&nbsp; /&nbsp; <그림 25> Step2에 설정해 놓은 2차 인증 방식 (우)

위 설정이 끝나면, Firefox 브라우저에서 pickup-dispatch 페이지 로그인 시 첫 로그인만 2차 인증을 진행하고

다음 로그인부터는 1차 인증만 완료하여도 로그인이 되는 것을 확인할 수 있습니다.

 

다시 Chrome(새 브라우저)에서 pickup-dispatch 페이지 로그인 시 쿠키가 존재하지 않으므로 2차 인증을 실시하는 것을 확인할 수 있습니다.