Skip to Content
Technical Articles
Author's profile photo Carlos Roggan

SAP Cloud Platform Backend service: Tutorial [0.5]: Configure XSUAA

This blog is part of a series of tutorials explaining the usage of SAP Cloud Platform Backend service in detail.

This post explains how to configure security for Backend service.


At the current point in time, SAP Cloud Platform Backend service supports only a very limited set of authorization mechanisms:

  1. OAuth authentication flow
  2. nothing else

Reason is the targeted usage by frontend applications rather than human testers.
Since Basic Authentication is – currently – not supported, it is necessary to do some configuration steps to enable OAuth

  1. Create xsuaa instance
  2. Create service key

This blog is not necessary if you use the Backend service cockpit to call your APIs.
Configuring security is only required if you want to call your APIs from external application or tool like e.g. REST client


Configure security in Cloud account

We need a couple of preparation steps, to be done in our cloud account, before we can request an authorization token: For that purpose there’s the service offering “Authorization & Trust Management” in the SAP Cloud Platform.

Below section describes how to create a service instance in your Cloud Foundry space.
If you’re new to SAP Cloud Platform trial account and Cloud Foundry and if you followed my tutorials in detail, then you probably don’t have a space yet.
The good news: Especially for YOU, I created a tutorial, describing how to enable Cloud Foundry and assign quota in your trial account.

1. Create xsuaa service instance

Go to your BETA-enabled subaccount, I mean that subaccount which you use to open your SAP Cloud Platform Backend service subscription.
Go into your space

Make sure that you choose a space which is located in the same subaccount like your Backend service subscription.

In the left navigation pane, expand “Services >” and click on “Service Marketplace”
Here you can see all the services that are offered in your cloud account:


Click on the tile “Authorization & Trust Managem…”
Then click on “Instances” in the left pane
Afterwards you can click on the “New Instance” button

In the creation dialog, make sure your “service plan” is chosen as “application”:

In the next wizard page, “Specify Parameters”, enter the following JSON snippet in the text field:

  "xsappname": "myAppName",
  "tenant-mode" : "dedicated",
  "foreign-scope-references": [

The value for property “xsappname” has to be unique

The syntax for foreign scope lets XSUAA resolve the scope based on the variable.
Here’s an alternative, using the hard-coded name of the foreign scope:

“xsappname”: “myAppName”,
“tenant-mode” : “dedicated”,
“foreign-scope-references”: [

The reference name of the foreign scope can be found in the details page of the Backend service, then expand the “Security” menu entry and view the “Role Templates” (see here)


The next wizard page allows to bind to an existing application.
You can ignore and press next.
Finally, enter a name of your choice for the new instance

Press “Finish”.
Your instance of xsuaa service is created in your space.
Now proceed with service key creation.

2. Create Service Key

Creating a service key is required because we want to call the Backend service API from externally.
Means, not from an app deployed in the Cloud Foundry Space, but from a REST client on our local Laptop. That’s why a service key needs to be explicitly created and properties need to be noted.
See documentation

Click on your newly created instance of xsuaa service

Ignore the “Referencing Apps” screen, click on “Service Keys” in the left navigation pane.
Then you can hit the button “Create Service Key”

In the creation popup, you can give an name of your choice, then press “Save”

The result is presented to your delighted eyes:

We’ve created a service instance of the xsuaa service and we’ve created a service key for it.
In the service key details we see 3 values which we’ll need later
Thus, we take a note of those 3 property values (I’ve marked them in the screenshot above)

In my example (slightly obfuscated):

“clientid”: “sb-baas_access!t12345”,
“clientsecret”: “2abcdefghijklmnopqrstuvwxy=”,
“url”: “”

If you don’t see a property like the “url”, the last one, you might need to maximize your browser window or use a different browser

clientid and clientsecret are used like user credentials by the client when it connects to the XSUAA instance.

Again, we need the client credentials because we want to connect to XSUAA instance from outside, from local REST client tool.
If we would write a web application and deploy it to SAP Cloud Platform, then we would bind it to an XSUAA instance and the client credentials would be assigned automatically under the hood


In this blog, we’ve created a service instance of xsuaa service with the parameters required for SAP Cloud Platform Backend service, subscribed in your trial account.

Furthermore, we’ve created a service key for the xsuaa service instance, required for the client authentication to the oauth endpoint

After these 2 preparation steps, you’re able to call your Backend service APIs from an external application, like e.g. a REST client.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Shilpa .
      Shilpa .

      Hi Carlos,

      From where did you get the application id "4bf2d51c-1973-470e-a2bd-9053b761c69c" that you specified as parameter while creating XSUAA?


      Author's profile photo Carlos Roggan
      Carlos Roggan
      Blog Post Author

      Hi Shilpa, my assumption is, using that id (I guess that's the subscription ID), that's the generic way how xsuaa is enabled to resolve the name of foreign scope. I haven't tried, but it should be possible (since in same identity zone) to directly use the name of the scope (can be found when assigning roles in Backend service). Also, I assume that the id itself needs to be documented, once Backend service is released for productive usage.
      Cheers, Carlos

      Author's profile photo Shilpa .
      Shilpa .

      Hi Carlos, The Subscription id that you provided worked for me. I think because it is trial, we have same subscription id. May be, in Production account, every subscription has a different id. I did not find anywhere on CF the subscription id. Also, may be you found the subscription id for trial BAAS from internal SAP documentation?


      Author's profile photo Carlos Roggan
      Carlos Roggan
      Blog Post Author

      Hi Shilpa, we’re subscribing to a multi-tenant application which is deployed only once, so I assume that the reference id is the same for everybody, even in production.
      As far as I know, the reference id is the same for trial and production
      I guess it is given during deployment, so only visible in the providing account, not for us. So has to be documented.
      I assume, pointing to the foreign scope name via the $XSAPPNAME variable and (service-plan, id, application-name) is the right way, like that it is resolved by XSUAA.
      I’ve now added an alternative to the description above: I’ve written the hard-coded reference name of the foreign scope. It can be found in the list of Role-Templates, in the details screen of the Backend service subscription (not in the BS itself)
      Here it is:
      “xsappname”: “myAppName”,
      “foreign-scope-references”: [ “Backend-service!t6131.AllAccess” ]

      Which one do you like more?
      Cheers, Carlos

      Author's profile photo Shilpa .
      Shilpa .

      Hi Carlos, Thanks for the alternative approach. Binding the whole BaaS to XSUAA either by Subscription id or BaaS’s foreign score may be fine as we are on Beta version. But when developing real time applications we would want to bind XSUAA at application level. Right now, Baas has no modularization/containerization(Projects/Application) and number of APIs can easily increase and difficult to maintain. XSUAA needs to be at project/application level is what I think. As Baas has a granularity at API level, XSUAA binding at API level also would be fine I guess.

      Thank you.

      Author's profile photo Carlos Roggan
      Carlos Roggan
      Blog Post Author

      Hi Shilpa,
      if I get you right, what you need is more fine granular configuration of binding.
      E.g. you create a UI5 application which uses 1 API, and you bind the app to xsuaa. This xsuaa allows access to all APIs. So it doesn't make much sense.
      Do I get you right?

      In this blog, I explained the fine granular configuration of roles in BaaS. Such role allows access to only 1 API.
      This would need to be used in XSUAA (what I haven't tried)
      Sounds like what you're asking for

      Second: you're proposing kind of coupling of APIs, right?  Sounds like a good idea.
      In a "Application Programming Model" project you can expose multiple services (I guess) and you have the coupling inside an MTA.
      In Backend service cockpit, you would expect anything similar?