Partilhar via

SharePoint 2010 SAML 클레임 사용자에 대한 로그인 토큰 만료를 올바르게 설정

  • Artigo

SharePoint 2010 SAML 클레임 사용자에 대한 로그인 토큰 만료를 올바르게 설정

최근에 로그인 쿠키 만료 프로세스에 대해 자세히 살펴보면서 한 가지 문제의 소지가 있는 부분을 발견하게 되었습니다. SAML 클레임 사용자는 ADFS에서 로그인 쿠키를 받은 후부터는 시간 초과 제한을 받지 않는 것 같습니다. 즉, 이 사용자는 브라우저를 닫은 지 몇 분 후 또는 몇 시간 후에 ADFS에 다시 인증하지 않고도 브라우저를 다시 열고 곧바로 사이트에 액세스할 수 있습니다. 그뿐만 아니라 Office 2010 클라이언트 응용 프로그램도 똑같이 작동합니다. 저는 이러한 문제를 야기하는 여러 가지 요인을 알아냈으며 이 게시물에서 이 문제에 대해 설명하려고 합니다.

먼저 간단히 배경 정보를 살펴보겠습니다. SAML 클레임으로 보안이 설정된 SharePoint 사이트에 처음 액세스하면 인증 및 클레임을 받는 화면으로 리디렉션됩니다. SAML ID 공급자(또는 IP-STS)가 이 모든 작업을 하고 사용자를 다시 SharePoint로 리디렉션합니다. 다시 SharePoint로 돌아오면 SharePoint에서 FedAuth 쿠키를 만듭니다. 이것이 바로 우리가 알고 있는 사용자 인증 방법입니다. 우리 팀은 보다 원활한 사용자 경험을 제공하기 위해 FedAuth 쿠키 값을 로컬 쿠키 폴더에 기록했습니다. 해당 사이트에 대한 이후 요청 시 사이트에 대한 유효한 FedAuth 쿠키를 찾으면 해당 쿠키만 읽고 재인증 없이 사용자에게 곧바로 SharePoint 콘텐츠를 제공합니다. ADFS 1.x와 SharePoint 2007에 익숙하다면 이러한 과정이 다소 생소하게 느껴질 수 있습니다. ADFS 1.x와 SharePoint 2007에서는 모든 웹 SSO 쿠키가 세션에 기반을 두었으므로 쿠키를 디스크에 저장하지 않았기 때문입니다. 즉, 브라우저를 잠시 닫으면 쿠키가 사라지므로 브라우저를 닫았다가 열 때마다 다시 인증해야 했습니다. 하지만 SharePoint 2010에서는 그렇지 않습니다.

업데이트 1: SharePoint 2007에서처럼 SharePoint STS가 세션 쿠키를 다시 받도록 SharePoint STS를 변경하는 방법을 알아냈습니다. 이 변경을 수행하는 PowerShell은 다음과 같습니다.

$sts = Get-SPSecurityTokenServiceConfig
$sts.UseSessionCookies = $true
$sts.Update()
iisreset

이 작업을 수행하고 나면 더 이상 FedAuth 쿠키가 디스크에 기록되지 않습니다. 다시 기본 동작으로 변경하려면 앞의 단계를 되돌려야 합니다.

$sts.UseSessionCookies = $false
$sts.Update()
iisreset

그렇다면 관리 가능한 수명을 가진 SAML 토큰을 가져오려면 이 동작을 어떻게 구성해야 할까요? 다음은 이 동작을 구성할 때 고려해야 할 사항입니다.

  1. ADFS에서 신뢰 당사자별로 TokenLifetime 속성을 설정할 수 있습니다. 아쉽게도 이 속성은 신뢰 당사자를 만들 때만 설정할 수 있는 것 같습니다. 이 경우 쿠키를 한번 받으면 계속해서 사이트에 액세스할 수 있는 것이 기본 동작이므로 다소 문제가 될 수 있습니다. 액세스가 허용되는 기간이 실제로 어느 정도인지는 테스트해 보지 못했습니다.

