Partager via

正確設定 SharePoint 2010 SAML 宣告使用者的登入 Token 期限

  • Article

正確設定 SharePoint 2010 SAML 宣告使用者的登入 Token 期限

最近，我在學習登入 Cookie 到期的過程時，發現一個大問題。 對於 SAML 宣告使用者，一旦他們從 ADFS 取得登入 Cookie 後，便似乎永遠不會逾時。 也就是說，他們關閉瀏覽器然後在數分鐘甚至數小時後重新開啟瀏覽器，依然可以直接瀏覽網站而不必向 ADFS 重新進行驗證。 而且，Office 2010 用戶端應用程式也是以相同方式運作。 我最後想到一些引發上述情況的原因並記述於下。

首先是一個非常簡短的背景說明。 當您第一次瀏覽至使用 SAML 宣告保護的 SharePoint 網站時，該網站會重新引導您取得認證以及取得宣告。 您的 SAML 身分識別提供者 (又稱為 IP-STS) 會完成以上所有事項並將您重新引導回 SharePoint。 當您回到 SharePoint 時，我們會建立一個 FedAuth Cookie，並藉此知道您已經通過驗證。 為了讓使用者體驗能夠更連續流暢，我們將 FedAuth Cookie 值寫入至本機 Cookie 資料夾中。 在對該網站發出的後續要求中，如果我們找到該網站的有效 FedAuth Cookie，我們將僅讀取 Cookie 並讓您進入 SharePoint 內容而不必重新驗證。 習慣使用 ADFS 1.x 及 SharePoint 2007 的使用者可能會對此感到驚訝，因為對他們而言，所有網頁 SSO Cookie 都是以工作階段為基礎，所以我們未將它們儲存到磁碟中。 例如，當您關閉您的瀏覽器時 Cookie 便消失，因此每次關閉然後再開啟瀏覽器時，都必須重新進行驗證。 這種情況在 SharePoint 2010 已不復見。

更新 #1：我們發現可以對 SharePoint STS 進行變更，讓它可以再度和工作階段 Cookie 一起作業，就如同在 SharePoint 2007 中那樣。下列 PowerShell 可以進行此項變更：

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

執行此作業後，您會發現將不再有 FedAuth Cookie 寫入至磁碟中。若要變更回預設的行為，您只要以相反順序執行步驟即可：

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

那麼，我們要如何設定此行為才能夠取得具有良好且容易管理週期的 SAML Token？ 以下是一些您需要考慮的事項：

  1. TokenLifetime 屬性可以針對 ADFS 中的每個信賴憑證者進行設定。但是，該屬性只能在您建立信賴憑證者時才能夠進行設定。這樣會有一點問題，因為它意謂預設行為是一旦您取得 Cookie，該 Cookie 會跟著您很一段長很長時間 (我沒有實際測試過到底有多長)。

更新 #2：Rich Harrison 曾經提供下列實用的程式碼，用來更新 ADFS 中信賴憑證者的 TokenLifetime：

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

其中 "SPS 2010 ADFS" 是 AD FS 2.0 中 Relying Party Trust 實體的名稱。

因此，如果您想要在建立期間設定 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. 將領域新增至識別碼清單 (亦即 urn:sharepoint:foo)
  2. 新增發行授權規則以容許存取所有使用者
  3. 新增發行轉換規則以傳送電子郵件地址及角色

 

  1. 如果您現在嘗試登入，您可能會發現，在向 ADFS 進行驗證後，便陷入不停地在 SharePoint 和 ADFS 之間來回的無止境迴路中。如果您檢查 Fiddler 中的流量將會發現您一直處於下列狀態，您向 ADFS 進行驗證成功，您回到 SharePoint，接著 SharePoint 成功發出 FedAuth Cookie，FedAuth Cookie 將您重新導向至 SharePoint 網站的 /_trust/authenticate.aspx，SharePoint 網站清除 FedAuth Cookie 並將您重新導向回 ADFS 網站。您就像乒乓球那樣不停地來回，直到 ADFS 加以停止同時提供錯誤訊息以及數行資訊為止：「同一個用戶端瀏覽器工作階段在過去 ‘12’ 秒內已經發出 ‘6’ 個要求。」實際上，它是有意義的資訊。因為 SharePoint STS 的預設 LogonTokenCacheExpirationWindow 為 10 分鐘。在本範例中，我在建立信賴憑證者時將 ADFS 中的 Token 週期設成 2 分鐘，因此，一旦它通過驗證便知道 Cookie 的有效期間短於 LogonTokenCacheExpirationWindow 值，於是又回到 ADFS 以再度進行驗證。就這樣不停地來來回回。如果要修正這個問題，您只要將 LogonTokenCacheExpirationWindow 變更為小於 SAML TokenLifetime 即可，如此便可以登入網站了。 以下是在 SharePoint 中設定 LogonTokenCacheExpirationWindow 的範例：

$sts = Get-SPSecurityTokenServiceConfig

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

$sts.Update()

Iisreset

 

現在，您只要正確設定這些設定值，SAML 使用者的登入期限便可以正確運作。在 2 分鐘內，我可以開啟與關閉瀏覽器視窗並繼續回到網站而不會被重新導向回 SharePoint。但在該時間之後，則會正確無誤地要求我重新向 ADFS 進行驗證。

這是翻譯後的部落格文章。英文原文請參閱 Setting the Login Token Expiration Correctly for SharePoint 2010 SAML Claims Users