[Active Directory] WAP

※ 필자가 진행했던 대회의 과제를 기반으로 정리하였습니다.

(AD FS에 대해 잘 모르시겠다 하시는 분들은 여기를 참고하세요!)

 

* WAP(Web Application Proxy)

- 웹 응용 프로그램 프록시는 외부 사용자가 회사 네트워크에 액세스 할 수 있도록 회사 네트워크 내부의 웹 응용 프로그램에 대한 역방향 프록시 기능을 제공한다.

- 웹 응용 프로그램 프록시는 AD FS를 사용하여 웹 응용 프로그램에 대한 액세스를 미리 인증하므로 사용자가 외부에서 도메인 내의 서비스(클라우드 폴더, 웹사이트 등)를 사용할 수 있다.

 

* WAP을 사용하는 이유

- WAP의 구성이 필요한 이유는 외부에서 SSO를 이용하기 위함이다. 만약 WAP 없이 AD Sync 및 AD FS 구성작업을 진행하면 외부(10.0.0.20)에서 AD FS Server(192.168.0.160)를 찾을 수 없기 때문에 로그인이 불가능하다. 아래 그림과 같이 DMZ에서 WAP을 구성함으로써 외부에서는 10.0.0.0대역의 IP를 192.168.0.0대역의 IP로 접속할 수 있게 해 준다.

 

* WAP의 두 가지 인증 방법

1. AD FS : 외부에서 접속할 때 AD FS 인증을 거치고 넘어간다.

2. 통과 : AD FS 인증을 하지 않고 넘어간다.

 

※ WAP 구성

아래는 외부에서 내부에 접근이 필요한 서비스를 proxy가 처리하는 과정이다.

① CES/CEP (비 도메인 유저가 도메인 내의 CA에게서 인증서 발급)

CES/CEP는 AD FS인증을 거치지 않고 내부의 서비스를 이용하게 된다. AD FS인증을 거치지 않으면 외부에서 내부에 접근할 때 로그인을 거치지 않는다.

 

② extra.wsc2019.ru (외부 접근을 위한 웹사이트)

extra 웹 사이트는 AD FS 인증을 거치게 된다. AD FS 인증을 거치면 아래처럼 로그인(SSO)을 하게 된다. 지원되는 클라이언트 인증 유형은 웹 및 MSOFBA이다.

웹 및 MSOFBA : MSOFBA는 STS로의 리디렉션이 일반 HTTP 리디렉션이 아니라 특수 MS-OFBA 헤더를 통해 수행된다. 아래는 MS-OFBA 프로토콜을 사용하는 클라이언트에 대한 인증 흐름이다.

⑴ 클라이언트가 웹 브라우저에서 ex) extra.wsc2019.ru 사이트에 접속을 요청한다.

⑵ 웹 응용 프로그램 프록시는 인증을 수행하는 AD FS 서버로 요청을 리디렉션 한다.

⑶ AD FS 서버는 요청을 웹 응용 프로그램 프록시로 다시 리디렉션 한다.이제 요청에 에지 토큰이 포함된다.

⑷ 사용자가 이미 AD FS 서버에 대해 인증을 수행했기 때문에 AD FS 서버는 요청에 SSO 쿠키를 추가한다. (로그인을 한 번 하면 쿠키가 남음 캐시가 남는다는 게 이 말)

⑸ 웹 애플리케이션 프록시는 토큰의 유효성을 검사하고 요청을 백 엔드 서버로 전달한다.

⑹ 백 엔드 서버는 요청을 AD FS 서버로 리디렉션 하여 애플리케이션 보안 토큰을 가져온다.

⑺ 요청은 백 엔드 서버로 리디렉션 된다.이제 요청에 애플리케이션 토큰과 SSO 쿠키가 포함된다. 사용자에게 extra.wsc2019.ru 사이트에 대한 액세스 권한이 부여되며 파일을 보기 위해 사용자 이름이나 암호를 입력할 필요가 없다.

 

③ Work Folders (클라우드 폴더 ADFS 접근)

클라우드 폴더도 extra와 같이 외부에서 도메인 내의 클라우드 서비스를 이용하기 위해 AD FS 인증을 거친다. 지원되는 클라이언트 인증 유형은 OAuth2이다.

 

★ OAuth2

