Einrichtung der Nachrichtenverarbeitung mit AS2

Einleitung

Der AS2 Adapter ist im B2B Standard enthalten. Zur Einrichtung müssen einige Global Properties, Services, Actions und Extensions angepasst werden.

Die Sicherheit (Verschlüsselung und Signatur sowie Entschlüsselung und Verifikation einer Signatur) der Kommunikation von AS2-Nachrichten kann mit dem Fastlane Security Server (FSS) umgesetzt werden.

Administration

Damit AS2 Nachrichten richtig gespeichert werden, muss Tomcat mit „-Dfile.encoding=ISO-8859-1“ gestartet werden. Falls nicht, lassen sich gespeicherte Nachrichten später nicht mehr entschlüsseln! Siehe B2B Installation Tomcat

Global Properties

Key

Value

Erklärung

B3P_KEYSTORE_KEY

Vlc4ZIHi7oc=

base64 verschlüsseltes Passwort für den Java Keystore, dass die Zertifikate enthält. Ist nur bei der Verwendung des B2B-AS2-Moduls anzugeben, nicht bei der Verwendung des FSS.

com.nextlevel.b2bbp.as2.service.inbound.AS2ReceiverServiceExtern.LOG_LEVEL

1

B3P_AS2_USE_MPID_SYNC

false

Falls „false“, dann wird die Extension B3P_AS2_MPID_MAP verwendet, statt MPID_SYNC. Sinnvoll, falls MPID_SYNC viele Einträge hat, die für AS2 nicht benötigt werden.

B3P_AS2_LOG_STREAM

true

Falls „true“ wird beim Versenden der AS2 Stream gespeichert. Es ist nicht der exakte, versendete Stream, der kann in Java nicht gespeichert werden, aber er enthält alle Header Variablen, die softwareseitig gesetzt werden.

Services

Es müssen zwei neue Services angelegt werden:

Receiver Service

Eigenschaft

Wert

ID

default_as2 (alternativ default_as2_new) WICHTIG keine anderen IDs!!!

Name

AS2 Receiver Service

Typ

AS2

Klasse:

com.nextlevel.b2bbp.as2.service.inbound.AS2ReceiverServiceExtern

Channel

Inbound (Beliebig auswählbar)

Richtung

Business Partner nach Engine

Status

STP

Erstellt von

b2bbp

Startup

nein

Eigenschaften:

B3P_STORE_ORIG_MSG

1 (dann werden die Originalnachrichten (verschlüsselt und signiert) gespeichert)

Anhang-Kodierungen Base64 und Quoted-Printable werden automatisch unterstützt.

Der Name des Anhangs (Dateiname) wird in die MessageContext-Variable B3P_ATTACHMENT_NAME gespeichert. Damit sie auch beim Neustart der Nachricht verfügbar bleibt, soll die Variable dem Save Messages Restartable Feature bekannt gegeben werden. Dafür sollte die Global Property Global Property RESTART_UTIL_SAVE_MESSAGES_RESTARTABLE auf true gesetzt und der Global Property RESTART_UTIL_OPTIONAL_ATTRIBUTES_TO_SAVE die MessageContext-Variable B3P_ATTACHMENT_NAME hinzugefügt werden.

Extension AS2_RECEIVER_EDI_PRIORITIES:

Diese Extension ist dazu da, eingehenden Edi Nachrichten in Abhängigkeit vom Edi-Inhalt eine Priorität zuzuordnen. Je kleiner der Zahlenwert umso höher ist die Priorität:

Anbei ein Beispiel:

equalsEdi(“UNB+2+0”, 9903681000004) AND equalsEdi(“UNH+2+0”, UTILMD) = 35

equalsEdi(“UNB+2+0”, 9903681000004) AND equalsEdi(“UNH+2+0”, INVOIC) = 10

equalsEdi(“UNB+2+0”, 9903681000004) AND equalsEdi(“UNH+2+0”, MSCONS) = 20

Sender Service

Eigenschaft

Wert

ID

egal z.B. as2-send

Name

AS2 Sender Service

Typ

AS2

Klasse:

com.nextlevel.b2bbp.as2.service.outbound.AS2SenderServiceExtern

Channel

Richtung

Engine nach Business Partner

Status

STP

Erstellt von

b2bbp

Startup

nein

Eigenschaften:

