Udostępnij za pośrednictwem

SharePoint 2013에서 신뢰도가 높은 앱의 문제를 해결하는 추가 팁

  • Artykuł

최초 문서 게시일: 2012년 11월 2일 금요일

안녕하세요. 저는 앱 개발자이고 개발 작업을 좋아하기는 하지만, 새로 만든 SharePoint 앱에서 "토큰 발급자가 신뢰할 수 있는 발급자가 아닙니다." 같은 문제가 하나 이상 발생하는 경우 해당 문제를 추적해야 하는 과정까지 좋아하는 것은 아닙니다. 이러한 경우에 여러분이 문제를 쉽게 해결할 수 있도록, 이 게시물에서는 제가 사용하는 문제 해결 방법의 목록을 공유하고자 합니다. 이 오류를 호출 및 해결하는 새롭고 유용한 방법이 확인되면 이 게시물을 업데이트하고 "업데이트"로 표시하겠습니다. 

이 게시물의 제목에도 나와 있는 "신뢰도가 높은 앱"이란, SharePoint 앱용 신뢰 브로커로 ACS를 사용하는 대신 OAuth 토큰을 만들어 고유 인증서로 서명을 한다는 의미입니다. 이 프로세스에 대해 전반적으로 설명하는 문서가 많이 있을 것이므로 여기서는 다시 설명하지 않습니다. 여기서는 여러분이 이러한 문서의 내용을 확인하여 해당 과정을 직접 수행해 보았으며 이 게시물의 문제 해결 과정을 진행할 준비가 되었다고 가정합니다. 먼저, 위에서 언급한 오류가 발생하는 몇 가지 경우는 다음과 같습니다.

  1. SPTrustedRootAuthority 목록에 추가 - 인증서를 사용하여 OAuth 토큰에 서명을 할 때는 New-SPTrustedRootAuthority를 만들어야 합니다. SharePoint 2010의 New-SPTrustedIdentityTokenIssuer와 마찬가지로 체인의 모든 인증서와 토큰 서명 인증서를 SharePoint의 신뢰할 수 있는 기관 목록에 추가해야 합니다. 이 프로세스를 수행하려면 https://blogs.technet.com/b/speschka/archive/2010/02/13/root-of-certificate-chain-not-trusted-error-with-claims-authentication.aspx(영문일 수 있음) 게시물에 설명되어 있는 것과 같은 단계를 따르면 됩니다. AD FS에서 인증서를 내보내는 작업에 대한 내용은 무시하십시오. 여기서는 GoDaddy, VeriSign 등의 공용 루트 CA, 자체 서명 인증서 또는 도메인 발급 인증서와 같은 기타 방법을 통해 신뢰도가 높은 앱의 인증서를 만들었다고 가정합니다.
  2. 클라이언트 ID에 모두 대문자 사용 - 다른 게시물에서도 설명했지만, 클라이언트 ID를 응용 프로그램의 AppManifest.xml 파일(자체 호스팅 솔루션을 작성하는 경우에는 웹 응용 프로그램의 web.config)에서 클라이언트 ID를 연결할 때 대문자를 사용해서는 안 됩니다. 여기에 대한 자세한 내용은 https://blogs.technet.com/b/speschka/archive/2012/07/28/an-important-tip-about-client-id-values-for-s2s-apps-in-sharepoint-2013.aspx(영문일 수 있음)에서 확인할 수 있습니다.
  3. 토큰 발급자가 신뢰 브로커로 구성되지 않음 - 이 문제에 대해서도 https://blogs.technet.com/b/speschka/archive/2012/09/27/another-apps-for-sharepoint-tip-with-the-error-quot-the-issuer-of-the-token-is-not-a-trusted-issuer-quot.aspx(영문일 수 있음)에서 설명한 적이 있습니다. 이 원인으로 인한 오류를 방지하려면 New-SPTrustedSecurityTokenIssuer를 만들 때 -IsTrustBroker 플래그를 포함해야 합니다.
  4. 업데이트: web.config에서 IssuerId 키 누락 - SharePoint 2013에서 앱의 신뢰 브로커 기능을 사용하려면 응용 프로그램에서 SharePoint로 보내는 JWT 토큰을 만들 때 신뢰 브로커의 IssuerId를 확인할 수 있어야 합니다. 이를 위해 응용 프로그램은 web.config에서 IssuerId 앱 속성을 찾습니다. 이때 응용 프로그램의 web.config에서 ClientId, ClientSecret 등과 동일한 위치를 검색합니다. 이 속성의 형식은 <add key="IssuerId" value="e9134021-0180-4b05-9e7e-0a9e5a524965"/>와 같습니다.
  5. 업데이트: Visual Studio용 Office 도구 RTM Preview 사용 - 실제로 RTM Preview 비트에는 버그가 있었는데 Preview 2에서는 수정되었습니다. 권한 부여 토큰을 SharePoint로 보내는 코드가 web.config에서 IssuerId 요소를 찾지 않고 다른 값을 보내는 현상이 발생합니다. 이때 전송되는 항목 및 그 이유는 중요하지 않으며, 해당 도구 버전에서 이 문제를 해결하려면 항상 web.config의 ClientId 키에서 SPTrustedSecurityTokenIssuer에 대해 IssuerId 값을 사용해야 한다는 것이 중요합니다. Preview 2 비트를 다운로드하여 즉시 설치하고, ClientId를 직접 만들어 등록한 고유 GUID로 변경하십시오(아래에서 설명하는 것처럼 Register-SPAppPrincipal 사용). ClientId는 OAuth 토큰에 서명을 한 응용 프로그램을 식별하며 SharePoint UI 전체에서 사용되므로 모두 동일해서는 안 됩니다. 문제 해결 또는 감사를 수행해야 하는 경우 모든 앱이 같은 값을 사용한다면 문제가 됩니다.

