DMS API calls with Logged in User Token

[abdulbasitg]

Hello Team,

I'm using the plugin in my CAP application and it works perfect. However, I have a complex scenario where I'm having issues with the plugin.

Scenario

I have a CAP application with HANA DB + DMS services. I want to deploy this CAP application to two different subaccounts in different regions (EU10 and AP11) but use the HANA DB and DMS instances centrally to make sure that both applications point to the same DB and DMS repository.

On the main subaccount, application is deployed with standard configurations. On the second subaccount, I'm creating user-provided service instances for HDI Container and DMS by providing credentials from the service instances in the main subaccount.

My application is able to access HDI Container as expected but I'm having errors in sdm plugin during the DMS access.

I've debugged the application and found that it is failing in generating tokens to access DMS API's.

Problem 1:

getClientCredentialsToken method in lib/util/index.js

let subdomain = cds.context.user?.tokenInfo?.getPayload()?.ext_attr?.zdn;

In this part of the code, the subdomain is retrieved from the user token and forwarded to the:

requests.requestClientCredentialsToken(
  subdomain,
  credentials.uaa,
  null
...
...

Since the subdomain of token endpoint (credentials.uaa.url) and user token is different, this method is trying to replace the tokenurl with the provided subdomain which generates an incorrect endpoint and token generation fails.

Problem 2:

generateSDMBearerToken method in lib/util/index.js

In this part of the code, the access token is being created with password grant_type which uses JWT token retrieved from user context.

Since the user specific JWT is used here, and this token is generated in different subaccount than the original service instance, API call returns unauthorized as expected.

I've tried to fix these errors locally and deployed the modified version. I'm now able to access to the DMS and all operations works fine.

Question/Recommendation:

DMS API has two different access options as described in the following documentation:

https://help.sap.com/docs/document-management-service/sap-document-management-service/develop-using-client-credential-flow?locale=en-US

As desribed in Step 2 & 3, it is possible to access DMS API with technical user ID (client id/secret from service instance/key) and user JWT token. However, based on my understanding, this plugin relies on the user's JWT token.

Since the plugin is attached to the CAP application, and all authorizations can be handled in CAP, I would expect technical user token is used in the plugin instead of user token. It might also be possible make this setting configurable with sdm settings in package.json.

I'm planning to use this plugin in many different applications in our landscape but this issue is a main blocker for us. Should I expect a fix in this part in future releases or do you think this is a limitation of the plugin and want to keep it as is?

I’d be happy to submit a pull request with my fix as well.

Thanks
Abdulbasit.

[dheerasameerk]

@abdulbasitg Thank you sharing your inputs. We will discuss on this issue and get back to you soon.

[dheerasameerk]

@abdulbasitg We plan to continue to use user token but I also want to hear your proposal on support of client credentials flow. Can you please share your proposal how you see this implemented?
Can you also share

• how you configured the sdm instance with CAP application for the secondary region, maybe the mta.yaml?
• a draft PR on the changes you propose in plugin?

[ashishjain14]

Hi @abdulbasitg : Any update on this?

[abdulbasitg]

Hi,

On the main region, I'm creating a regular SDM instance with the following yaml code:

  - name: my-dms-instance
    type: org.cloudfoundry.managed-service
    parameters:
      service: sdm
      service-plan: standard   

For the second region, first I download the instance credentials from the SDM instance on the main region and put it into a json file on the project folder. Then, I've the following yaml code for my second region deployment:

  - name: my-dms-instance-remote
    type: org.cloudfoundry.user-provided-service
    parameters:
      path: my-dms-instance-key.json
      service-tags:
        - "sdm"

After deploying with this mta.yaml, User-Provided Service instance is created on my subaccount with the credentials provided in the json file.

Then, I'm adding this resource into the dependency of my main service. The app can recognize this service and tries to connect but fails on the following command:

let subdomain = cds.context.user?.tokenInfo?.getPayload()?.ext_attr?.zdn;

Since the subdomain is different on my second region, generateSDMBearerToken method call does not work.

I tried to replace fetchAccessToken with getClientCredentialsToken and it worked successfully. However, after I update the sdm plugin to 1.3.2 version, which has been released recently, I started to have new issues. I need to do some cleanups and fixes in my code before sending it as a pull-request.

In parallel, I'm trying to create a new CAP plugin based on the SDM plugin fixing the parts that I'm having token issues. That seems to be a better solution for me. In this way, I can keep my changes in a separate project and easier to align with the new updates from the SDM plugin.

Let me know if you need further details.

BTW, user-provided instance method on the second region works successfully for hdi container instances. I'm able to connect to the same HDI container from two different regions using this approach.

Thanks,
Abdulbasit.

[dheerasameerk]

@abdulbasitg Thanks for sharing information.
Good to hear that you were able to make changes to the plugin to make it work for your use case. Please continue to use the new plugin which you are creating.
Based on the changes you suggested, we will create a backlog for this and will prioritize based on the capacity.

[abdulbasitg]

BTW, I've found another way to handle my requirement. I've created a DMS Integration Option instance on my second region and onboarded my main DMS repository as an external repository to the new instance.

This is better solution for me, since it will not require any change on the mta.yaml file. I can deploy with the same configurations to both subaccounts, without making additional changes for the second region.

I'll still continue to work on extending the plugin and post the updates here.