Understanding XSUAA in depth

[JakobFra]

Dear community,

currently, I am writing the third part of my blog post series about BTP destination, it will be about Oauth2ClientCredentials destinations. I have already a code sample, this was easy and straight forward, but now I am struggling with drawing a big picture that really satisfies me. I get more and more the feeling that somehow an important puzzle piece is missing in my knowledge about XSUAA in BTP. Now I hope that someone here might be able to help me to close this gap!

I have a Client and a Server, the Server requires a valid JWT token that is accepted by the XSUAA service instance. The client has a binding to the destination service, that has a destination with Client ID and Secret of the XSUAA Service as well as the token URL. According to the theory, XSUAA service acts as OAuth2 Authorization Server, i.e. it validates the Client Credentials and, in case of success, it returns a JWT token that then can send as Bearer token in the request from client to server. So far, so good. But: what confuses me is the fact that the Token Service URL (i.e. the XSUAA endpoint) is a generic URL that is the same for every XSUAA instance in this subaccount (https://????????trial.authentication.????.hana.ondemand.com). Furthermore, even if I do not have any XSUAA service instance in the subaccount, this endpoint exists and I can use e.g. for getting a token for the destination service. I.e., although in documentation it often looks like XSUAA is kind of a standalone instance, there seems to be another component inbetween. So my question is: what exactly is XSUAA, is it a standalone service instance or rather kind of a tenant within the platform UAA? And what is this mysterious component listening to the generic authentication-URL mentioned above?

I would be really happy and thankful if someone could help me to bring light into my current state of confusion 🙂

[CarlosRoggan · Accepted solution]

Hi,

yes, in the OAuth scenario, we have one central "Authorization server". This role is taken by XSUAA.
The question is: how far does it reach?
In BTP we have the concept of "identity zone" which is currently equal to "subaccount", which is equal to accounting concept, for paying customers. As such, the XSUAA server takes care of one subaccount.
I think, more detailed info about setup of xsuaa server is not required for us (e.g. is the XSUAA itself a multitenant app, etc)

When creating an instance of xsuaa "service" in BTP, what actually is happening: a "client" in terms of OAuth is created and registered at the "Authorization Server". As such, an instance is just some text-artifact, containing the id of the registered client, and pwd, etc
This client can be used to fetch an access token, which usually has format as JWT.

If you write a server app, you bind your app to an instance of xsuaa, so you register your OAuth client, which can be used to access your server app endpoint.
As oauth is an "Authorization" framework, you use your client to define Authorization model, i.e. "scopes"

If your server app is called by a client app that has its own xsuaa instance, then you can define "grant" statements such that the foreign client will get the scopes that you grant.

Now, if you write a BTP "service", you will provide some fuctionality that can be invoked via REST api. You will want to protect this API with OAuth. As such, you create an own instance of xsuaa for your "service".
Your "service-broker" will send the credentials of your own service-xsuaa-instance to the apps that are bound to your service. This is done during "binding" creation.

So in your scenario, you have 2 client-credentials processes:
You fetch a token, when calling the "destination-service", because it is protected.
Secondly, the destination service does exactly this procedure for you: fetching a token for whatever you configure in the destination configuration.

For my personal taste, I would change the diagram as follows:
XSUAA-icon represents an "instance" of xsuaa, thus renaming it to "XSUAA-instance"
Then, your server-app has an xsuaa-instance AND the destination service instance has an XSUAA-instance.
The client is bound to the instance of destination-service, right? (or uses service key, which is the same)
Furthermore, I would add the destination configuration to the diagram. One configuration is configured with the clientid/secret (or certificate) of the xsuaa of the server.

Does that make sense?
Please, if there's an expert reading this, do share some internal secret info 😉

Kind Regards,
Carlos

[JakobFra · Accepted solution]

Hi carlos.roggan ,

thanks a lot for your very detailed explanation. This definitely helps a lot. So, to summarize, in terms of running services there is one XSUAA server and all the XSUAA services in the CF spaces, are, as you wrote, OAuth Clients, I.e. in the end a client Id/secret pair together with application specific configuration for roles, grants, etc, managed by this subbaccount-specific XSUAA server.

I think what confused / confuses me is the fact that in documentation it is often referred to XSUAA „service instances“, what I am associating rather with running applications, that are hosted as a container or something similar.

I will update my diagram and consider your suggestions accordingly. Let me share it here once I have it ready 🙂

Regards,

Jakob

[CarlosRoggan · Accepted solution]

Hi jafranke ,

yes, I think you summarized correct and I agree with your confusion. To add my own confusion: the fact that in documentation of xsuaa, they talk about "the application". It confused me that this was not my app, which I deploy to CF, no, no, "application" refers to what is mentioned with "xsappname", the application in the OAuth flow, on behalf of which a token with required permissions is fetched, etc I'm sure you know which confusion I'm talking about 😉

I'd like to share a blog post with you, which might help further in understanding how xsuaa works:

https://blogs.sap.com/2020/06/02/how-to-call-protected-app-from-external-app-as-external-user-with-s...

and maybe this one:
https://blogs.sap.com/2022/07/28/sap-btp-security-how-to-use-mtls-with-destinations/

OAuth explained with my simple words.

https://blogs.sap.com/2019/05/06/sap-cloud-platform-backend-service-tutorial-14-about-oauth-mechanis...

BTW, good that now I know whom to contact when I have questions wrt destinations...;-)

Cheers,
Carlos

[JakobFra · Accepted solution]

Hi carlos.roggan,

thanks a lot for your feedback and for the provided links, I will definitely have a look into them. Actually, I guess most of my destination knowledge is based on other blog posts from you about token exchange etc 😄 😉

Regards,
Jakob