최초 문서 게시일: 2012년 7월 23일 월요일

SharePoint 2013에서 많이 들어서 관련 게시물이 많이 작성하게 되는 것 중 하나가 oAuth입니다.  SharePoint 2013에서 oAuth는 보안 주체(사용자 또는 응용 프로그램)의 ID를 설정하기 위해 두 응용 프로그램 간에 트러스트를 설정하는 데 사용됩니다.  SharePoint에서는 SharePoint와 Exchange, Lync 등 간에, 새 클라우드 앱 모델을 사용 중인 ACS 또는 개별 응용 프로그램 개발자 간에 또는 다른 두 SharePoint 팜 간에 원격 SharePoint 인덱스 기능 등을 검색하는 데 oAuth 트러스터를 사용합니다.

 

oAuth에서 수행하지 않는 것이 사용자에 대한 인증 공급자가 됩니다. New-SPTrustedIdentityTokenIssuer를 사용하여 ID 공급자에 대한 트러스트를 만들 수 있습니다.  oAuth 트러스트의 경우 이름에 New-SPTrustedSecurityTokenIssuer라는 매우 비슷한 새로운 cmdlet이 있습니다.   보안 토큰 발급자를 통해 이런 종류의 트러스트를 설정하는 경우 S2S(Server to Server) 트러스트라고 합니다.  이 머리글자어는 SharePoint 2013에서 많이 사용되므로 기억해 두십시오.  이 게시물에서는 이 트러스트를 만드는 데 필요한 특수 항목에 대해 설명하겠습니다.

 

다행히도 S2S 트러스트를 필요로 하는 많은 기능이 이 트러스트를 자동으로 설정합니다.  기능 활성화를 통해 트러스트를 설정하거나, 기능을 설정하는 중에 트러스트를 생성하도록 기능 팀에서 실행할 PowerShell 스크립트 또는 cmdlet를 제공할 수 있습니다.  이 작업을 직접 수행해야 하는 경우도 있습니다. 이 경우 이 게시물을 참조하십시오.

 

먼저 SSL을 사용할지 여부를 결정해야 합니다.  실제로 SharePoint 2013에서는 대부분의 경우 SSL을 사용해야 합니다.  그 이유는 SharePoint 2013에는 oAuth를 사용하는 많은 시나리오가 있고 이 경우 액세스 토큰을 사용하여 쿠키를 전달하기 때문입니다.  액세스 토큰은 데이터에 연결하는 문을 여는 열쇠와 비슷합니다.  액세스 토큰은 인증서로 서명되므로 다른 사용자가 자체 액세스 토큰을 만들어 위장할 수 없지만, 쿠키가 일반 텍스트로 전송되는 것을 원치는 않을 것입니다. 왜냐하면 이론적으로 쿠키를 포착한 누군가가 쿠키의 수명 기간 동안 쿠키를 재생할 수 있기 때문입니다.  SSL은 동일한 이유로 양식 기반 인증 사이트에서 SSL을 사용하는 경우와 동일한 방법으로 쿠키 재생 공격으로부터 사용자를 보호합니다.  따라서 여전히 HTTP를 통해 사이트를 실행할 충분한 이유가 있습니다. 예를 들어 테스트 환경에 있거나, 개발자 환경을 구축 중이거나, 내부 네트워크에서 완전히 실행하여 위험을 느끼지 못하는 경우 등이 있습니다.  이 게시물은 판결을 위한 것이 아니라 설명을 위한 것입니다.  J

 

1단계:  STS 구성

SharePoint의 STS(보안 토큰 서비스) 구성에는 STS를 사용하지 않을 경우에 조정할 수 있는 몇 가지 설정이 있습니다.  다음 cmdlet을 사용하여 모든 STS 구성 설정을 가져올 수 있습니다.  Get-SPSecurityTokenServiceConfig   트러스트를 설정하는 방법은 두 가지입니다. 모든 SharePoint 팜에 있는 새로운 oAuth 메타데이터 끝점을 사용하거나 인증서를 사용합니다.  메타데이터 끝점을 사용하는 것이 가장 쉬운 방법이지만 끝점이 SSL로 보안되지 않는 경우 SharePoint STS의 AllowMetadataOverHttp 속성을 true로 설정해야 합니다.  SSL을 통해 웹 앱을 실행하지 않을 경우 AllowOAuthOverHttp 속성도 true로 설정해야 합니다.  다음은 이러한 속성을 설정하는 방법을 보여주는 축소판 PowerShell입니다.

 

