Request destination from other subaccount without BTP multi tenancy

[brampurnot]

Hi there!

we have a very specific architecture where we we have our app deployed in multiple Kyma clusters in different regions. The idea is that customers will be redirected to the cluster with the best response time and only when all services are healthy.

For this particular use-case, we cannot use the standard BTP Multi tenancy concept with the SaaS registry. What we want to achieve now is that we deploy our app in multiple subaccounts within the same global account.

Tenants will still have their own subaccount in their region of choice. SAP IAS is used for the identity federation part. The challenge we have now is that we want to create the destinations in the subaccounts of the tenants. Therefore we need to be able to access the subaccounts destination service. We currently store the service binding details upon onboarding of the tenant in the credstore.

We are able to create and get the destinations by using the old SAP Cloud SDK Core fetchDestination function: cloudSDK.fetchDestination(<<tenant destination URI>>, <<access_token>>)

However we are not able to do the same with the new getDestination. We have tried with a custom serviceBindingTransformFn and also with the iss but keep on getting the following error: JKU of the JWT token (https://digicore.authentication.ap10.hana.ondemand.com/token_keys) does not match with the uaa domain (authentication.sap.hana.ondemand.com). Use legacy-token-key.

Is there any possibility to achieve this with the SAP Cloud SDK V2?

Thanks, Bram

[FrankEssenberger]

Hello @brampurnot,

the error you are seeing is related to the fact that we changed our token exchnage part to use @sap/xssec which tries do get a token for the destination service using a JWT having a different landscape then the service.

To my knowledge the destination service is isolated to a landscape so you need a way to hand in the URL of the destination service. We do not offer this on the getDestination API because this is not needed in general. However we still export the methods we use internally like the fetchDestination. They are found under the internal path:

import {fetchDestination} from '@sap-cloud-sdk/connectivity/internal`;

For these methods you do not have a guarantee of semantic versioning but with a test coverage you could still include them with some confidence.

I think we will not offer the fecthDestination as part of the public API but we will keep it internally with a high likelyhood. Alternatively you could also do a small rewrite using public methods:

• Get a service token for the destination service using serviceToken
• Make a call to the desitntaion service using the token we have a executeHttpRequest() method if you want to use it here is the API of the destination service
• Parse destination with parseDestination

Best Frank