Basically, there are three distinct usages:
Case 1:
The local openFT instance checks the identity of the partner instance. This assumes that a current, public key of the partner instance was stored locally, see section "Keys of partner systems".
A configuration of this kind makes sense, for example, if a server’s files are to be accessed via openFT. It is important for the local openFT instance, that the received data come from a reliable source (the authenticated partner). In contrast, the source of an access attempt is unimportant to the server.Case 2:
The partner instance checks the identity of the local openFT instance. This requires that a current, public key of the local openFT instance is stored in the partner instance (recoded in the case of Unix and Windows partners), see section "Local RSA key pairs" and section "Secure distributing of keys".
A configuration of this kind would be conceivable, for example, if partner systems in several branch offices were to be accessed from a central computer via openFT and the branch computers were only permitted to access the central computer (and, in fact, only the central computer).Case 3:
Both of the openFT instances engaged in a transfer authenticate each other (combination of case 1 und case 2). This assumes that current, public keys were mutually exchanged and the partners are addressing each other using their instance IDs. In this way, it can be ensured that the data not only comes from a reliable source, but that it will also end up in reliable hands.
In the case of configuration errors that inhibit the authentication of one of the partners participated in the request no session is created which can execute the request. As a result, the problem can be identified not on the basis of the request status but of the partner status. The partner state (RAUTH or LAUTH) shows on which side the problem was recognized.