LINQPad로 Facebook Graph API 빠르게 테스트하기

C#을 사용하면서 알아두면 여러모로 유용하게 활용할 수 있는 도구로 LINQPad가 있습니다. LINQPad Developer Edition부터는 NUGET 패키지를 Query에 포함시킬 수 있는 기능도 제공이 되는데, 이 기능을 활용하여 Outercurve Foundation이 관리하는 Facebook .NET SDK NuGet 패키지를 추가하여 빠르게 Facebook Graph API를 호출할 수 있습니다.

LINQPad에서 NuGet 패키지를 추가하려면, 쿼리 창에서 오른쪽 버튼을 클릭한 다음, NuGet Package Manager 메뉴를 선택합니다.

그 다음, 검색어에 Facebook을 입력하여 검색하면, Facebook이라는 이름의 NuGet 패키지가 검색 결과 제일 처음에 나타납니다. Add To Query 버튼을 눌러 패키지 캐시에 추가한 다음, 설치가 완료되면 Add Namespace 링크를 클릭하여 쿼리에서 편하게 쓸 수 있도록 합니다.

아래 코드 조각을 테스트하기 위해서는 App ID, App Secret, Access Token을 사전에 Facebook Developer 페이지를 통하여 획득하셔야 합니다. 아래 샘플 코드에서는 관리 권한이 있는 Facebook Page에 대해 간단하게 포스팅하고, 해당 포스트의 정보를 가져오는 코드이므로 대상 Page ID도 획득해야 합니다.

string appId = "";
string appSecret = "";
string accessToken = "";
string pageId = "";

FacebookClient client = new FacebookClient(accessToken)
{
  AppId = appId,
  AppSecret = appSecret
};
dynamic result = null;

result = client.Post($"/{page_id}/feed", new
{
  message = $"Random Message {DateTime.UtcNow.Ticks.ToString()}"
});
((object)result).Dump();

result = client.Get($"/{result.id}", new
{
  fields = new string[] { "id" }
});
((object)result).Dump();

Facebook의 Graph API가 반환하는 JSON 응답 객체를 Newtonsoft JSON 라이브러리를 이용하여 C# 객체로 변환하면, 이것을 DLR 바인딩에 연결하여 필요한 프로퍼티에 액세스할 수 있습니다. 그리고 이렇게 얻어온 응답 결과를 LINQPad의 내장 Extension 메서드인 Dump 메서드로 시각적으로 잘 정리된 형태의 표로 볼 수 있습니다.

한 가지 아쉬운 점은, DLR 컨텍스트에서는 LINQPad의 Dump 확장 메서드가 제대로 작동하지 않아서, object 타입으로 캐스팅하여 DLR 컨텍스트를 해제한 다음 Dump 메서드를 호출해주어야 합니다. 실행 결과는 아래와 같습니다.

Facebook이 아니어도, Newtonsoft JSON과 HttpClient를 활용하면 비슷한 방법으로 REST API들을 테스트해볼 수 있습니다.

 

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

지난번 글에 이어서 Access Control을 실제로 ASP.NET 웹 사이트에 사용하기 위한 방법을 살펴보도록 하겠습니다. Access Control은 이제 독립적인 Building Block 중 하나로 언급되고, AppFabric이라는 브랜드 네임은 더 이상 붙지 않습니다.


주: 글 작성의 편의상 ACS 혹은 액세스 제어 서비스라는 말을 혼용해서 사용하려고 합니다.


Access Control 서비스 신청하기


Access Control 서비스는 2012년 여름 현재 아직 새 포털 사이트 (manage.windowsazure.com)에서 프로비져닝하거나 관리할 수 있는 UI가 없습니다. 그러나 빠른 시일 내에 추가가 될 것으로 예상되며, 현재는 실버라이트 기반의 포털 사이트 (windows.azure.com)에서 프로비져닝하고 관리할 수 있습니다.


로그인하고 난 다음에 화면 좌측 하단의 “서비스 버스, 액세스 제어 및 캐시” 탭을 클릭합니다. 사용중인 서비스가 있다면 아래와 같이 나타날 수 있으며, 다른 서비스가 없다면 상단 리본 메뉴에서 “새로 만들기” 버튼을 클릭합니다.



