RSS 2.0
ADFS2.0 を使用するクレーム対応アプリケーションを作成する手順を次の記事で紹介しました。最後に動作確認を行いましょう。認証後アプリケーションページにセキュリティートークンがポストされる際、既定の RequestValidator によりページ検証のエラーが発生するので Webアプリケーション側に一部修正を行います。
1. 動作確認実施
Webアプリケーションのページを参照してみましょう。Windows 認証用のポップアップ画面が表示されます。ユーザー名とパスワードを入力し、 OK ボタンをクリックします。
画面が表示される想定なのですが、下記メッセージのエラー画面が表示されます。
危険な可能性のある Request.Form 値がクライアント
(wresult="<t:RequestSecurityTo...") から検出されました。
これは ADFS2.0がユーザーを認証後、Webアプリケーションにセキュリティトークンをポストされます。セキュリティートークン(SAMLトークン)が設定された フォームデータの値が XMLになっています。このため、ASP.NET既定のリクエストヴァリデーターにより不正なリクエストとみなされたためエラーが発生します。
ここで作成した SampleRequestValidatorクラスは、WIF SDK をインストールしたサンプルフォルダにある %SystemDrive%\Program Files (x86)\Windows Identity Foundation SDK\v4.0\Samples で使用されているクラスと同じものです。
また、.NET 3.5 用のWIF SDK をインストールしたときに インストールされるWIF用 のWebサイトテンプレートからWebサイトを作成したときに自動的に作成される RequestValidator と同じものです。
using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
namespace ClaimWeb01
{
using System.Web.Util;
using Microsoft.IdentityModel.Protocols.WSFederation;
public class SampleRequestValidator : RequestValidator
{
protected override bool IsValidRequestString(HttpContext context, string value, RequestValidationSource requestValidationSource, string collectionKey, out int validationFailureIndex)
{
validationFailureIndex = 0;
if (requestValidationSource == RequestValidationSource.Form && collectionKey.Equals(WSFederationConstants.Parameters.Result, StringComparison.Ordinal))
{
SignInResponseMessage message = WSFederationMessage.CreateFromFormPost(context.Request) as SignInResponseMessage;
if (message != null)
{
return true;
}
}
return base.IsValidRequestString(context, value, requestValidationSource, collectionKey, out validationFailureIndex);
}
}
}
今回作成した SampleRequestValidator を使用するように クレーム認証を使用するWebアプリケーションのweb.config を修正します。system.web 要素に httpRuntime 要素を追加します。下記コードのように requestValidationType に 新しく作成した SampleREquestValidator クラスを指定します。
<system.web> <!-- SignIn Response 時のValidation Error 対策 --> <httpRuntime requestValidationType="ClaimWeb01.SampleRequestValidator" /> … </system.web>
準備は整ったはずです。再度 Webアプリケーションのページを表示しましょう。アプリケーションプールのユーザーが ApplicationPoolIdentity の場合下のようなエラーが発生すると思います。
エラーメッセージに データ保護操作に失敗しました。スレッドが偽装されている場合など、現在のスレッドのユーザーコンテキストに対してユーザープロファイルが読み込まれていないことが原因であった可能性があります.
カスタムWebアプリケーションで使用しているアプリケーションプールの詳細設定を開きます。プロセスモデルの ユーザー プロファイルの読み込み を True にして OK ボタンをクリックします。
再度 Web アプリケーションを起動すると Windows 統合認証用のポップアップ画面が表示され、アカウントとパスワードを入力するとWindowsのアカウント, UPN, 所属するセキュリティグループの一覧が表示されます。
証明書にアクセスできない旨のエラーが発生した場合な 証明書スナップインから https に使用する証明書にアクセスできることを確認してください。
フォーム認証が行われると、下図のようにフォームベースのサインイン画面が表示されるようになります。
おまけですが、今回 Dynamics CRM 2011 用の IFD 展開を 実装するときに使用したのと同じ ADFS2.0 を使用しています。なので、フォーム認証画面でサインイン後 Dynamics CRM 2011 の画面にアクセスすると シングルサインオンを行えます。(カスタムWebnアプリの認証方法が Windows 認証のままだと、フォーム認証画面にリダイレクトされます。これは同じ認証方法で認証されていないための仕様通りの動作となります。)
説明は以上です。
いろいろ手順が多いですが手順を踏めば問題なく作成できると思います。
今回は、いきなり ADFS2.0 を STS として使用しVisual Studio でデバッグもできるようにする手順を紹介しました。一般的なWIFを使用したクレーム認証を行うWebアプリの開発では.NET 3.5 用の WIF SDK インストール時に作成されるWebサイトテンプレートからプロジェクトを作成したさいに 作成される ローカルのカスタムSTSで動作確認したり、 FedUtil.exe (Add STS reference 等から起動) ツールのウィザードの途中でカスタムSTSサイトを作成し、そのカスタムSTSをカスタマイズして動作確認したアプリケーションを 検証環境用の IIS にデプロイするという流れになると思います。IISデプロイ後、再度 FedUtil.exe を使用して web.config を ステージングやプロダクション環境にセットアップされた ADFS2.0 (STS) を使用するように 修正することになります。