AS4 Outbound Sender

Dieser Service empfängt eine AS4 Nachricht vom Crypto Operations via Message Broker und versendet diese an den Marktpartner. Diese versendete Nachricht wird zur Persistierung an den AS4 Message Service via Message Broker geschickt. Und auch die empfangene Bestätigung des Marktpartners wird zur Verifizierung an den Crypto Operations versendet.

Hardware Anforderungen

Eine Service-Instanz erfordert mindestens 512 MB RAM.

Wir empfehlen 0,4 CPU-Kerne je Instanz.

Logs werden auf die Festplatte geschrieben, entsprechend muss genügend Speicherplatz vorhanden sein.

Abhängigkeiten

Der Service greift auf einen Message-Broker zu, um Nachrichten zu empfangen und zu versenden.

Der Service nutzt die REST API des Security Server FSS. Der FSS muss im Hintergrund auf ein HSM zugreifen können.

Der Service verbindet sich per AS4 mit zahlreichen anderen AS4 Endpunkten. Dies beinhaltet auch externe AS4-Endpunkte.

Einfache Konfiguration der as4-outbound-sender.properties

Der AS4 Outbound Sender versendet die Edifact Nachricht als AS4 Nachricht an den Marktpartner. Anschließend wird diese AS4 Nachricht als Business Message an den AS4 Message Service und die erhaltene Bestätigung als Receipt an den Crypto Operations übergeben.

Dazu benötigt der AS4 Outbound Sender die Angaben zum Message-Broker.

rabbitmq.host=localhost
rabbitmq.port=5672
rabbitmq.username=guest
rabbitmq.password=guest

Mit skipCrypt lässt sich die Anbindung zum Crypt Operation für Entwicklungszwecke ausschalten.

skipCrypt=false

AMQP Konfiguration

Falls Sie das Standard Routing nutzen, muss das Routing nicht weiter konfiguriert werden. Wenn Sie Ihr Routing anpassen möchten, lesen Sie die folgende Dokumentation.

Die Property consumer.max.attempts verhindert das mehrfache Versenden der Nachricht, wenn die Versendung fehlgeschlagen oder ein anderer Fehler aufgetreten ist.

consumer.max.attempts=1

Default: 3

Das Intervall zwischen den einzelnen Versuchen kann konfiguriert werden. Der Wert ist in Millisekunden angegeben

consumer.retry.interval=2000

Default: 1000

Empfang der AS4 Nachricht

Der Consumer empfängt die signierte AS4 Nachricht über die Queue as4.outbound.default.

cryptoConsumerExchangeName=as4.outbound

Versendung der Business Message

Der Producer versendet die AS4 Nachricht (in diesem Kontext die Business Message) über die Queue as4.messages.default.

businessMessageExchangeName=as4.messages

Weiterleiten der Empfangsbestätitung

Der Producer versendet die Empfangsbestätigung des Marktpartners an den Crypto Operations über die Queue as4.verify.default.

receiptCryptoExchangeName=as4.verify

Crypto Errors

Im Fall das Crypto Operations ausgeschaltet wird, die Signaturprüfung der Quittung gescheitert ist und es sich nicht um eine signierte Pathswitch Nachricht handelt, landet die zu versendete Nachricht in der Queue as4.messages.default. Es wird ein dazugehöriges, “leeres” Receipt mit entsprechendem Report in die Queue as4.receipt.default gelegt. Die Objekte werden im As4-Message-Service konsumiert und persistiert, sodass sie im MessageMonitor einsehbar sind.

receiptExchangeName=as4.receipt
businessMessageExchangeName=as4.messages

Routing Konfiguration der as4-outbound-sender.properties

Für die Aktivierung des Routings müssen der headerName und die headerValues gesetzt werden. Den headerName kann man sich als Filterkategorie vorstellen, während die headerValues den zu filternden Werten entsprechen. Nachrichten mit Werten, die nicht explizit als headerValues aufgelistet sind, laufen weiterhin über die default Route.

Als headerName werden folgende Parameter angeboten:

