Inside Microsoft.comActive Directory Federation Services 사용

Jim Guthrie

Microsoft는 중요한 내부 리소스에 액세스할 수 있도록 비즈니스 파트너에게 엑스트라넷을 제공합니다. 엑스트라넷 아키텍처를 사용하려면 조직 외부에 있는 각 참가자가 이 공간에 대한 고유한 도메인 계정을 가지고 있어야 합니다. 이 계정은 명백한 이유로 파트너가 아닌 Microsoft 직원들이 만들어 관리합니다.

±×·¯³ª 제대로 작동한다 하더라도 사용자 환경은 그리 만족스럽지 못할 수 있으며 Microsoft에서 모든 파트너 사용자를 관리하려면 리소스도 상당히 많이 필요합니다.

지금부터 엑스트라넷이 현재 어떻게 작동하는지 알아보겠습니다. 고객이나 파트너는 응용 프로그램에 로그인할 때 자격 증명을 입력해야 합니다. 같은 세션에서 다른 리소스에 액세스할 때도 자격 증명을 입력하라는 메시지가 표시됩니다. 이러한 메시지는 다른 리소스를 보려 할 때마다 계속 표시됩니다. 재무 데이터베이스와 같이 리소스를 여러 개 사용하는 단일 응용 프로그램에 로그인할 경우 각 리소스에 대해 개별적으로 인증해야 하는데, 이것은 사용자의 입장에서 번거롭고 귀찮은 일입니다.

그런데 ADFS(Active Di­rec­tory® Federation Services)를 사용하면 여러 번 인증해야 하는 문제를 쉽게 해결할 수 있습니다. ADFS는 Windows Server® 2003 R2 구성 요소로서, 조직 간의 트러스트를 원활하게 하여 각 조직이 고유한 사용자를 관리하면서 동시에 여러 리소스를 공유할 수 있도록 합니다. 이 칼럼에서는 Microsoft가 ADFS를 사용하여 엑스트라넷의 리소스에 액세스할 때 여러 번 자격 증명을 입력해야 하는 문제를 해결하는 방법에 대해 살펴보겠습니다. 이 방법은 여러분이 나중에 직접 유사한 솔루션을 구현하는 데 도움이 될 것입니다. 자세한 설명에 앞서 몇 가지 기본 ADFS 용어에 익숙해질 수 있도록 그림 1을 살펴보겠습니다.

Figure 1 ADFS 용어

ADFS 솔루션

사용자가 ADFS 지원 응용 프로그램에 액세스하려고 하면 영역 검색을 위해 브라우저가 FS-R(페더레이션 서비스 리소스)로 전송됩니다. 이때 사용자는 세션 동안 사용할 자격 증명을 선택하고, 클라이언트가 선택한 영역에 따라 FS-A(페더레이션 서비스 계정) 서버로 리디렉션됩니다. 이 서버에서 사용자는 Windows Live™ ID(이전의 Passport 계정), Win­dows 통합 인증 또는 SSL 인증의 형식으로 입력하는 자격 증명을 기준으로 쿠키로 저장되는 유효한 계정 토큰을 받게 됩니다(그림 2 참조). 이 모델에서 자체의 고유한 계정 페더레이션 서버를 유지 관리하는 것은 개별 조직의 책임입니다. 따라서 Mi­cro­soft 파트너 서버의 경우 해당 환경에 있는 모든 계정을 Microsoft.com에서 관리할 필요가 없어집니다. 물론 책임 수준을 구현하는 경우에는 페더레이션할 조직을 신중하게 선택하고 이 조직이 계정 정보를 적극적으로 관리하도록 해야 합니다.

그림 2** ADFS 흐름 **(더 크게 보려면 이미지를 클릭하십시오.)

다음 단계에서는 다시 FS-R 서버로 돌아가서 계정 토큰을 리소스 토큰으로 교환합니다. 해당 구성에서 이 토큰은 FS-R에서 수행된 클래임-매핑 프로세스를 통해 사용자에게 부여된 전체 권한 목록을 포함합니다. 토큰을 받은 후 사용자는 세션이 열려 있는 동안 또는 기본적으로 최대 24시간 동안 ADFS 지원 응용 프로그램에서 SSO(Single Sign-On) 기능을 사용할 수 있게 됩니다. SSO 창은 구성이 가능하므로 기본 시간을 변경할 수도 있습니다. 이제 ADFS 지원 응용 프로그램에 SSO가 설정되었으므로 보다 안전하고 효율적으로 엑스트라넷에 액세스할 수 있습니다. ADFS 인증 프로세스에 대한 자세한 내용은 2006년 7월에 발행된 Matt Steele의 TechNet Magazine 기사 "ADFS를 사용하여 Single Sign-on 단순화"를 참조하십시오.

