HTTPS-Webdienst mit WCF nutzen

Question

Ich versuche, den Webdienst eines Kunden mit WCF zu konsumieren. Der Webdienst des Kunden wird über HTTPS ausgeführt, und ich kann ihn mit der folgenden Bindung problemlos konsumieren:

<bindings>
  <basicHttpBinding>
    <binding name="PurchaseOrderSoap" closeTimeout="00:01:00" openTimeout="00:01:00"
        receiveTimeout="00:10:00" sendTimeout="00:01:00" allowCookies="false"
        bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard"
        maxBufferSize="65536" maxBufferPoolSize="524288" maxReceivedMessageSize="65536"
        messageEncoding="Text" textEncoding="utf-8" transferMode="Buffered"
        useDefaultWebProxy="true">
      <readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384"
          maxBytesPerRead="4096" maxNameTableCharCount="16384" />
      <security mode="Transport" />
    </binding>
  </basicHttpBinding>
</bindings>

Unser Sicherheitsteam hat mir jedoch gesagt, ich müsse Message ou TransportWithMessageCredential Sicherheit, denn Fortify 360 beklagt, dass Transport die Sicherheit ist zu schwach.

Wenn ich versuche Meesage Ich erhalte diesen Fehler:

System.InvalidOperationException: BasicHttp binding requires that 
BasicHttpBinding.Security.Message.ClientCredentialType be equivalent to the 
BasicHttpMessageCredentialType.Certificate credential type for secure messages. Select 
Transport or TransportWithMessageCredential security for UserName credentials.

Und mit TransportWithMessageCredential Ich erhalte den folgenden Fehler:

System.InvalidOperationException: The username is not provided. Specify username in 
ClientCredentials.

Ich habe keinen Benutzernamen und kein Passwort (ich kann mich in meinem Browser problemlos einloggen), daher meine Frage:

Kann ich die Message ou TransportWithMessageCredentials wenn ein bestehender HTTPS-Webdienst genutzt wird (ohne dass der Herausgeber Änderungen vornimmt)? Wenn ja, welche Änderungen muss ich an meiner Konfiguration vornehmen?

Bearbeitet, um die Frage zu klären.

Answer 1

Wenn Sie den Drittanbieter nicht dazu bringen können, einen Endpunkt zu seinem Dienst hinzuzufügen, der die Nachrichtensicherheit unterstützt, sitzen Sie fest. Es scheint, dass sie derzeit nur basicHttpBinding mit Sicherheit auf Transportebene unterstützen.

Die Transportsicherheit ist nicht "weniger" sicher als die Sicherheit auf Nachrichtenebene. Sicherheit auf Nachrichtenebene bedeutet, dass der Inhalt der Soap-Nachricht verschlüsselt wird. So können Sie eine Nachricht entweder im Klartext speichern oder weiterleiten und trotzdem sicher sein, dass niemand die Nachricht einsehen kann. Wenn Sie nur zwischen Ihrem System und dem Anbieter über das Internet kommunizieren, sind Transport- und Nachrichtensicherheit gleichermaßen sicher.

Answer 2

Das basicHttpBinding unterstützt nur die Sicherheit von Benutzernamen und Zertifikatsnachrichten. Wenn Sie also keinen Mechanismus zur Überprüfung von Benutzeranmeldeinformationen in Ihrem System haben, können Sie Zertifikate verwenden.

<security mode="TransportWithMessageCredential">
    ...
    <message clientCredentialType="UserName"/>
</security>

Die andere Möglichkeit ist die Verwendung einer anderen Bindung wie wsHttpBinding, bei der die Nachrichtensicherheit standardmäßig aktiviert ist und die auch die Anmeldetypen Windows und Issued Token unterstützt. Welche dieser Optionen Sie implementieren, hängt weitgehend von Ihren Implementierungsanforderungen und Ihrer Umgebung ab.

Answer 3

Verfügen Sie nicht über eine Art von Ausnahmeregelung, mit der Sie feststellen können, warum es unmöglich ist, die beste Empfehlung von Fortify umzusetzen?

Ich denke, das Beste, was Sie tun können, ist, sich mit Ihrem Webservice-Anbieter in Verbindung zu setzen und um eine Erweiterung zur Unterstützung der Transportrichtlinien von Fortify zu bitten.

Auch: Ich bin misstrauisch, weil Sie sagen, dass der Webbrowser Sie ohne Anmeldeinformationen verbindet. Das bedeutet wahrscheinlich, dass das System, mit dem Sie sich verbinden, ein wenig komplexer ist als Sie annehmen. Verschiedene Verbindungen oder verschiedene URLs können von verschiedenen Servern bedient werden (SSO?) oder verschiedenen Sicherheitsrichtlinien unterliegen (Client-Zertifikat usw.)