Skip to Content

The following steps will explain how to secure applications in SAP Cloud Platform, CloudFoundry which are built based on the S/4HANA Cloud SDK.

Note: This post is part of a series. For a complete overview visit the SAP S/4HANA Cloud SDK Overview.

Goal of this blog post

This tutorial will cover how to protect your Java-based Hello World microservice with authenticated and authorized users. To achieve this the tutorial covers the following aspects:

  1. Setting up and configuring the App Router component as a central entry point to your microservice landscape to handle authentication and authorization for you.
  2. Protect your Java microservice so that it only accepts requests based on a valid JSON Web Token (JWT) that is received from the App Router.
  3. Assign roles and scopes to your application users and let your backend deal with authorization information.



Before we dive deeper into the real setup of the architecture, let’s quickly review the architecture we intend to go for.

Figure 1 presents the final setup. First, we still have our existing “Hello World” or “Business Partner” Java-based microservice that we have created in the previous tutorials. However, instead of letting the customer access this application directly, we will use the so-called Application Router (App Router) that serves two purposes.

On the one hand, the App Router is a general entry point into the world of microservices. The main idea is that you can split an application into multiple microservices with independent deployability, polyglot runtimes & persistence and independent teams. Therefore, a central entry component is required that hides the complexity of the microservice landscape from the end customer.

On the other hand, the App Router is mainly responsible for managing authentication flows. The App Router takes incoming, unauthenticated requests from users and initiates an OAuth2 flow with the Extended Services for User Account and Authentication (XSUAA). The XSUAA service is an SAP-specific extension of CloudFoundry’s UAA service to deal with authentication and authorization (it may again delegate this aspect to other providers such as external Identity Providers, see later in this tutorial). If the user authenticates at the XSUAA, it will respond with a JSON Web Token (JWT) containing the authenticated users as well as all scopes that he or she has been granted.

Figure 1: Authentication Flow during Runtime

The JWT is passed by the App Router to the underlying microservices so that they are freed up from this task. At the same time, these microservices can only be accessed with a valid JWT, hence, are protected from unauthenticated traffic.

The JWT contains a signature that needs to be verifiable by every microservice to establish trust. Hence, every service require a key (client-secrets or public keys) to verify this signature and reject any requests with non-valid JWTs. Therefore, every service has to maintain a service binding to the XSUAA that provides this information for runtime verification (Figure 2). To enable this, every microservice binds to a dedicated XSUAA instance which writes this information into the VCAP_SERVICES environment variable which the microservices can use to verify any token’s validity.

Figure 2: Provisioning view with XSUAA binding


With these basics in mind, let’s create the picture of Figure 1 and Figure 2 by setting up the App Router, XSUAA and backend microservices to enable full application security.

Setup the App Router to authenticate your users.

The App Router can be installed in two different ways: (1) Download from Service Marketplace and (2) Download from the SAP NPM Registry. These steps are explained below:

Alternative 1: Get the App Router via Service Marketplace

  1. Before you can start the setup and configuration of the App Router component you need to download the XSA Javascript package from Service Marketplace: At the time of writing the package XS_JSCRIPT14_3-70001363.ZIP is the most recent one.
  2. After downloading the package extract it to your favorite <location>
  3. cd <location>/@sap
  4. Copy the approuter directory to some newly created directory that we call <destLocation>

Alternative 2: Get the App Router via SAP NPM Registry

