Windows Server의 ADFS(Active Directory Federation Service), IDentity 처리에 대한 고려 및 클라우드 시대를 위한 확장

오늘은 Windows Server 2012 R2에 있는 ADFS(Active Directory Federation Service)를 살펴보겠습니다. 제 블로그내 예전 포스팅들을 살펴보니, 이미 ADFS에 대해서 몇번 살펴본 적이 있고.. Microsoft Identity 관련 세미나 발표 자료에도 ADFS에 대한 이야기는 몇번 진행한 적이 있었습니다.

Windows Server 2008이 나오면... (25) - ADFS

아주 기본적인 컨셉은 위의 블로그 포스팅을 살펴보시면 아실 수 있습니다. 크게 ADFS를 활용할 수 있는 시나리오는 2가지 정도입니다.

1. AD의 형태로 ID 중앙 관리를 하고 있는데, AD 도메인에 가입하여, Windows 인증을 제공할 수 없는 리소스가 있는 경우
2. ID 중앙 관리를 하고 있는 두 조직이 상호간의 비즈니스 관계 형성으로 리소스를 제공해야 하는데, ID는 기존 조직에서 관리하고자 하는 경우
   일반적으로 2개의 조직이 상호 비즈니스를 할 경우, 웹 사이트를 제공해야 하는 조직(리소스를 가진 조직)에서 접속용 계정을 같이 제공하고 있습니다. 접속용 계정이 실제 이용자를 가진 조직에서 적절한 사용자만 이용하는지, 권한이 할당된 사용자가 존재하는지에 대해서는 리소스를 가진 조직에서는 알 수 없습니다. 엄밀하게 ID에 대한 부분은 실제 계정 정보와 사용자가 일치된 위치 형태로 관리되어야 합니다.

ADFS 기술은 Windows Server 2003 R2에서부터 제공되어 왔으며, 근간이 되는 WS-Federation과 WS-Trust 표준은 그 이전에 발표된 기술 형태입니다. 공용 클라우드가 많아지고 있는 요즘, 공용 클라우드를 사용하는 ID를 조직내에서 관리하고자 할 경우에, ADFS가 정답이 되고 있고, 앞서 살펴보았던 Microsoft Azure의 AD와 사내 AD의 공존을 위해서도 ADFS 시나리오가 이용되고 있습니다

.

위의 그림은 Microsoft의 공용 클라우드 서비스 중 하나인 Office 365입니다. 별도의 인프라없이 Office 365만을 사용하기 시작한다면, 기본적으로 계정@원하는이름.onmicrosoft.com의 주소를 가지게 됩니다. 물론 다음 포스팅에서 살펴볼 Microsoft Azure의 AD에 약간의 작업을 하면, 본인 회사의 도메인을 계정 형태로 사용할 수 있습니다. 이와 같이 별도의 ID 제공 서비스(AD나 기타 여러 형태)가 없었다면, 손쉽게 시작할 수 있는 ID 시나리오이지만, 기존에 조직내에서 사용하던 ID가 있으면, 사용자의 이용 복잡성은 올라가게 됩니다. 사내 계정도 기억해야 하고, Office 365용 계정도 기억해야 하게 되죠.

이 경우, Office 365는 이용하고자 하는 리소스에 해당됩니다. 조직내 AD 서비스가 ID를 제공하는 제공자가 되는 것이죠. AD 계정을 사용하려면, 서버를 AD 도메인에 가입해야 하는데, 공용 클라우드인 Office 365는 사내 AD에 가입할 수 있는 형태가 아닙니다. 이 때, 외부의 리소스와 사내 ID 시스템을 연계할 수 있는 표준을 페더레이션 서비스(Federation Service)라고 부릅니다.

이해를 돕기 위해, 일상의 예제로 가보겠습니다. (개인적으로 일상의 예제와 기술의 설명이 연계되는 것이 가장 좋은 기술이라고 생각합니다. )

해외 여행을 갈 경우를 생각해보겠습니다.

1. 소속된 국가에서 여권을 발급받는다. 여권이 만료된 경우, 갱신이 필요할 수도 있습니다.
2. 해당 여권을 안전하게 보관, 소지하여, 여행을 원하는 국가로 도착합니다.
3. 해당 국가의 입국 심사대에서 여권을 제시합니다.
4. 입국 심사대의 직원은 여권이 정상적인지, 도난된 것은 아닌지, 해당 사용자의 국가로 조회를 시도합니다.
5. 정상적인 여권이라면, 입국이 가능한지 질문 혹은 이력 조회를 한후, 입국을 허가/거부합니다.

