SAP
Urgent: Support Broker Request to fetch Destinations
Describe the Problem
Hi Experts,
I have an request which is related to the destination fetch of an Broker instance. Currently it is not supported that a service broker could call a destination, because it could not identify the XSUAA service.
Error if I try to call a destination: Could not find XSUAA service binding matching the token.
I went deeper to the analysis and found out that its true the clientID and the audiences are not matching. But if I look on the details which are there it should be fine to let the request through.
Let me explane.
The request comes with @sap-cloud-sdk/connectivity/dist/scp-cf/environment-accessor/xsuaa.js -> getXsuaaServiceCredentials.
Over here we have the token.
Inside of those method(getXsuaaServiceCredentials) the method @sap-cloud-sdk/connectivity/dist/scp-cf/environment-accessor/service-credentails.js -> getServiceCredentials is called.
There with the method getServiceBindingsWithCredentials will bring back the xsuaa instance.
After that a check is done via getCredentialsWithJwt if the token matches the xsuaa.
Inside of it the credentails parameter holds the xsuaa instance which is like that:
apiurl: "https://api.authentication.eu10.hana.ondemand.com"
clientid: "sb-kdtaskprocessor-auth-tddoemdev!bXXXXXX"
clientsecret: "..."
credential-type: "binding-secret"
identityzone: "oem-dev-csrd95hr"
identityzoneid: "491294...9c2b5b5"
sburl: "https://internal-xsuaa.authentication.eu10.hana.ondemand.com"
serviceInstanceId: "cc38d6...34c971"
subaccountid: "4912...c2b5b5"
tenantid: "4912...c2b5b5"
tenantmode: "shared"
trustedclientidsuffix: "|kdtaskprocessor-auth-tddoemdev!bXXXXXX"
uaadomain: "authentication.eu10.hana.ondemand.com"
url: "https://oem-...hr.authentication.eu10.hana.ondemand.com"
verificationkey: "-----BEGIN PUBLIC KEY-----...-----END PUBLIC KEY-----"
xsappname: "kdtaskprocessor-auth-tddoemdev!bXXXXXX"
zoneid: "4912...c2b5b5"
Now it checks if the token has a matching client or audience. But with a token from a service broker, the clientid or the audience will never be the same.
Thats my current Problem.
Propose a Solution
My suggested solution here is to see if it's not ok to just check if the clientID has the identical trustedclientidsuffix that is present in the service bindings. Because then it's okay for the broker to request the destinations, right?
Service Broker Token details:
{
"jti": "7f2554...7fd5",
"ext_attr": {
"enhancer": "XSUAA",
"subaccountid": "7fa1e...d7e7",
"zdn": "oem-test",
"serviceinstanceid": "a60f0...7f50fb"
},
"sub": "sb-a60f...0fb!bXXXXXX|kdtaskprocessor-auth-tddoemdev!bXXXXXX",
"authorities": [
"uaa.resource"
],
"scope": [
"uaa.resource"
],
"client_id": "sb-a60f...0fb!bXXXXXX|kdtaskprocessor-auth-tddoemdev!bXXXXXX",
"cid": "sb-a60f...0fb!bXXXXXX|kdtaskprocessor-auth-tddoemdev!bXXXXXX",
"azp": "sb-a60f...0fb!bXXXXXX|kdtaskprocessor-auth-tddoemdev!bXXXXXX",
"grant_type": "client_credentials",
"rev_sig": "27c5e207",
"iat": 1750163611,
"exp": 1750206811,
"iss": "https://oem-stest-test-y8zx6ymv.authentication.eu10.hana.ondemand.com/oauth/token",
"zid": "7fa1e...4d7e7",
"aud": [
"uaa",
"sb-a60f...0fb!bXXXXXX|kdtaskprocessor-auth-tddoemdev!bXXXXXX"
]
}
XSUAA Details:
apiurl: "https://api.authentication.eu10.hana.ondemand.com"
clientid: "sb-kdtaskprocessor-auth-tddoemdev!bXXXXXX"
clientsecret: "..."
credential-type: "binding-secret"
identityzone: "oem-dev-csrd95hr"
identityzoneid: "491294...9c2b5b5"
sburl: "https://internal-xsuaa.authentication.eu10.hana.ondemand.com"
serviceInstanceId: "cc38d6...34c971"
subaccountid: "4912...c2b5b5"
tenantid: "4912...c2b5b5"
tenantmode: "shared"
trustedclientidsuffix: "|kdtaskprocessor-auth-tddoemdev!bXXXXXX"
uaadomain: "authentication.eu10.hana.ondemand.com"
url: "https://oem-...hr.authentication.eu10.hana.ondemand.com"
verificationkey: "-----BEGIN PUBLIC KEY-----...-----END PUBLIC KEY-----"
xsappname: "kdtaskprocessor-auth-tddoemdev!bXXXXXX"
zoneid: "4912...c2b5b5"
So if something inside of the token aud [] has a audience with trustedclientidsuffix or the client ID matches the pattern it is good to go.
Method which is the relevant one:
@sap-cloud-sdk/connectivity/dist/scp-cf/environment-accessor/service-credentails.js -> getCredentialsWithJwt
-> matchesClientId
-> matchesAudience
Describe Alternatives
No response
Affected Development Phase
Production
Impact
Blocked
Timeline
I am blocked to use the newest SDK Cloud packages. So security Issues already are there.
Additional Context
Used packages: "@sap-cloud-sdk/connectivity": "^3.26.4", "@sap-cloud-sdk/http-client": "^3.26.4", "@sap/cds": "^8", "@sap/xssec": "^4.8.0",
Actual prod packages: "@sap-cloud-sdk/connectivity": "3.15.0", "@sap-cloud-sdk/http-client": "3.15.0", "@sap/cds": "^8", "@sap/xssec": "4.2.1",
Thanks for the ticket and the report. We are investigating the issue and will notify you when we have any further updates.
Hi @ChristophMatthies, I wanted to ask if you have already some updates.
Best regards, Max
Hi @maxpfab, thanks for checking in. We've discussed this item in the team. The ticket is currently in the Input Queue, waiting to be picked up by a developer with capacity to investigate. Thanks for your patience.
Hello @maxpfab,
The error message Could not find XSUAA service binding matching the token is thrown either while trying to verify the incoming XSUAA JWT or while trying to fetch a client credentials token to access a destination service.
In canary version, 4.0.3-20250718125934.0 we no longer verify the incoming JWTs and use UAA credentials inside the destination service to obtain the service token.
Although the fix you are asking for is in another function altogether, the error message you point out probably comes from the JWT verification step.
Can you test with the canary version to see if the issue still persists?
Hello @KavithaSiva,
I used now the following packages: "dependencies": { "@cap-js/hana": "^1.9.1", "@sap-cloud-sdk/connectivity": "4.0.3-20250718125934.0", "@sap-cloud-sdk/http-client": "4.0.3-20250718125934.0", "@sap/cds": "^8.9.4", "@sap/cds-mtxs": "^2.7.6", "@sap/xssec": "^4.9.0", "axios": "^1.10.0", "cfenv": "^1.2.4", "express": "^4.21.2", "moment-timezone": "^0.6.0" },
Also I have linked the destination like that inside of the cds config: "cds":
{
"profile": "with-mtx-sidecar",
"log": {
"format": "plain",
"levels": {
"cds": "off",
"performance-rebook": "debug"
}
},
"features": {
"kibana_formatter": false
},
"requires": {
"multitenancy": true,
"db": {
"kind": "hana",
"vcap": {
"label": "sm",
"plan": "container"
}
},
"auth": "xsuaa",
"public_equipment_api": {
"kind": "odata-v2",
"credentials": {
"destination": "public_equipment_api",
"requestTimeout": 600000
},
"destinationOptions": {
"selectionStrategy": "alwaysSubscriber",
"useCache": true
}
}
}
}
Still I get another issue: 2025-07-23T09:44:58.97+0000 [APP/PROC/WEB/0] OUT [cds|789b22a5-b692-47bf-87b9-27d0259b7836] - connect to public_equipment_api > odata-v2 { destination: 'public_equipment_api', requestTimeout: 600000 } 2025-07-23T09:44:58.97+0000 [APP/PROC/WEB/0] OUT [performance-rebook|789b22a5-b692-47bf-87b9-27d0259b7836] - Public Equipment API | /S2A_EquipmentMasterDataSet?$filter=EquiID eq '1600424f-0b0f-4017-82a5-00b2f2d3737e' 2025-07-23T09:44:59.21+0000 [APP/PROC/WEB/0] ERR [remote|789b22a5-b692-47bf-87b9-27d0259b7836] - Error: Error during request to remote service: Failed to resolve the destination 'name: public_equipment_api'. 2025-07-23T09:44:59.21+0000 [APP/PROC/WEB/0] ERR at run (/home/vcap/deps/0/node_modules/@sap/cds/libx/_runtime/remote/utils/client.js:251:31) 2025-07-23T09:44:59.21+0000 [APP/PROC/WEB/0] ERR at process.processTicksAndRejections (node:internal/process/task_queues:105:5) 2025-07-23T09:44:59.21+0000 [APP/PROC/WEB/0] ERR at async RemoteService.on_handler (/home/vcap/deps/0/node_modules/@sap/cds/libx/_runtime/remote/Service.js:281:20) 2025-07-23T09:44:59.21+0000 [APP/PROC/WEB/0] ERR at async next (/home/vcap/deps/0/node_modules/@sap/cds/lib/srv/srv-dispatch.js:64:17) 2025-07-23T09:44:59.21+0000 [APP/PROC/WEB/0] ERR at async RemoteService.handle (/home/vcap/deps/0/node_modules/@sap/cds/lib/srv/srv-dispatch.js:62:10) 2025-07-23T09:44:59.21+0000 [APP/PROC/WEB/0] ERR at async RemoteService.handle (/home/vcap/deps/0/node_modules/@sap/cds/libx/_runtime/remote/Service.js:295:16) 2025-07-23T09:44:59.21+0000 [APP/PROC/WEB/0] ERR at async getS2AEquipmentData (/home/vcap/app/srv/public-api/public-equipment-api-access.js:21:24) 2025-07-23T09:44:59.21+0000 [APP/PROC/WEB/0] ERR at async EventBuffer.fillBufferWithRelevantEvents (/home/vcap/app/srv/buffer/event-buffer.js:31:24) 2025-07-23T09:44:59.21+0000 [APP/PROC/WEB/0] ERR at async DowntimeRequestClass.calculateDowntimesToRebook (/home/vcap/app/srv/beforeReadClasses/downtimeRequestClass.js:48:5) 2025-07-23T09:44:59.21+0000 [APP/PROC/WEB/0] ERR at async RebookService.onDowntimeSetRead (/home/vcap/app/srv/performance-data.js:49:5) { 2025-07-23T09:44:59.21+0000 [APP/PROC/WEB/0] ERR statusCode: 502, 2025-07-23T09:44:59.21+0000 [APP/PROC/WEB/0] ERR reason: Error: Error during request to remote service: Failed to resolve the destination 'name: public_equipment_api'. 2025-07-23T09:44:59.21+0000 [APP/PROC/WEB/0] ERR at resolveDestination (/home/vcap/deps/0/node_modules/@sap-cloud-sdk/connectivity/dist/scp-cf/destination/destination-accessor.js:56:15) 2025-07-23T09:44:59.21+0000 [APP/PROC/WEB/0] ERR at process.processTicksAndRejections (node:internal/process/task_queues:105:5) 2025-07-23T09:44:59.21+0000 [APP/PROC/WEB/0] ERR at async /home/vcap/deps/0/node_modules/@sap-cloud-sdk/http-client/dist/http-client.js:88:37 2025-07-23T09:44:59.21+0000 [APP/PROC/WEB/0] ERR at async run (/home/vcap/deps/0/node_modules/@sap/cds/libx/_runtime/remote/utils/client.js:240:16) 2025-07-23T09:44:59.21+0000 [APP/PROC/WEB/0] ERR at async RemoteService.on_handler (/home/vcap/deps/0/node_modules/@sap/cds/libx/_runtime/remote/Service.js:281:20) 2025-07-23T09:44:59.21+0000 [APP/PROC/WEB/0] ERR at async next (/home/vcap/deps/0/node_modules/@sap/cds/lib/srv/srv-dispatch.js:64:17) 2025-07-23T09:44:59.21+0000 [APP/PROC/WEB/0] ERR at async RemoteService.handle (/home/vcap/deps/0/node_modules/@sap/cds/lib/srv/srv-dispatch.js:62:10) 2025-07-23T09:44:59.21+0000 [APP/PROC/WEB/0] ERR at async RemoteService.handle (/home/vcap/deps/0/node_modules/@sap/cds/libx/_runtime/remote/Service.js:295:16) 2025-07-23T09:44:59.21+0000 [APP/PROC/WEB/0] ERR at async getS2AEquipmentData (/home/vcap/app/srv/public-api/public-equipment-api-access.js:21:24) 2025-07-23T09:44:59.21+0000 [APP/PROC/WEB/0] ERR at async EventBuffer.fillBufferWithRelevantEvents (/home/vcap/app/srv/buffer/event-buffer.js:31:24) { 2025-07-23T09:44:59.21+0000 [APP/PROC/WEB/0] ERR request: { 2025-07-23T09:44:59.21+0000 [APP/PROC/WEB/0] ERR method: 'GET', 2025-07-23T09:44:59.21+0000 [APP/PROC/WEB/0] ERR url: "/S2A_EquipmentMasterDataSet?$filter=EquiID eq '1600424f-0b0f-4017-82a5-00b2f2d3737e'", 2025-07-23T09:44:59.21+0000 [APP/PROC/WEB/0] ERR headers: [Object] 2025-07-23T09:44:59.21+0000 [APP/PROC/WEB/0] ERR }, 2025-07-23T09:44:59.21+0000 [APP/PROC/WEB/0] ERR correlationId: '58fa7d47-6036-42f2-5dd5-5e7abb5e9d4a' 2025-07-23T09:44:59.21+0000 [APP/PROC/WEB/0] ERR } 2025-07-23T09:44:59.21+0000 [APP/PROC/WEB/0] ERR }
I also tried to use the latest version 4.1.0 and I got the same error back.
@maxpfab from the stack trace you attached I can't really figured out what caused the issue. Could you please enable debug logging and attach the debug logs?
Check here
(Use setGlobalLogLevel('debug') in any of the classes/files that load during application start)
Hi,
I have now exported the Logs:
kdperformance-srv-tddoemdevmtx-2025-07-29 07_36_20.575+0000.txt
Hopefully you can find something.
Thanks, Max
Apologies for the delayed response Max. We are short on people for the past few weeks and I couldn't get back to you earlier. I checked the logs and it looks like fetching the client credentials token for the destination service is failing. We use xssec library to fetch this, could you enable debug logs for @sap/xssec to see what is causing the failure?
Is 789b22a5-b692-47bf-87b9-27d0259b7836 the tenant id for your subscriber tenant? Alternatively, you could also try to fetch the client credentials token in a REST client like Bruno or Insomnia to see what causes the error. Unfortunately, I don't see the cause of failure in the logs.
No worries. I know that problem all too well.
I have done that, could I somehow send you those logs? Because there are many credentails inside.
And yes that is the tenant I am talking about.
Should a service instance which is dropped in the same subaccount be able to access the destinations? Because it is still those broker credentails which was registred while the subscription.
Yes, please email me the logs at [email protected]. To fetch the client credentials token we use the UAA credentials available inside the destination service binding.
Should a service instance which is dropped in the same subaccount be able to access the destinations?
I assume you are specifically talking about the XSUAA instance here, which is not relevant in the current flow.
Thats what I also found out, that when you subscribe the service you are able to get the destinations with the xsuaa creds of the provider.
Yeah because it is not really linked to the subscription. It is a broker which was setup by a own and not included direcly inside of the cds, like cds add hana.
Lets see if you can find something :) I've sent you the mail.
Thanks for your help!
I looked at the logs, it's a 401, but I am a bit puzzled on why, the constructed request looks good from my side, with the tenant id also being passed with the correct header. So, the credentials from destination service should ideally work to fetch a token.
When you say broker, do you mean the destination service instance was created with a broker plan or the XSUAA service instance?
So we have a Service Broker which hosts the api from the CAP Service. With the Subscription, the broker gets registred inside of the subscriber subaccount. Now a Broker Instance could be created with the Instances and Subscription Tab. When the Instance is created there is a key which holds the credentails to access the service.
Let me know if you need some more details :)
But, how is this service connected to the destination service? The current issue is faced when you are trying to fetch a token to access the destination service. Could you please give us more details about your setup? How is the destination that you are trying to fetch related to this service broker instance?
I guess you were right that it was working now. I have missed to add the destinations dependency to the subscription.
Did it outside of the cap/requires inside of the package.json.
I will be on leave untill Wednesday afterwards I will to another test.
But so far thanks for your support. I will reach out if it was not working anymore.
Is that now working in each of the further releases?
Yes, the behaviour change (no longer verifying JWTs and using UAA inside the destination service credentials to fetch the token) was added in version 4.1.0
Perfect :) I have done some more tests and it is now working also with the newest version.
"@sap-cloud-sdk/connectivity": "^4.1.1", "@sap-cloud-sdk/http-client": "^4.1.1",
Thanks for your efforts. Now I can upgrade the other services as well.