이름에서 알 수 있듯이 네임스페이스 아래에 다수의 서비스가 연결되어있습니다. 관련성이 떨어져보이긴 하지만 캐시도 네임스페이스 아래에 배치하여 프로비져닝할 수 있도록 하고 있습니다. 여기서 한 가지 유의하실 것이 하나 있는데, 실제로 사용하려는 서비스에만 체크해야 불필요한 지출이 발생하지 않습니다. 그리고 이곳의 캐시는 최근 소개된 Dedicated Cache와는 다른 것으로 고성능을 전제로 하지만 상대적으로 작은 용량, 높은 비용이 특징입니다.



서비스 버스 신청 후에는 내부 활성화 및 프로비져닝 절차가 복잡한 것으로 추정되고, 이 때문인지 다른 클라우드 서비스보다 다소 시간이 많이 걸립니다. 완전히 사용할 수 있는 상태가 되면 아래 그림과 같이 항목이 나타나며, 특별히 액세스 제어를 신청했다면 상단 리본 메뉴의 액세스 제어 서비스 버튼이 활성화됩니다.


NOTE: 아마 더 이상 그런 일은 없겠지만 ACSV1으로 신청해서 사용 중인 계정을 아직도 가지고 계시다면, ACSV2로 업그레이드를 따로 요청하셔야 합니다. (아마 지금즈음이면 어떤 형태로든 ACSV2 기반으로 마이그레이션되었을 것으로 봅니다.)



ACS 관리하기


ACS 포털은 각 서비스 노드마다 따로 제공되는 것으로 위의 그림에서 액세스 제어 서비스 버튼을 클릭하면 아래 그림과 같이 새 웹 페이지가 나타날 것입니다. 접속 주소의 패턴은 https://[네임스페이스 이름].accesscontrol.windows.net/v2/mgmt/web 과 같습니다. 



그런데 실버라이트 포털에서 그냥 나와버려서 당황하셨을 수도 있는데, 걱정하지 않으셔도 됩니다. 로그인 상태는 지금 보시는 포털과 실버라이트 포털 사이에 모두 세션이 일치된 상태로 계속 유지가 되기 때문에 (즉 SSO를 구현하고 있기 때문에) 사용에 전혀 지장이 없습니다.


ACS는 여러분이 어떻게 설정하는가에 따라 전적으로 동작이 달라지게 되겠지만 보통은 (1) ID 공급자를 지정하여 ACS 서비스가 여러분의 응용프로그램을 위하여 어떤 ID 공급자와 계약을 맺을 것인지 정의하고, (2) ACS에 여러분의 응용프로그램의 속성을 등록하여 상호 작용에 필요한 정보를 사전에 관리하고, (3) ID 공급자와 응용프로그램 사이에 주고 받을 데이터의 내용을 관리하는 것으로 설정을 다룹니다. 그리고 지금 이야기한 단계 모두 ACS 사이트의 자동 생성 기능을 사용하면 어렵지 않게 초기화할 수 있습니다. 이번 블로그 글에서는 ACS 첫 설정에 대한 내용을 살펴보려고 합니다.


ID 공급자 추가하기


당연한 이야기이지만 Windows Azure는 Windows Live ID (혹은 앞으로는 Microsoft ID라고 불리겠군요)를 기반으로 모든 서비스 프로비저닝이 이루어지므로 기본적, 종속적, 필수적으로 ACS의 기본 ID 공급자로 자동 구성되어있으며 동시에 뺄 수 없도록 보호되어있습니다.


Windows Live ID 공급자를 제외하면 웹 관리 UI 상으로는 아래 그림과 같은 종류의 ID 공급자들을 지원합니다.



별 다른 노력 없이 쉽게 추가할 수 있는 공급자 종류로 Google과 Yahoo!가 있고, 기존의 인프라가 선행되어야 하는 공급자 종류로 Facebook와 WS-Federation ID 체계를 지원하는 공급자를 택할 수 있게 되어있습니다. 만약 여러분이 작성하려는 웹 서비스가 소셜 네트워크와 친화적일 필요가 있다면 ACS를 사용해서 한 번에 Facebook과 Google, Yahoo!를 인증 공급자로 택하여 SSO를 자동으로 구현할 수 있는 것입니다.


저는 여기서 간단하게 Google을 ID 공급자로 등록해보도록 하겠습니다. 기회가 되면 Facebook을 활용하는 것도 글로 다루어보도록 하겠습니다.



로그인 페이지 상에 표시할 상세 정보를 지정할 수 있는 페이지가 보입니다. 특별한 설정 없이 저장 버튼을 눌러도 무방하므로 계속 진행합니다.



새 ID 공급자와 ACS 간의 연동이 완료되었습니다. 계속해서 신뢰 당사자 응용프로그램 등록 절차를 진행합니다.


