OFTP
Um OFTP-Kommunikation zu nutzen, muss der OFTP-Service lizenziert und aktiviert sein. Bei Interesse wenden Sie sich bitte an unsere Mitarbeiter im Support bzw. im Vertrieb.
OFTP (ODETTE FILE TRANSFER PROTOCOL) ist eine Art FTP über ISDN oder TCP/IP.
OFTP bedeutet, Datenübertragungen per Odette Filetransfer gemäß VDA 4914-2 zu empfangen und zu senden. Dabei wird die Kommunikation von einem Partner initiiert. Nach Austausch von sogenannten Odette-IDs, die in Deutschland vom Verband der Automobilindustrie vergeben werden, und Passwörtern können Dateien in beiden Richtungen ausgetauscht werden. Die Dateien erhalten für die Übertragung einen vorkonfigurierten virtuellen Dateinamen. Ab OFTP Version 2 können die Daten verschlüsselt oder unverschlüsselt übertragen werden, vorher nur unverschlüsselt.
Nach der Übertragung erfolgt eine Bestätigung in Form einer End to End Response (EERP). Diese kann entweder unmittelbar nach der Übertragung innerhalb derselben Verbindung erfolgen oder der Empfänger wählt sich selbsttätig neuerlich zum ursprünglichen Absender zur Übertragung ein.
Erfolgt die Übertragung über einen Dritten, so wird das EERP erst vom endgültigen Empfänger zurück übermittelt.
Der Lobster Integration Server unterstützt alle OFTP-Versionen. Unsere Software wurde von Odette für OFTP2 zertifiziert und die Lobster GmbH wird von Odette in der Liste der OFTP2-konformen Software-Hersteller geführt.
Die Übertragung kann auf verschiedene Transportschichten aufbauen.
ISDN (B- und D-Kanal)
TCP/IP
TLS
Für den Betrieb mit ISDN ist eine CAPI-fähige ISDN-Karte und ein auf dem System installierter CAPI-Treiber notwendig, über den die ISDN-Karte programmtechnisch angesprochen werden kann. Da für die Verwendung des Treibers per Java eine sogenannte JNI-Schicht eingesetzt werden muss, ist je nach verwendetem Betriebssystem das Kompilieren einer speziellen C-Datei erforderlich. Für folgende Betriebssysteme existieren bereits vorkompilierte Dateien.
Alle unterstützten Windowsversionen
Linuxsysteme mit CAPI-2.0-Treibern (kein l4i)
BSD
Für Geräte, die das rcapi-Protokoll beherrschen, existiert ein Java-basierter Treiber, der ohne plattformspezifische Komponenten auskommt. Dann wird keine JNI-Schicht benötigt.
Für den Betrieb über TCP/IP muss der OFTP-Service entsprechend konfiguriert sein. Das folgende Listing zeigt den dazu notwendigen Eintrag in der Konfigurationsdatei ./etc/oftp.xml.
<Set name="useVersion2ReceiveThreads">True</Set> <!-- Version 2, sonst 1.3 --><Call name ="enableTCPListener"> <Arg>127.0.0.1</Arg> <!-- IP address binding to --> <Arg type="int">3305</Arg> <!-- Port listening to --> <Arg type="int">2</Arg> <!-- Number of acceptor threads --></Call>Auch wenn die Protokollversion 2 vereinbart ist, kann der Service mit Partnern kommunizieren, die diese Version noch nicht unterstützen. Dabei wird dynamisch die höchste Version ausgehandelt, die beide Seiten unterstützen.
OFTP2-Features nutzen
Wenn die TLS-Verschlüsselung für OFTP over TCP/IP tatsächlich genutzt werden soll, müssen weitere Voraussetzungen in der Konfiguration des OFTP-Service beachtet werden. Das folgende Listing zeigt den dazu notwendigen Eintrag in der Konfigurationsdatei ./etc/oftp.xml, um einen TLS-Listener zu aktivieren. Der TLS-Listener verwendet einen anderen TCP-Port, als der unverschlüsselte TCP-Listener.
<Call name="enableTLSListener"> <Arg>0.0.0.0</Arg> <!-- IP address binding to --> <Arg type="int">6619</Arg> <!-- TLS port listening to --> <Arg type="int">2</Arg> <!-- Number of acceptor threads --></Call><Set name="serverCertSubjectName">*CN=OFTP2TLSSECAUTH*</Set>Der OFTP-Service mit TLS-Listener braucht ein Zertifikat, um sich gegenüber den Clients auszuweisen, ganz analog zu einem sicheren Webserver. Dieses Zertifikat sucht der OFTP-Service aus der Menge der eigenen Zertifikate. Er findet diese eigenen Zertifikate anhand der X.500-Adresse des Zertifikats durch Vergleich mit dem Konfigurationsparameter serverCertSubjectName. Falls ein Teil der Adresse, z. B. der Canonical Name (CN=...) zur eindeutigen Kennzeichnung des Zertifikats ausreicht, können die anderen Teile der Adresse durch einen Platzhalter * ersetzt werden. Das Zertifikat muss natürlich in der Partnerverwaltung existieren. Damit ist der Service in der Lage ankommende TLS-Verbindungswünsche der Clients entgegenzunehmen.
Für die ausgehende Verbindungsrichtung gibt es weitere Konfigurationen in der Datei ./etc/oftp.xml. Das folgende Listing zeigt die Konfiguration für die Verwendung von Trusted Server Lists (TSL). Das erste Argument in addSCXHandlerSettings mit dem Wert OFTP2 ist der Name einer Liste von erlaubten Zertifizierungsstellen (CA), von denen ein Zertifikat beglaubigt sein muss, um gültig zu sein. Das zweite Argument ist eine URL, unter welcher diese Liste bereitgestellt wird. Es ist möglich, mehrere SCX-Handler mit verschiedenen Namen zu konfigurieren. Odette verwaltet außer der Liste OFTP2 für produktive OFTP2-Verbindungen auch noch die Liste TEST.
<Call name ="addSCXHandlerSettings"> <Arg>OFTP2</Arg> <!-- Name of the list --> <Arg>http://www.odette.org/TSL/</Arg> <!-- Managed by odette --></Call><Set name="acceptAllTLSCertificates">true</Set> <!-- Version 2, sonst 1.3 -->Mit dem Parameter acceptAllTLSCertificates kann man diese Liste umgehen, wenn der Wert true ist. Dann werden alle Zertifikate akzeptiert, also insbesondere selbst-signierte Zertifikate.
Hinweis: Bitte beachten Sie den Unterschied zwischen TLS (Transport Layer Security) und TSL (Trusted Server List).
Hinweis: Bitte stimmen Sie mit dem Kommunikationspartner ab, ob dieser auch selbst-signierte Zertifikate akzeptiert. Dadurch können Sie eventuell Zeit und Kosten für die Beglaubigung Ihres Zertifikats sparen. Wenn die Beglaubigung durch eine Zertifizierungsstellen (CA), die in der TSL enthalten ist, unbedingt erforderlich ist, dann entspricht der Signatur-Prozess dem im Abschnitt Selbstsigniertes oder durch Zertifizierungsstelle beglaubigtes Zertifikat? beschriebenen.
Praxistipp: Für viele Anwender ist der Grund für den Übergang von OFTP1 zu OFTP2 die Ablösung der ISDN-Verbindungen durch TCP-Verbindungen über das Internet. In diesem Fall sollen die Internet-Verbindungen über einen sicheren Kanal erfolgen, der ähnliche Sicherheitsmerkmale bietet, wie eine ISDN-Verbindung. Um dieses Ziel zu erreichen, reicht es üblicherweise aus, wenn die Internet-Verbindung über TLS (Transport Layer Security) verschlüsselt wird. Die zusätzlichen Möglichkeiten zur Verschlüsselung und Signierung der übertragenen Dateien, die zusätzlich im OFTP2-Protokoll implementiert sind, werden dann nicht genutzt, sondern nur der sichere Kanal über TLS. Bitte beachten Sie, dass dann parallel zu dem sicheren TLS-Listener nicht auch noch der unsichere TCP-Listener in ./etc/oftp.xml aktiviert ist, sofern keine unverschlüsselten TCP-Verbindungen ausdrücklich ermöglicht werden sollen. Prüfen Sie bitte auch, dass im OFTP2-Partnerkanal (Partnerverwaltung) nur dann der erlaubte Untertyp TCP/IP markiert sein soll, wenn Sie ausdrücklich die unverschlüsselte Übertragung zulassen wollen. Für die Konfiguration ausgehender Verbindungen wird in der Partnerverwaltung die Partneradresse eingetragen. Für TLS-Verbindungen muss diese Adresse mit oftps:// beginnen, für die unverschlüsselten TCP-Verbindungen mit oftp://.
Mehrere OFTP-Service-Instanzen
In Ausnahmefällen ist es erforderlich, mehr als einen OFTP-Service zu konfigurieren, z. B. wenn mehrere ISDN-Geräte angesteuert werden sollen. Dem zweiten und jedem weiteren OFTP-Service muss dann in seiner Konfigurationsdatei, z. B. ./etc/oftp_2.xml, ein Name zugewiesen werden, aber nicht dem ersten.
<Set name="name">OftpService_2</Set>Die verfügbaren Service-Namen stehen dann in den Dialogen für den zeitgesteuerten Eingangsagenten OFTP und den Antwortweg OFTP zur Auswahl.