1번의 경우가, AD에서 인증 후, 받은 보안 토큰입니다. 2번의 경우가 리소스를 가진 지역으로 안전하게 전송할 수 있는 통신 수단입니다.(페더레이션에서는 HTTPS) 3번의 경우가 리소스 지역에서 본인의 보안 토큰을 제시하는 형태입니다. 4번의 경우가 제시받은 토큰이 정상적으로 발급되고, 현재도 유효한지 리소스 지역에서 ID 지역으로 확인을 하는 형태입니다. 5번이 인증이 완료되면, 허가를 해주는 순서입니다.

어떠신가요? 이해가 조금 되었나요? ADFS는 이러한 형태로 AD의 계정을 페더레이션 서비스 표준을 사용하는 다른 조직과 연결할 수 있게 합니다.

ADFS는 커베로스나 NTLM 형태의 Windows 인증을 사용하지 않고, 웹 기반의 표준 인증 프로토콜을 사용합니다. 따라서, 표준 페더레이션을 사용하는 기술과 연계가 가능합니다.(IBM Tivoli, Ping, CA, Oracle, Shibbolete 2등, 관련 가이드)위의 그림은 Windows Server 버전에 따른 ADFS 지원 프로토콜의 목록입니다. 리소스가 해당 프로토콜을 지원하면, ADFS를 통해서 연결이 가능하다는 의미입니다. 또한 ADFS를 통해 인증을 받을 경우에는 클레임 기반 ID(SAML Token, Security Assertion Markup Language)가 발급되게 됩니다.

클레임 기반 ID는 사용자에 대한 인증 여부와 함께, 리소스에서 필요한 정보를 포함하고 있습니다. 예를 들어, 접속 후, 사용자의 이름이나 전자 메일 주소등이 필요한 경우, 사용자의 ID 시스템에서 정보를 추출하여, 토큰내 포함하여 전송하게 됩니다. 이렇게 뽑힌 사용자의 정보 하나하나를 클레임(Claim)이라고 부릅니다. 클레임에 구성되는 값들은 AD 속성에서 추출하여 만들 수 있습니다.

일반적으로 리소스 서비스에서는 단순히 사용자의 인증만을 필요로 하는 것이 아니라, 사용자의 각종 정보가 필요하여, 사용자의 ID를 저장하고, 이를 활용하는 경우가 많습니다. 이러한 정보는 실제 서비스에 필요하지 않은 정보까지도 수집할 수 있게 되죠. (마치 많은 인터넷의 서비스들처럼) 실제 사용자의 정보는 ID를 가진 조직에서 관리하고 있습니다. 페더레이션 서비스에서는 이러한 정보 역시, 리소스를 가진 조직에서 저장하는 형태가 아니라, 필요한 정보를 ID 제공자에게서 받아오는 형태로 되어 있습니다. 물론 제공에 대한 부분은 ID 제공자가 결정할 수 있습니다.

ADFS를 설치하는 것은 그렇게 어렵지 않습니다. 서버 관리자에서 ADFS 역할을 추가하면, 구성에 필요한 정보등을 묻고, 구성을 완료해주며, 다수의 ADFS 서버를 구성하여, 고가용성이나 부하 분산을 하려면, SQL Server를 활용하여, 여러대의 ADFS 서버를 구성할 수 있습니다. 설치에 대한 가이드는 TechNet에 잘 정리되어 있습니다. 기본 한대 설치시, Windows Server 2012 R2에 내장된 Windows Internal Database(WID, 기존 SQL Server Express 유사)에 설치되는데, 필요시 원격 SQL Server로 이전할 수도 있습니다. (참고 가이드)

ADFS 서버는 AD 도메인에 가입되어 있어야 합니다. ADFS 서버를 인터넷으로 노출시키는 것이 이러한 이유로 꺼릴 수 있게 되는데, 이를 위해 AD에 가입되어 있지 않은 서버를 ADFS를 위한 프록시로 구성하고, 외부로 노출할 수 있습니다. ADFS 프록시(Proxy)는 외부 요청에 대해서 입출입을 담당하는 역할만 하게 되며, Windows Server 2012 R2에서는 ADFS 프록시를 WAP(Web Application Proxy, 웹 응용 프로그램 프록시)이 담당합니다.

ADFS 서비스는 HTTPS를 기반으로 하고 있으므로, 인증서(암호화, 서명용)가 필요합니다. 해당 인증서는 상호간에 신뢰할 수 있는 인증 기관에서 발급하여야 하므로, 사설 인증 기관 사용시 상호 등록을 해주거나, 실제 공인 인증서를 구입하여, 사용해야 합니다. (권장) 기본 설치시, 자체 서명된 인증서가 설치되므로, ADFS 관리 도구에서 변경해야 합니다.

