eBizTalk - Berichten, Unterhalten, Weiterbilden

Ob Branchendiskurs, Fachartikel oder ein Blick hinter die Unternehmenskulissen: eBizTalk ist die Plattform, die uns auffordert, unsere Leser über Events und Projekte auf dem Laufenden zu halten. Und uns gegenseitig natürlich auch.

BizTalk - SOAP-Requests mit WS-Security

Veröffentlicht am 23.04.2019 von Jean-Pierre Pereira , BizTalk , Security , Integration

Erst kürzlich wollten wir einen SOAP 1.1-Request mit WS-Security aus einem BizTalk Send Port heraus senden. Wir dachten anfangs nicht, dass dies eine große Herausforderung werden könnte - andere Authentifizierungsverfahren sind ja nun auch reichlich in den diversen Adaptern (z.B. BasicHttp-Adapter) implementiert. Tatsächlich ist es jedoch anders als vermutet, In BizTalk sind mehrere, schwer zu recherchierende Schritte nötig, um dies nach unseren Voraussetzungen umzusetzen. Daher hier nun eine kleine Zusammenfassung unserer Erkenntnisse.

Zunächst möchte ich einmal die Anforderungen definieren. Wir möchten:

  1. Einen SOAP 1.1-Request mit WS-Security aus einem BizTalk-Send Port versenden
  2. Zusätzliche Informationen in den HTTP-Headern hinterlegen
  3. Auf Transport-Ebene benötigen wir eine Verschlüsselung, da sonst das Passwort auf dem Weg zum Ziel gelesen werden kann

Die Punkte 2 und 3 klingen zunächst trivial. Ich habe sie jedoch mit aufgeführt, da der erste Punkt Seiteneffekte auf genau diese beiden Punkte haben wird.

clip_image002[5]

WS-Security im SOAP-Request

Wie bereits einleitend beschrieben, haben wir erst einmal versucht den BasicHttp-Adapter zu verwenden. Problem: Dieser Adapter unterstützt keine WS-Security. Und der WSHttp-Adapter kommt wegen dessen Bindung zu SOAP 1.2 nicht in Frage. Hier musste also eine andere Lösung her:

WCF-Custom Send Port einrichten

Zunächst erstellen wir uns ein WCF-Custom Send Port und setzen wie gewohnt unsere Einstellungen. Das bedeutet z.B. die richtige Pipeline auszuwählen, Filter zu setzen usw.

Ist das getan müssen wir noch ein paar andere Schritte erledigen:

  1. Zum Binding-Tab wechseln
  2. customBinding auswählen
  3. httpTransport mit einem Rechtsklick entfernen und mit einem erneuten "Rechtsklick->Add extension" die httpsTransport Erweiterung hinzufügen
  4. Mit einem letzten "Rechtsklick->Add extension" fügen wir noch die Security-Erweiterung hinzu

Damit haben wir alle nötigen Komponenten hinzugefügt. Diese müssen nun nur noch konfiguriert werden. Dabei müssen folgenden Punkte beachtet werden:

image

Username und Passwort könnt ihr wie gewohnt im Credentials-Tab oder direkt im Code (z.B. in einer Pipeline-Komponente) setzen.

Nach diesem Abschnitt ist man dazu in der Lage Soap-Nachrichten mit der WS-Authentifizierung zu verschicken. Problem: Wie erlangt man nun die Kontrolle über die HTTP-Header zurück? Mit einem WCF-WebHttp Adapter hatte man immer die Möglichkeit die Outbound Http Headers über die Admin-Console oder die MessageContext-Properties zu setzen. Diese Möglichkeit wurde entfernt.

WCF-Behavior zum Setzen der HTTP-Header

An dieser Stelle möchte ich überhaupt nicht näher darauf eingehen wie man WCF-Behaviors in BizTalk implementiert. Stattdessen stelle ich einige Links zur Verfügung - denn dieses Vorgehen ist im Internet sehr gut dokumentiert.

https://www.bencode.net/biztalk,wcf/2011/06/26/biztalk-custom-wcf-behaviour

wcf-samples message-inspectors

Nun sollten wir eigentlich zufrieden sein: Wir können ein SOAP 1.1 Request mit WS-Security und selbst gesetzten HTTP-Headern an einen beliebigen Endpunkt senden. In unserem Fall kam es jedoch vor, dass wir wegen der Umstellung auf HTTPS Probleme bekamen. Nämlich die folgende Fehlermeldung:

The request was aborted: Could not create SSL/TLS secure channel!

TLS 1.2 auf einem Windows-Server aktivieren

Der Fehler liegt hierbei in den meisten Fällen bei der Konfiguration des Windows Servers, da veraltete Sicherheitsstandards verwendet werden und der zu erreichende Endpunkt diesen Standard nicht mehr unterstützt. Die Rede ist von SSL3 (hier gab es vor einiger Zeit den POODLE-Exploit, den ein paar nette Google-Mitarbeiter gefunden haben – siehe hier: Exploiting SSL 3.0 ).

SSL3 gilt es nun zu deaktivieren. Stattdessen wollen wir ausschließlich TLS 1.2 verwenden. Dabei geht man wie folgt vor:

  1. Unbedingt ein Backup von der Registry machen! Dafür muss man einfach den obersten Knoten rechtsklicken und die Daten exportieren.
  2. Wechsel zu "HKLM\System\CurrentControlSet\Control\ SecurityProviders\Schannel\Protocols"
  3. Nun geht man in JEDEN Unterordner hinein (Client/Server) und setzt den Wert von "DisabledByDefault" auf "1"
    image
  4. Den Unterordner "TLS 1.2" lässt man dabei unberührt. Stattdessen setzt man den Wert "Enabled" auf "1"
    image
  5. Wechsel zu "HKLM\SOFTWARE\Wow6432Node\Microsoft\ .NetFramework\v4.0.30319" und ein neues "DWORD-Value(32 bit)" erstellen
  6. a. Namen auf "SchUseStrongCrypto" setzen

    b. Im Inhalt steht der Wert 1

  7. Den Punkt 5 wiederholt man unter dem folgenden Pfad: "HKLM\SOFTWARE\Microsoft\ .NetFramework\v4.0.30319"
    image

Nun können wir unsere Zugangsdaten über die WS-Security sicher übertragen und sollten auch keine Fehlermeldung erhalten - denn wir nutzen eine sichere, transportorientierte Verschlüsselung.

google_about_ebiz fb_about_ebiztwitter_about_ebizxing_about_ebiz