4

WCF 4.0 には、WCF REST スターター キットの RequestInterceptor に対するアナログ クラス/モジュール/何かがありますか?

4

3 に答える 3

7

アップデートで戻ってきました。

私はたまたまコードの単純さを重視しており、この問題をうまく解決した後は、クエリ文字列メソッドよりも好きだとは言えません。AuthZ メソッドと一緒に AuthN メソッドを呼び出す各サービス エンドポイントに単一の呼び出しをドロップすることは、一部の人が考えるよりも簡単に思えます。

とにかく、十分な意見...解決策について。解決策は、このリンクの Stackoverflow のすぐ下にありますが、私たちのコンテキストでは十分に説明されていません...そのため、ここにあるサンプル コードについて「user634119」の功績を認めます: OperationContext のヘッダー

まず、serviceBehavior を web.config ファイルに追加する必要があります。

<behaviors>
  <serviceBehaviors>
    <behavior>
      <serviceAuthenticationManager serviceAuthenticationManagerType="WCF.BasicAuthorization, WCF"></serviceAuthenticationManager>
      <serviceAuthorization impersonateCallerForAllOperations="false" principalPermissionMode="Custom" serviceAuthorizationManagerType="WCF.BasicAuthentication, WCF">
      </serviceAuthorization>
    </behavior>
  </serviceBehaviors>
</behaviors>

次に、クラスを作成します (上記の serviceBehaviors ブロックで参照されているように、BasicAuthorization と呼ばれます)。

//Authorize the call against the URI resource being requested...
public class BasicAuthorization : ServiceAuthorizationManager
{
    public override bool CheckAccess(OperationContext operationContext, 
    ref Message message)
    {
        //some code
    }
}

次に認証クラスを作成します。

// Authenticate the header signature as described in my previous post
public class BasicAuthentication : ServiceAuthenticationManager
{
    public override ReadOnlyCollection<IAuthorizationPolicy> Authenticate(
        ReadOnlyCollection<IAuthorizationPolicy> authPolicy, Uri listenUri, 
        ref Message message)
    {
        //some code
    }
}

Authenticate メソッドでは、HttpRequestMessageProperty を使用してリクエスト ヘッダーの詳細を取得し、最初の返信で説明したのと同じ 3 つの手順を実行します。

于 2011-06-29T14:27:04.017 に答える
4

Eduardo、あなたは尋ねました：@carlosfigueira：認証サブシステムを実装するためにそれを使用できますか？

私は同じ問題に取り組んでおり、少なくとも1つの解決策（以下で説明）と、今後の承認ヘッダーベースの解決策（「傍受」を考えているものだと思います）があります。

WCF 4 REST WebHttpプログラミングモデルベースのエンドポイントを保護する最も簡単な方法は、次のとおりです。

  1. 共有秘密キーとAPIキーを各クライアントに発行して、資格情報として使用します。APIキーは実際にはユーザー名と同じです。
  2. すべてのエンドポイントをSSL経由で実行して、チャネル/メッセージ/データのセキュリティを常に確保します
  3. クライアントに共有シークレットを使用して、タイムスタンプとそのAPIキーを含むHMAC-SHA1（または同等の）ハッシュ署名文字列を生成するように要求します。
  4. すべてのリクエストで、これら3つすべてをクエリ文字列パラメータとして渡すようにクライアントに要求します。
    • サイン
    • タイムスタンプ
    • APIキー
    • 例：https ： //127.0.0.1/RestEndpoint？Sig = {sigString}＆ApiKey = {apiKey}＆TimeStamp = {timeStamp}＆ここにある他のすべてのパラメーター...
  5. サービス側では、3つの文字列すべてを取得する認証メソッドを実装してから、次のようにします。
    • APIキーを検索し、DBまたは他の場所にあるクライアントの共有シークレットを返します。
    • タイムスタンプをDateTime.Nowと比較して、リプレイ攻撃をかわすためにリクエストが15分以内であることを確認します。
    • これらの3つの文字列を使用して、署名文字列を再作成し、クライアントから渡された文字列と比較します。
    • それらが一致する場合、リクエスターは本物です。

現在、これを行うためのより良い方法は、HTTP認証リクエストヘッダーを使用してこれらの3つの文字列を保存し、グローバルインターセプター風のプロセスにすべてのリクエストを監視させることです。これにより、認証ブロックなしでエンドポイントが公開される可能性を防ぐことができます（少なくとも、おそらくその可能性は低くなります）。

クエリ文字列を使用してこのすべての情報を伝達する際の問題は、クエリ文字列の最大長が2k（クライアント/ブラウザによって異なります）であり、デバッグ時にクエリ文字列が非常に読みにくくなることです...しかし、それに慣れてください。

これを行うためのより洗練された方法は、クライアントがこれら3つの認証文字列をセキュリティトークンサービスエンドポイントに渡すことを要求するSTSモデルであると考える人もいます。応答メッセージは、クライアントが3つの文字列の代わりに各呼び出しで渡すセッショントークンを返します。確かに、クライアントの場合、呼び出しごとにHMACハッシュ署名を生成する必要はありませんが、サーバー側はトークンを認証する必要があり、セッションの概念により、クリーンなRESTfulステートレス動作が損なわれます。

クエリ文字列と認証ヘッダーの両方の方法論を実装するコードブロックを投稿するために最善を尽くします。

于 2011-06-23T13:29:09.740 に答える
3

1-1 をマップするものはありませんが、WCF コアの IDispatchMessageInspector を使用して、RequestInspector が行うほとんどのシナリオを実装できます。http://blogs.msdn.com/b/carlosfigueira/archive/2011/04/19/wcf-extensibility-message-inspectors.aspxの投稿には、メッセージ インスペクターに関する詳細情報が含まれています。

于 2011-05-16T22:15:09.917 に答える