ADFS는 ID에 대한 클레임 정보를 3가지 형태에서 연결할 수 있습니다. 기본적으로 AD, 그리고 LDAP, SQL까지 지원하며, 해당 형태의 DB에 저장된 정보를 클레임 형태로 사용하여, 토큰을 생성할 수 있다는 의미입니다.

ADFS 기본 설치시, 특성 저장소는 AD가 기본적으로 들어가 있으며, 이에 대한 사용을 클레임 공급자 트러스터에 추가해줍니다. AD의 정보를 뽑아서, 토큰 형태로 사용할 수 있게 한다는 것이죠.

만약 다른 조직에서 우리 조직내 리소스를 활용한다면, 해당 조직에서 발급된 클레임 기반 ID를 사용할 수 있게 등록하는 것부터 시작해야 합니다. 페더레이션 서비스를 사용하는 조직에 대한 기본 정보(메타데이터)를 입력해야 합니다. 이를 위해서 클레임 공급자 트러스트 추가를 클릭합니다.

페더레이션 서비스에서는 제공하는 클레임 및 여러 서버 정보를 메타데이터 주소를 통해서 제공할 수 있습니다. 이에 ID를 제공할 페더레이션의 메타데이터 주소를 입력하거나, 메타데이터 관련 파일을 제공받아서, 입력합니다.

ADFS 설치를 완료하면, 끝점(Endpoint) 항목내 메타데이터가 익명으로 제공되고 있습니다. 외부에서 접근 가능한 DNS 주소를 ADFS 페더레이션 서비스 속성 값과 연계하여, 메타데이터 확인용 URL을 얻을 수 있습니다.

예를 들어, SUNNY.COM에서 제공하는 ID가 우리의 리소스를 사용한다면, SUNNY.COM과 페더레이션 트러스트(WS-Trust)를 맺어야 합니다. 이를 위해서 SUNNY.COM의 페더레이션 서비스와 연결을 해야 하는데, 이 경우 SUNNY.COM 페더레이션 서비스의 메타데이터 URL나 정보가 필요하다는 것입니다. 메타데이터 URL은 https://sts.sunny.com/federationmetadata/2007-06/federationmetadata.xml 이런 형태가 됩니다.

리소스를 가진 조직에서 더이상 해당 ID 조직과 비즈니스 관계가 없다면, ADFS에서 설정된 WS-Trust 관계를 사용 중지하면 더이상 이용할 수 없게 됩니다. 설정 이후 ADFS를 사용하도록 설계된 웹 사이트에 접근을 하게 되면, 인증을 위해 처리 신호가 리소스 조직내 ADFS로 전달되게 됩니다.

이렇게 본인의 조직(Realm)을 선택하는 형태가 나타납니다. ADFS 서비스는 본인의 조직 선택(Home Realm)을 한 정보를 해당 컴퓨터의 쿠키로 저장하여, 손쉬운 접근이 가능하게 할 수 있습니다. 또한 ADFS 접속 사이트에 대해서 위의 그림처럼 커스터마이징도 가능합니다. (관련 가이드)

본인의 조직을 선택하면, 해당 조직의 ADFS로 연결되게 됩니다. 여기서 본인의 ID와 계정을 입력하면, 본인 조직내 ID 시스템에서 인증이 진행되게 되죠. 또 한가지 생각해볼 포인트가 있습니다. SUNNY.COM에서는 리소스를 가진 KOALRA.COM에 대해서 별도의 셋팅을 해야 할까요? 아무나 우리 조직의 ID 정보를 받아가면 안되겠죠. 더불어, SAML 토큰내 어떠한 사용자의 클레임을 전달할지도 결정해야 합니다.

ID 조직에서 리소스 조직으로 신뢰함을 설정하는 영역이 신뢰 당사자(Relying Party) 트러스트입니다. 여기서 리소스 조직의 ADFS 서비스의 정보를 등록해주는 절차가 필요합니다. 아까와 반대로 ID를 가진 조직에서 더이상 리소스 조직의 서비스를 이용하지 않을 경우에도 제어가 가능합니다. 페더레이션 서비스에서는 모든 서버간 교신은 HTTPS를 사용합니다.

어떠한 속성을 뽑아서, 클레임으로 전달할지에 대해서 결정이 가능합니다.

또한 사용 권한에 대한 부분도 설정할 수 있습니다.

