Different credentials in service keys of XSUAA

[former_member748]

I have a XSUAA service instance bound to a deployed app in SAP BTP and I want an external system like a SAP S/4HANA to call the OData service exposed by my app.

So the flow is that the external system calls the XSUAA API with the client id and client secret (client_credentials grant), then with the jwt calls the OData service of the app.

The problems is that I want multiple systems to be able to call the app, so I would prefer that each one has a different way of authentication (at least a different client secret).

So I tried to create service keys, but they are identical. They have the same client id and client secret in them. Is this the expected behaviour? Can I specify anything in the JSON when creating the service key to make it unique somehow?

[draschke]

https://answers.sap.com/questions/13203074/sap-hana-20-sps05-xsa-xs-create-service-key.html

[former_member748]

diraschk thanks for the link, this answers my question. I was also thinking what’s the purpose of creating more service keys if they are the same.

[CarlosRoggan · Accepted solution]

Hi,

If this is the desired setup, I see the following possibility:

You can create additional instances of xsuaa, for each external system. So each system will get its own client secret
The jwt which is issued in that way, won’t be accepted by your app
As such, the xsuaa of your app needs to grant the access to the xsuaa of the external system
It is described here:
https://blogs.sap.com/2020/06/02/how-to-call-protected-app-from-external-app-as-external-user-with-s...

Note that it is required to define scopes, otherwise the “foreign” xsuaa won’t be listed as “aud”
See here fore details:
https://blogs.sap.com/2020/09/03/outdated-sap_jwt_trust_acl/

Maybe you can think of a different approach:
For instance, you can add custom properties when requesting a jwt token
It is described here:
https://blogs.sap.com/2020/10/21/how-to-add-custom-properties-to-jwt-token/
This won’t give you a new client secret, but mitht be interesting for you

Cheers,
Carlos

[CarlosRoggan · Accepted solution]

Maybe it helps to consider that:

ONE instance of xsuaa takes the role of ONE client in the OAuth flow
A client registers to the "Authorization Server" (in terms of OAuth) and as such, it gets the credentials.
A service key is just a concept for remote access to a service instance. I mean, you use it if you don't BIND an app to the service instance
if you BIND multiple apps to ONE service instance, you get the same clientid as well.

Also helpful:

This of ONE instance of xsuaa as ONE application (in terms of OAuth). Note that in the params of the xsuaa, you define an attribute "xsappname", means application name of the OAuth client.
As such, each service key will have same credentials for the same "xs-application"

[former_member748 · Accepted solution]

carlos.roggan thank you so much for the options you presented. I am interested also in workarounds for this so your input is very much appreciated!

The custom properties option seems like it can solve my problem. Now a better question, do you think that the fact that my XSUAA instance has plan shared (for multitenancy purposes) can conflict with this option?

Kind regards,

Stefania

[CarlosRoggan · Accepted solution]

Hi Stefania,

I'm not so familiar here, but as far as I understand, the shared would mean, that the credentials are delegated to all subscribers, so the host application can authorize the users of subscribed app.
I wouldn't expect that that would cause an impact
hopefully 😉