question

Upvotes
Accepted
malcolm.cudworth avatar image
1 ●0 ●0 ●0

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.

#productopen-dacsentitlements
icon clock
10 |1500

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

2 Answers

· Write an Answer
Upvotes
Accepted
Jirapongse avatar image
86.8k ●294 ●53 ●79

@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.

icon clock
10 |1500

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

Upvotes
malcolm.cudworth avatar image
1 ●0 ●0 ●0

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.


icon clock
10 |1500

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

malcolm.cudworth avatar image 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

Jirapongse avatar image Jirapongse malcolm.cudworth

@malcolm.cudworth

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.

Write an Answer

Hint: Notify or tag a user in this post by typing @username.

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