question

Upvotes
Accepted
129 6 14 23

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

My application works as a proxy for different users which are connecting to it to get data from TREP(ADS/ADH). I would like to use Remote authentication that entitlements are done in TREP site. I have found in RFA Java Developer Guide that

-“For remote environments, the application must supply the Tokenized Principal Identity when creating the Session. This is because remote environments authenticate the user upon the initial connection.”

- "An application may supply the Tokenized Principal Identity either when creating the Session or when configuring “userName” in SSL configuration.”

This seems that my application needs to have multiple sessions for multiple users. Is it true? If not, how to implement SSL subscriber application to have single session supporting multiple users for Remote authentication?

treprfarfa-apisslconsumer
icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 5.0 MiB each and 10.0 MiB total.

1 Answer

Upvote
Accepted
9.5k 10 5 7

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");
        }
}
icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 5.0 MiB each and 10.0 MiB total.

Click below to post an Idea Post Idea