1

WCFHttpバインディングを選択するのに役立つ次の基準があります。私のサービスは次のことを行う必要があります。

  1. イントラネットサポートのなりすまし/委任で展開される
  2. 未知のテクノロジーを使用してクライアントと相互運用可能であること
  3. クライアントとサーバー間のトランザクションフローをサポートする
  4. 可能であれば証明書を使用しない（「トランスポート」セキュリティモードを破棄する）

basicHttpBindingとwsHttpBindingのどちらかを決定する必要があります。

ここに、3つのポイントに関するいくつかのメモと質問があります。

  1. 「メッセージ」セキュリティモードと「Windows」clientCredentialTypeを使用したwsHttpBindingを使用すると、委任を実行できると思います。
  2. ポイント1で選択したセキュリティ構成は、委任を実装するために相互運用性をサポートするのが複雑になるようですが、私は正しいですか？WS- *標準（wsHttpBinding）は間違いなく相互運用可能ですが、「メッセージ」セキュリティと「Windows」クレデンシャルと組み合わせると、WS- *互換クライアントでサービスを呼び出すことができますか？
  3. wsHttpBindingは、トランザクションフローをサポートするためにここに行く方法のようだと思いますか？
  4. 私たちの状況では、証明書なしで「メッセージ」セキュリティを使用する方が簡単に思えますか？

前もって感謝します

4

1 に答える 1

1

トランザクション フローをサポートする場合は、wsHttpBinding を使用する必要があります。basicHttpBinding はまさに、基本的なXML Web サービスです。MS は、WS-I Basic Profile v1.1 をサポートしていると主張していますが、そのバインディングで MTOM を使用できるため、v1.2 に似ています。

どちらも相互運用性が高く、wsHttpBinding は多数の WS-* 標準の実装です。サポートされていないのは、古い SOAP のみのクライアントです。これには、.NET 2.0 スタイルの Web サービス リファレンスや、さまざまな形式の Java ベースの SOAP プロキシを使用するすべての人が含まれます。

セキュリティを使用すると、wsHttpBinding が表示されることのメリットをより多く得ることができます。basicHttpBinding は Windows 資格情報を処理できませんが、ご指摘のとおり、相互運用性が制限されます。Windows 資格情報を使用して Windows 以外のクライアントを認証するのは非常に難しいと思われますが、ご指摘のとおり、それが偽装を行う唯一の方法です。Windows で実行されている非 WCF クライアントの場合、クライアントはログインしているユーザーの認証トークンに引き続きアクセスできるため、もっとうまくいく可能性があります。

セキュリティ モードが非 WCF クライアントに与える影響を確認する最善の方法は、サービスのバインディングを公開し、wsimportそれらに対して Java ツールを実行することです。WSDL から機能するプロキシを生成できる場合は、任意のクライアントからサービスを使用できるはずです。

于 2012-03-20T20:28:48.227 に答える