This alternative approach requires that you have npm installed on your machine.

  1. Go to your favourite <destLocation> and create the approuter directory
    cd <destLocation>
    mkdir approuter
    cd approuter
  2. Place the following package.json in your approuter directory
      "name": "approuter",
      "dependencies": {
        "@sap/approuter": "*"
      "scripts": {
        "start": "node node_modules/@sap/approuter/approuter.js"
  3. Install AppRouter dependencies using the following commands
    npm config set @sap:registry
    npm install

Proceed with the App Router Setup independent of your download preferences

  1. Within <destLocation>/approuter create a new file called xs-app.json with the following content:
      "welcomeFile": "index.html",
      "routes": [{
        "source": "/",
        "target": "/",
        "destination": "app-destination"
  2. Within <destLocation> create a new manifest.yml file for the AppRouter microservice with the following content.
    - name: approuter
      host: approuter-p1942765239trial
      path: approuter
      memory: 128M
      buildpack: nodejs_buildpack
        TENANT_HOST_PATTERN: 'approuter-(.*)'
        destinations: '[{"name":"app-destination", "url" :"", "forwardAuthToken": true}]'
        - my-xsuaa

    Adapt the TENANT_HOST_PATTERN in the manifest.yml file to the host of the Cloud Foundry region you are running on; the above assumes EU (eu10).

    Understanding the AppRouter’s manifest.yml and xs-app.json:

    The TENANT_HOST_PATTERN is a variable that declares the pattern how multiple tenants in the URL are identified and handled. During runtime, the App Router will match the incoming host against the pattern and tries to extract the regular expression from the pattern. It will use the matched string to delegate authentication to the respective XSUAA tenant (in SAP Cloud Platform the tenant ID corresponds to the subaccount ID. If you desire different URL patterns, you need to change this pattern accordingly.

    Note that the TENANT_HOST_PATTERN variable is only required in real multi-tenant application, i.e, applications where a physical deployment serves multiple clients from the same deployment. We assume in this blog series that we want to build multi-tenant applications, as we aim towards cloud-native development. However, this variable is not necessary if you have a single-tenant application. To realize this, the xs-security.json security descriptor may declare tenant-mode: dedicated (see step 5 below).

    Destinations is a variable that declares the internal routes from the App Router to the underlying backend microservices. As we only have one hello world microservice yet, we define only one destination called app-destination here. This app-destination is referenced by the previously created xs-app.json file.

    The services section declares to bind our own XSUAA service instance to the App Router. This binding will ensure a corresponding VCAP_SERVICE entry that holds the client ID, client secret and public key that is required to validate any incoming OAuth token/JWT from the XSUAA service:


  3. Within the manifest.yml replace the destinations variable with the specific URL to your Java backend service used in the previous tutorials. In my case, the URL is
  4. Within the manifest.yml replace the host name to your unique host identifier by using approuter-<tenantID>. In my case the host name is
  5. Now we need to create a service binding to the XSUAA service. As a prerequisite we require a xs-security.json (security descriptor) file that contains a declaration about authorization scopes we intend to use in our application. In our case, we simply declare a DISPLAY scope that we will use later on to authorize our users. In addition, we declare a so-called role template called “Viewer” that references our DISPLAY scope. We put this file to <destLocation>/xs-security.json. For a more detailed explanation on scopes and role templates, see the appendix of this tutorial. More details on the syntax of the xs-security.json can be found here.Note 1: that the xsappname has to be unique within the entire XSUAA instance. We follow here the same pattern using our <appID>-<tenantID>. In my case this is firstapp-p1942765239trial.Note 2: As explained above, tenant-mode: shared assumes a multi-tenant application and will require the TENANT_HOST_PATTERN variable to be declared. You may also use “tenant-mode”: “dedicated” if you develop a single-tenant application.
      "xsappname": "firstapp-p1942765239trial",
      "tenant-mode": "shared",
      "scopes": [
          "name": "$XSAPPNAME.Display",
          "description": "display"
      "role-templates": [
          "name": "Viewer",
          "description": "Required to view things in our solution",
          "scope-references"     : [
  6. We then create a service instance called my-xsuaa of the XSUAA service by issuing the following command and using the xs-security.json file:
    cf create-service xsuaa application my-xsuaa -c xs-security.json
    • If you have created this instance of the XSUAA service before without the xs-security.json parameter, you can unbind and delete the existing instance with these commands before creating it with the above command:
      cf unbind-service firstapp my-xsuaa
      cf delete-service my-xsuaa​
  7. Before we deploy your folder structure should look similar to this:

    You may have different content in the approuter folder depending on the download alternative you have chosen. Ensure that xs-app.json and package.json and the node_modules directory with content are present.
  8. Then deploy the AppRouter using the following (with the appropriate API endpoint of your Cloud Foundry region):
    cd <destLocation>
    cf api
    cf login
    cf push
  9. Afterwards you should be able to locate the App Router from within your browser using the host name of your deployment. In my case this is which should face you with the following login page where you can use your user e-mail and password:

  10. After logging in you should see the HelloWorld servlet which is now served by the App Router as a proxy to your Java application:

Protect your backend microservice

After authentication works with the App Router, your java backend service is still fully visible in the web and not protected. We, therefore, need to protect our java microservices as well so that they accept requests with valid JWTs for the current user only. In addition, we will setup the microservice in a way that it deals with authorization, i.e., understands the OAuth scopes from the JWT that we have configured previously using the xs-security.json file.

In the following, we will use the Spring Security framework to protect the microservices. You can also use standard mechanisms of the SAP Java buildpack to achieve the same. If you do not want to use Spring Security please follow the steps here, nonetheless, the concepts described hereinafter apply for both methods.

Install XS Security libs to your local Maven repository:

The first step is to get some additional Java libs from Service Marketplace. To get them, do the following steps:

  1. Download additional XS security libs from service marketplace: 
  2. At the time of writing the latest package is XS_JAVA_1-70001362.ZIP (19.03.2018).
  3. Unzip <destLocation>
  4. Install XS Security Libs to your local maven repo using:
    cd <destLocation>
    mvn clean install

Enhance your project’s pom.xml

In the second step, we go back to our HelloWorld or Business Partner application and open the main application/pom.xml which looks similar to this structure:

In the <dependencies> section of the application/pom.xml, we enhance the following additional dependencies to our project:

<!-- Authentication and Authorization imports with Spring Security -->

This dependency section contains three main parts of dependencies:

  1. The packages add certain aspects of the Spring security framework to our application, in particular the OAuth framework of Spring security.
  2. The packages contain specific security adaptations for the CloudFoundry/XSA environment.
  3. The packages contain platform-specific native implementations for the JWT validation.

Add Spring as Servlet Listener to your web.xml

Afterwards you need to go to your web.xml in src/main/webapp/WEB-INF and add the following lines. If you have used the Archetype in Step 3 of the Tutorial: these lines should be already there and you can simply uncomment them.


This configuration introduces the Spring Security Filter Chain on all incoming routes of your Java microservice and declares that the entire security configuration can be found in a file called spring-security.xml.

Introducing spring-security.xml

In the next step we need to protect our routes on a more fine-grained basis by introducing the file spring-security.xml to our /src/main/webapp/WEB-INF directory. If you have used the Archetype in Step 3 of the Tutorial: this file should be already there.

To protect all your routes so that users have to be at least authenticated you spring-security.xml should contain at least the following line:

<sec:intercept-url pattern="/**" access="isAuthenticated()" method="GET" />

This code says that all users which access all URLs under / with the GET method have to be at least authenticated. You can find the full reference for access management here:

The full spring-security.xml should look like this:

<?xml version="1.0" encoding="UTF-8" ?>
<beans xmlns=""
   <!-- protect secure resource endpoints ================================================ -->
   <sec:http pattern="/**" create-session="never"
      <sec:anonymous enabled="false" />
      <!-- section to protect your endpoints -->
      <!-- Example: Check a specific OAuth Scope (i.e., authorization) on a resource -->
      <!--<sec:intercept-url pattern="/hello" access="#oauth2.hasScope('${xs.appname}.Display')" method="GET" />-->
      <!-- Example: Check only authentication on a resource -->
      <sec:intercept-url pattern="/**" access="isAuthenticated()" method="GET" />
      <sec:custom-filter ref="resourceServerFilter" before="PRE_AUTH_FILTER" />
      <sec:access-denied-handler ref="oauthAccessDeniedHandler" />
   <bean id="oauthAuthenticationEntryPoint"
   <bean id="oauthWebExpressionHandler"
   <bean id="accessDecisionManager"
            <bean class="">
               <property name="expressionHandler" ref="oauthWebExpressionHandler" />
            <bean class=""  />
    <sec:authentication-manager alias="authenticationManager"/>
   <oauth:resource-server id="resourceServerFilter"
      resource-id="springsec" token-services-ref="offlineTokenServices" />
   <bean id="offlineTokenServices"
         <property name="verificationKey" value="${xs.uaa.verificationkey}" />
         <property name="trustedClientId" value="${xs.uaa.clientid}" />
         <property name="trustedIdentityZone" value="${xs.uaa.identityzone}" />
   <bean id="oauthAccessDeniedHandler"
      class="" />
   <!-- define properties file =========================================================== -->
   <bean class="">
      <property name="location"  value="classpath:/" />

Modify your backend manifest.yml to bind XSUAA and trust for all identity zones

Now we need to modify the manifest.yml a bit to interpret the JWT sufficiently. To do this add the following lines to your backend microservice’s manifest.yml file:

SAP_JWT_TRUST_ACL: '[{"clientid" : "*", "identityzone" : "*"}]'

In addition, we need to bind our my-xsuaa instance to our java backend service as well so that we have the OAuth secret to validate the JWT’s signature

- my-xsuaa

In my example case, the final manifest.yml may look like this (depending on your progress with other steps of the tutorial):

- name: firstapp
  memory: 768M
  host: firstapp-p1942765239trial
  path: application/target/firstapp-application.war
  buildpack: sap_java_buildpack
    JBP_CONFIG_SAPJVM_MEMORY_SIZES: 'metaspace:96m..'
    SAP_JWT_TRUST_ACL: '[{"clientid" : "*", "identityzone" : "*"}]'
  - my-destination
  - my-xsuaa

Deploy and test the application

Now we are ready to build and deploy the application to try all our changes with

mvn clean install
cf push

After deployment, accessing your backend service should not be possible anymore and will quit with the following message:

However, you should be still able to access your application using the App Router as the entrypoint:

Recommended Changes with Usage of AppRouter

Removed Mocked Auth User

If you have previously enabled the mocking of tenant and user information via the environment variable ALLOW_MOCKED_AUTH_HEADER as mentioned in Step 5 of this tutorial series, you should now remove this setting. Execute the following command:

cf unset-env firstapp ALLOW_MOCKED_AUTH_HEADER

Removed CSRF Token protection from backing service

If you have previously exposed the backing service directly to the end user, you have used the RestCsrfPreventionFilter on the backend to protect against Cross-Site-Request-Forgery. As this is now in the responsibility of the App Router, we should remove it. For this remove the following lines from your web.xml:


Use OAuth scope to authorize users

Now that we saved the backend microservice from unauthenticated users, we also want to make sure that certain endpoints can be called only when users have specific authorizations. In the following example, we want to use our Display OAuth scope.

Enhance spring-security.xml to protect routes with OAuth scopes

The backend itself can be easily adapted based on the spring-security.xml. In this case, we protect the /hello route with our Display OAuth Scope. Introduce (or uncomment) the following line within the <sec:http> element:

<sec:intercept-url pattern="/hello" access="#oauth2.hasScope('${xs.appname}.Display')" method="GET" />

Afterwards you need to redeploy the application with

mvn clean install
cf push

Assign users to scopes

Furthermore, the user accessing the application, needs to be assigned the Display OAuth scope. This is done using the SCP cockpit.

First, go to your trial account on Cloud Foundry and find the role collections menu under the Security module:


Second, create a new role collection which you can give an arbitrary name. In our case, we call the role collection Business Partner Manager.


Afterwards, select the role collection “Business Partner Manager” and select “Add Role”. From the menu, select your application and the corresponding role template and role as shown below:


Afterwards, the user has to be assigned to the newly created Business Partner Manager 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 “Business Partner Manager” role collection from the menu to assign it to your user:


Afterwards you have a route that is protected by the Display OAuth scope which you can still access because the user has now the corresponding role.

That’s it for today. Now you have learned the basics to protect your application on SAP Cloud Platform, CloudFoundry based on the SAP S/4HANA Cloud SDK. Stay tuned for upcoming blog posts about more advanced usages of the SAP S/4HANA Cloud SDK.



Understanding Roles, Role Collections and Scopes

The following picture explains how the various concepts are related to each other.

Gray Box: As a SCP developer (e.g., SAP, partner, customer) of the business application (gray box), you define role templates which may contain multiple OAuth scopes. The developer here define the scope, role templates and additional attributes within the xs-security.json as explained in this tutorial which is used when creating the service instantiation to the XSUAA.

Orange Box: As an SCP tenant administrator of the business application (customer) can create a role collection which is spanning multiple roles reflecting the role templates. This way you can achieve, on the one hand, a fine-granular authorization control for the microservices and, on the other hand, compose them very flexibly in coarse-grained role collections. The idea behind this is, that, for example, the Business Partner Manager role collection may span multiple applications and microservices all having individual scopes. The role collections resolves the roles and scopes and returns a union of all scopes which are composed by the role collection.

Green Box: As an administrator of the users (customer), the role collection can then be assigned to the final user using the SAML attribute “Groups”.

Troubleshooting Json Web Tokens

Sometimes it might be necessary to investigate the JWT on the backend microservice during development to check for potential errors. Here is an example Servlet that prints the token out.

public class JwtDebugServlet extends HttpServlet {
    protected void doGet(final HttpServletRequest request, final HttpServletResponse response )
            throws ServletException, IOException
        Enumeration headerNames = request.getHeaderNames();
        while (headerNames.hasMoreElements()) {
            String key = (String) headerNames.nextElement();
            String value = request.getHeader(key);
            response.getOutputStream().println(key+" : "+value);

Afterwards you may use to decode the token. Note: You should never use this with any productive JWT as these tokens are shared on a public website. Fallback to local solutions.

Troubleshooting OAuth Scopes from XSUAA

In addition, you may use the XSUAA to see which current scopes and roles a particular users has. You could do this with your XSUAA tenant-specific URL:


In our example this would be:

which returns something like this:

Setting up your own Identity Provider

So far, we have used the XSUAA service itself as the user provider. However, in production scenarios customer’s may want to use their own Identity Provider (IdP) as a user provider or delegate into on-premise user stores such as LDAP or ActiveDirectory. In the following, we quickly show how the XSUAA service can delegate requests to such an external IdPs.

To make this happen, the IdP and the service provider (SP) have to exchange security metadata, i.e., the IdP has to import the metadata of the SP and vice versa.

You can retrieve the metadata from your XSUAA tenant by following the pattern https://<tenantID> In my case, that would be This downloads the metatdata to your local computer.

Second, you need to import the metadata into your IdP. In the following, we use an own SAP Cloud Identity tenant to do this.

  1. Within the IdP, we have to create a new application called MyApp where we select the SAML 2.0 Configuration
  2. Import the SP’s metadata and click “Save”.
  3. Back in the SCP account cockpit we need to add the IdP’s metadata in the same manner
  4. Click “New Trust Configuration” and add the metadata from the IdP and click “Save”

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Former Member

    Hello Philipp,


    Nicely written.

    Some comments:

    1)  TENANT_HOST_PATTERN is a variable required for multi tenant applications. This is the default in the application plan.  If the application is not a multi-tenant aware application, you can add the following entry to your xs-security.json:


    When adding this and recreating a service instance, it is not required to set the TENANT_HOST_PATTERN .

    2) Many applications use spring for their logic. For applications not using spring, an alternative is to use the sap_java buildpack and set authentication method XSUAA in web.xml See

    1. Philipp Herzig Post author

      Hi Martijn,

      thanks a lot for the feedback, very good points. I tried to incorporate them already during the text now!

      Thanks a lot


  2. Wolfgang Janzen

    I also like the summary; it provides a good introduction to the fairly complex topic.


    Regarding Appendix: Understanding Roles, Role Collections and Scopes

    It might be worth to emphasize that the different areas (highlighted with different colors) aims at different target groups:

    Green -> IdP User Manager (customer)
    Red   -> SAP Cloud Platform Tenant Admin (customer)
    Grey  -> SAP Cloud Platform Developer (SAP / partner / customer)

    Currently we only support the mapping from IdP User Groups (via SAML attribute “Groups” – the name is currently hard-coded) to Role Collections. The same IdP User Group can be used to assign one or more Role Collection to a user (on UAA side).

  3. Philipp Herzig Post author

    Update History

    • 06.10.2017: Changes XS2 security libs to LATEST version to avoid troubles with newer versions of these libs as they are not managed over Maven Central.
    • 18.09.2017: Recommendations after usage of App Router (e.g., mocked auth user, CSRF Filter)
    • 12.08.2017: Updated to Spring Security OAuth 2.2.0-RELEASE dependency:
    • 24.03.2018: Updated Java dependencies to latest XS2 security libs (0.27.2) and OAuth 2.3.2.RELEASE
  4. Former Member

    Hi Philipp,

    Thanks for posting the blog. When i run the command

    cf api

    It raises the following exception. Can you please help in resolving the same?

    Exception 0xc0000005 0x0 0x42024dbf 0x7ffdcf080e57



    1. Philipp Herzig Post author

      Hello Sankeerth,

      this sounds like a very general issue with your cf command line client. Can you post what cf help brings up?

      Thank you


      1. Former Member

        Hi Philipp,

        Thanks for the response. Below is the result of cf help.

        C:\Users\sankeerth\workspace\cf_firstapp>cf help
        Warning: Error read/writing config: unexpected end of JSON input for C:\Users\sankeerth\.cf\config.json
        cf version 6.32.0+0191c33d9.2017-09-26, Cloud Foundry command line tool
        Usage: cf [global options] command [arguments...] [command options]
        Before getting started:
        config login,l target,t
        help,h logout,lo
        Application lifecycle:
        apps,a run-task,rt events
        push,p logs set-env,se
        start,st ssh create-app-manifest
        stop,sp app
        restart,rs env,e
        restage,rg scale
        Services integration:
        marketplace,m create-user-provided-service,cups
        services,s update-user-provided-service,uups
        create-service,cs create-service-key,csk
        update-service delete-service-key,dsk
        delete-service,ds service-keys,sk
        service service-key
        bind-service,bs bind-route-service,brs
        unbind-service,us unbind-route-service,urs
        Route and domain management:
        routes,r delete-route create-domain
        domains map-route
        create-route unmap-route
        Space management:
        spaces create-space set-space-role
        space-users delete-space unset-space-role
        Org management:
        orgs,o set-org-role
        org-users unset-org-role
        CLI plugin management:
        plugins add-plugin-repo repo-plugins
        install-plugin list-plugin-repos
        Commands offered by installed plugins:
        Global options:
        --help, -h Show help
        -v Print API request diagnostics to stdout
        1. Philipp Herzig Post author

          I did not have this error before, but your cf config.json seems to be broken. Maybe reinstalling the CF CLI tools help. Is the exception address the only thing that appears on cf api?

          1. Former Member

            I tried a couple of solutions but none of those helped in solving this issue.

            1. Deleted config.json file and let CF generate that again.
            2. Reinstalled the CF CLI tool.



            1. Philipp Herzig Post author

              Hi Sankeerth,

              unfortunately, I cannot help you here as this seems to be a CF CLI related issue. Please try to ask your question on Stackoverflow:

              Best regards


    1. Philipp Herzig Post author

      Hi Nick,

      hard to say without having more details and not having any information on your SP. Have you really imported the metadata from whatever subaccount (provider, consumer) into your own IdP and also vice versa, i.e., your IdP has the metadata of your whatever XSUAA instance that is attached to your SP.

      If you have logged in before, you may also require to kill any existing session cookies using Chrome Dev Tools or similar.

      I could have a look, if you give me more details or even access to your account.



  5. Former Member

    Hi Philipp,

    This is one of the blog which has covered all the topics needed to enable and handle security. Thanks for such a great content. Really appreciate your effort.

    Keep on posting.

    Best Regards, Kirti Kumar Sharma


    Hi Philipp,

    I’ve a question for you :

    I’ve followed your blog with my SAP Cloud Foundry Trial Landscape account and all worked fine.

    Now I’ve created a new account on the Trial Landscape environment, it’s just a test account.

    However, when I try to run the phase where the user has to assign a role collection to his trust configuration I get the following error:

    Does this means that only “real” SAP accounts can follow your blog? Is there any easy way to fix it? I tried also with the P-Number, but I got the same results.




    1. Philipp Herzig Post author

      Hi Simmaco,

      thanks for your feedback. This error typically occurs, if you haven’t logged in with this specific user at your XSUAA instance before (e.g., on approuter). After logging in once, you should be able to edit assignments for your user.

      Best regards



    Hi Philipp,

    it seems that the link for downloading the “XS_JAVA” package now brings to an empty list. Could you please double check? I had to type “XS_JAVA” in the search box for downloading the package.




    1. Philipp Herzig Post author

      Hi Bert,

      seems like you have pushed only the package.json to CF and CF does not have a link to the SAP NPM registry. I would recommend set the config + npm install locally and then push the whole local content to CF. Maybe it works with an extra .npmrc file (, but I have never tried this myself.

      Best regards



  8. Henning Heitkoetter

    Change log (January 4, 2018):

    • Adapt to new business partner example
    • Change XSUAA service instance name to my-xsuaa (instead of myuaa) and other changes to maintain consistency troughout the tutorial
  9. Former Member

    Very good article. I only have one question. From the JWT Token I can get only the scope of the current logged on user. Is there a way to see also the roles behind that scope using xs2 security ?

    Thank you,



    1. Philipp Herzig Post author

      Hi Bruno,

      not to my knowledge, I also just but it is an interesting question. I will check this soon when I will touch this topic again. Also the XS2 libraries do not seem to have any methods for retrieving the roles from the JWT.

      Best regards



  10. Joice Liu

    Thanks Philipp. You post has helped me a lot in securing my XSA application which currently I have been working on recently.

    I faced the issue having access problem in through web router to the application, from your post I realized, I didn’t forward the Token currently through destination in the manifest.yml when I push the application.

    In terms of this URL you used in the destination as well as api setup. Currently, I can only use URL which is the machine host with expected port where I run this XSA application. I cannot modify this URL like something similar to

    Did I miss something here? Or if it’s still unclear, I would like to provide more information I have here.

    Thanks, again!

    1. Philipp Herzig Post author

      Hi Joice,

      happy that the blog helped you to get your security setup fixed.

      Regarding the domain, you cannot change that at the moment. This is a so-called shared-domain, i.e., an domain that exists across or independent your Cloud Foundry organization. If you try to create your own shared domain using cf create-shared-domain this will return with an error telling you that you are not allowed to create your own shared domain. You can create your own org-specific domains. However, they are not reachable externally.

      Per SCP landscape, there is one dedicated shared domain depending on the datacenter you are in. For the CloudFoundry environment of SAP Cloud Platform you currently have

      • Europe (Frankfurt) with (API endpoint:
      • US East (VA) with (API endpoint:
      • US Central (Beta) with (API endpoint:
      • US West (Beta) (API endpoint:

      Best regards


  11. Former Member

    After I deployed the approuter to cloud foundry, the app is getting crashed. Below is the log


    2018-04-11T15:26:11.61-0400 [APP/PROC/WEB/0] ERR npm ERR! Linux 4.4.0-111-generic
    2018-04-11T15:26:11.61-0400 [APP/PROC/WEB/0] ERR npm ERR! argv “/home/vcap/deps/0/node/bin/node” “/home/vcap/deps/0/bin/npm” “start”
    2018-04-11T15:26:11.61-0400 [APP/PROC/WEB/0] ERR npm ERR! node v6.13.1
    2018-04-11T15:26:11.61-0400 [APP/PROC/WEB/0] ERR npm ERR! npm v3.10.10
    2018-04-11T15:26:11.61-0400 [APP/PROC/WEB/0] ERR npm ERR! path /home/vcap/app/package.json
    2018-04-11T15:26:11.61-0400 [APP/PROC/WEB/0] ERR npm ERR! code ENOENT
    2018-04-11T15:26:11.61-0400 [APP/PROC/WEB/0] ERR npm ERR! errno -2
    2018-04-11T15:26:11.61-0400 [APP/PROC/WEB/0] ERR npm ERR! syscall open
    2018-04-11T15:26:11.62-0400 [APP/PROC/WEB/0] ERR npm ERR! enoent ENOENT: no such file or directory, open ‘/home/vcap/app/package.json’
    2018-04-11T15:26:11.62-0400 [APP/PROC/WEB/0] ERR npm ERR! enoent ENOENT: no such file or directory, open ‘/home/vcap/app/package.json’
    2018-04-11T15:26:11.62-0400 [APP/PROC/WEB/0] ERR npm ERR! enoent This is most likely not a problem with npm itself
    2018-04-11T15:26:11.62-0400 [APP/PROC/WEB/0] ERR npm ERR! enoent and is related to npm not being able to find a file.
    2018-04-11T15:26:11.62-0400 [APP/PROC/WEB/0] ERR npm ERR! enoent
    2018-04-11T15:26:11.62-0400 [APP/PROC/WEB/0] ERR npm ERR! Please include the following file with any support request:
    2018-04-11T15:26:11.62-0400 [APP/PROC/WEB/0] ERR npm ERR! /home/vcap/app/npm-debug.log

    1. Philipp Herzig Post author

      Hi Sankeerth,

      this looks like the package.json is not deployed to CloudFoundry. Please show the content of your approuter directory and how you push the approuter to CF.



      1. Former Member

        I am unable to attached a image here, so writing the folder structure.

        I have following folders and files in approuter.

        • doc folder
        • lib folder
        • node_modules folder
        • approuter.js
        • package.json
        • xs-app.json

        I placed this approuter folder inside a directory(favorite location) along with manifest.yml and xs-security.json files.


        In command prompt, i changed the working directory to  favorite location and executed the cf push command.





  12. Former Member


    We are not using Java spring framework.

    We have tried steps given in “Configure Integrated Container Authentication of the SAP Java Buildpack”.

    But still our app is not protected. Anything we are missing?

    1. Philipp Herzig Post author

      Hi Sankalp,

      using the Spring security artifacts should be independent of whether you are using the rest of the Spring framework or not. Our tutorial series is based on TomEE, hence, the blog is also compatible with non-Spring containers. However, if you need help regarding servlet protection with the standard servlet approach, I need more information on what you did already.

      Btw: The standard servlet approach is also described in our book which will be available at the end of the week: .

      In case you want to share your code examples, feel also free to submit your question on StackOverflow:



  13. Former Member


    When I try securing the backend service using spring (Protect your backend microservice).

    I get the following error.

    2018-05-24T16:54:07.54+0530 [APP/PROC/WEB/0] OUT Exit status 0

       2018-05-24T16:54:07.54+0530 [CELL/0] OUT Cell c18a646f-cf40-4970-ab84-836eb4542ce4 stopping instance d50bb138-d189-4b02-66b7-96a5

       2018-05-24T16:54:07.54+0530 [CELL/0] OUT Cell c18a646f-cf40-4970-ab84-836eb4542ce4 destroying container for instance d50bb138-d189-4b02-66b7-96a5

       2018-05-24T16:54:07.57+0530 [API/0] OUT Process has crashed with type: “web”

       2018-05-24T16:54:07.59+0530 [API/0] OUT App instance exited with guid 46be197c-299f-4e0a-a3f4-2c53ebb88333 payload: {“instance”=>”d50bb138-d189-4b02-66b7-96a5”, “index”=>0, “reason”=>”CRASHED”, “exit_description”=>”Codependent step exited”, “crash_count”=>6, “crash_timestamp”=>1527161047538206124, “version”=>”4465e843-c95f-4c61-90f5-a02f3634e563”}

       2018-05-24T16:54:07.80+0530 [CELL/0] OUT Cell c18a646f-cf40-4970-ab84-836eb4542ce4 successfully destroyed container for instance d50bb138-d189-4b02-66b7-96a5

    Best Regards,


    The complete log is available here:



Leave a Reply