Eigenschaft Beispielwert Erklärung
B3P_ENCODING ISO-8859-1 In welchem Charset die Edifact verschickt wird
B3P_STORE_ORIG_MSG 1 1 - speichern, 0 - nicht speichern (default 0)
B3P_AS2_TRANSFER_MC_VARIABLE_TYPES CUSTOM_HEADER ; separierte Liste mit MessageContext Variablen, die als Headers in der AS2 Nachricht verschickt werden
CONTENT_TYPE_APPLICATION_EDIFACT_RECEIVERS 1298222312300 ’,’-separierte Liste mit PartnerILNs, für die der Content-type als application/EDIFACT gesendet wird. Benötigt für NCG unverschlüsselt/unsigniert
REMOVE_MULTIPART_RECEIVERS 1298222312300 ’,’-separierte Liste mit PartnerILNs, für die die Nachricht nicht in ein Multipart Objekt gepackt wird. Benötigt für verschlüsselte/signierte Kommunikation mit NCG
B3P_AS2_ATTACHMENT_BASE64_TRANSFER_ENCODING X Wenn diese Property existiert und nicht leer ist, werden alle Attachments base64 kodiert versendet.
MDN_MICALG sha-256,sha-224,sha1 Fordert den Empfänger, den Message Integrity Check (MIC) der MDN mit diesem Algorithmus durchzuführen. Mehrere Algorithmen können kommasepariert angegeben werden. Möglich sind: sha1, md5, sha-224, sha-256, sha-384, sha-512. (default: “sha1,md5”)

Action OutboundMailHandler

Die Action mit der Klasse OutboundMailHandler (z.B. namens Sender-Action) wird so konfiguriert, dass der AS2-Service aufgerufen wird:

B3P_USED_SERVICE_ID muss dafür auf die ID des AS2-Sender-Services zeigen. Das kann auch über dynamische Ausdrücke gemacht werden, um je nach Partner unterschiedliche Kommunikationsarten zu nutzen (Email, AS2 intern, AS2 extern) Empfohlener Wert: ${elp(SENDER_EMAIL,${template(OUTBOUNDSERVICE_&(this.FORMAT.partnerCode))},true)}

Die konkrete Service-ID wird in der Extension SENDER_EMAIL konfiguriert, wo die eigenen Systeme konfiguriert werden. Zwischen den eigenen Systemen wird über internes AS2 kommuniziert, mit den externen Partner über Email. Dort können aber auch Partner konfiguriert werden, die über externes AS2 angesprochen werden. Dafür muss für diese Partner die Service-ID des AS2 Sender Service (z.B. as2-send) hintegerlegt werden. Beispiel:

### Default ###
OUTBOUNDSERVICE=MAIL_OUT

### System Lieferant 9999999999999 ###
OUTBOUNDSERVICE_9999999999999=AS2_OUT

### Externes AS2 Partner 8888888888888 ###
OUTBOUNDSERVICE_8888888888888=as2-send

In der Action sollte B3P_AS2_SUBJECT den gleichen Wert und Einstellungen wie B3P_MAIL_SUBJECT erhalten. Zum Beispiel den dynamischen Ausdruck ${template(&(this.FORMAT.type)_&(this.FORMAT.attributes.UtilRef)_&(this.FORMAT.senderCode)_&(this.FORMAT.partnerCode)_&(this.FORMAT.referenceId))}

Benutzersteuerung & GUI

Unter Benutzer und Rollenadministration muss ein neues Attribut erstellt werden:

ID: Module_AS2

Wert:

Override={view=mainView,type=AddChild,target=toolBarBox,name=org.b2bbp.ui.uicomponent.MainNavLinkButton,value=[id:'KeystoreButton';label:'AS2 Partnerbeziehungen';isExtension:'false';type:'com.nextlevel.b2b.as2.ui.swf';provider:'nextlevel.com';version:'1.0';container:'applicationViewStack';toolTip:'AS2 Partnerbeziehungen';width:'180';labelPlacement:'right';textAlign:'left';horizontalGap:'10';paddingLeft:'5';paddingRight:'5';iconURL:'images/famfamfam-icons/key.png']}

Des Weiteren wird für jeden Benutzer, der AS2 Partnerbeziehungen administrieren darf, eine Rolle für dieses Attribut erstellt. z.B: RollenID: admin, AttributID: Module_AS2

Wenn die Security für AS2-Nachrichten mit dem B2B-AS2-Modul und nicht mit dem FSS umgestezt wird, mus des Weiteren eine Global Property mit dem Namen B3P_KEYSTORE_KEY erstellt werden. Sie gibt das Base64 codierte Passwort des Java Keystores an, in dem alle Zertifikate abgelegt werden. Das Passwort kann frei gewählt werden, darf aber nach erstmaligem Start des Moduls nicht mehr verändert werden. Falls b2bbp als Passwort verwendet werden soll, lautet die base64 Verschlüsselung Vlc4ZIHi7oc=