Microsoft는 회사 리소스의 보안을 유지하기 위해 엑스트라넷의 인터넷 통로를 회사 네트워크와 분리하여 각 서버를 잠재적인 이중 홈으로 설정했으며, 회사 내부 사용자의 단방향 트러스트를 허용하고 서버를 활용하여 필요한 보호 수단을 제공했습니다. 또한 외부 사용자가 필요한 리소스에 액세스할 수 있도록 허용한 엑스트라넷 공간에 별도의 도메인을 사용했습니다.

구현할 때 가장 주의를 기울였던 두 가지 사항은 부하 분산과 ADFS 정책 파일 변경입니다. 부하 분산은 전역 수준과 로컬 수준에서 모두 수행해야 하는 작업이었습니다. 처음에는 프로덕션 환경에서 두 영역에 있는 프런트 엔드 웹 서버 클러스터에 CDN(Content Delivery Network) 파트너 Akamai 또는 Savvis의 전역 부하 분산을 사용하려 했습니다. 그러면 한 쌍의 영역 서버가 모두 오프라인이 되는 경우(그렇게 될 가능성은 낮지만)에도 최종 사용자에게는 시스템 가용성이 보장되기 때문입니다. 이것은 CDN에서 제공하는 서버 상태 확인 서비스를 이용하는 장애 조치 자동화를 통해 이루어집니다. 또한 CDN 서비스를 사용하면 나중에 더 많은 클러스터를 쉽게 추가할 수도 있습니다. 그러나 비용 절감 차원에서 프리프로덕션 배포에서는 CDN 서비스를 사용하지 않기로 결정했습니다.

영역 수준에서는 NLB(네트워크 부하 분산) 클러스터링을 통해 로컬 장애 조치용 서버를 쌍으로 구성했습니다. 특별한 부하 분산 기능을 사용하지 않으므로 하드웨어로 이 작업을 쉽게 마칠 수 있었는데, NLB를 사용한 이유도 역시 비용 절감을 위해서입니다. 이 구성에서는 지원되는 모든 환경에서 99.9% 이상의 가동 시간을 보장하는 안정성을 제공합니다.

또 다른 작업은 ADFS의 핵심인 ADFS 정책 파일이 전체 환경에 올바르게 배포되고 이 파일의 변경 사항도 복제되도록 하는 것이었습니다. 이를 위해 Windows Server 2003 R2의 또 다른 기본 제공 기능이자 새로운 상태 기반 멀티 마스터 복제 엔진인 DFS-R(분산 파일 시스템 복제)을 사용했으며, 각 백 엔드 서버에서 24시간 풀 메시 복제로 DFS-R 그룹 구성원을 설정했습니다. 이제 어디에서 정책 파일이 변경되든 변경 내용이 모든 서버에 배포됩니다. 이 파일을 변경할 수 있는 사용자를 제어하기만 하면 계속해서 안정적이고 가용성이 높은 서비스를 제공할 수 있습니다.

Microsoft는 ADFS 스냅인에서 모든 변경이 이루어지도록 노력해 왔는데, 실제 사용하면서 이 파일을 가끔 수동으로 업데이트해야 한다는 것을 알게 되었습니다. 수동으로 업데이트할 경우 ADFS가 이 파일의 버전을 추적한다는 것에 주목해야 합니다. 이것은 변경 사항이 해당 환경에 적용되도록 파일을 증분해야 함을 의미합니다.

<TrustPolicyEntryUri>urn:federation:parttestint</TrustPolicyEntryUri> 
<TrustPolicyVersion>127
</TrustPolicyVersion> 

또한 모든 XML과 마찬가지로 정책 XML 파일도 대소문자를 구분한다는 점도 유의해야 합니다. 정책 XML 파일에는 응용 프로그램이나 다른 ADFS 서버에 대한 참조가 많이 있으며 항상 서버 간에 그대로 복사되어야 합니다. 다음의 일반적인 예를 살펴보십시오. 여기에서 첫 번째 RevocationCheckFlags는 수동으로 입력되었으며 두 번째 RevocationCheckFlags는 UI에서 수정된 트러스트된 응용 프로그램 URL입니다.

<RevocationCheckFlags>None
</RevocationCheckFlags>
<TrustPolicyEntryUri>https://adfstest.parttest.extranettest.microsoft.com/NTApp/
</TrustPolicyEntryUri>

