How to use single session supporting multiple users for remote authentication in SSL RFA Java Sub...

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");
        }
}