• tenant: ILN Nummer des Senders
• partner: ILN Nummer des Empfängers.
• sector: GAS, ELECTRICITY

Es können mehrere Werte kommasepariert angegeben werden.

receiptCryptoExchangeName=as4.verify
receiptCryptoHeaderName=tenant
receiptCryptoHeaderValues=

businessMessageExchangeName=as4.messages
businessMessageHeaderName=tenant
businessMessageHeaderValues=

receiptExchangeName=as4.receipt
receiptHeaderName=tenant
receiptHeaderValues=

Wird der Producer für das Routing konfiguriert muss natürlich auch die Gegenstelle dafür eingerichtet werden. Dem Consumer wird über die Gruppe der Wert (Value) aus der HeaderValues Liste zugewiesen nach welchem gefiltert werden soll. Bitte den Default Wert nur ändern, wenn Routing verwendet werden soll. Aktuell muss der BindingRoutingKey jedoch immer angegeben werden. Dieser ist, wenn kein Routing verwendet wird ‘default’.

cryptoConsumerExchangeName=as4.outbound
cryptoConsumerGroup=default
spring.cloud.stream.rabbit.bindings.consumeSignedEncryptedMessage-in-0.consumer.bindingRoutingKey=default

Mit der Variable consumer.max.attempts wird verhindert, dass die Nachricht versendet wird, wenn die Verarbeitung fehlschlägt.

consumer.max.attempts=1

Max Concurrency - Parallelität

Es ist möglich für dein Consumer die Eigenschaft max-concurrency zu setzen. Diese definiert die maximale Anzahl von gleichzeitigen Verarbeitungsthreads, die für einen Consumer gestartet werden können. Der Default liegt bei 50.

cryptoConsumerMaxConcurrency=50

Mindestens verfügbare Consumer

Es ist möglich den Outbound-Sender vorzugeben wie viele Consumer er mindestens vorhalten soll egal wie hoch oder niedrig gerade die Last ist. Somit werden Verzögerung bei schwankenden Nachrichtenvolumen verhindert. Der Default ist 1.

spring.cloud.stream.bindings.consumeSignedEncryptedMessage-in-0.consumer.concurrency = 5

REST API

Die API bietet Server-Health Informationen an.

Der Port lässt sich über folgende Property konfigurieren: server.port=8080

Multi-Mandantenfähigkeit

Falls das AS4-System für mehrere Mandanten betrieben wird, kann der AS4 Outbound Sender für jeden Mandanten mindestens eine eigene Instanz haben. Bei einer solchen Konfiguration muss für jeden Mandanten eine eigene Queue eingerichtet werden. Über die Exchange muss entsprechend dem Mandanten in die jeweilige Queue geroutet werden.

Der AS4-Outbound-Sender arbeitet außerdem als AMQP Producer. Hier müssen keine weiteren Anpassungen vorgenommen werden.

Ausfallsicherheit

Wie üblich für Microservices können mehrere Instanzen des AS4-Outbound-Senders parallel betrieben werden, um die Last zu verteilen und Ausfallsicherheit zu gewährleisten.

In einem solchen Szenario konsumieren mehrere Instanzen die gleiche Queue und verteilen so die Nachrichten.

Der AS4-Outbound-Sender arbeitet außerdem als AMQP Producer. Hier müssen keine weiteren Anpassungen vorgenommen werden.

mTLS

Der AS4-Outbound-Sender fungiert als AS4-Client, der die Geschäftsnachricht an einen AS4-Server sendet.

Um mTLS auf der Seite des AS4-Outbound-Senders zu aktivieren, müssen zum einen JDK_JAVA_OPTIONS gesetzt und zum anderen in der application.properties gewissen Eigenschaften gesetzt werden:

JDK_JAVA_OPTIONS: "-Djdk.tls.cipherSuites=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_BRAINPOOLP384R1,TLS_ECDHE_ECDSA_WITH_BRAINPOOLP256R1,TLS_ECDHE_ECDSA_WITH_SECP384R1,TLS_ECDHE_ECDSA_WITH_SECP256R1 -Djdk.tls.namedGroups=brainpoolP384r1,brainpoolP256r1,secp384r1,secp256r1"

