しばらく前にカスタムWCFバインディングを作成して、負荷分散されたファームがIIS経由でサービスをホストできるようにしました。カスタムバインディングの理由は、各サーバーにSSLがないが、ユーザー名+パスワードのクライアントクレデンシャルを受け入れる機能が必要だったためです。このファームの前のプロキシにはSSLがあるため、トラフィックはファイアウォールの外側で暗号化されます。このカスタムバインディングは正常に機能しますが、現在、マシンからのトラフィックをローカルで監視する必要があり、SSLを使用せずにこれを実行したいと考えています。
問題はこれです-セキュリティモードを「TransportWithMessageCredential」に設定した場合、.netクライアントでSSLが必要です。そうでない場合は、「無効なスキーム、予期されるhttps」という楽しいエラーが発生します。
クライアントがSSLが欠落していることを「無視」するカスタムを作成しても、SOAPヘッダーを介してユーザー名とパスワードを渡せるようにすることは可能ですか？
うん、私はこれについてしばらく前に「方法：WCFを使用したSSLパススルー--または--プレーンHTTPを介したTransportWithMessageCredential」というブログ投稿を書きました。
HttpTransportBindingElement要するに、セキュリティの提供について「嘘をつく」独自のサブクラスを作成する必要があるということです。
.net 3.5 sp1には、AllowInsecureTransportプロパティをSecurityBindingElementに追加する修正プログラムがあります。これは、.net 4beta2にも含まれます。
カスタムバインディングでは、security mode = "Message"を使用しただけでもエラーが発生すると思いますか？カスタムバインディングは実際には必要ありませんでした。なぜなら（私が間違っていなければ）セキュリティmode = "Message"（SSLを必要としない）でwsHttpBindingを使用できるからです。
もう1つの方法は、SSL証明書を自分で生成し、IISにインストールして、呼び出し元のコードにすべての証明書ポリシーを信頼することですが、これは一般的に嫌われています（安全でないチャネルを介してユーザー名とパスワードを送信する場合と同様）。
3番目のオプションは、ユーザー名とパスワード（またはある種のトークン）をパラメーターとして受け入れるようにコントラクトの操作を変更するか、データコントラクトを変更して、既に送信しているオブジェクトと一緒に情報を送信できるようにすることです。