12台のマシンのセットでホストされているWCFサービスがあります。これらのマシンへのゲートウェイであるロードバランサーがあります。
これで、サイトはSSLとしてセットアップされました。ユーザーの場合と同様に、httpsのURLを使用してアクセスします。サイトのアドレスを指定するURLはhttpsですが、どのサーバーにもhttpsバインディングがなく、SSLを要求するように設定されていません。これは、ロードバランサーがhttpsを処理し、バランサーからサーバーへの接続が暗号化されていない(これはファイアウォールの背後で行われるため、それほど重要ではない)と信じています。
SilverlightクライアントがWCFサービスにアクセスしようとすると、「見つかりません」エラーが発生するという問題があります。私は開発マシンと共にテストサイトをセットアップし、web.configのバインディングとエンドポイントがクライアントで機能することを確認しました。このエラーが発生するのは、実稼働環境の場合のようです。
次のweb.configに何か問題がありますか? httpsを別の方法で処理する方法を設定する必要がありますか?
エンドポイントとバインディングを使用してすべてのプログラムによるソリューションを試してきたので、現在、これで途方に暮れています。私が見つけたソリューションはどれも、私たちが扱っている方法でロードバランサーを扱っていません。
Web.configサービスモデル情報:
<system.serviceModel>
<behaviors>
<serviceBehaviors>
<behavior name="TradePMR.OMS.Framework.Services.CRM.CRMServiceBehavior">
<serviceMetadata httpsGetEnabled="true" />
<serviceDebug includeExceptionDetailInFaults="false" />
</behavior>
<behavior name="TradePMR.OMS.Framework.Services.AccountAggregation.AccountAggregationBehavior">
<serviceMetadata httpsGetEnabled="true" />
<serviceDebug includeExceptionDetailInFaults="false" />
</behavior>
</serviceBehaviors>
</behaviors>
<bindings>
<customBinding>
<binding name="SecureCRMCustomBinding">
<binaryMessageEncoding />
<httpsTransport />
</binding>
<binding name="SecureAACustomBinding">
<binaryMessageEncoding />
<httpsTransport />
</binding>
</customBinding>
<mexHttpsBinding>
<binding name="SecureMex" />
</mexHttpsBinding>
</bindings>
<serviceHostingEnvironment aspNetCompatibilityEnabled="true" />
<!--Defines the services to be used in the application-->
<services>
<service behaviorConfiguration="TradePMR.OMS.Framework.Services.CRM.CRMServiceBehavior"
name="TradePMR.OMS.Framework.Services.CRM.CRMService">
<endpoint address="" binding="customBinding" bindingConfiguration="SecureCRMCustomBinding"
contract="TradePMR.OMS.Framework.Services.CRM.CRMService" name="SecureCRMEndpoint" />
<!--This is required in order to be able to use the "Update Service Reference" in the Silverlight application-->
<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
</service>
<service behaviorConfiguration="TradePMR.OMS.Framework.Services.AccountAggregation.AccountAggregationBehavior"
name="TradePMR.OMS.Framework.Services.AccountAggregation.AccountAggregation">
<endpoint address="" binding="customBinding" bindingConfiguration="SecureAACustomBinding"
contract="TradePMR.OMS.Framework.Services.AccountAggregation.AccountAggregation" name="SecureAAEndpoint" />
<!--This is required in order to be able to use the "Update Service Reference" in the Silverlight application-->
<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
</service>
</services>
</system.serviceModel>
</configuration>
ServiceReferences.ClientConfigは次のようになります。
<configuration>
<system.serviceModel>
<bindings>
<customBinding>
<binding name="StandardAAEndpoint">
<binaryMessageEncoding />
<httpTransport maxReceivedMessageSize="2147483647" maxBufferSize="2147483647" />
</binding>
<binding name="SecureAAEndpoint">
<binaryMessageEncoding />
<httpsTransport maxReceivedMessageSize="2147483647" maxBufferSize="2147483647" />
</binding>
<binding name="StandardCRMEndpoint">
<binaryMessageEncoding />
<httpTransport maxReceivedMessageSize="2147483647" maxBufferSize="2147483647" />
</binding>
<binding name="SecureCRMEndpoint">
<binaryMessageEncoding />
<httpsTransport maxReceivedMessageSize="2147483647" maxBufferSize="2147483647" />
</binding>
</customBinding>
</bindings>
<client>
<endpoint address="https://Service2.svc"
binding="customBinding" bindingConfiguration="SecureAAEndpoint"
contract="AccountAggregationService.AccountAggregation" name="SecureAAEndpoint" />
<endpoint address="https://Service1.svc"
binding="customBinding" bindingConfiguration="SecureCRMEndpoint"
contract="CRMService.CRMService" name="SecureCRMEndpoint" />
</client>
</system.serviceModel>
</configuration>
(アドレスは、開発者のマシンまたは本番サーバーを指すように動的に構築されるため、重要ではありません)
アプリが本番稼働中であることを知っているが、ここで回答が見つからないという何人かの人々から尋ねられたので、私はこれに答えています。
上記のシナリオではこれを解決できませんでした。クライアントからロードバランサーへのHTTPSは問題ありません。問題は、ロードバランサーがその接続を取得し、暗号化されていない形式でWebサーバーを指す場合です。これにより、WCFプロトコルが壊れているようです。クライアントはHTTPS通信を送信していますが、サーバーは暗号化されていない通信を取得しています。
すべてのSSL通信を通過させることで問題を解決しました。
最善の「解決策」は、WCFサービスがHTTP送信方法を使用していないかどうかを確認し、これらの通信を変更せずに通過させるようにロードバランサーを設定することです。ロードバランサーは、Webサイトから生成された通常のHTTPSトラフィックに対して標準の操作手順を実行できます。
私たちのアプリケーションシナリオではWCFサービスがASP.NETと互換性がある必要があるため、これはテストしていません。
うまくいけば、他の誰かがさらに詳しい情報を使ってこれについて詳しく説明できます。
これは非常に古い質問だと思いますが、最近この問題に遭遇し、次の手順で解決しました。
https://blog.tonysneed.com/2012/06/18/building-scalable-and-secure-wcf-services/
ここに記載されている他の応答の1つとして、HttpTransportElementとそのBindingElementTypeをサブクラス化する必要があるため、接続が安全であると「WCFをだます」ようにISecurityCapabilitiesを返します。その後、このトランスポート要素をcustomBindingで使用できます。
私たちは同じ問題に遭遇し、Microsoftの開発者によって提供されたソリューションに取り組みました。その解決策は、ロードバランサーからサーバーへのSSLの要件をオーバーライドするカスタムHttpTransportを作成することです。