- 대부분의 서비스 인증과 리소스에 대한 권한 부여 기능이 필요하다. 인증과 권한 부여 기능은 다양한 방법으로 제공되고 있는데 대표적인 방법으로 OAuth를 사용하고 있다. Facebook, Google, Twitter 등 대형 서비스에 널리 사용되고 있기 때문에 많은 개발자에게 친숙한 방법이다.

- OAuth는 서버와 클라이언트 사이에 인증을 완료하면 서버는 권한 부여의 결과로써 access token을 전송한다. 클라이언트는 access token을 이용해서 접근 및 서비스를 요청할 수 있다. 서버는 access token 기반으로 서비스와 권한을 확인하여 접근을 허용할지 말지를 결정하고, 결과 데이터를 클라이언트에게 보내준다. 서버는 access token을 기반으로 클라이언트를 확인하여 서비스하기 때문에, 세션이나 쿠키를 이용해 클라이언트의 상태 정보를 유지할 필요가 없다.

- OAuth 프로토콜을 사용하는 클라이언트의 대한 인증 흐름은 아래와 같다.

⑴ 클라이언트는 ex) work.wsc2019.ru 경로를 사용하여 게시된 클라우드 폴더에 액세스 하려고 한다.

⑵ 앱은 웹 애플리케이션 프록시에서 게시 한 URL(work.wsc2019.ru)에 HTTPS 요청을 보낸다.

⑶ 웹 애플리케이션 프록시는 인증 AD FS 서버의 URL의 포함된 앱에 HTTP 401 응답을 반환한다. 이 프로세스를 ‘검색’이라고 한다.

⑷ 앱은 HTTPS 요청을 AD FS 서버로 보낸다.

⑸ 앱은 웹 인증 브로커를 사용하여 AD FS 서버에 인증하기 위해 자격 증명을 입력하는 대화 상자를 생성한다.

⑹ 인증에 성공하면 AD FS 서버는 OAuth 토큰과 에지 토큰이 포함된 콤보 토큰을 만들고 토큰을 앱에 보낸다.

⑺ 앱은 콤보 토큰이 포함 된 HTTPS 요청을 웹 애플리케이션 프록시에서 게시 한 URL로 보낸다.

⑻ 웹 애플리케이션 프록시는 콤보 토큰을 두 부분으로 분할하고 에지 토큰의 유효성을 검사한다.

⑼ 에지 토큰이 유효한 경우 웹 애플리케이션 프록시는 OAuth 토큰만 사용하여 요청을 백 엔드 서버로 전달한다. 사용자에게 게시된 웹 애플리케이션에 대한 액세스 권한이 부여된다.

 

+ (추가)HTTP Basic을 사용하는 애플리케이션 게시

스마트폰을 포함한 리치 클라이언트를 Exchange 사서함과 연결하기 위해 많은 프로토콜에서 사용되는 인증 프로토콜이다. 아래는 HTTP Basic을 사용하는 클라이언트에 대한 인증 흐름이다.

⑴ 사용자는 게시된 웹 응용 프로그램 전화 클라이언트에 액세스 하려고 한다.

⑵ 앱은 웹 애플리케이션 프록시에서 게시한 URL에 HTTPS 요청을 보낸다.

⑶ 요청에 자격 증명이 포함되지 않은 경우 응용 프로그램 프록시는 인증 AD FS 서버의 URL의 포함된 앱에 HTTP 401 응답을 반환한다.

⑷ 사용자는 인증이 Basic으로 설정되고 사용자 이름과 www-authenticate 요청 헤더에 있는 사용자의 Base 64 암호화 된 암호를 사용하여 HTTPS 요청을 다시 앱에 보낸다.

⑸ 장치를 AD FS로 리디렉션 할 수 없기 때문에 웹 응용 프로그램 프록시는 사용자 이름과 암호가 포함 된 자격 증명을 사용하여 AD FS에 인증 요청을 보낸다. 토큰은 장치를 대신하여 획득.

⑹ AD FS로 전송되는 요청 수를 최소화하기 위해 웹 응용 프로그램 프록시는 토큰이 유효한 동안 캐시 된 토큰을 사용하여 후속 클라이언트 요청의 유효성을 검사한다. 웹 응용 프로그램 프록시는 주기적으로 캐시를 정리한다. 성능 카운터를 사용하여 캐시 크기를 볼 수 있다.

⑺ 토큰이 유효하면 웹 애플리케이션 프록시가 요청을 백엔드 서버로 전달하고 사용자에게 게시된 웹 애플리케이션에 대한 액세스 권한이 부여된다.