Einrichtung AS2-Verbindung

Die Einrichtung neuer Partnerbeziehungen geschieht über das Modul AS2 Partnerbeziehungen. Es besteht aus 2 Tabs:

MPIDs

B2B_Installation_as2_gui_mpid

In diesem Tab werden die System- und Partner-MPIDs gepflegt, für die die Partnerbeziehungen konfiguriert werden sollen.

Zertifikate

Die Zertifikatsverwaltung erfolgt über den Fastlane Security Server. Vgl. hierzu FSS Zertifikatsverwaltung. Zertifikate für AS2 müssen als Alias den gleichen Wert haben, der auch in den IDs der Partnerbeziehungen verwendet wird (meistens ILN).

Für das Routing der Nachrichten innerhalb der B2B gelten die gleichen Regeln wie für den FSS. Es sind also die üblichen ChannelDistributions und Channels des FSS zu benutzen. Vergleiche hierzu die FSS Dokumentation.

Der AS2 Receiver Service verschickt das MDN erst, nachdem die Verarbeitung durch den FSS abgeschlossen wurde. Entsprechend sollte der Timeout zum FSS nicht zu hoch gesetzt werden.

Partnerbeziehungen

B2B_Installation_as2_gui_partnerrel

Unter Partnerbeziehungen sind alle bisher angelegten Partnerbeziehungen mit deren Einstellungen sichtbar. Außerdem können neue Beziehungen angelegt, alte gelöscht und die Gültigkeit einer Beziehung angepasst werden.

Bei der Erstellung einer neuen Beziehung muss angegeben werden, welche Art der Signatur verwendet wird, wie verschlüsselt wird, ob die Beziehung für ein- (inbound markiert) oder ausgehende Nachrichten gilt und ob Nachrichten komprimiert ausgetauscht werden sollen.

Durch Anklicken einer bestehenden Beziehung werden die entsprechenden Daten als Vorbelegung der Felder zur Erzeugen einer neuen Beziehung verwendet.

In Abhängigkeit von den Einstellungen erscheinen unter SystemMPID und PartnerMPID unterschiedliche Auswahlmöglichkeiten. Für ausgehende, signierte Nachrichten können beispielsweise nur MPIDs gewählt werden, für die ein Private Key hinterlegt wurde.

Als Adresse für ausgehende Nachrichten wird die URL des AS2-Webservices des Partners eingetragen.

Als Adresse für eingehende Nachrichten wird die URL eingetragen, an die die Partner ihre Nachrichten schicken sollen. Die Tomcat-Knoten hören auf Verbindungen unter http://<host>:<port>/b2bbp-engine/as2Extern. Port ist der konfigurierte Port des HTTP-Connectors von Tomcat. Wenn Partner direkt an diese Adresse schicken sollen, muss in Partnerbeziehungen genau diese Adresse eingetragen werden. Üblicherweise wird aber zwischen dem Partner und dem Tomcat-Knoten ein Loadbalancer eingerichtet. Entsprechend muss dann hier als Adresse die im Loadbalancer konfigurierte URL (ggf. mit Suffix “/b2bbp-engine/as2Extern”) eingetragen werden.

Bei ausgehenden Nachrichten werden diese an “URL” gesendet, bei eingehenden Nachrichten ist die Beziehung nur gültig, wenn die Nachricht an die unter “URL” angegebene Url versendet wurde.

Des Weiteren kann die Gültigkeit der Beziehung über die Felder gültig von bzw. gültig bis eingeschränkt werden.

Konfiguration der AS2-Ids bei den ausgehenden Nachrichten

Im AS2-Stream werden die Header AS2-From und AS2-To gesetzt. Die Werte werden über folgende Logik ermittelt:

Falls am AS2-Sender-Service die Eigenschaften B3P_FIXED_PARTNERID und B3P_FIXED_SENDERID gesetzt sind, ist AS2-From der Wert der Eigenschaft B3P_FIXED_SENDERID und AS2-To der Eigenschaft B3P_FIXED_PARTNERID

Andererseits, falls im MessageContext die Variable B3P_AS2_USE_SENDER_RECEIVER_FROM_MC = true gesetzt ist, ist AS2-From der Wert der MessageContext-Variable B3P_AS2_FROM und AS2-To der Wert der Eigenschaft B3P_AS2_TO. Diese Variablen setzt man normalerweise in der Action der Klasse OutboundMailHandler mit den Ausdrücken

