Session – Logon Protocol
The logon message is utilized to authenticate a user attempting to establish a connection to a remote system. The logon message must be the first message sent by the application requesting to initiate a FIX session.
The HeartBtInt (108) field is used to declare the timeout interval for generating heartbeats.
Upon receipt of a Logon message the session acceptor will authenticate the party requesting connection and issue a Logon message as acknowledgment that the connection request has been accepted. The acknowledgment Logon can also be used by the initiator to validate that the connection was established with the correct party.
The session acceptor must be prepared to immediately begin processing messages after receipt of the Logon. The session initiator can choose to begin transmission of FIX messages before receipt of the confirmation Logon, however it is recommended that normal message delivery wait until after the return Logon is received to accommodate encryption key negotiation.
The confirmation Logon can be used for encryption key negotiation. If a session key is deemed to be weak, a stronger session key can be suggested by returning a Logon message with a new key. This is only valid for encryption protocols that allow for key negotiation. (See the FIX Home Page Application notes for more information on a method for encryption and key passing.)
The logon format is as follows:
Tag | Field Name | Req'd | Description |
---|---|---|---|
8 | BeginString | Y | FIX.4.0 (Always unencrypted, must be first field in message) |
9 | BodyLength | Y | (Always unencrypted, must be second field in message) |
35 | MsgType | Y | (Always unencrypted, must be third field in message) |
49 | SenderCompID | Y | (Always unencrypted) |
56 | TargetCompID | Y | (Always unencrypted) |
115 | OnBehalfOfCompID | N | Trading partner company ID used when sending messages via a third party (Can be embedded within encrypted data section.) |
128 | DeliverToCompID | N | Trading partner company ID used when sending messages via a third party (Can be embedded within encrypted data section.) |
90 | SecureDataLen | N | Required to identify length of encrypted section of message. (Always unencrypted) |
91 | SecureData | N | Required when message body is encrypted. Always immediately follows SecureDataLen field. |
34 | MsgSeqNum | Y | (Can be embedded within encrypted data section.) |
50 | SenderSubID | N | (Can be embedded within encrypted data section.) |
57 | TargetSubID | N | “ADMIN” reserved for administrative messages not intended for a specific user. (Can be embedded within encrypted data section.) |
116 | OnBehalfOfSubID | N | Trading partner SubID used when delivering messages via a third party. (Can be embedded within encrypted data section.) |
129 | DeliverToSubID | N | Trading partner SubID used when delivering messages via a third party. (Can be embedded within encrypted data section.) |
43 | PossDupFlag | N | Always required for retransmissions, whether prompted by the sending system or as the result of a Resend Request. (Can be embedded within encrypted data section.) |
97 | PossResend | N | Required when message may be duplicate of another message sent under a different sequence number. (Can be embedded within encrypted data section.) |
52 | SendingTime | Y | (Can be embedded within encrypted data section.) |
122 | OrigSendingTime | N | Required for message resends. If data is not available set to same value as SendingTime (Can be embedded within encrypted data section.) |
112 | TestReqID | N | Required when the heartbeat is the result of a Test Request message. |
93 | SignatureLength | N | Required when trailer contains signature. Note: Not to be included within SecureData field |
89 | Signature | N | Note: Not to be included within SecureData field |
10 | CheckSum | Y | (Always unencrypted, always last field in message) |