클라우드 시대의 피아식별: Access Control #1

Windows Azure AppFabric에 새로 추가될 구성 요소 중 가장 많은 기대를 받고 있는 서비스가 2011년중 런칭을 준비하고 있습니다. 바로 Access Control에 관한 향상인데, 매력적인 내용이 무궁 무진합니다. 이제 여러분은 기존에 개발한 웹 응용프로그램에 약간의 수정을 가하는것 만으로도 손쉽게 Windows Live ID, Google, Yahoo!, Facebook을 통한 통합 인증을 구현할 수 있고 더불어서 기존에 설치하여 운영 중인 Active Directory Domain이 있다면 여기에 Active Directory Federation Services 2.0을 추가 설치하여 이와 연동하는 것도 가능합니다. ASP.NET 응용프로그램 관점에서 이는 전적으로 Windows Identity Foundation (WIF)을 통하여 손쉽게 구현할 수 있는 부분입니다.

Windows Identity Foundation에 대한 간략한 소개

Windows Identity Foundation (이하 WIF)은 XML Web Service Enhancements에서 소개된 적이 있는 WS-Trust와 WS-Federation 표준을 지원하는 .NET 기반의 ID/클레임 기반 인증을 손쉽게 구현할 수 있도록 도와주는 기술 집합입니다. 단순한 프레임워크만 제공되는 것이 아니고, Visual Studio 2008이나 Visual Studio 2010에 연동하여 프로젝트의 설정을 변경할 수 있도록 도와주는 기능도 같이 설치되므로 코드 작업을 거의하지 않고 기본 틀을 만드는 것이 가능합니다.

WIF는 전통적으로 ASP.NET 기반 응용프로그램에서 사용하던 인증 방식을 초월합니다. 전통적으로 ASP.NET 기반 응용프로그램들은 웹 브라우저를 통하여 접근하는 사용자들에게서 직접 ID와 비밀 번호를 받아 이를 내부 DB와 대조하여 쿠키를 교환하는 방식을 사용해왔습니다. 대부분의 경우 이는 합당한 것이며 당연한 절차였습니다. 하지만 잘못 구현할 경우 정보가 유출되거나 의도하지 않은 사고로 이어지기 쉬웠고, 대개는 이러한 일 때문에 웹이 다소 위험한 공간이라는 편견을 사용자들에게 가지게 하는 부작용도 초래하였습니다. 하지만 WIF는 사용자 인증이라는 다소 민감한 사안을 좀 더 전문적인 기관이나 검증된 솔루션으로 위임한 채, 이들 기관으로부터 결정된 사항을 비대칭 암호화 기반의 데이터로 넘겨받아 피아식별에 필요한 정보만을 추출하여 사용하는 방식을 이용하는데에 큰 도움을 줍니다.

클레임 기반의 인증에서 가장 좋은 점은, 인증에 관한 모든 불안 요소를 제거하고, 피아식별이 완료된 이후에 해당 사용자를 정확히 식별하고 프로필을 안전하게 관리하는 것에만 집중하면 된다는 것입니다. 좀 더 서비스의 완성도를 높이는 일에 많은 시간을 할애하고 노력을 기울일 수 있음을 의미합니다.

Windows Identity Foundation의 역할

WIF를 프로그래밍 코드 측면에서 살펴보면 핵심은 System.Threading.Thread.CurrentPrincipal 정적 프로퍼티에 있습니다. 기본적으로 이 프로퍼티는 IPrincipal 인터페이스를 구현하는 특정 객체의 참조를 반환하는, 즉, ASP.NET의 기본 인증 방식을 통하여 인증이 완료된 사용자임을 증명하는 객체가 반환됩니다. 하지만 WIF를 사용하도록 구성한 시점부터는 IClaimsPrincipal 인터페이스를 사용하여 하나 이상의 클레임 정보를 아래와 같이 액세스할 수 있게 됩니다. (C# 코드)

IClaimsIdentity claimsIdentity = ((IClaimsPrincipal)Thread.CurrentPrincipal).Identities[0];

이미 사용자는 이 페이지를 실행하기에 앞서 적당한 인증 절차를 모두 거쳐 웹 사이트에 로그인한 상태이며, 이러한 부분들은 WIF 내의 FedUtil 도구가 자동 생성하는 STS (Secure Token Service) 웹 사이트에 의하여 처리가 끝납니다. WIF의 개발자 경험에 관한 역할은 이 FedUtil 도구를 개발자가 손쉽게 부를 수 있고, FedUtil 도구를 통하여 기존 ASP.NET이나 WCF 프로젝트가 WIF와 성공적으로 통합될 수 있도록 설정을 업데이트하는 데에 주 목적이 있습니다. 물론 필요하다면 FedUtil을 이용하여 STS 없이 Classic ASP.NET 인증 체계를 이용하도록 되돌리는 것도 가능합니다.

클레임 기반의 인증을 사용한다는 것은 좋은데 이 일을 누가 대신 처리해준다는건지 이해가 잘 되지 않을 수 있습니다. 사실 기본적으로 WIF 내의 FedUtil은 이러한 일을 해주기 위한 도구입니다. WIF 기반 응용프로그램으로 기존 응용프로그램 코드를 변환하거나 복원하는 역할, STS 서비스를 새로 만드는 역할을 담당하게 됩니다. STS 서비스는 자신의 역할을 올바로 수행할 수 있도록 추가적으로 개발될 필요가 있는데 이때 STS 자체는 ASP.NET 응용프로그램의 형태로 작성된 것이고, 다양한 종류의 WIF 보조 서비스들과 상호작용하면서 실제 요구 사항에 부응하는 인증 시스템을 만들 수 있게 된 셈입니다.

AppFabric Access Control?

AppFabric Access Control은 이제 여기서 가장 중요한 역할을 담당하게 됩니다. STS를 클라우드로 올려서 서비스로 제공하는 것이기도 하고 동시에 일반적으로 직접 구현이 어려운 주요 유명 서비스들의 인증 방식을 변환하여 제공해주는 매우 중요한 역할을 합니다. AppFabric Access Control의 역할을 로컬 환경에서 구현하려면 많은 기능들을 A-to-Z로 구현해야 하며 이 자체만으로도 굉장한 프로젝트가 될 것입니다.

AppFabric Access Control이 클레임을 생성하는 과정은 입력과 출력으로 나눌 수 있는데, 입력은 사용자로부터의 입력이 실제 클레임 정보 제공자로부터 들어오는 과정을 말하는 것으로 초기 버전의 Access Control보다 더 강력해진 것입니다. 그렇게 되어 Google과 Yahoo!, Facebook, AD FS를 경유하는 인증이 가능해지게 되었습니다. 그리고 출력은 이후 시리즈에서 더 살펴볼 예정이지만 사전에 정의된 Rule Group에 의하여 조건부로 설정된 결정 사항들을 전달하는 방식을 여러가지 형태로 제공하는 것으로 OpenID, Facebook, OAuth, WS-Authentication, WS-Federation 등 이름만 들어도 쉽게 알 수 있는 인증 방식들을 제공합니다.

다음 시간에는

다음 시간에는 WIF를 이용하여 ASP.NET MVC 3 응용프로그램을 코드 수정 없이 신속하게 클레임 기반의 인증을 지원하는 웹 사이트로 변환하는 과정을 보이도록 하겠습니다. 감사합니다.

댓글 남기기