AS2_USE_SENDER_RECEIVER_FROM_MC = true
B3P_AS2_FROM = ${loadExtensionProperty(SENDER_EMAIL,${template(AS2_FROM_&(this.FORMAT.senderCode))},true)}
B3P_AS2_TO = ${loadExtensionProperty(SENDER_EMAIL,${template(AS2_TO_&(this.FORMAT.partnerCode))},true)}

Die Einträge AS2_FROM_<MPID> und AS2_TO_<MPID> müssen in der Extension SENDER_EMAIL eingetragen werden.

Andererseits wird AS2-From aus dem Format-Objekt ermittelt und gleicht Format.systemCode, und AS2-To ist gleich Format.partnerCode

Bestimmung der Partnerbeziehung, die benutzt werden soll

Normalerweise werden, um die passende Partnerbeziehung zu finden, die Werte AS2-From und AS2-To genommen (wie sie bestimmt werden, steht im vorherigen Kapitel)

Falls diese Ids nicht in den Partnerbeziehungen benutzt werden können, kann man pro System oder Partner direkt angeben, unter welchen Ids die Partnerbeziehung ermittelt werden soll.

Für die ausgehenden Nachrichten passiert das über die MessageContext-Variablen B3P_PARTNER_RELATIONSHIP_FROM und B3P_PARTNER_RELATIONSHIP_TO

B3P_PARTNER_RELATIONSHIP_FROM = ${elp(SENDER_EMAIL,${template(AS2_MODULE_ID_&(this.FORMAT.systemCode))},true)}
B3P_PARTNER_RELATIONSHIP_TO = ${elp(SENDER_EMAIL,${template(AS2_MODULE_ID_&(this.FORMAT.partnerCode))},true)}

Die Ids werden somit in der Extension SENDER_EMAIL unter dem Schlüssel AS2_MODULE_ID_<MPID> konfiguriert.

Für die eingehenden Nachrichten passiert das über die Extension B3P_RECEIVER_AS2_MAP, in der die Header-Werte auf die Ids in der Partnerbezierung gemappt werden, zum Beispiel:

21X-DE-F-G0G0G-2=980022200002_AS2
21X-DE-F-A0BBB-8=990099900002_AS2

Fachliche Belege

B2B_Installation_as2_gui_prof_record

Im Monitoring wird unter Fachliche Belege die ein-/ausgehende Nachricht abgelegt. Falls die ServiceProperty B3P_STORE_ORIG_MSG gesetzt ist, wird auch die Originalnachricht (verschlüsselt und signiert) abgelegt.

Des Weiteren wird das empfangende/gesendete MDN (Message Disposition Notification) angezeigt. Ein MDN ist eine automatisch generierte Nachricht, die synchron als Bestätigung versendet wird. Falls sie positiv ist, wird bestätigt, dass die Nachricht beim Empfänger entschlüsselt und die Signatur überprüft werden konnte. Ein negatives MDN liefert den Fehler an den Sender zurück, der bei der Verarbeitung des Empfängers aufgetreten ist. Negative MDNs werden als Icon im Bestätigungsfeld angezeigt (Status MER). Ein MDN bestätigt keine erfolgreiche Verarbeitung der Nachricht, sondern nur eine erfolgreiche Übertragung der Nachricht!

AS2-Security mit Fastlane Security Server

Verschlüsselung und Signatur für AS2-Nachrichten wird mit dem Fastlane Security Server (FSS) umgesetzt. (Die Global Property USE_FSS_FOR_AS2 hat keine Bedeutung mehr und kann entfernt werden.)

Die Anbindung an FSS ist normalerweise per Keycloak abgesichert. Dies wurde üblicherweise bei der Anbinung der E-Mail Kommunikation an FSS bereits konfiguriert. Falls die AS2-Kommunikation über einen eigenen B2B-Knoten laufen soll, soll diese Konfiugration dafür wiederholt werden (keycloak.json in lib oder conf-Verzeichnis abegen, siehe hier)

Die Konfiguration der AS2-Partnerbeziehungen in der B2B ist weiterhin gültig. Insbesondere können die Outbound-Algorithmen (Verschlüsselungsalgorithmen und Hashalgorithmen für Signatur) partnerscharf konfiguriert werden. Inbound kann partnerscharf konfiguriert werden, ob Verschlüsselung und Signatur gefordert wird.

Nach der Migration der Zertifikate sind alle Zertifikate und Schlüssel in der AS2 Zertifikatsverwaltung zu löschen.

Bei der Verarbeitung auftretende Fehler & Warnungen können per Regelwerk behandelt werden

