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

...scriber?
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");
}
}0 - Implement the application to have multiple Sessions with Remote
Categories
- All Categories
- 3 Polls
- 6 AHS
- 36 Alpha
- 166 App Studio
- 6 Block Chain
- 4 Bot Platform
- 18 Connected Risk APIs
- 48 Data Fusion
- 34 Data Model Discovery
- 689 Datastream
- 1.4K DSS
- 627 Eikon COM
- 5.2K Eikon Data APIs
- 11 Electronic Trading
- 1 Generic FIX
- 7 Local Bank Node API
- 3 Trading API
- 2.9K Elektron
- 1.4K EMA
- 255 ETA
- 559 WebSocket API
- 39 FX Venues
- 15 FX Market Data
- 1 FX Post Trade
- 1 FX Trading - Matching
- 12 FX Trading – RFQ Maker
- 5 Intelligent Tagging
- 2 Legal One
- 24 Messenger Bot
- 3 Messenger Side by Side
- 9 ONESOURCE
- 7 Indirect Tax
- 60 Open Calais
- 278 Open PermID
- 44 Entity Search
- 2 Org ID
- 1 PAM
- PAM - Logging
- 6 Product Insight
- Project Tracking
- ProView
- ProView Internal
- 23 RDMS
- 2K Refinitiv Data Platform
- 706 Refinitiv Data Platform Libraries
- 4 LSEG Due Diligence
- LSEG Due Diligence Portal API
- 4 Refinitiv Due Dilligence Centre
- Rose's Space
- 1.2K Screening
- 18 Qual-ID API
- 13 Screening Deployed
- 23 Screening Online
- 12 World-Check Customer Risk Screener
- 1K World-Check One
- 46 World-Check One Zero Footprint
- 45 Side by Side Integration API
- 2 Test Space
- 3 Thomson One Smart
- 10 TR Knowledge Graph
- 151 Transactions
- 143 REDI API
- 1.8K TREP APIs
- 4 CAT
- 27 DACS Station
- 121 Open DACS
- 1.1K RFA
- 106 UPA
- 194 TREP Infrastructure
- 229 TRKD
- 918 TRTH
- 5 Velocity Analytics
- 9 Wealth Management Web Services
- 96 Workspace SDK
- 11 Element Framework
- 5 Grid
- 19 World-Check Data File
- 1 Yield Book Analytics
- 48 中文论坛