Wie wird die HTTPS-Bindung und Endpunktkonfiguration des WCF-Dienstes in IIS mit Load Balancer ausgeführt?

Wir haben einen WCF-Dienst, der auf 12 Computern gehostet wird. Es gibt einen Load Balancer, der ein Gateway zu diesen Computern darstellt.

Jetzt ist die Site als SSL eingerichtet. wie bei einem Benutzer, der über eine URL mit https darauf zugreift. Ich weiß so viel, die URL, die die Site adressiert, ist https, aber keiner der Server hat eine https-Bindung oder ist so eingerichtet, dass SSL erforderlich ist. Dies lässt mich glauben, dass der Load Balancer das https verwaltet und die Verbindung vom Balancer zu den Servern unverschlüsselt ist (dies findet hinter der Firewall statt, also kein Problem).

Das Problem besteht darin, dass ein Silverlight-Client beim Versuch, auf einen WCF-Dienst zuzugreifen, den Fehler "Nicht gefunden" erhält. Ich habe zusammen mit unseren Entwicklercomputern eine Testsite eingerichtet und sichergestellt, dass die Bindungen und Endpunkte in der web.config mit dem Client zusammenarbeiten. In der Produktionsumgebung scheint es so zu sein, dass wir diesen Fehler erhalten.

Stimmt etwas mit der folgenden web.config nicht? Sollten wir festlegen, wie https anders behandelt wird?

Diesbezüglich sind wir derzeit ratlos, da ich jede programmatische Lösung mit Endpunkten und Bindungen ausprobiert habe. Keine der Lösungen, die ich gefunden habe, befasst sich mit einem Load Balancer so, wie wir es tun.

Informationen zum Web.config-Servicemodell:

  <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>

Die ServiceReferences.ClientConfig sieht folgendermaßen aus:

<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>

(Die Adressen sind ohne Bedeutung, da diese dynamisch so erstellt werden, dass sie auf die Maschine eines Entwicklers oder auf den Produktionsserver verweisen.)

Ich beantworte dies, da ich von einigen Leuten gefragt wurde, die wissen, dass die App in Produktion ist, aber hier keine Antwort gesehen haben.

Wir konnten dies im obigen Szenario nicht lösen. HTTPS vom Client zum Load Balancer ist in Ordnung. Das Problem besteht darin, dass der Load Balancer diese Verbindung auf einen Webserver in einem unverschlüsselten Format verweist. Dies scheint das WCF-Protokoll zu brechen. Der Client sendet HTTPS-Kommunikation, der Server erhält jedoch eine unverschlüsselte Kommunikation.

Wir haben das Problem gelöst, indem wir die gesamte SSL-Kommunikation durchlaufen haben.

Die beste "Lösung" wäre zu sehen, ob Ihr WCF-Dienst nicht die HTTP-Übertragungsmethode verwendet, und Ihren Load Balancer so einzurichten, dass diese Kommunikation unverändert weitergeleitet wird. Der Load Balancer kann dann seine Standardarbeitsanweisung für regulären HTTPS-Verkehr ausführen, der von der Website generiert wird.

Ich habe dies nicht getestet, da für unser Anwendungsszenario der WCF-Dienst mit ASP.NET kompatibel sein muss.

Hoffentlich kann jemand anderes dies mit weiteren Informationen erläutern.

Mir ist klar, dass dies eine sehr alte Frage ist, aber ich bin kürzlich auf dieses Problem gestoßen und habe es mithilfe der hier angegebenen Schritte gelöst:

https://blog.tonysneed.com/2012/06/18/building-scalable-and-secure-wcf-services/

Wie eine der anderen Antworten hier besagt, ist die Unterklasse HttpTransportElement und sein BindingElementType erforderlich, damit ISecurityCapabilities zurückgegeben werden, die WCF "täuschen", dass die Verbindung sicher ist. Sie können dieses Transportelement dann in einer benutzerdefinierten Bindung verwenden.

Wir sind auf dasselbe Problem gestoßen und haben uns für eine Lösung entschieden, die von einem Entwickler bei Microsoft bereitgestellt wurde. Diese Lösung besteht darin, einen benutzerdefinierten HttpTransport zu erstellen, der die Anforderung überschreibt, SSL vom Load Balancer zum Server zu haben.