클레임, Azure 및 SharePoint 통합 도구 키트 2부
클레임, Azure 및 SharePoint 통합 도구 키트 2부
이 게시물은 CASI(클레임, Azure 및 SharePoint 통합) 키트에 대한 내용을 다루는 총 5부의 시리즈 중 2부입니다. 1부에서는 전체 프레임워크와 솔루션에 대해 간략히 살펴보고 시리즈에서 다룰 내용에 대해 설명했습니다. 이 게시물에서는 접근 방식의 패턴에 대해 중점적으로 설명하겠습니다.
1. 사용자 지정 WCF 응용 프로그램을 데이터 및 콘텐츠에 대한 프런트 엔드로 사용
2. 클레임을 인식하도록 지정
3. 사용자 지정 WCF 응용 프로그램을 Windows Azure 클라우드로 올릴 수 있도록 몇 가지 사항 추가 변경
WCF 사용
CASI 키트 프레임워크의 기본 전제는 모든 응용 프로그램 데이터가 WCF 응용 프로그램을 프런트 엔드로 사용한다는 것입니다. 다른 모든 사용자 지정 응용 프로그램과 마찬가지로 이는 여러분과 같은 개발자가 만들어야 하는 부분입니다. 여러분의 프로젝트에서 이와 관련된 작업을 수행하기 위해 SharePoint와 관련된 지식은 거의 필요 없으며 Visual Studio를 사용하여 WCF 응용 프로그램을 만들 수 있는 .NET 개발자라면 누구나 할 수 있습니다. 최종 목표가 이 WCF 서비스를 Windows Azure에서 호스팅하는 것이라면 Windows Azure 개발 키트를 사용하여 Azure 응용 프로그램을 만들기 위한 서식 파일을 다운로드한 다음 처음부터 Azure WCF 응용 프로그램을 만들기 시작하는 것이 좋습니다. CASI 키트의 현재 버전에서 이해해야 할 한 가지 중요한 제한 사항이 있는데 이 게시물에서 짚고 넘어가려 합니다. CASI 키트에서는 WCF 메서드에 대한 매개 변수로 핵심 .NET 데이터 형식만 전송할 수 있습니다. 따라서 string, bool, int 및 date는 정상적으로 작동하지만 사용자 지정 클래스를 매개 변수로 전달하기 위한 메서드가 없습니다. 그러나 사용자 지정 클래스를 전달해야 한다면 문자열로 매개 변수를 만들고 WCF 메서드를 호출하기 전에 이 매개 변수를 XML로 직렬화를 해제한 다음 WCF 코드에서 개체 인스턴스로 다시 직렬화하는 것이 좋습니다. 이제까지 살펴본 결과 이 외에는 별다른 중요한 제한 사항이 없지만 CASI 키트가 널리 채택되어 사용되면 바라는 사항들이 속속 제기되기 시작할 것으로 확신합니다. 약간 다른 이야기지만 오늘 소개하는 키트는 이러한 모든 요소를 한데 엮는 방법을 풀어낸 저만의 아이디어일 뿐이며 제가 생각하고 결정했던 주요 시나리오의 중요한 부분을 충족하도록 디자인되었습니다. 여러분이 이 키트를 사용하게 되면 많은 개선의 여지가 드러날 것으로 생각합니다.
클레임을 인식하도록 지정
WCF 응용 프로그램이 만들어지면 다음 단계에서는 응용 프로그램에서 클레임을 인식하도록 합니다. 이 단계의 경우 이제 과정을 시작한 저로서는 전혀 기여할 수가 없습니다. 대신 Office 팀의 Eric White가 SharePoint의 클레임을 WCF 응용 프로그램에 통합하는 방법에 대해 설명한 유용한 4부로 구성된 블로그 게시물을 소개합니다. 여러분이 이미 각자의 WCF 서비스를 만들었다는 가정하에 https://blogs.msdn.com/b/ericwhite/archive/2010/05/13/determining-caller-identity-within-a-wcf-web-service.aspx(영문일 수 있음)에 게시된 Eric의 블로그 시리즈 2부부터 시작하겠습니다. 또한 여러분은 계속 진행하면서 Eric이 https://blogs.msdn.com/b/ericwhite/archive/2010/06/18/establishing-trust-between-a-wcf-web-service-and-the-sharepoint-2010-security-token-service.aspx(영문일 수 있음)에 게시한 3부에 나와 있는 단계를 수행해야 합니다. 3부는 절차: 웹 서비스와 SharePoint Server 간에 트러스트 관계 설정이라는 섹션으로 시작됩니다. 실제로 SharePoint STS 토큰 서명 인증서의 지문을 복사하고 이 지문과 일부 다른 정보를 WCF 응용 프로그램의 web.config 파일에 복사하는 순간부터 나오는 모든 단계를 수행해야 합니다. 응용 프로그램이 Windows Azure에서 호스팅되는 경우에는 자체 서명된 인증서를 사용하는 것이 별다른 도움이 되지 않으므로 저는 3부의 SSL 단계를 일일이 진행하지는 않겠습니다. 자체 서명된 인증서 외에 다른 인증서가 없으면 이 단계를 따라야 합니다. 그러나 일반적으로는 Windows Azure WCF 응용 프로그램과 관련하여 적절한 인증 기관으로부터 올바른 SSL 인증서를 얻는 것으로 예상해야 합니다. 참고: Eric의 블로그 4부에 소개된 단계를 수행할 필요는 없습니다. 지금까지 설명한 단계를 수행했으면 올바르게 작동하는 WCF 응용 프로그램과 이러한 응용 프로그램을 인식하는 SharePoint 클레임을 얻게 되었을 것입니다. 이 게시물의 마지막 단계에서는 이를 Windows Azure로 올리기 위해 추가로 수행해야 하는 단계를 소개하겠습니다.
Windows Azure에서 작동하도록 설정
이제 올바르게 작동하는 WCF Azure 응용 프로그램이 있으므로 응용 프로그램이 WIF(Windows Identity Framework)를 통해 클레임 인증과 토큰을 계속해서 지원하고 Windows Azure 클라우드에서 호스팅되도록 하기 위한 몇 가지 작업을 수행해야 합니다. 그럼 여기서 이러한 작업의 목록을 나열해 보겠습니다.
1. 디버깅에 로컬 가상 디렉터리를 사용하도록 WebRole 프로젝트(즉, WCF 프로젝트)를 구성합니다. 이렇게 하는 것이 인증서를 사용하는 부분을 위해 VS.NET 개발 서버에 의지하는 것보다 훨씬 편리하며 여러분도 만족하실 것입니다. 이를 변경하려면 WebRole 프로젝트 속성을 두 번 클릭한 다음 웹 탭을 클릭합니다. "IIS 웹 서버 사용" 라디오 단추를 선택하고 가상 디렉터리 만들기 단추를 클릭합니다. 가상 디렉터리가 만들어지면 프로젝트 속성을 닫을 수 있습니다.
2. WebRole 프로젝트에 Microsoft.Identity에 대한 참조를 추가합니다. 이 참조를 Copy Local = true 및 Specific Version = false로 변경해야 합니다. 이렇게 하는 이유는 WIF 어셈블리를 응용 프로그램 패키지가 포함된 클라우드에 복사해서 올려야 하기 때문입니다.
3. 이 WCF 핫픽스를 다운로드합니다. Win2008 R2의 경우 https://code.msdn.microsoft.com/KB981002/Release/ProjectReleases.aspx?ReleaseId=4009(영문일 수 있음)에서, Win2008의 경우 https://code.msdn.microsoft.com/KB971842/Release/ProjectReleases.aspx?ReleaseId=3228(영문일 수 있음)에서 각각 다운로드합니다.
4. 이 특성을 여러분의 WCF 클래스에 추가해야 합니다. [ServiceBehavior(AddressFilterMode = AddressFilterMode.Any)]. 따라서 예를 들자면 클래스가 다음과 같은 형태를 나타내게 됩니다.
namespace CustomersWCF_WebRole
{
[ServiceBehavior(AddressFilterMode = AddressFilterMode.Any)]
public class Customers : ICustomers
{
5. 서비스에서 사용되는 동작 요소에 다음 구성 데이터를 포함해야 합니다. 이렇게 하면 Azure 환경에서 포트가 무작위로 할당될 수 있는 문제가 해결됩니다. 이 문제를 로컬로 테스트하려면 위의 3번에서 설명한 핫픽스가 있어야 합니다.
<useRequestHeadersForMetadataAddress>
<defaultPorts>
<add scheme="http" port="80" />
<add scheme="https" port="443" />
</defaultPorts>
</useRequestHeadersForMetadataAddress>
제 WCF 서비스에 대한 web.config 컨텍스트의 예는 다음과 같습니다.
<behaviors>
<serviceBehaviors>
<behavior name="CustomersWCF_WebRole.CustomersBehavior">
<federatedServiceHostConfiguration name="CustomersWCF_WebRole.Customers"/>
<serviceMetadata httpGetEnabled="true" httpsGetEnabled="true"/>
<serviceDebug includeExceptionDetailInFaults="false"/>
<useRequestHeadersForMetadataAddress>
<defaultPorts>
<add scheme="http" port="80" />
<add scheme="https" port="443" />
</defaultPorts>
</useRequestHeadersForMetadataAddress>
</behavior>
</serviceBehaviors>
</behaviors>
6. 먼저 여러분이 WCF 응용 프로그램에 사용하는 SSL 인증서를 Azure 개발자 포털에 업로드합니다. 참고: CASI 키트의 기본 클래스는 SSL을 사용하도록 구조화되어 있므로 WCF Windows Azure 응용 프로그램에 SSL 지원을 구현해야 합니다. 이것이 클라우드 서비스와 SharePoint 팜 사이에 중요한 데이터를 전달하기 위해 필요할 것으로 예상되는 요구 사항이기를 바랍니다. 이어서 Roles 폴더에서 WebRole 프로젝트 이름을 두 번 클릭하여 Visual Studio에서 Azure 역할 속성에 인증서를 추가합니다. 와일드 카드 인증서를 사용해도 되는 것으로 확인되었지만 여기서는 PFX 인증서를 사용해야 하므로 PFX 파일을 만들 때 체인의 모든 인증서를 내보내야 합니다. 여러분이 인증서를 개발자 포털에 업로드하면 Azure에서는 이를 모두 널리 퍼뜨립니다.
7. 모든 Azure 응용 프로그램이 cloudapp.net에서 호스팅되더라도 여러분의 SSL 인증서는 someName.yourDnsName.com에 대한 인증서여야 합니다. 예를 들어 제 SSL 인증서는 *.vbtoys.com에 대한 와일드 카드 인증서였습니다. 저는 DNS에 azurewcf.vbtoys.com이라는 새 CNAME 레코드를 만들었으며 이 레코드에서는 myAzureApp.cloudapp.net을 참조했습니다. 따라서 제 요청과 SSL 인증서는 *.vbtoys.com에 대한 것이므로 제 인증서가 작동하는 https://azurewcf.vbtoys.com에 연결하면 DNS에서 CNAME 레코드(myAzureApp.cloudapp.net)를 토대로 제 요청을 리디렉션합니다.
8. Azure 프로젝트에서 Roles 폴더에 있는 WebRole 프로젝트 이름을 두 번 클릭하고 이러한 속성을 다음과 같이 설정합니다.
a. 구성 탭: 다음에 대한 브라우저 시작: HTTP 및 HTTPS 끝점의 선택을 취소합니다.
b. 인증서 탭: 서비스와 함께 SSL에 사용할 인증서를 추가합니다. 예를 들어 저는 연구실에서 모든 웹 서버에 대해 제 도메인에서 발행한 와일드 카드 인증서를 사용하므로 여기에 제 와일드 카드 인증서를 추가했습니다.
c. 끝점 탭: HTTP 및 HTTPS에 대한 확인란을 모두 선택합니다. 이름은 각각 HttpIn와 HttpsIn이어야 합니다. 이제 HTTPS 섹션에서 SSL 인증서 이름 드롭다운에 b단계에서 추가한 SSL 인증서가 포함되어 있어야 합니다.
9. 스크립트를 반환하는 WCF 메서드가 있는 경우 CASI 키트에 포함된 웹 파트를 사용하거나 고유한 JavaScript 함수에서 이를 태그의 innerHTML에 할당할 때 제대로 작동하도록 하려면 스크립트 태그에 DEFER 특성이 포함되어야 합니다. 예를 들어 스크립트 태그는 다음과 같아야 합니다. <script defer language='javascript'>
10. <style>처럼 다른 서식 태그가 포함된 콘텐츠를 반환하는 WCF 메서드를 사용하는 경우에는 <pre> 태그로 둘러싸야 하며 그렇지 않으면 CASI 키트에 포함된 웹 파트를 사용하거나 고유한 JavaScript 함수에서 이를 태그의 innerHTML에 할당할 때 올바르게 처리되지 않습니다. 예를 들어 스타일 태그와 함께 반환하는 콘텐츠는 다음과 같습니다. <pre><style>.foo {font-size:8pt;}</style></pre>
여기까지가 WCF 응용 프로그램이 Azure에서 호스팅되도록 구성하기 위한 단계입니다. 다음은 구현에 따라 유용하거나 필요할 수 있는 팁 몇 가지를 소개합니다.
1. 서비스를 사용하는 끝점 주소를 만들 때 정규화된 이름을 사용합니다. 즉, machineName보다는 machineName.foo.com을 사용합니다. 이는 Windows Azure에서 호스팅되는 최종 형식으로 좀 더 깔끔하게 전환되며 SSL 인증서가 정규화된 도메인 이름을 사용하도록 디자인된 경우 발생하는 오류를 해결할 수도 있습니다.
2. SSL을 통해 WSDL을 가져오려는 경우 httpsGetEnabled="true" 특성을 <serviceMetadata httpGetEnabled="true" /> 요소에 추가해야 할 수도 있습니다. 하지만 현재 SharePoint Designer에는 WSDL에 SSL을 사용하지 못하도록 하는 버그가 있습니다.
3. 디버깅 및 데이터 연결에 팁에 대한 자세한 내용은 https://blogs.technet.com/b/speschka/archive/2010/09/19/azure-development-tips-for-debugging-and-connection-strings.aspx(영문일 수 있음)에서 제 게시물을 참조하십시오.
4. 대부분의 경우 WCF 서비스 네임스페이스는 https://tempuri.org인 것으로 가정해야 합니다. 네임스페이스를 변경하는 방법과 관련된 지침은 https://blogs.infosupport.com/blogs/edwinw/archive/2008/07/20/WCF_3A00_-namespaces-in-WSDL.aspx(영문일 수 있음)의 게시물에서 확인할 수 있습니다.
완성된 WCF 서비스
위의 구성 단계를 모두 완료하고 WCF 응용 프로그램을 Windows Azure에 배포한 상태에서 사용자가 SharePoint 사이트에서 이 WCF 서비스를 호출하면 해당 사용자의 전체 사용자 토큰과 함께 이와 연결된 모든 클레임이 제공됩니다. 또한 이러한 변경 작업 후에 WCF 서비스는 조직 내에서도 올바르게 작동하므로 응용 프로그램을 클라우드에 올리기 전에 몇 가지를 점진적으로 변경해 보려는 경우 테스트하기가 매우 쉽다는 점을 알려 드립니다. 이러한 사용자 토큰이 있으면 WCF 서비스에서 정말로 흥미로운 작업을 할 수 있게 됩니다. 예를 들어 WCF 서비스 내에서 사용자의 모든 클레임을 열거하고 이를 토대로 모든 유형의 세밀하게 구성된 권한과 관련된 결정을 내릴 수 있습니다. 현재 사용자가 관리자인 경우 일부 부가적인 수준의 세부 정보가 요청에 반환되므로 현재 사용자가 관리자인지 확인하도록 사용자 클레임 집합에 대해 LINQ를 사용하는 예제는 다음과 같습니다.
//look for the claims identity
IClaimsIdentity ci =
System.Threading.Thread.CurrentPrincipal.Identity as IClaimsIdentity;
if (ci != null)
{
//see if there are claims present before running through this
if (ci.Claims.Count > 0)
{
//look for a group claim of domain admin
var eClaim = from Microsoft.IdentityModel.Claims.Claim c in ci.Claims
where c.ClaimType ==
"https://schemas.microsoft.com/ws/2008/06/identity/claims/role" &&
c.Value == "Domain Admins"
select c;
//see if we got a match
if (eClaim.Count() > 0)
//there’s a match so this user has the Domain Admins claim
//do something here
}
}
이와 더불어 WCF 메서드에 대해 직접 사용 권한을 요청하는 멋진 기능을 활용할 수 있습니다. 예를 들어 데이터 저장소를 쿼리하고 고객 CEO의 목록을 반환하는 WCF 메서드를 사용하며 영업 책임자 외의 다른 직원이 이 정보를 사용하는 것을 원치 않을 경우 다음과 같이 메서드에 PrincipalPermission 요구를 포함하면 이를 쉽고 요령 있게 구현할 수 있습니다.
//the customer CEO list should not be shared with everyone,
//so only show it to people in the Sales Manager role
[PrincipalPermission(SecurityAction.Demand, Role = "Sales Managers")]
public string GetCustomerCEOs()
{
//your code goes here
}
이제 “Sales Managers”에 대한 클레임이 없는 다른 누군가가 이 메서드를 호출하기 위해 메서드의 호출을 시도하는 코드를 실행하면 액세스가 거부됩니다. 정말 멋지죠?
또 다른 중요한 점은 이를 위장할 수가 없다는 것입니다. 예를 들어 연구실에서 고유한 도메인을 만들어 이 도메인에 계정을 추가하고 이 계정을 추가할 영업 책임자 역할을 만들 수 없습니다. 이렇게 할 수 없는 이유는 여러분이 Eric White의 블로그에서 수행한 단계에서 확인할 수 있습니다(이 게시물의 "클레임을 인식하도록 지정" 섹션). SharePoint STS에서 사용되는 토큰 서명 인증서의 날인을 추가한 부분이 떠오를 것입니다. 즉, 클레임은 WCF 응용 프로그램으로 들어갈 때 SharePoint STS의 공개 키로 서명할 토큰을 찾게 됩니다. SharePoint STS는 해당 토큰 서명 인증서에 대한 개인 키가 있는 유일한 엔터티이므로 SharePoint STS에서만 이러한 공개 키를 사용하여 토큰에 서명할 수 있습니다. 이를 통해 해당 SharePoint 팜에 대해 인증된 사람만 WCF 서비스를 사용할 수 있게 되며 사용자는 자신이 로그인했을 때 부여 받은 클레임만 가지게 됩니다. 또한 흥미롭게도 사용자 디렉터리에 대해 인증될 때 부여 받은 클레임뿐만 아니라 SharePoint에서 사용자 지정 클레임 공급자와 함께 클레임 추가를 통해 제공 받은 모든 추가 클레임도 포함됩니다. 따라서 이는 진정한 통합형 종단 간 솔루션이라고 할 수 있습니다.
다음 단계
다음 게시물에서는 CASI 키트와 함께 제공되는 웹 파트와 사용자 지정 기본 클래스에 대해 설명하겠습니다. 이를 사용하면 새 Azure WCF 응용 프로그램에 쉽고 빠르게 연결할 수 있습니다. 또한 앞으로는 기능을 시연하기 위한 수단으로 CASI 키트를 위해 제가 작성한 WCF 서비스를 사용하겠습니다. 이 서비스에 사용한 .cs 파일은 이 게시물에 첨부했습니다. 이를 현재 상태대로 사용할 수는 없으며 이 파일에 들어 있는 다양한 메서드, 데이터 형식 그리고 이 키트에 대해 특정 기능이 구현된 방식을 확인할 수 있도록 할 목적으로만 단순하게 포함되어 있습니다. 다음 게시물에서는 주로 a) GetAllCustomersHtml, b) GetCustomerCEOs 및 c) GetAllCustomers 메서드를 사용하겠습니다. 이들 메서드는 a) HTML을 반환하고(웹 파트에 데이터를 표시하기 위한 사실상의 기본 설정 반환 형식), b) PrincipalPermission 요구를 사용하며, c) WCF 응용 프로그램에서 사용자 지정 클래스 형식을 반환하고 CASI 키트를 사용하여 SharePoint에서 이러한 데이터를 다시 가져온 후 동일한 리치 클래스 형식을 사용하는 방법을 보여 준다는 점에서 흥미롭습니다.
이 문서는 번역된 블로그 게시물입니다. 원본 문서는 The Claims, Azure and SharePoint Integration Toolkit Part 2를 참조하십시오.