0

現在、WCF SOAP サービスを構築しています。もちろん、サービスで何らかの認証が必要になります。

この非常に役立つブログ投稿を読むと、組み込みの認証ポイントを使用するには、エンドポイントでwsHttpバインディングを使用する必要があることがわかります。

これは、ユーザーが WCF によって公開されたメタデータ (基本的には、C# で記述された Web サービス参照を含むクライアントのようなもの) に基づいてクライアントを介してサービスと通信することを保証できれば問題ありません。ただし、これを保証することはできません。

ユーザーが生の (暗号化されていない) XML だけで通信できるようにする必要があります。

だから、質問：

  1. wsHttpバインディングは未加工の XML 入力を引き続き許可しますか?
  2. そうでない場合、私はより賢明でしょうか
    • 2 つの別個の認証ポイントを実装しますか? 1 つは raw XML 入力用、もう 1 つは暗号化された入力用 または
    • wsHttp生の XML 入力と共有されるメソッド内検証にフォールバックする入力を許可しますか?
  3. ユーザーが未加工の XML 要求内で資格情報を渡すことを許可するのは賢明ですか?

編集：元の投稿で何かを誤解したり誤解したりしたように聞こえるので、ここで「生のXML」の意味を明確にします。

生の XML とは、SOAP パケットと付随する HTTP ヘッダーだけを意味します。soapUI や Fiddler から送信する場合もあります。私が理解しているように、バインディングを介したメッセージはwsHttp、クライアントが WSDL から (たとえば C# で) 生成されるときに暗号化されます。

そうでない場合、クライアントを介してリクエストを実行するのと同じ種類の資格情報を生の XML (より適切な用語が必要なため) リクエストに添付するにはどうすればよいでしょうか? それらは HTTP ヘッダーとして添付されていますか? SOAPエンベロープのXML要素?

4

1 に答える 1

0

wsHttp は SOAP バインディングです。つまり、コンテンツが SOAP エンベロープでラップされ、メッセージに関連するヘッダーやさまざまな WS-* 仕様が使用されている可能性があります。

生の XML をサポートする必要があるのはなぜですか? 今日、ほとんどのプラットフォームは SOAP メッセージングをサポートしており、SOAP の全体的な考え方は、異なるプラットフォーム間の相互運用性を提供することです。ほとんどのプラットフォームでは、SOAP クライアントを生の XML クライアントと同じくらい簡単に開発できます。ほとんどの場合、WSDL を取得してクライアントを生成するだけです。認証やメッセージの暗号化などの標準的な機能を使用したい場合は、これがはるかに優れた方法です。

現在、未加工の XML に対して相互運用可能な認証を行うためのフックはありません。これを行うには独自のメカニズムを考え出す必要があり、それは非標準になります。これは、Web サービスのユーザーにとって、SOAP を使用した場合よりも多くの開発作業が必要になることを意味します。

于 2011-07-29T01:17:29.163 に答える