How to use single session supporting multiple users for remote authentication in SSL RFA Java Subscr
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?
Best Answer
-
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:- Implement the application to have multiple Sessions with Remote
authentication to serve multiple users. Hence, the permission/entitlement
checks are still on TREP side. - 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");
}
}1 - Implement the application to have multiple Sessions with Remote
Categories
- All Categories
- 6 AHS
- 39 Alpha
- 161 App Studio
- 4 Block Chain
- 4 Bot Platform
- 16 Connected Risk APIs
- 47 Data Fusion
- 30 Data Model Discovery
- 608 Datastream
- 1.3K DSS
- 577 Eikon COM
- 4.9K Eikon Data APIs
- 7 Electronic Trading
- Generic FIX
- 7 Local Bank Node API
- Trading API
- 2.7K Elektron
- 1.3K EMA
- 236 ETA
- 519 WebSocket API
- 33 FX Venues
- 10 FX Market Data
- 1 FX Post Trade
- 1 FX Trading - Matching
- 12 FX Trading – RFQ Maker
- 5 Intelligent Tagging
- 2 Legal One
- 20 Messenger Bot
- 2 Messenger Side by Side
- 9 ONESOURCE
- 7 Indirect Tax
- 59 Open Calais
- 264 Open PermID
- 39 Entity Search
- 2 Org ID
- PAM
- PAM - Logging
- 8.4K Private Comments
- 6 Product Insight
- Project Tracking
- ProView
- ProView Internal
- 20 RDMS
- 1.4K Refinitiv Data Platform
- 367 Refinitiv Data Platform Libraries
- 3 Refinitiv Due Diligence
- LSEG Due Diligence Portal API
- 3 Refinitiv Due Dilligence Centre
- Rose's Space
- 1.1K Screening
- 18 Qual-ID API
- 13 Screening Deployed
- 23 Screening Online
- 10 World-Check Customer Risk Screener
- 990 World-Check One
- 44 World-Check One Zero Footprint
- 45 Side by Side Integration API
- Test Space
- 3 Thomson One Smart
- 1.2K TR Internal
- Global Hackathon 2015
- 2 Specialists Who Code
- 10 TR Knowledge Graph
- 150 Transactions
- 142 REDI API
- 1.7K TREP APIs
- 4 CAT
- 21 DACS Station
- 117 Open DACS
- 1.1K RFA
- 103 UPA
- 172 TREP Infrastructure
- 224 TRKD
- 886 TRTH
- 5 Velocity Analytics
- 5 Wealth Management Web Services
- 59 Workspace SDK
- 9 Element Framework
- 5 Grid
- 13 World-Check Data File
- Yield Book Analytics
- 46 中文论坛