$c = Get-SPSecurityTokenServiceConfig

$c.AllowMetadataOverHttp = $true

$c.AllowOAuthOverHttp= $true

$c.Update()

 

2단계:  트러스트 만들기

필요에 따라 STS를 구성한 경우 한 팜에서 다른 팜으로 트러스트를 설정하는 방법을 살펴볼 수 있습니다.  위에서 설명한 것처럼 모든 SharePoint 팜에는 정보 및 액세스 토큰 서명 인증서를 제공하는 데 사용되는 메타데이터 끝점이 있습니다.  메타데이터 끝점은 /_layouts/15/metadata/json/1에 있습니다.   브라우저에서 이 위치로 이동하면 저장할지를 묻는 메시지가 표시됩니다. 끝점을 저장한 후 실행하여 검사할 수 있습니다.  메모장에서 열리면 JSON 페이로드인 것입니다.  이 경우 STS("발급자")에 대한 이름 식별자와 특수 버전의 토큰 서명 인증서("x509certificate" 키의 "값"으로 설명됨)가 함께 포함되어 있습니다.  데이터를 자세히 살펴보면 발급자는 서비스 이름 + "@" + 영역 값임을 알 수 있습니다.  또한 STS에 대한 NameIdentifier 속성과 일치합니다. 이 정보는 중요합니다. 그 이유에 대해 좀 더 설명 드리겠습니다.

 

이 예에서 FARM_A는 FARM_B를 원격 SharePoint 인덱스로 사용할 것이므로 FARM_B는 FARM_A의 호출을 신뢰해야 합니다.  또한 FARM_A는 http://FARM_A에 웹 응용 프로그램이 있습니다.   트러스트를 만들기 위해 FARM_B의 서버에서 New-SPTrustedSecurityTokenIssuer cmdlet을 다음과 같이 실행했습니다. "$i = " 항목을 사용한 이유에 대해서는 게시물의 뒷부분에서 설명하겠습니다.

 

$i = New-SPTrustedSecurityTokenIssuer -Name FARM_A -Description "FARM_A description" -IsTrustBroker:$false -MetadataEndPoint "http://FARM_A/_layouts/15/metadata/json/1"

 

이제 서비스 전용 팜을 통해 트러스트를 설정합니다.  웹 응용 프로그램, 사이트 모음 및 SSL 인증서를 만들지 않을 것이므로 서비스 전용 팜에서 트러스트를 만들 수 있습니다.  따라서 두 번째 방법인 New-SPTrustedSecurityTokenIssuer cmdlet을 사용하여 트러스트를 설정할 수 있습니다.  두 번째 양식에서는 토큰 서명 인증서와 이름 식별자를 제공할 수 있습니다.  토큰 서명 인증서는 SharePoint 2010에서와 동일한 방법으로 가져옵니다. 즉, 팜의 서버로 이동하고 MMC를 실행하고 로컬 컴퓨터에 대한 인증서 스냅인을 추가한 다음 SharePoint…인증서 노드를 찾습니다. 이 목록의 첫 번째 인증서가 찾고 있는 인증서입니다. 이 인증서를 로컬 드라이브에 개인 키 없이 .cer 파일로 저장합니다.  트러스트를 설정하려면 위에서 설명한 STS의 NameIdentifier 특성과 인증서가 필요합니다.  이 경우의 cmdlet은 다음과 같습니다. 여기서는 STS 인증서를 FARM_B의 서버에 있는 C:\sts.cer 파일에 복사했다고 가정합니다.

 

$i = New-SPTrustedSecurityTokenIssuer -name FARM_A -Certificate "C:\sts.cer" -RegisteredIssuerName "00000003-0000-0ff1-ce00-000000000000@72da1552-085a-49de-9ecb-73ba7eca8fef " -Description "FARM_A description" -IsTrustBroker:$false

 

