WCF サービスに ClaimsAuthenticaitonManager を実装して、エンタープライズ ADFS からの着信クレームを受け入れ、それらをシステムのユーザーに関連するクレームに変換します (または、AD ユーザーがシステムの一部として登録されていない場合は、承認されていない応答を生成します)。これらの変換されたクレームは、アプリケーション データベースにクエリを実行することによって生成されます。クレームを変換するためにデータベースに到達できない場合に、Authenticate メソッドから 503 ステータスを返すことによって、ネットワーク接続の問題の可能性を説明したいと思います。
第一に、これは合理的なアプローチであり、第二に、要求パイプラインのこの時点でそのようなことを行うことは可能ですか?どうすればよいでしょうか?
WCF SOAP サービスでこれを行う正しい方法は、カスタム を使用することですErrorHandler。これは、WIF を使用しているかどうかに関係なく当てはまります。
カスタム エラー ハンドラは を実装しIErrorHandlerます。これにより、サービスは例外をスローできます。例外は、WCF によって登録済みのカスタム エラー ハンドラーに渡されます。これにより、例外を検査し、適切な障害を作成できます。
あなたの場合、おそらく SQL クライアントからの例外をスローするでしょう。適切な障害を作成するだけでなく、他の関連するアクションを実行することもできます (通常、エラーをログに記録するなど)。
上の 2 つの方法は次のIErrorHandlerとおりです。
ProvideFault(Exception error, MessageVersion version, ref Message fault)これにより、スローされた例外を調べて、正しい障害を変更または作成できます。
と
HandleError(Exception error)これは、応答がクライアントに返された後に呼び出されます。ここで、エラーのログ記録などを行うことができます。
これを実装する方法の詳細については、次の URL を参照してください。
http://blogs.msdn.com/b/carlosfigueira/archive/2011/06/07/wcf-extensibility-ierrorhandler.aspx
エラー ハンドラは、上記のリンクのように、コードを使用して簡単に接続できます。少し余分な作業を行うだけで、カスタム サービス動作拡張機能を実装することで、web.config を使用して接続できます。これを行う方法の例は、次の場所にあります。
http://weblogs.asp.net/pglavich/archive/2008/10/16/wcf-ierrorhandler-and-propagating-faults.aspx
通常、SOAP サービスの場合、HTTP ステータス コード (つまり、503 ステータス) を直接返すことはありません。代わりに、エラーを a でラップして、FaultExceptionそれを返します。
WCF REST の場合、 をスローするだけWebFaultExceptionで、組み込みのエラー ハンドラーがwebHttpBindingHTTP エラーへの変換を処理します。