Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
Showing results for 
Search instead for 
Did you mean: 
In this post we will be creating a simple nodeJS application using express.js to expose a http end point. Along with that we will be using SAP Cloud Platform's xsuaa PaaS to secure our end point. Later we will be deploying the application on to a Kubernetes cluster.

This sample application is to show how applications running on Kubernetes can access the PaaS from SAP Cloud Platform via Service Manger Broker.

I have set up the Kubernetes cluster using Minikube for this post, but I have also installed the same application on to Gardener Cluster with out any change.

I have integrated my Kubernetes cluster with SAP Cloud Platform Service Manager using the steps given in Register Kubernetes Clusters at the Service Manager. You can consider Register Kubernetes Clusters at the Service Manager as a prerequisite for this post.

Bind XSUAA Service

Now we need to create a service binding to the XSUAA service. As a prerequisite we require security descriptor that contains a declaration about authorisation scopes we intend to use in our application. In our case, we simply declare a DISPLAY scope that we will use later on to authorise our users. In addition, we declare a so-called role template called Viewer that references our DISPLAY scope.

Let's first create the xs-security.json considering the above.
"xsappname": "xsuaa-k8-scp-example",
"scopes": [
"name": "$XSAPPNAME.Display",
"description": "display"
"role-templates": [
"name": "Viewer",
"description": "Read Access",
"scope-references": [

Now with the above content let's create a service instance of XSUAA using service catalog cli in Kubernetes. You can also create and bind service instance using Kubenetes configuration.
$ svcat provision xsuaa-example --class xsuaa --plan broker --params-json '{"xsappname":"xsuaa-k8-scp-example","scopes":[{"name":"$XSAPPNAME.Display","description":"display"}],"role-templates":[{"name":"Viewer","description":"Read Access","scope-references":["$XSAPPNAME.Display"]}]}'

Name: xsuaa-example
Namespace: default
Class: xsuaa
Plan: z48zz57zz45zgt9z2fzjz4azz47zz4-fd5fd60de69db525c44c9608067cb61a

- description: Read Access
name: Viewer
- $XSAPPNAME.Display
- description: display
name: $XSAPPNAME.Display
xsappname: xsuaa-k8-scp-example

Let's check if the service instance is created correctly. We need to check it the status is in READY state. Service instance binding is possible only when the the service instance is in READY state.
$ svcat get instance

xsuaa-example default xsuaa z48zz57zz45zgt9z2fzjz4azz47zz4-fd5fd60de69db525c44c9608067cb61a Ready

Once the service instance is in READY state, we can go ahead and bind the service instance. Once you bind the instance, two things (binding and secret) will be generated and the service instance will be ready for consumption by any application.
$ svcat bind xsuaa-example

Name: xsuaa-example
Namespace: default
Secret: xsuaa-example
Instance: xsuaa-example

No parameters defined

$ svcat get bindings

xsuaa-example default xsuaa-example Ready

$ kubectl get secrets
default-token-nvqvg 3 4d20h
xsuaa-example Opaque 13 106s

With this we complete the setup in Kubernetes and ready to develop application which can use XSUAA instance that we created. But before that we need to do security configuration in SAP Cloud Cockpit.

Assign Users to Scope in SAP Cloud Cockpit

To regain access to our secured endpoint in the application, you need to get the Display OAuth scope assigned to the user. This is done using the SCP cockpit.

Go to the Sub Account that we have created for enabling the service manager API access through SaaS subscription using the steps provided in Register Kubernetes Clusters at the Service Manager post and navigate to Security → Role Collections.

Create a new role collection which you can give an arbitrary name. In our case, we call the role collection Viewer.

Afterwards, select the role collection Viewer and select Add Role. From the menu, select your application and the corresponding role template and role.

Now the user has to be assigned to the newly created Viewer in order to receive the Display scope. In order to do this, select the trust configuration from the security menu and select the SAP ID Service from the list.

In the opening dialog, enter your user ID as e-mail into the user field and click Show Assignments followed by Add Assignments.

Select the Viewer role collection from the menu to assign it to your user.

With this we are done with the setup in SAP Cloud Platform for user to have Display auth scope.

Sample Application

Application Coding

Create a folder k8 and under that create folders like xsuaa-k8-scp-example and xsuaa-k8-scp-example-config.

Let's first finish the required coding in xsuaa-k8-scp-example. Afterwards we can jump on to the configuration in xsuaa-k8-scp-example-config.
├── Dockerfile
├── package.json
└── server.js

var express = require('express');
var xsenv = require('@sap/xsenv');
var passport = require('passport');
var JWTStrategy = require('@sap/xssec').JWTStrategy;

var app = express();

passport.use(new JWTStrategy(xsenv.getServices({uaa:{tag:'xsuaa'}}).uaa));

app.use(passport.authenticate('JWT', { session: false }));

app.get('/', function (req, res, next) {
console.log("Authenticated Request Reached...");
var isAuthorized = req.authInfo.checkScope('xsuaa-k8-scp-example!b10809.Display');
if (isAuthorized) {
console.log("Authorization success. User: " + + ", Path: '/'.");
res.send('Application user: ' +;
} else {
console.log("Authorization failed. User: " + + ", Path: '/'.");

var port = process.env.PORT || 8085;
app.listen(port, function () {
console.log('myapp listening on port ' + port);

"name": "xsuaa-k8-scp-example",
"version": "1.0.0",
"description": "",
"main": "server.js",
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1"
"dependencies": {
"@sap/xsenv": "1.2.7",
"@sap/xssec": "^2.1.16",
"express": "^4.17.1",
"http": "0.0.0",
"passport": "^0.4.0"
"author": "",
"license": "ISC"

FROM node:10.15.3-jessie-slim


COPY package.json .
COPY server.js .
COPY node_modules ./node_modules

CMD DEBUG=* node server.js

Create Docker Image

Connect the local docker environment to Minikube Kubernetes
eval $(minikube docker-env)

Install node modules defined in package.json
npm install

Create a docker image for the application.
$ docker build -t xsuaa-k8-scp-example:0.9 .
Sending build context to Docker daemon 25.87MB
Step 1/6 : FROM node:10.15.3-jessie-slim
---> b2566e062f4a
Step 2/6 : EXPOSE 8085
---> Using cache
---> e40927591070
Step 3/6 : COPY package.json .
---> Using cache
---> 2157829d59cc
Step 4/6 : COPY server.js .
---> Using cache
---> 73f35f9aae4c
Step 5/6 : COPY node_modules ./node_modules
---> 43a6d7f86cac
Step 6/6 : CMD DEBUG=* node server.js
---> Running in a5ebb6456a3f
Removing intermediate container a5ebb6456a3f
---> 103580985707
Successfully built 103580985707
Successfully tagged xsuaa-k8-scp-example:0.9

List the docker images to see if the image added.
$ docker image list
xsuaa-k8-scp-example 0.9 72b63f9eb3f0 30 seconds ago 211MB
<none> <none> 4e85af197088 25 hours ago 211MB v1.17.3 ae853e93800d 3 weeks ago 116MB v1.17.3 90d27391b780 3 weeks ago 171MB v1.17.3 b0f1517c1f4b 3 weeks ago 161MB v1.17.3 d109c0821a2b 3 weeks ago 94.4MB
kubernetesui/dashboard v2.0.0-beta8 eb51a3597525 2 months ago 90.8MB v0.3.0-beta.2 8da829e9f261 3 months ago 42.7MB 1.6.5 70f311871ae1 3 months ago 41.6MB 3.4.3-0 303ce5db0e90 4 months ago 288MB
kubernetesui/metrics-scraper v1.0.2 3b08661dc379 4 months ago 40.1MB v0.3.2 1dffd12df62a 4 months ago 48.7MB
node 10.15.3-jessie-slim b2566e062f4a 10 months ago 187MB 3.1 da86e6ba6ca1 2 years ago 742kB v1.8.1 4689081edb10 2 years ago 80.8MB

Now we have our application docker image is preset in the minikube repository. Now let's create the Kubernetes deployment configuration for the same.

Create Kubernetes Deployment Configuration

Go to xsuaa-k8-scp-example-config and create a file named xsuaa-k8-scp-example.yaml with the following content.
apiVersion: apps/v1
kind: Deployment
app: xsuaa-k8-scp-example
name: xsuaa-k8-scp-example
replicas: 1
app: xsuaa-k8-scp-example
app: xsuaa-k8-scp-example
- image: xsuaa-k8-scp-example:0.9
name: xsuaa-k8-scp-example
- name: clientid
valueFrom: { secretKeyRef: { name: xsuaa-example, key: clientid } }
- name: identityzone
valueFrom: { secretKeyRef: { name: xsuaa-example, key: identityzone } }
- name: sburl
valueFrom: { secretKeyRef: { name: xsuaa-example, key: sburl } }
- name: trustedclientidsuffix
valueFrom: { secretKeyRef: { name: xsuaa-example, key: trustedclientidsuffix } }
- name: apiurl
valueFrom: { secretKeyRef: { name: xsuaa-example, key: apiurl } }
- name: clientsecret
valueFrom: { secretKeyRef: { name: xsuaa-example, key: clientsecret } }
- name: identityzoneid
valueFrom: { secretKeyRef: { name: xsuaa-example, key: identityzoneid } }
- name: tenantid
valueFrom: { secretKeyRef: { name: xsuaa-example, key: tenantid } }
- name: tenantmode
valueFrom: { secretKeyRef: { name: xsuaa-example, key: tenantmode } }
- name: uaadomain
valueFrom: { secretKeyRef: { name: xsuaa-example, key: uaadomain } }
- name: url
valueFrom: { secretKeyRef: { name: xsuaa-example, key: url } }
- name: verificationkey
valueFrom: { secretKeyRef: { name: xsuaa-example, key: verificationkey } }
- name: xsappname
valueFrom: { secretKeyRef: { name: xsuaa-example, key: xsappname } }

If you see I am creating multiple environment variables for the Kubernetes pod, so that we can consume the same in our application running on the same pod. Now the question is how do we know what all parameters are provided by the service instance, so that we can provide the configuration here. For doing so we need to describe the secret that got created while we were creating the binding for the service instance.
$ kubectl describe secrets/xsuaa-example
Name: xsuaa-example
Namespace: default
Labels: <none>
Annotations: <none>

Type: Opaque

identityzoneid: 36 bytes
tenantid: 36 bytes
trustedclientidsuffix: 34 bytes
url: 50 bytes
clientid: 36 bytes
clientsecret: 28 bytes
identityzone: 5 bytes
sburl: 59 bytes
tenantmode: 9 bytes
uaadomain: 36 bytes
verificationkey: 442 bytes
xsappname: 33 bytes
apiurl: 48 bytes

If you check the Kubernetes config that we have created and the secret retrieved above, I have configured those parameters that are provided by the service instance. Currently for the security reasons we can not see the value for the parameters here. To see the parameters, we need to deploy our application in Kubernetes pod using the above Kubernetes configuration.

Retrieve Service Instance parameter value from Kubernetes pod

As we are using Kubernetes configuration, it's easy for us to create a pod having our application running. At this stage our application will not be running and the pod would be in error state. To eliminate this error we can comment some of the code in server.js to make it look as following.

var express = require('express');

var app = express();

app.get('/', function (req, res, next) {
console.log("Authenticated Request Reached...");

var port = process.env.PORT || 8085;
app.listen(port, function () {
console.log('myapp listening on port ' + port);

With the above code your pod would be in running state, when you deploy the application. Please use the following command from k8 folder to deploy the pod in Kubernetes cluster.
kubectl apply -f xsuaa-k8-scp-example-config/

Once the pod is deployed, we can list the pods using the following command.
$ kubectl get pod -o wide
xsuaa-k8-scp-example-6b7d458bd6-cdgv9 1/1 Running 0 25h minikube <none> <none>

Now it's time to get inside the pod.
$ kubectl exec -it xsuaa-k8-scp-example-6b7d458bd6-cdgv9 bash

Once we can inside the pod, we can use the following command to retrieve all the parameters that are available to the applications running on the pod.
# env
xsappname=<app name>
verificationkey=-----BEGIN PUBLIC KEY-----<cert key>-----END PUBLIC KEY-----

Once when we have retrieved all the parameters, we can revert our server.js to original one.

Setting up VCAP_SERVICES parameter for SAP node APIs

SAP NodeJS libraries are designed to read VCAP_SERVICES of Cloud Foundry for consuming PaaS service instance configurations from environment. So to use those libraries in our application running in Kubernetes, we need to wrap all the parameters inside VCAP_SERVICES. While we could find a way to make this discovering the parameter values from secret happen automatically for us, for this POC we have hardcoded VCAP_SERVICES in our Kubernetes deployment configuration. You can also create a kubernetes secret to store the VAP_SERVCES. After hard coding the same in Kubernetes deployment configuration, the configuration file looks like below.

Note: I had to add few more parameters to VCAP_SERVICES as they were mandatory for @Sap/xssec library. Those properties are name, label, tag, plan. cfservices.js expects those to be there to apply filter on to that while searching.
apiVersion: apps/v1
kind: Deployment
app: xsuaa-k8-scp-example
name: xsuaa-k8-scp-example
replicas: 1
app: xsuaa-k8-scp-example
app: xsuaa-k8-scp-example
- image: xsuaa-k8-scp-example:0.9
name: xsuaa-k8-scp-example
value: "{\"xsuaa\":[{\"credentials\":{\"apiurl\":\"\",\"clientid\":\"sb-xsuaa-k8-scp-examplexxxx\",\"clientsecret\":\"xxxxxxxxxxxxxxx\",\"identityzone\":\"xxx\",\"identityzoneid\":\"55d8129b-1e6b-4231-9c80-000ae080f9dd\",\"sburl\":\"\",\"tenantid\":\"55d8129b-1e6b-4231-9c80-000ae080f9dd\",\"tenantmode\":\"dedicated\",\"uaadomain\":\"\",\"url\":\"\",\"verificationkey\":\"-----BEGIN PUBLIC KEY-----<cert key>-----END PUBLIC KEY-----\",\"xsappname\":\"xsuaa-k8-scp-example!b10809\"},\"tags\":[\"xsuaa\"],\"label\":\"xsuaa\",\"plan\":\"application\",\"name\":\"xsuaa-example1\"}]}"

Application Deployment

Once we are ready with the VCAP_SERVICES, we can now deploy our application to Kubernetes and test the end point to see if it is secured by XSUAA of SAP Cloud Platform. For deploying the application we can use the same command as used before.
kubectl apply -f xsuaa-k8-scp-example-config/

Once you deploy the application Kubernetes pod, you need to port forward the pod port to your local system port in order to access the end point.
kubectl port-forward deployment.apps/xsuaa-k8-scp-example 8085:8085

With this we are now ready to access the endpoint from outside of the Kubernetes pod.

Application Testing

Getting the JWT Token

In order to access the application we need to first retrieve the JWT token on behalf of the user to whom we have assigned the scope in the earlier steps. Use the following curl to get the JWT token.
curl --location --request POST '' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--header 'Accept: application/json' \
--data-urlencode 'grant_type=password' \
--data-urlencode 'password=<user's password>' \
--data-urlencode 'username=<user's email address>' \
--data-urlencode 'client_id=<xsuaa client id>' \
--data-urlencode 'client_secret=<xsuaa client secret>' \
--data-urlencode 'response_type=token'


"access_token": "<token>",
"token_type": "bearer",
"id_token": "<token>",
"refresh_token": "<token>",
"expires_in": 43199,
"scope": "openid xsuaa-k8-scp-example!b10809.Display",
"jti": "65501d3df7de4e7387267f44e106a8ea"

End Point Access (With Valid JWT)

curl -i --location --request GET 'http://localhost:8085/' \
--header 'Accept: application/json' \
--header 'Authorization: Bearer <token>'


HTTP/1.1 200 OK
X-Powered-By: Express
Content-Type: text/html; charset=utf-8
Content-Length: 43
ETag: W/"2b-M8JdCOGSPyy3PSSpF4lP7MEeqAI"
Date: Wed, 04 Mar 2020 08:46:45 GMT
Connection: keep-alive

Application user:

End Point Access (With Invalid JWT)

curl -i --location --request GET 'http://localhost:8085/' \
--header 'Accept: application/json' \
--header 'Authorization: Bearer <token>'


HTTP/1.1 403 Forbidden
X-Powered-By: Express
Date: Wed, 04 Mar 2020 08:47:43 GMT
Connection: keep-alive
Content-Length: 9


If we are hardcoding the VCAP_SERVICES, then there is no advantage of using a Service Manager Broker in Kubernetes, in stead we can create secrets in Kubernetes using the service instance credential of SAP CP(In this case VCAP_SERVICES). But if you want to write your own implementation, the you can use the secret attributes directly.

This architecture can be applied to other cloud providers like AWS and GCP, where you can build an application using the best platform services available across. It's mandatory for the cloud provides to implement/comply with Open Service Broker API Specifications. While this architecture gives us an advantage of using platform services across cloud providers, it also brings a latency to the application for accessing different services from across providers.