3단계:  토큰 서명 인증서 신뢰

SPTrustedIdentityTokenIssuer를 사용할 때와 마찬가지로 oAuth 토큰에 서명하는 데 사용되는 트러스트를 SharePoint의 신뢰할 수 있는 루트 인증 기관 목록에 추가해야 합니다.  또한 이 작업을 수행하는 두 가지 옵션이 있습니다.  메타데이터 끝점을 통해 트러스트를 만들 경우 다음과 같이 트러스트를 설정할 수 있습니다.

 

New-SPTrustedRootAuthority -Name FARM_A -MetadataEndPoint http://FARM_A/_layouts/15/metadata/json/1/rootcertificate

 

그렇지 않은 경우 SharePoint 2010에서와 같은 방법으로 신뢰할 수 있는 인증 기관 목록에 추가할 수 있습니다.

 

$root = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("C:\sts.cer")

New-SPTrustedRootAuthority -Name "Token Signing Root CA Certificate" -Certificate $root

 

여기서는 트러스트의 관점에서 작업을 수행합니다. 트러스트를 설정했으므로 이제 트러스트를 기반으로 새 응용 프로그램 보안 주체를 만들 수 있습니다.  사용하는 방법은 응용 프로그램에 따라 다릅니다. 원격 SharePoint 인덱스의 경우 시나리오를 지금 완성하겠습니다.

 

4단계:  앱 보안 주체 만들기(원격 SharePoint 인덱스에만 해당하는 예):

이 프로세스는 앱 보안 주체 가져오기와 권한 부여의 두 가지 단계로 구성됩니다.  이 시나리오에서 FARM_B는 원격 SharePoint 인덱스를 쿼리할 것이므로 FARM_A의 호출을 신뢰해야 합니다.  내 앱 보안 주체의 경우 FARM_A가 사용할 웹 앱에 대한 참조를 FARM_B에서 가져와야 합니다.  참조를 가져온 다음 FARM_A에 참조를 사용할 권한을 부여할 수 있습니다.

 

앱 보안 주체에 대한 참조를 가져오려면 cmdlet을 다음과 같이 사용합니다.

 

$p = Get-SPAppPrincipal -Site http://FARM_B -NameIdentifier $i.NameId

 

중요:  여기서 특히 SharePoint 2013 베타 기간 동안 공통되게 발생하는 기억해야 할 한 가지 중요한 사항이 있습니다.  SPAppPrincipal을 가져오려고 시도할 때 PowerShell에서 한 번도 본적 없는 오류가 발생할 수 있습니다.  서버의 사용 가능한 메모리가 5% 미만일 경우 모든 WCF 호출이 실패하는 것을 확인했습니다.  이 PowerShell cmdlet은 WCF로 호스트되는 서비스 응용 프로그램 끝점으로 호출되므로 메모리가 부족하면 Get-SPAppPrincipal cmdlet이 실패합니다.  응용 프로그램 로그에서 Windows 이벤트 뷰어를 체크 인하여 이것이 문제의 원인인지 여부를 확인할 수 있습니다.  이 문제는 지금까지 나에게 여러 번 발생했으므로 다른 사용자에게도 나타날 가능성이 있습니다.

 

게시물의 앞부분에서 설명한 것처럼 내 $i 변수를 사용하여 FARM_A에서 STS의 NameIdentifier를 파악했습니다.  이제 FARM_B 웹 앱의 앱 보안 주체에 대한 참조가 있으므로 보안 주체에 다음과 같이 권한을 부여할 수 있습니다.

 

Set-SPAppPrincipalPermission -Site http://FARM_B -AppPrincipal $p -Scope SiteSubscription -Right FullControl

 

이상은 두 SharePoint 팜 간에 oAuth 트러스트를 만드는 데 사용할 수 있는 옵션과 방법입니다.  oAuth 및 다양한 용례와 문제점을 계속 조사하여 이 블로그를 통해 지속적으로 알려드리겠습니다.

이 문서는 번역된 블로그 게시물입니다. 원본 문서는 Setting Up an oAuth Trust Between Farms in SharePoint 2013을 참조하십시오.