https://www.connected-pawns.com/2017/04/09/wcf-webhttp-adapter-basic-authorisation/
Dieses Verhalten hat sich bis BizTalk 2020 gehalten.
Verschiedene Workarounds und Lösungen sind somit entstanden:
- Den Header in den Port Properties anpassen, indem man im Tab «Messages» den Authorization-Tag mit den Base64 kodierten Zugangsdaten hinzufügt. Dies hat allerdings den klaren Nachteil, dass die Zugangsdaten praktisch frei einsehbar sind, da Base64 keine Verschlüsselung und problemlos rückwärts konvertierbar ist.
- Das Schreiben eines Custom Behaviors, welches die Zugangsdaten dem Header hinzufügt.
- Das Schreiben eines Custom Pipeline Components, welche die Zugangsdaten dem Header hinzufügt.
Nachfolgend wird letztere Möglichkeit gezeigt.
Sogleich stellt sich die Frage, woher die Zugangsdaten kommen. Hartkodiert in die Custom Pipeline genügte uns nicht, also nutzen wir den Windows Credential Store. Damit lassen sich Zugangsdaten für einen Windows-Benutzer in Windows ablegen und dann wieder anhand eines Schlüsselworts (Target) im Klartext abholen. Da es über die Identität des angemeldeten Benutzers passiert, besteht grundsätzlich keine Gefahr, dass jemand Unbefugtes an diese gelangt, es sei denn, er kennt die Anmeldedaten des entsprechenden Benutzers.
Custom Pipeline Component
Ich werde nicht genau auf die Erstellung einer Custom Pipeline Component eingehen, da es im Internet bereits gute Tutorials dafür gibt (https://blog.tallan.com/2006/11/21/custom-pipeline-components-part-1-getting-started/).Durch das Implementieren der benötigten Interfaces werden die essentiellen Methoden eingebunden. Die Interessanteste davon ist wohl Execute, wo wir die Nachricht und deren Kontext erhalten und bearbeiten können.
Die Zugangsdaten werden also für den aktuellen Benutzer (welcher bei der Host-Instanz eingetragen ist, mit welcher der SendPort und somit die Pipeline läuft) anhand des in der Pipeline konfigurierten Schlüsselworts (Target) aus dem Windows Credential Store geholt, in einen Base64-String umgewandelt und mit dem «Authentication: Basic »-Präfix dem bestehenden HTTP Header hinzugefügt.
Die Abholung der Zugangsdaten aus dem Windows Credential Store passiert in der Klasse Credential aus der Drittanbieter-Komponente CredentialManagement (verfügbar als Nuget Package https://www.nuget.org/packages/CredentialManagement/). Der zu schreibende Code zeigt sich also sehr simpel:
Verwendung
Nachdem die DLL, in welcher unser Custom Pipeline Component definiert ist, über die BizTalk Administration Console als Ressource registriert ist und sich somit im GAC befindet, sollte sie (nach allfälligem Neustart von Visual Studio) der Toolbox hinzugefügt werden können.
(In der Toolbox im Pipeline-Designer > Rechtsklick > Choose items… > Registereintrag «BizTalk Pipeline Components» > Browse… > DLL auswählen > Entsprechende Checkbox anhaken)
Danach kann sie wie jede andere Komponente in der Pipeline verwendet werden.
Ist dann auch die DLL, in welcher die Pipeline mit dem Custom Pipeline Component verwendet wird, in BizTalk registriert, sollte sie bei einem SendPort ausgewählt werden können und in den Properties das Feld für das Eintragen des Targets anbieten.
Werden für den Benutzer, der in der entsprechenden Host-Instanz eingetragen ist, nun Zugangsdaten mit dem eingetragenen Target «System_XY_Credentials» erstellt, werden diese für die Anmeldung beim Endpunkt verwendet.
Windows Credential Store
Der Windows Credential Store kann entweder über das Windows UI (Control Panel\User Accounts\Credential Manager) oder über die Kommandozeile mit dem Befehl cmdkey (https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/cmdkey) verwendet werden.
Insbesondere, wenn Zugangsdaten für einen Benutzer angelegt werden müssen, bei dem man sich gar nicht bei Windows anmelden kann, erweist sich die Kommandozeile als Rettung. Damit kann man nämlich auch Zugangsdaten für einen anderen Benutzer verwalten, sofern man seine Anmeldedaten besitzt.
Raphael, QUIBIQ Schweiz
