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.

Find more posts tagged with

entitlements

open-dacs

#product

Accepted answers

Jirapongse

@malcolm.cudworth

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.

All comments

Jirapongse

@malcolm.cudworth

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.

malcolm.cudworth

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.

malcolm.cudworth

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

EXPLORE OUR SITES