Server Side Session Management

, ,
1

Imported from previous forum

2

Hi -

Our FIX client performs a FIX Logon before placing orders and general messaging, after the Logon only our username is sent in the SenderCompID (tag 49) which seems to be the case with most API’s and software. I am guessing that the server does some sort of check their side to tie this to the Logon message. What stops FIX clients changing the SenderCompID to that of another user?

This is a generic question, just want some high level answers or suggestions on how people approach this - it seems like a gaping security hole to me or maybe im missing the point?

Thanks,

John

3

It depends upon individual implementations but aside from the username & password we usually keep track of the sender comp ID emanating from the logon message throughout the session.

All subsequent messages need to contain the same sender comp ID or if different then a permissioning mechanism needs to be in place to validate incoming sender comp ID’s, on behalf of comp ID’s etc.

For example sender comp ID ABC logs in and then also sends an order with sender comp ID XYZ – this particular market participant might have registered multiple sender comp ID’s with the counterparty so then it becomes a seamless process for the entitlement of that order to go to XYZ as long as the counterparty is able to validate that ABC & XYZ belong to the same entity.

–Aditya Kapur

Hi -

Our FIX client performs a FIX Logon before placing orders and general messaging, after the Logon only our username is sent in the SenderCompID (tag 49) which seems to be the case with most API’s and software. I am guessing that the server does some sort of check their side to tie this to the Logon message. What stops FIX clients changing the SenderCompID to that of another user?

This is a generic question, just want some high level answers or suggestions on how people approach this - it seems like a gaping security hole to me or maybe im missing the point?

Thanks,

John