OpenDACS API - Allways ACCESS_ALLOWED
We are trying to use the Java DACS Open API, and are following the tutorial set down.
From tutorial 5 we are generating a dacs lock via the PE codes available to the dacsId requested for via
public List<String> getUserSubServiceList(Handle dacsHandle) throws InterruptedException
{
while (!statusMap.containsKey(dacsHandle)) {
Thread.sleep(10);
}
Vector<AuthorizationUserSubServices> serviceList = new Vector<>();
AuthorizationCheckStatus status = new AuthorizationCheckStatus();
try {
AuthorizationCheckResult authCheckResult = dacsAgent.getUserSubServiceList(dacsHandle, status, SERVICE_NAME, serviceList);
if (authCheckResult == AuthorizationCheckResult.ACCESS_ALLOWED) {
return serviceList.stream()
.map(AuthorizationUserSubServices::getSubServiceName).collect(Collectors.toList());
}
} catch(AuthorizationException ae) {
LOGGER.error("AuthorizationAgent.getUserServiceList() failed");
}
return Lists.emptyList();
}
and cross checking the returned SubService (PDP) codes against the
authCheckResult = dacsAgent.getPeToSubServiceList(status, SERVICE_NAME, listPeToSs)
to generate the list of PE codes to supply to the Lock.
AuthorizationLock lock = new AuthorizationLock(subscribedService.getServiceId(), AuthorizationLock.OR, peCodes);
byte[] dacsLock = lock.getAuthorizationLock();
The using a checkSubscription call on a RIC
AuthorizationCheckResult authCheckResult = dacsAgent.checkSubscription(dacsLoginHandle, authUsage,
AuthorizationRequestType.NORMAL_REQUEST_LOGGING, authCheckStatus, SERVICE_NAME, ric, dacsLock);
This call ALLWAYS returns AuthorizationCheckResult.ACCESS_ALLOWED, even for those RICS which are disallowed under DACS, and return an error when requesting over the EMA libraries in real-time.
So the questions are:
1. What are we doing wrong
2. Are we using the correct service name, currently we have it set to hEDD.
Best Answer
-
Thank you for reaching out to us.
The DACS lock of a subscribed item could be different from the dacslock used in the dacsAgent.checkSubscription.
Typically, the DACS lock should look like this.
0x03 0x01 0x01 0x62 0x16 0xC0
0x01 0x01 represents the serviceId (257).
0x62 0x16 represents PE (6216).Therefore, please check the byte values in byte[] dacsLock.
The service name depends on the setup environment. It could be "hEDD" but please check with your infrastructure or server team. However, it should be the same service name used by EMA.
0
Answers
-
Re-doing the tests with a cut down set of PE codes
RIC = XYL.MX (an equity on the MEX pdp code)
TEST1
long[] peCodes = new long[] {85, 88}; // MEX pe codes
TEST2
long[] peCodes = new long[] {1, 2}; // OSAKA pe codes
Where we do NOT have entitlements to the MEX pdp code
Test 1 result = Access Denied: DACS User Profile denied access (Access Denied: User req to IDN for Prod e.g. - WWDSMCRSP) (LOGGED_IN) (ACCESS_DENIED) (UNSPECIFIED_RATE) (UNSPECIFIED_TIMELINESS)
Test 2 result = Access Allowed: (LOGGED_IN) (ACCESS_ALLOWED) (UNSPECIFIED_RATE) (UNSPECIFIED_TIMELINESS)
So does the check take into account the RIC being passed at all?
On a third test we decided to mix the MEX and Osaka codes together
TEST3
long[] peCodes = new long[] {1, 2, 85, 88};
When combined like this and the AuthorizationLock.AND option specified we get the ACCESS_DENIED
When combined like this and the AuthorizationLock.OR option specified we get the ACCESS_ALLOWED
Which would tend to convince that the only thing actually being checked was the PE codes, and not the RIC in the slightest.
0 -
Following up on this - is there a copy of the source code anywhere we can debug through to see what exactly is happening under the covers
0 -
As far as I know, Content Base Entitlement (CBE) performs entitlement checks against DACS Locks. We don't provide the OpenDACS API source code.
You may contact the DACS support team directly via MyAccount for more information regarding entitlement checks.
0
Categories
- All Categories
- 6 AHS
- 37 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 中文论坛