Silverlight 4 プラットフォーム (WS-Trust) からのユーザー認証に IdentityServer を使用しています。
ユーザーが適切な資格情報を送信すると、もちろんすべて問題なく、Silverlight アプリの RP に追加のクレームを含むトークン Cookie を作成します。
パスワードが正しくない場合、Silverlight アプリは HTTP ステータス コード 500 (SOAP 仕様で定義された SOAP 例外を送信するための標準値) を受け取ります。
Silverlight http スタックはこのようなステータス コードの結果を無視するため、クライアントに送信する前に STS にこのステータス コードを強制的に変更させようとしました。オブジェクトのインスタンスをエンドポイントの IDispatchMessageInspector インターフェイスにインストール/登録して、その場でステータス コードを変更しようとしていました (SilverlightFaultBehavior が Silverlight と連携する WCF サービスの変更を行うのと同様の方法です)。または私は何かを知りません）。
結果が OK (パスワードは OK) の場合、HTTP ステータス コードを変更でき、IDispatchMessageInspector インターフェイスを持つオブジェクトでメソッドが呼び出されますが、パスワードが正しくない場合、検査オブジェクトのメソッドはまったく呼び出されず、結果を変更できません。 (HTTP ステータス コード) したがって、結果は再び 500 になります。
IdentityServer は適切な構成で WSTrustServiceHost ホスト オブジェクトをインスタンス化するだけなので、WSTrust の処理全体が WIF のみによって行われるように見えます。
トークンが既に古くなっているとどうなるかわかりません。WIF は HTTP ステータス 500 でも例外をスローしますか? Silverlight プラットフォームで WIF によって生成された例外を読み取ることはできますか?
Silverlight 5 は WS-Trust をサポートする必要がありますが、STS サーバーが HTTP ステータス 500 を送信した場合、例外情報は再び無視されますか? Silverlight 5 でテストした人や、そのような問題の解決策を知っている人はいますか?