Empfang und Versand von AS2-Nachrichten über HTTPS

Es ist möglich, die AS2-Verbindung über HTTPS (HTTP mit SSL/TLS-Verschlüsselung) einzurichten.

AS2-Empfang

Damit die Nachrichten über HTTPS empfangen werden können, muss im Tomcat dafür ein Connector konfiguriert werden. Die Einrichtung ist in der Tomcat-Dokumentation beschrieben: SSL/TLS Configuration How-To und HTTP Connector - SSL Support

Ab dem 1.4.2022 ist bei Nutzung von HTTPS nur TLS in der Version 1.2 oder 1.3 zu verwenden. Tomcat unterstützt eingehende Verbindungen über diese sowie andere Versionen. Um die Verbindung über andere Versionen zu verbieten, muss der Tomcat-Connector auf folgende Weise konfiguriert werden:

<Connector
	protocol="org.apache.coyote.http11.Http11NioProtocol"
	port="<HTTPS_PORT>"
	maxThreads="150"
	scheme="https"
	secure="true"
	SSLEnabled="true"
	keystoreFile="<PATH_TO_KEYSTORE>"
	keystorePass="<KEYSTORE_PW>"
	clientAuth="false"  
	sslProtocol="TLS"
	sslEnabledProtocols="TLSv1.3,TLSv1.2"/>

AS2-Versand

Für den Versand über HTTPS ist keine besondere Konfiguration nötig. In der Partner-URL muss nur https:// als Protokoll eingetragen sein.

Standardmäßig wird versucht, TLS in der Version 1.2 zu verwenden. Falls der Empfänger sie nicht unterstützt, wird auf eine andere Version ausgewichen. Um andere Versionen als 1.2 und 1.3 zu verbieten, müssen beim Start der B2B diese Parameter übergeben werden: -Djdk.tls.client.protocols="TLSv1.3,TLSv1.2" -Dsun.security.ssl.allowUnsafeRenegotiation=false -Dhttps.protocols="TLSv1.3,TLSv1.2"

Proxy Einrichtung

AS2 unterstützt Kommunikation über einen Proxy.

Der Proxy Host und Port kann entweder global in Global Properties oder in den Service Properties konfiguriert:

Einrichtung über Service Properties:

HTTP_PROXY_URL für den Host, z.B. “localhost”

HTTP_PROXY_PORT für den Port, z.B. “9090”

Einrichtung über Global Properties:

B3P_PROXY_SERVER (url:port)

Wenn der Proxy über diese Global Property eingerichtet ist, wird die Proxy-Konfiguration in Service Properties ignoriert.

Einrichtung der Proxy Authentifizierung

Wenn der Proxy eine Basic-Auth Authentifizierung verlangt, können diese Global Properties benutzt werden:

B3P_PROXY_USER

B3P_PROXY_PASSWORD (b2b base64 codiert)

Ausnahmen für Proxy

Soll mit einem Partner nicht über einen Proxy kommuniziert werden, müssen die URLs in der Global Property B3P_PROXY_EXCLUDELIST eingetragen werden.

B3P_PROXY_EXCLUDELIST (url1;url2)

Selbstsignierte Zertifikate erzeugen

Zu Testzwecken können selbstsignierte Zertifikate eingespielt werden. Sie können mit dem Tool OpenSSL erzeugt werden (https://www.openssl.org/). Es folgen die Kommandozeilen-Anweisungen für dieses Tool.

  1. Privates Key erzeugen

    openssl genrsa -des3 -out privkey.pem 2048

  2. Selbstsigniertes Public Zertifikat erzeugen. Dieses wird dem Partner gegeben.

    openssl req -new -x509 -key privkey.pem -out pubcert.crt -days 1095

  3. Privates PKCS#12 Zertifikat erzeugen. Das wird lokal hochgeladen.

    openssl pkcs12 -export -out privcert.p12 -inkey privkey.pem -in pubcert.crt

Bekannte Probleme

MDN: multipart/mixed content not supported

Die PartnerILN muss bei verschlüsselter Kommunikation in die ServiceProperty REMOVE_MULTIPART_RECEIVERS des AS2SenderServices aufgenommen werden.

Bei unverschlüsselter in die ServiceProperty CONTENT_TYPE_APPLICATION_EDIFACT_RECEIVERS.

P12 Zertifikat kann nicht hochgeladen werden

Es muss sichergestellt sein, dass der Keystore-Typ PKCS#12 ist und nicht JKS o.ä.

(im Keystore Explorer steht unten nach dem Öffnen Keystore Type: PKCS#12)

View Me   Edit Me