Bei der Authentifizierung sind drei Einsatzfälle zu unterscheiden:
Fall 1:
Die lokale openFT-Instanz überprüft die Identität der Partnerinstanz. Das setzt voraus, dass lokal ein aktueller öffentlicher Schlüssel der Partnerinstanz abgelegt wurde, siehe Abschnitt „Schlüssel von Partnersystemen“.
Eine derartige Konfiguration macht beispielsweise Sinn, wenn per openFT auf Dateien eines File Servers zugegriffen werden soll. Für die lokale openFT-Instanz ist es wichtig, dass die bezogenen Daten aus einer sicheren Quelle (dem authentifizierten Partner) kommen, umgekehrt ist es für den File Server unerheblich, wer dort zugreift.Fall 2:
Die Partnerinstanz überprüft die Identität der lokalen openFT-Instanz. Das setzt voraus, dass ein aktueller öffentlicher Schlüssel der lokalen openFT-Instanz in der Partnerinstanz hinterlegt ist (bei Unix- und Windows-Partnern umcodiert), siehe Abschnitte „Lokale RSA-Schlüsselpaare“ und „Sicheres Verteilen von Schlüsseln“.
Eine solche Konfiguration wäre beispielsweise denkbar, wenn von einem zentralen Rechner per openFT auf Partnersysteme in mehreren Filialen zugegriffen werden soll und die Filialrechner nur Zugriffe des Zentralrechners (und wirklich nur dieses Rechners) zulassen dürfen.Fall 3:
Beide an einer Übertragung beteiligten openFT-Instanzen authentifizieren sich gegenseitig (Kombination aus Fall 1 und Fall 2). Das setzt voraus, dass gegenseitig aktuelle öffentliche Schlüssel ausgetauscht wurden und sich die Partner über ihre Instanzidentifikationen adressieren. Damit ist gewährleistet, dass die Daten sowohl aus einer sicheren Quelle stammen als auch nur in sichere Hände gelangen.
Bei Konfigurationsfehlern, die die Authentifizierung eines der an einem Auftrag beteiligten Partner verhindern, kommt keine Session zustande, in der der Auftrag durchgeführt werden kann. Daher lässt sich das Problem nicht am Auftragszustand, sondern am Partnerzustand ablesen. Der Partnerzustand (RAUTH oder LAUTH) gibt Auskunft darüber, auf welcher Seite das Problem erkannt wurde.