업데이트 2: Rich Harrison이 ADFS에서 신뢰 당사자에 대한 TokenLifetime을 업데이트하는 방법을 제공했습니다.

Set-ADFSRelyingPartyTrust -TargetName "SPS 2010 ADFS" -TokenLifetime 5

여기서 "SPS 2010 ADFS"는 AD FS 2.0에서 신뢰 당사자 트러스트 엔터티의 이름입니다.

ADFS에서 신뢰 당사자를 만들 때 신뢰 당사자의 TokenLifetime을 설정하려면 PowerShell을 사용해야 합니다. 다음은 제가 신뢰 당사자를 만들 때 사용한 간단한 한 줄짜리 스크립트입니다.

Add-ADFSRelyingPartyTrust -Name "FC1" -Identifier "https://fc1/_trust/" -WsFedEndpoint "https://fc1/_trust/" -TokenLifetime 2 -SignatureAlgorithm https://www.w3.org/2000/09/xmldsig#rsa-sha1

이런 식으로 신뢰 당사자를 만든 후 다음과 같은 작업을 수동으로 수행해야 합니다.

  1. ID 목록에 영역(urn:sharepoint:foo)을 추가합니다.
  2. 모든 사용자에 대해 액세스를 허용하도록 권한 발급 규칙을 추가합니다.
  3. 전자 메일 주소와 역할을 보내도록 변환 발급 규칙을 추가합니다.

 

  1. 이제 한번 로그인해 보십시오. ADFS에 인증하면 SharePoint와 ADFS 사이를 계속해서 전환하는 무한 루프가 시작될 것입니다. Fiddler에서 트래픽을 살펴보면 ADFS에 성공적으로 인증했으며 SharePoint로 다시 돌아왔다는 것을 알 수 있습니다. SharePoint에서는 FedAuth 쿠키를 성공적으로 발급하고 그런 다음 사용자를 SharePoint 사이트의 /_trust/authenticate.aspx로 리디렉션합니다. 여기서 FedAuth 쿠키가 삭제되고 사용자가 다시 ADFS 사이트로 리디렉션됩니다. ADFS가 반복되는 이 과정을 중지하고 “동일한 클라이언트 브라우저 세션에서 지난 '12'초 동안 '6'개의 요청을 했습니다."와 같은 오류 메시지를 표시할 때까지 사용자는 기본적으로 SharePoint와 ADFS 사이를 계속해서 전환하게 됩니다. 이러한 현상은 당연한 것입니다. SharePoint STS의 기본 LogonTokenCacheExpirationWindow는 10분이기 때문입니다. 저는 신뢰 당사자를 만들 때 ADFS에서 토큰 수명을 2분으로 설정했습니다. 이 경우 인증하는 즉시 SharePoint STS에서 쿠키 수명이 LogonTokenCacheExpirationWindow 값보다 작다는 것을 인식하고 재인증을 위해 다시 ADFS로 돌아갑니다. 이런 식으로 계속 반복됩니다. 따라서 이 부분만 수정하려면 LogonTokenCacheExpirationWindow를 SAML TokenLifetime보다 작은 값으로 변경한 다음 사이트에 로그인하면 됩니다. 다음은 SharePoint에서 LogonTokenCacheExpirationWindow를 설정하는 예입니다.

$sts = Get-SPSecurityTokenServiceConfig

$sts.LogonTokenCacheExpirationWindow = (New-TimeSpan –minutes 1)

$sts.Update()

Iisreset

 

이제 설정을 제대로 구성했으므로 SAML 사용자의 로그인 만료가 올바르게 작동합니다. 2분 동안에는 브라우저 창을 닫았다가 열어도 SharePoint로 다시 리디렉션되지 않고 사이트로 돌아갈 수 있습니다.

이 문서는 번역된 블로그 게시물입니다. 원본 문서는 Setting the Login Token Expiration Correctly for SharePoint 2010 SAML Claims Users을 참조하십시오.