다음으로는 이 오류와 관련된 한 가지 문제를 추가로 살펴보겠습니다. 문제 해결을 수행하여 이 오류가 해결되었다고 생각했는데 자체 호스팅 응용 프로그램의 SharePoint 사이트에서 콘텐츠를 검색하려고 하면 액세스 거부 오류가 표시될 수 있습니다. 이 오류의 의미는 다음과 같습니다.

  1. SharePoint 앱의 AppManifest.xml 파일에 포함된 ClientId 값이 자체 호스팅 앱의 web.config에 포함된 ClientId 값과 일치하지 않습니다. 현재 이 문제를 해결할 수 있도록 Visual Studio 도구를 개선하는 중입니다.

이제 이 오류를 추적하는 방법에 대해 알아볼까요? 해당 과정이 간단하다면 이렇게 게시물을 통해 별도로 설명을 할 필요도 없었겠죠. 개인적으로 이 문제가 발생했을 때 찾아본 유용한 데이터 원본을 소개해 드리겠습니다. 새로운 데이터가 확인되면 역시 아래 목록에 추가하도록 하겠습니다.

  1. ULS 로그 - 가장 효율적인 방법은 제공하는 ULS 로그를 열어 보는 것입니다. 물론 데이터의 양이 엄청나기는 하겠지만요. 중앙 관리->모니터링->진단 로깅 구성으로 이동합니다. 여기서 SharePoint Foundation 범주를 확장하고 앱 인증, 응용 프로그램 인증, 인증 권한 부여 및 클레임 권한 부여 항목을 선택합니다. 이러한 항목에 대해 로깅 및 추적 수준을 자세한 정보 표시로 설정하고 변경 내용을 저장한 후에 응용 프로그램을 다시 시작해 보십시오. 다양한 ULS 로그 보기 도구 중 하나를 선택하여 요청이 수신 및 처리되는 과정을 살펴볼 수 있습니다. 이 과정을 통해 앱 인증 문제를 효율적으로 파악할 수 있습니다.
  2. Fiddler - Fiddler 역시 이러한 상황에서&nbsp매우 유용합니다. 일반적으로 가장 자주 발생하는 오류는 401 권한이 없음 오류인데요(항상 기본 문제는 "토큰 발급자가 신뢰할 수 있는 발급자가 아닙니다."임). 요청의 마지막 프레임을 표시하여 Response 프레임에서 Headers 탭을 클릭하면 Bearer realm="8a96481b-6c65-4e78-b2ef-a446adb79b59",client_id="00000003-0000-0ff1-ce00-000000000000",trusted_issuers="<e9134021-0180-4b05-9e7e-0a9e5a524965@8a96481b-6c65-4e78-b2ef-a446adb79b59,00000003-0000-0ff1-ce00-000000000000@8a96481b-6c65-4e78-b2ef-a446adb79b59>" 와 같은 WWW-Authenticate 쿠키가 표시됩니다. 이 쿠키를 통해 어떤 정보를 확인할 수 있을까요? 보시다시피 ClientId 값은 e9134021-0180-4b05-9e7e-0a9e5a524965여야 하고 영역은 8a96481b-6c65-4e78-b2ef-a446adb79b59여야 합니다. ClientId 값은 쉽게 확인할 수 있습니다. 자체 호스팅 앱의 AppManifest.xml 파일과 web.config를 확인하면 됩니다. 영역이 잘못될 가능성은 거의 없지만, 다음 PowerShell을 실행하면 언제든지 영역을 확인할 수 있습니다.

$spurl ="https://foo"
$spsite = Get-SPSite $spurl
$realm = Get-SPAuthenticationRealm -ServiceContext $spsite
$realm

그러면 현재 영역이 화면에 출력됩니다. 마지막으로 한 가지 더 확인할 수 있는 사항이 있습니다. 사용 중인 ClientId에 대해 appPrincipal을 만들었는지 확인하십시오. 이 항목을 확인하는 데 사용할 수 있는 PowerShell 명령도 있으며, 위의 WWW-Authenticate 헤더를 사용하는 경우 아래와 같은 명령을 실행하면 됩니다.

Get-SPAppPrincipal -NameIdentifier <e9134021-0180-4b05-9e7e-0a9e5a524965@8a96481b-6c65-4e78-b2ef-a446adb79b59> -Site https://foo

이 명령 실행 시 오류가 발생하거나 결과가 반환되지 않으면 유효한 SPAppPrincipal이 없는 것이므로 PowerShell을 사용하여 만들어야 합니다. 아래에 SPAppPrincipal의 예가 나와 있습니다.

$clientId = "some guid you create"
$spurl ="https://foo"
$spsite = Get-SPSite $spurl
$realm = Get-SPAuthenticationRealm -ServiceContext $spsite
$fullAppIdentifier = $clientId + <'@'> + $realm
$appPrincipal = Register-SPAppPrincipal -NameIdentifier $fullAppIdentifier -Site $spsite.OpenWeb() -DisplayName "My Cool App"

이것으로 신뢰도가 높은 앱 문제 해결 팁 게시물을 마치겠습니다. 새로운 정보가 있으면 이 게시물을 업데이트하겠습니다.

 

 

 

 

이 문서는 번역된 블로그 게시물입니다. 원본 문서는 More TroubleShooting Tips for High Trust Apps on SharePoint 2013을 참조하십시오.