보안을 한층 강화하기 위해 ADFS의 또 다른 구성 요소인 FS-P(페더레이션 서비스 프록시)를 사용하여 들어오는 인터넷 요청에서 직접 액세스할 수 없는 계층에 FS-R을 유지하도록 했습니다. 단일 프록시 집합을 사용하여 프리프로덕션 영역에서 여러 ADFS 환경을 호스트하는 독특한 방법을 통해 Microsoft.com에서 프록시를 구현했습니다. 재미있게도 초기 기술 램프 업(ramp-up) 중 레지스트리 키를 수정하기만 하면 이를 달성할 수 있음을 발견했습니다. 이 키는 HKLM\Software\Micro­soft\WebSSO에 있는데 이 키에서 초기 디렉터리의 값만 변경하면 여러 환경에 프록시를 사용할 수 있습니다. 기본값은 다음과 같습니다.

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WebSSO]
“InitialDirectory”=”E:\\\\ADFS\\\\parttestint”

다음과 같이 키를 변경하면 환경을 전환할 수 있습니다.

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WebSSO]
“InitialDirectory”=”E:\\\\ADFS\\\\parttest”

배치 파일을 만들면 이 프로세스를 간편하게 관리할 수 있습니다. 그런데 프록시와 리소스 또는 계정 서버 간에는 일대일 관계가 있으므로 현재 버전의 ADFS MMC 스냅인에서는 전환 환경을 지원하지 않습니다. 따라서 배치 파일이 프록시 서버의 사용을 최대화하는 유일한 방법입니다. 이 방법은 호스트할 환경 수에 관계없이 필요한 실제 서버의 수를 제한하기 때문에 결과적으로 상당한 비용 절감 효과를 가져다 줍니다.

아키텍처 관점에서 또 다른 비용 절감 수단인 가상 컴퓨터를 사용하여 프리프로덕션 환경을 실행하고 있는데, 이 덕분에 6개의 서버를 추가로 구매하고 보관할 필요가 없어졌으며 현재까지 성능 문제도 발생하지 않았습니다. 그러나 프로덕션 환경의 요구 사항이 상당히 늘어나 이를 충족하기 위해 고성능의 실제 컴퓨터를 사용하기로 했습니다.

Active Directory에만 적용이 국한되지 않음

Microsoft.com은 인증에 Active Directory 계정을 사용할 뿐 아니라 Windows Live ID 계정과도 성공적으로 통합되었습니다. Windows Live ID(WLID) 4.5를 사용하면 개인의 Windows Live ID 계정으로 사용자 지정 클래임 변환을 통해 Microsoft 리소스에 대한 액세스를 위임할 수 있습니다. 따라서 이제 더 이상 특정 도메인 계정이 필요하지 않으므로 SSO 인증 측면에서 큰 소득입니다.

당면 문제

앞으로 해결해야 할 가장 큰 문제는 토큰 서명 인증서 공유를 위한 ADFS 관리입니다. 현재는 대개 1년 후에 갱신하기까지 유효한 표준 인증서를 사용하고 있습니다. 그러나 갱신할 때 각 해당 서버가 적절하게 업데이트되어야 하는데, 이 작업은 FS-R에 상당한 영향을 줍니다. 페더레이션을 15개나 20개만 사용하여 겨우 관리할 수도 있겠지만 수천 개는 아니어도 최소한 수백 개의 규모를 고려해야 합니다. 이 경우 단일 환경의 SSL 인증서를 관리하기 위해 전담 직원이 필요합니다. 여러 팀에서 이 솔루션을 자동화하는 최상의 방법을 찾고 있지만 아직까지는 찾지 못했습니다.

또 다른 문제는 일부 응용 프로그램이 기본적으로 ADFS를 지원하지 않을 수도 있다는 것입니다. 사이트에서 ADFS 기능을 사용하기 위해서는 약간의 프로그래밍이 필요한데 차세대 SharePoint에서 ADFS의 구현 요구를 지원하도록 Microsoft® Office SharePoint® Services 팀과 긴밀하게 협력하고 있습니다.

결론

ADFS 모델을 사용할 것인지 결정할 때는 여러 가지 사항을 고려해야 합니다. 그 중 하나는 고객이 액세스할 리소스 수 입니다. 조직 간의 페더레이션 트러스트를 설정하는 프로세스는 단순한 작업일 수 있지만 허용 가능한 액세스 정책을 작성, 검토 및 실행하는 데는 시간과 노력이 필요합니다. 따라서 고객이 한 개의 리소스에만 액세스할 경우 수고할 가치가 있는지 결정해야 합니다. 그러나 리소스 수가 많아질수록 이점도 많아집니다.

자세한 내용은 ADFS 개요 및 Active Directory Federation Services: 페더레이션 ID 및 액세스 관리 방법을 참조하십시오.

Jim Guthrie는 Microsoft.com 운영 팀에서 ADFS를 담당하고 있으며 Enterprise Portal Platform Support 팀의 시스템 엔지니어이기도 합니다.

© 2008 Microsoft Corporation 및 CMP Media, LLC. All rights reserved. 이 문서의 전부 또는 일부를 무단으로 복제하는 행위는 금지됩니다..