응용프로그램 정보 등록하기


ACS를 실제로 사용하려는 웹 사이트의 정보를 등록해야 합니다. 위의 화면 상 왼쪽 메뉴에서 “신뢰 당사자 응용프로그램” 메뉴를 클릭하고 추가 링크를 클릭하면 아래 그림과 같이 등록 절차가 시작됩니다.


요구하는 항목의 수가 많아 부담스러운 페이지이긴 하나 모두 의미가 있는 항목들이므로 하나씩 찬찬히 살펴보면서 진행해야 합니다.




  • 이름: 관리 도구나 기타 메타데이터 상에서 표시할 알아보기 쉬운 이름을 입력하며, 보통은 도메인 이름 약칭을 적어주면 유용합니다.

  • 모드: 수동으로 설정 입력에 체크합니다.

  • 영역: ACS로 인증을 거친 이후에 실제로 전달받은 토큰이 쓰일 수 있는 URL 경로를 지정합니다. 사이트 전체를 ACS 인증 체제로 확정하려면 그냥 도메인을 포함하여 루트 URL을 지정하고, 그렇지 않은 경우에는 웹 서버 설정과 맞추어 지정해야 합니다. 동일 도메인이라 할지라도 이 영역을 벗어나면 먼저 인증하여 받은 토큰은 자동으로 무력화됩니다.

  • 반환 URL: XML 형태로 넘어오는 보안 토큰값을 실제로 받아서 처리할 URL을 지정합니다. 이 URL을 정확히 지정하여 로그인해서 넘어오는 어떤 임의의 사용자가 실제 여러분이 가지고 있는 사용자 DB와 일치하는 동일 사용자인지 피아식별하고 판정할 수 있습니다.

  • 오류 URL: 옵션 항목이며, 오류가 발생했을 때 사용자가 당황하지 않도록 안내문구를 표시해줄 URL을 지정하여 서비스에 대한 클레임을 최소화하는데 활용할 수 있습니다.

  • (계속)



  • 토큰 형식: 토큰 데이터를 ACS에서 응용프로그램으로 넘길 때 어떤 형태로 패키징해서 보낼 것인지를 결정하는 부분으로, 이번 강좌에서 사용하려는 프레임워크인 Windows Identity Foundation을 고려하여 SAML 2.0으로 지정합니다. 만약 다른 프레임워크를 사용하려는 경우 적절한 포맷을 선택합니다.

  • 토큰 암호화 정책: ACS에서 토큰을 넘겨받을 때 인증서와 키 값을 이용하여 토큰을 암호화해서 넘겨받아야 하는 경우가 있을 때 암호화 사용을 선택합니다. 여기서는 암호화를 필수적으로 사용해야 하는 경우가 아니므로 암호화 정책을 기본값으로 설정하겠습니다.

  • 토큰 수명: 토큰이 발행되고 난 뒤에 만료되기까지의 기간을 설정합니다. 초 단위의 값이며 기본값은 10분입니다.

  • ID 공급자: 앞 단계에서 등록한 공급자들 중에서 지금 등록하려는 응용프로그램과 연결하려는 ID 공급자를 따로 지정할 수 있습니다. 보통은 네임스페이스와 연결된 모든 ID 공급자를 선택할 수 있지만 편의에 따라 설정을 바꿀 수 있습니다.

  • 규칙 그룹: ID 공급자와 이 응용프로그램 사이에 어떤 정보를 주고 받을 것인지에 대한 구체적인 설정을 보관하는 규칙 그룹을 선택할 수 있습니다. 이미 만들어진 규칙 그룹을 고르거나 새로운 규칙 그룹을 만들어 독립적인 설정을 구성할 수 있습니다.

  • 토큰 서명: 토큰 서명 시 사용하려는 인증서를 고를 수 있는데, 자체 제공되는 ACS용 인증서를 이용하거나 여러분이 기존에 소유하고 있는 인증서를 대신 지정할 수 있습니다. 선택 옵션에 따라 하단에 새 옵션 필드가 하나 더 늘어날 수 있습니다.

  • 인증서: 토큰 서명에 사용할 인증서를 직접 지정하도록 옵션을 변경하면 나타나는 옵션 필드로 X.509 인증서와 연결되어있는, 비밀 키를 포함하는 PFX 파일과 비밀 키 값을 지정해야 합니다.