이렇게 설정된 SUNNY.COM의 구성대로라면, KOALRA.COM ADFS에서는 SUNNY.COM의 사용자 이름(UPN), 그룹 정보를 받게 됩니다. 또하나의 일상 예제를 들어보죠. 외국에 입국 심사를 받을 때, 입국 심사 서류를 쓰는 경우가 많습니다. 해당 서류에는 그 나라 문화에 적절한 형태의 표기들이 있습니다. 대표적인 것이 생년월일을 표시하는 순서죠. 이 순서를 틀리게 써서, 다시 작성했던 경험이 누구나 한번쯤은 있을 것입니다. ADFS도 동일합니다. 상대방 영역에서 전달해준 클레임이 우리가 사용하는 클레임 형태와 달라서, 변경을 해야 하는 경우, 또한 필요로 하는 클레임만 받고 싶은 경우에 대해서 리소스 조직의 ADFS에서 다시 설정을 할 수 있습니다.

외부 사용자에 대해서 내부와 구분을 위해 표기를 더하거나, 표기 방법을 바꾸거나, 아니면 그대로 통과시키는 형태로 구성이 가능합니다.

KOALRA.COM의 리소스를 사용하기 위해서, SUNNY.COM과 페더레이션 트러스트를 맺고, 상호간의 SAML 토큰을 위한 구성이 완료되었습니다. ID를 가진 측에서는 ID에 관련된 자체와 전달이 필요한 정보(클레임)만을 선택해서 전달할 수 있고, 받는 리소스 조직에서도 전달받은 정보를 본인 조직의 형태로 변경, 혹은 그대로 활용할 수 있다는 것까지 이해가 되었을 것입니다.

리소스 조직내에 ADFS를 활용하는 웹 서비스가 여러대일 수 있습니다. 서비스들마다, ADFS에서 필요로 하는 정보가 다를 수도 있습니다. 또한 ADFS 관리자가 알지 못한 채, ADFS 서버에서 인증을 처리하도록 다른 IT 엔지니어/개발자가 서비스를 제공하고 있을 수도 있죠. 리소스를 가진 조직에서도 ADFS를 사용할 수 있게, 해당 서비스를 등록해줘야 합니다. 쓸 수 있도록, 등록하는 것.. 앞서 SUNNY.COM을 믿겠다는 것과 동일한 절차가 진행됩니다. 신뢰 당사자 트러스트입니다.

신뢰 당사자 트러스트에서 ADFS를 사용할 리소스 서비스를 등록해줘야, 해당 서비스에서 ADFS를 활용할 수 있게 됩니다. (이용 권한을 부여하는 것과 유사하다고 생각하면 쉽습니다.) 또한 서비스별로 사용 가능한 클레임, 클레임 형태를 지정할 수 있습니다. 클레임에 대한 구성은 클레임 공급자별로 별도로 지정할 수 있는 것도 당연하죠.(KOALRA.COM 내부, SUNNY.COM, 또다른 조직에 따라 다 다르게 설정 가능)

ADFS를 활용할 수 있게 구성된 웹 사이트 화면입니다. 사용자가 로그인했을 때, 전달된 클레임을 통해 오른쪽 상단에 이름을 표기하였고, SAML 토큰과 클레임을 볼 수 있도록 해놓았습니다. SAML 토큰의 유효 기간등의 정보는 ADFS에서 설정이 가능합니다.

클레임을 Windows 보안 토큰으로 변환해주는 서비스를 활용할 수도 있습니다. 이를 이용하여, 클레임 기반의 인증을 처리하지 못하는 레가시 서비스들에 대해서도 ADFS와의 연계를 진행할 수도 있습니다. 해당 서비스는 Windows Identity Framework(WIF)에서 제공합니다.

ADFS가 조금 이해가 되어야, Microsoft Azure의 AD와 이야기를 확장할 수 있습니다. Office 365와 사내 AD를 연계할 때, ADFS 구성을 해본 IT 엔지니어 분들도 계실 것입니다. Office 365가 리소스 조직이고, 우리가 ID 조직이므로, 우리는 신뢰 당사자 트러스트에 Office 365 조직만 추가해주면 됩니다.

이와 관련된 방법을 Office 365 도움말에서 제공했었습니다. 조금 이해가 되시나요? Office 365에 연결(Connect-MsolService), 우리 내부 ADFS 지정(Set-MsolAdfscontext), 이후 Office 365에 우리 ADFS 등록(New-MsolFederatedDomain)…

눈에 보이진 않지만, Office 365쪽에는 우리 조직이 클레임 공급자 트러스트에 추가되어 있겠죠.

매우 길었던 포스팅입니다. 시간될 때, 차분히 ADFS에 대해서 숙지해놓으시면, 클라우드 시대에 적절한 ID 방안, 그리고 다음 포스팅에서 이어질 Microsoft Azure AD와 연동에서 도움이 될 것이라 생각합니다.