SharePoint 2010 SAML クレーム ユーザーのログイン トークンの有効期間を適切に設定する

SharePoint 2010 SAML クレーム ユーザーのログイン トークンの有効期間を適切に設定する

ここのところ、ログイン Cookie の有効期限切れのプロセスを理解しようと取り組んでいたのですが、かなり大きい問題と思えることを見つけました。 SAML クレーム ユーザーは、いったんログイン Cookie を ADFS から取得すると、絶対にタイムアウトしないようなのです。 つまり、ブラウザーを閉じてから数分後または数時間後でも、ブラウザーを再び開いて、ADFS に対する再認証を行わずにサイトに直接移動できるわけです。 Office 2010 クライアント アプリケーションも同じように動作しました。 この問題を引き起こしている複数の原因がようやくわかったので、ここで説明します。

まず、背景をざっと簡単に説明しましょう。 SAML クレームで保護されている SharePoint サイトに初めて移動すると、ユーザーはリダイレクト先で認証されて、クレームを取得します。 この処理はすべて SAML の ID プロバイダー (IP-STS とも呼ばれます) が実行し、ユーザーは SharePoint に再びリダイレクトされます。 ユーザーが SharePoint に戻ると、FedAuth Cookie が作成されます。これで、そのユーザーが認証済みであることがわかるというしくみです。 ユーザー側の処理を速やかにするため、FedAuth Cookie の値はローカルの Cookie フォルダーに書き込まれます。 これ以降、そのサイトの要求時にサイトの有効な FedAuth Cookie が見つかると、その Cookie が単に読み取られるだけで、ユーザーは再認証を行わずに SharePoint コンテンツに直ちに移動できます。 このことは、ADFS 1.x と SharePoint 2007 に慣れている人にとっては少し衝撃でしょう。というのも、Web SSO Cookie はすべてセッション ベースだったのでディスクに保存されなかったからです。 たとえば、ブラウザーを閉じると Cookie は消失したので、ブラウザーを閉じて開くたびに再認証が必要でした。 これは SharePoint 2010 には当てはまりません。

更新方法 #1: SharePoint STS に変更を加えれば、SharePoint 2007 の場合と同じように、セッション Cookie を再び使用できるようになります。次の PowerShell を指定すると、変更が加えられます。

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

これを行うと、ディスクに書き込まれる FedAuth Cookie はなくなります。既定の動作に戻すには、手順を逆転させるだけです。

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

それでは、管理しやすい SAML トークンを取得するようにこの動作を構成するにはどうしたらよいでしょうか。 次にこの点について説明します。

1. TokenLifetime プロパティは、証明書利用者ごとに ADFS に設定できます。残念なことに、このプロパティを設定できるのは証明書利用者の作成時のみのようです。これは少し問題です。つまり、Cookie をいったん取得すると有効時間が延々と続くことが既定の動作だからです (有効である時間がどれくらいかを実際にテストして調べたことはありません)。

更新方法 #2: うれしいことに Rich Harrison 氏が ADFS の証明書利用者の TokenLifetime を更新するための次のナゲットを提供してくれました。

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

ここで、"SPS 2010 ADFS" は ADFS 2.0 内の証明書利用者信頼エンティティの名前です。

このように、作成時に ADFS に証明書利用者の TokenLifetime を設定するには、PowerShell を使用して行う必要があります。以下は、私が証明書利用者の作成に使用した簡単な 1 行スクリプトです。

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. 電子メール アドレスとロールを介して送信するための案件変換規則を追加します。

2. 試しにログインしてみると、ADFS への認証後に SharePoint と ADFS の間を往復するエンドレス ループに巻き込まれることに気付くことでしょう。Fiddler でトラフィックを調べると、ADFS に対する認証に成功し、SharePoint に戻って FedAuth Cookie を正しく取得しているのに、SharePoint サイト上の /_trust/authenticate.aspx にリダイレクトされ、そこで FedAuth Cookie が消去されて、ADFS サイトに再びリダイレクトされていることがわかります。要するに、ADFS によって停止されるまでリダイレクトは繰り返され、エラー メッセージと “The same client browser session has made ‘6’ requests in the last ‘12’ seconds.” という説明が表示されます。実は、これは無理もないことがわかります。SharePoint STS の既定の LogonTokenCacheExpirationWindow が 10 分だからです。この場合、私は証明書利用者を作成したときに、ADFS 内のトークンの有効時間を 2 分に設定したので、認証されると直ちに Cookie の有効時間が LogonTokenCacheExpirationWindow 値より短いことが認識され、再認証のために ADFS に戻されました。このためにリダイレクトが繰り返されたわけです。したがって、これを修正するには、LogonTokenCacheExpirationWindow を SAML TokenLifetime より小さい値に変更するだけで済みます。これでサイトにログインできるようになります。 以下は、SharePoint での LogonTokenCacheExpirationWindow の設定例です。

$sts = Get-SPSecurityTokenServiceConfig

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

$sts.Update()

Iisreset

このように、以上の設定を正しく行えば、SAML ユーザーのログイン有効時間は正しく機能するようになります。これで、ブラウザーのウィンドウを開いて閉じてから 2 分間は SharePoint に再びリダイレクトされることなく、引き続きサイトにも戻ることができます。ただし 2 分を超えると、ADFS に対する再認証が正常に実行されます。

これはローカライズされたブログ投稿です。原文の記事は、「Setting the Login Token Expiration Correctly for SharePoint 2010 SAML Claims Users」をご覧ください。