ACS의 인증은 사이트 도메인 경계를 넘나드는 형태로 진행되기 때문에, 위의 옵션에서 잠시 나왔던 것 처럼 localhost 주소가 등록하려는 Application의 실제 주소가 될 수 있습니다. 달리 표현하면, VPN 환경과 같이 외부와 격리되어있으면서 실제 VPN 네트워크 안에 참가해야만 유효한 특별한 형태의 네트워크일지라도 ACS나 실제 ID 공급자와 통신하는데 문제가 없다면 좀 더 견고한 인트라넷-인터넷 간 상호 인증을 구현하는 것도 얼마든지 가능합니다. 그리고 localhost 주소를 지원하므로 당연히 Visual Studio나 Eclipse 등의 개발 도구 등으로 만든 Ad-hoc 서버의 주소를 넣어서 ACS 기능을 테스트하는 것도 당연히 가능합니다.


저의 경우에는 테스트를 위하여 Visual Web Developer 2010 Express Edition을 이용하여 ASP.NET MVC 프로젝트를 만들고 이 주소를 Application으로 등록하기로 하였습니다. Visual Studio 개발 서버나 IIS Express 모두 Ad-hoc 서버이므로 정확한 포트 번호의 확인을 위해서 만든 웹 프로젝트의 속성에서 포트 번호를 확인해야 합니다.



제가 테스트를 위해서 확정해야 하는 주소는 http://localhost:50086 이군요. 이 주소를 바탕으로 신뢰 응용프로그램 정보에 다음과 같이 정보를 등록하려고 합니다.



  • 이름: MyApp

  • 수동으로 설정 입력

  • 영역, 반환 URL, 오류 페이지 주소: http://localhost:50086/

  • ID 공급자: Google 및 Windows Live ID

  • 기타 항목은 모두 기본값으로 설정합니다.

저장 버튼을 누른 다음에는 아래와 같이 응용프로그램 정보가 새로 등록된 것을 볼 수 있습니다.



이제 규칙 그룹의 세부 설정을 완성해야 합니다.


규칙 그룹 구성하기


규칙 그룹 링크를 화면 왼쪽에서 클릭하면 아래 그림과 같이 응용프로그램 등록 과정에서 자동으로 추가된 항목이 나타날 것입니다. 규칙 그룹 이름을 클릭하여 상세 정보를 확인합니다.



규칙 그룹의 상세 내역을 확인해보면 처음 만들어진 그룹이기 때문에 아무것도 등록되어있지 않은 것을 볼 수 있습니다. 규칙 그룹의 이름 같은 부분들은 역시 이곳에서 편집이 가능하고, 어떤 규칙 그룹과 앱이 연결되어있는지도 한 번에 파악할 수 있습니다.



하단의 생성 링크를 클릭하여 자동으로 ID 공급자와 응용프로그램들 사이에 필요한 모든 규칙을 한 번에 만들도록 구성할 수 있습니다. ID 공급자들이 ACS에 제안하는 기본적인 옵션들을 한번에 만들어주므로 일반적인 연동을 위해서는 보통 이 작업 한 번으로 필요한 모든 기능을 자동으로 구성할 수 있게 되어있습니다.



규칙들이 아래 그림과 같이 등록된 것을 볼 수 있습니다. ID 공급자별로 제공할 수 있는 클레임과 클레임의 출처, 그리고 간단한 설명이 열거되어있습니다.



Google의 경우 사용자의 Google 계정과 연결된 메일 주소, 사용자 이름, 그리고 고유 식별자를 제공하며, Windows Live ID의 경우에는 다른 정보 없이 최소한의 식별자만을 제공하고 있습니다. 이후에 다시 살펴보겠지만 사실 모든 ID 공급자들이 친절하게 e-mail 주소를 공개한다는 보장은 할 수 없습니다. 그렇기 때문에 파악이 쉬운 e-mail 주소와 같은 클레임을 직접 사용하려고 하기 보다는 고유 ID 값을 근거로 새로운 프로필을 만들도록 권하는 방식이 ACS 사용 시에는 더 좋은 방법이라고 할 수 있습니다.


마무리


이제 기본적인 구성이 모두 완료되었습니다. 실제 응용프로그램에서 ACS와 연동하여 SSO를 어떻게 구현할 수 있는지 그 내용을 다음번 강좌때 올리도록 하겠습니다.

클라우드 시대의 피아식별: 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 응용프로그램을 코드 수정 없이 신속하게 클레임 기반의 인증을 지원하는 웹 사이트로 변환하는 과정을 보이도록 하겠습니다. 감사합니다.