How to use single session supporting multiple users for remote authentication in SSL RFA Java Subscriber?

Hello @Akechi Sato

Unfortunately, Tokenized Principal Identity used for remote authentication (TREP works with DACS Infrastructure) is bind in Session level using Session.acquire(Sting, TokenizedPrincipalIdentity). There is no any creating Event source method that accepts TokenizedPrincipalIdentity. Only StandardPrincipalIdentity for local authentication(RFA works with DACS Infrastructure) is accepted and this allows the application can have single session. Normally, StandardPrincipalIdentity is used when the application connects to RTIC which is end of life and we do not support RFA connecting to it. Hence, this is impossible that the application will have single Session for multiple users with Remote authentication.

There are 2 possible workarounds that I suggest:

1. Implement the application to have multiple Sessions with Remote authentication to serve multiple users. Hence, the permission/entitlement checks are still on TREP side.
2. Integrate the application with Open DACS API which is embedded in rfa.jar. By using Open DACS API, the application can work with DACS Infrastructure likewise TREP does. The application will have single Session but the permission/entitlement checks are on the application side. Open DACS API verify if the validated user is entitled to receive the requested item from the specified service. It performs permission/entitlement check against the DACS Lock retrieved from a Refresh/Permission Data message of the item for which the OMM/MarketData application subscribes. If the user is allowed to access the requested item, the data should be forwarded to the user. For more details and example application, please refer to Tutorial 5 - Integrating DacsClient with StarterConsumer

The example in the Tutorial 5 does not use MarketData interface(Legacy interface) that your application use; it uses OMM interface.If you would not like to migrate to OMM interface, you can modify your application based on the Tutorial. However, some steps must be changed for MarketData interface as listed below:

• Step 2.1: Performing Login to DACS Infrastructure after login to ADS successfully. When MarketData application logins to ADS successfully, it will get ConnectionEvent with UP state. Hence, the source code of this step should be executed when the application receives ConnectionEvent with UP state as the example shown below:

protected void processConnectionEvent(ConnectionEvent connectionEvent){ 
      if(connectionEvent.getConnectionStatus().getState() == ConnectionStatus.UP) {
            //highlight source code in step 2.1
            ...
      }
}

• Step 4: Getting the DACS Lock from a Refresh of the item. DACS Lock in SSL connection used by MarketData interface is not in a Refresh but it is in a Permission Data message. Hence, the application has to check if it receives Permission Data then get the DACS Lock in data. The example source code

protected void processMarketDataItemEvent(MarketDataItemEvent marketDataItemEvent)
{
      ...
      else if (marketDataItemEvent.getMarketDataMsgType() == MarketDataItemEvent.PERMISSION_DATA)
        {
            // PERMISSION_DATA,
            System.out.println("Received MARKET_DATA_ITEM_EVENT (misc), service = "+ marketDataItemEvent.getServiceName() + ", msgType = " + marketDataItemEvent.getMarketDataMsgType() + ", item = "+ marketDataItemEvent.getItemName());
            byte [] dacsLock = null;
            dacsLock = marketDataItemEvent.getData().clone();
            System.out.println("DACS Lock was got from the Permission data");
        }
}