In der application.properties sind folgende Properties zu setzen:

client.ssl.enabled=true

addressServiceUrl=http://localhost:8089/aep-as4-address-service
#ssl.tenant.id=9907647000008,9903111000003

fss.server.api.url=http://localhost:2222/fss/api/v1
ssl.partner.client=shared-client

Die TLS-Funktionalität kann über die Eigenschaft client.ssl.enabled ein-/ausgeschaltet werden (entweder durch Setzen auf true oder false). Der Standardwert für client.ssl.enabled ist false. Wenn die Eigenschaft nicht konfiguriert ist, wird sie daher standardmäßig auf „false“ gesetzt.

Der Service unterstützt parallel mehrere Mandanten. Wenn wir die Liste der Mandanten aus dem AS4-Address-Service automatisch abrufen möchten, müssen die Mandanten im AS4-Address-Service konfiguriert werden. Für diese Verbindung müssen wir die Eigenschaft addressServiceUrl in der Konfigurationsdatei definieren. (Alternativ kann die Liste der Mandanten, für die wir TLS konfigurieren möchten, wie gezeigt explizit in der Eigenschaft ssl.tenant.id mithilfe durch Kommas getrennter Werte angegeben werden.)

Hinweis: Konfigurieren Sie entweder die Eigenschaft addressServiceUrl oder ssl.tenant.id – konfigurieren Sie nicht beide Eigenschaften gleichzeitig.

Hinweis: Falls die addressServiceUrl genutzt wird, gilt: Der AS4-Address-Service muss ausgeführt und vom AS4-Outbound-Sender aus aufrufbar sein. Alle benötigten Mandanten müssen zur Bootzeit des AS4-Outbound-Senders verfügbar sein. Falls sich Mandanten zur Laufzeit ändern, müssen Sie den AS4-Outbound-Sender neu starten.

Für jeden Mandanten muss ein Marktpartner-TLS-Zertifikat/-Schlüssel im FSS/HSM vorhanden sein. Für jeden Marktpartner müssen alle Zertifikate der Aussteller-Zertifikatskette im FSS shared-client verfügbar sein. Die FSS-URL wird über die Property fss.server.api.url konfiguriert. Der shared-client wird über die Property ssl.partner.client angegeben. Wenn die Eigenschaft von ssl.partner.client nicht festgelegt ist, lautet der Standardwert shared-client.

Hinweis: Der FSS muss ausgeführt und vom AS4-Outbound-Sender aus aufrufbar sein. Alle benötigten Zertifikate müssen zur Bootzeit des AS4-Outbound-Senders verfügbar sein. Falls sich Zertifikate zur Laufzeit ändern, müssen Sie den AS4-Outbound-Sender neu starten.

Zertifikat Cache

Zertifikate werden intern gecached. Dieser Cache muss regelmäßig aktualisiert werden. Dies ist notwendig um z.B. den änderbaren Sperrlistenstatus aktuell zu halten.

Der Cache wird automatisch auf zeitlicher Basis aktualisiert, per Default alle 6 Stunden.

Das Zeitinterval der automatischen Aktualisierung für Zertifikat-Caches kann über die Eigenschaft clear-certificate-cache konfiguriert werden. Hierbei handelt es sich um einen Cron-Ausdruck. Beispiel:

#         day of week ------------+
#               month ----------+ |
#        day of month --------+ | |
#                hour ------+ | | |
#              minute ----+ | | | |
#              second --+ | | | | |
#                       | | | | | |
clear-certificate-cache=0 0 6 * * *

Weitere Details zur Cron-Konfiguration finden Sie in der Spring-Doku.

Widerrufstatus von Zertifikaten cachen

Um den Widerrufstatus von Zertifikaten zu cachen und nicht für jede Nachricht erneut abzurufen, muss folgender Wert in der application.properties gesetzt werden:

revocation.status.cache.enabled=true

Dann wird der Widerrufstatus der Marktpartnerzertifikate maximal einmal pro Stunde geprüft. Falls Probleme beim Abrufen des Widerrufstatus auftreten, wird der gecachte Status für maximal 6 Stunden verwendet. Diese Zeiträume können mit folgenden Konfigurationseinstellungen angepasst werden:

revocation.status.cache.max.usage=T6H
revocation.status.cache.refresh.after=T1H

Syntax: 1H für eine Stunde, 30M für 30 Minuten, 1D für einen Tag, oder Kombinationen wie 1d4H or 1H30M

Prüfung von nicht gespeicherten Partnerzertifikaten während des TLS-Handshakes

Während des TLS-Handshakes kann die Vertrauensprüfung des Partnerzertifikats nun auch durchgeführt werden, wenn das Zertifikat nicht im FSS gespeichert ist. Diese Prüfung findet im FSS statt. Wenn das Zertifikat im FSS gespeichert ist, werden diese Informationen für die Prüfung herangezogen. Wenn das Zertifikat nicht gespeichert ist, werden die Informationen aus dem Zertifikat verwendet und die Sperrliste von der Sub-CA heruntergeladen. Folgenden Prüfungen werden durchgeführt, um zu prüfen, ob das Zertifikat vertrauenswürdig ist:

• Zertifikatskette ist im FSS vorhanden und vertrauenswürdig
• Wenn das Zertifikat vorhanden ist: Aktiv oder inaktiv
• Validity/time slice
• Sperrlistenstatus
• Purpose ist TLS

Um diese Funktion zu aktivieren (FSS-URL ist ebenfalls konfiguriert):

ssl.trust-info=true

Wichtig ist zu beachten, dass für dieses Feature mindestens die FSS Version 2025-02-27-01 verwendet werden muss.

Anhang: Gesamtkonfiguration

Folgende Konfiguration reicht in einem Standard-System mit TLS aus: application.properties:

rabbitmq.host=rabbitmq3
rabbitmq.port=5672
rabbitmq.username=guest
rabbitmq.password=${RABBITMQ_PASSWORD}

# Timeout default to 300 second
connectionTimeout=300

# Die automatische Aktualisierung für Zertifikat-Caches kann über die Eigenschaft konfiguriert werden: Standard ist 0 0 6 * * *
clear-certificate-cache=0 0 6 * * *
# Keystore-Dateien können während der Cache-Aktualisierung durch die Eigenschaft standardmäßig false gelöscht werden
deleteKeystoreFiles=false

#=== FSS ===#
fss.server.api.url=http://fss:2222/fss/api/v1
## Page size for fss requests
fss.page.size.value=100

#=== SSL Properties ===#
client.ssl.enabled=true
ssl.partner.client=shared-client
addressServiceUrl=http://localhost:8089/aep-as4-address-service

JDK_JAVA_OPTIONS:

JDK_JAVA_OPTIONS: "-Djdk.tls.cipherSuites=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_BRAINPOOLP384R1,TLS_ECDHE_ECDSA_WITH_BRAINPOOLP256R1,TLS_ECDHE_ECDSA_WITH_SECP384R1,TLS_ECDHE_ECDSA_WITH_SECP256R1 -Djdk.tls.namedGroups=brainpoolP384r1,brainpoolP256r1,secp384r1,secp256r1"

Optionale Proxy Configuration

Es ist möglich den Outbound-Sender mit einem Proxy zu verbinden. Falls Basic-Authentifizierung mit User und Passwort nowendig sind, kann dies ebenfalls konfiguriert werden.

#=== Proxy Properties ===#
proxyEnable=false
proxyAddress=
proxyPort=
proxyUser=
proxyPassword=

Falls der Proxy benötigt wird, muss die Eigenschaft proxyEnable auf true gesetzt werden. Die proxyAddress gibt die Addresse (Host) an, unter welcher der Proxy verfügbar ist. Wenn der Proxy beispielsweise unter localhost läuft, wird 127.0.0.1 eingetragen. Sollte keine Authentifizierung mit User und Passwort erforderlich sein, können diese Eigenschaften leer bleiben.

Allgemeine Hinweise zur Konfiguration finden Sie hier.