Skip to Content
Author's profile photo Akhil Agarwal

SAP Cloud Platform Cloud Foundry: Some Basic Concepts


Ever since SAP Cloud Platform included in itself the Cloud Foundry environment, its journey has been incredible. The platform has caught the fancy of application developers across the world, who also bring high expectations. SAP has done exceedingly well to make the platform highly useful by adding a multitude of Business, Application and Platform services such as Machine Learning, IoT, Analytics and Integration, with high quality and flexibility. The multi-cloud strategy has only added more feathers to the cap.

If you have caught up with the trend and have started developing applications on SAP Cloud Platform Cloud Foundry, then you may already be enjoying the excellent reference documentation available on SAP Help Portal as well as Cloud Foundry Portal. However, with this also comes the risk of losing your focus in this sea of information.

If you identify with this situation, then you are at the right place.

This mini blog is aimed at providing you with simplistic view of topics that may otherwise seem complex such as Security, Authentication and Destination Configuration.

How to start

With a trial account on Cloud Foundry, you get a 30-day free access to basic functionality like sub-accounts, user management, up to 10 services, up to 1 GB of instance and application memory. But this suffices when you start small, say with a simple “Hello World!” application. It would be recommended to then then slowly iterate and add more meat to your application. For example, start with Basic Authentication, before exploring more complex authentication mechanisms. In short, start with a small, monolith application and then iteratively add other facets to it.

Security Overview

The Security Concept in SAP Cloud Platform Cloud Foundry follows the principle of OAuth Tokens.

The entry point of a “yet unauthorized” client request is the Application Router, which is primarily responsible for authenticating the user through the User Account and Authentication Service (UAA).

When a request comes in, the application instance, that contains the Application Router, triggers authentication at the UAA through OAuth 2.0. In this process, the application instance acts as the OAuth client, while the UAA acts as the OAuth server.

If the UAA is able to successfully authenticate the user (through an IdP), it sends a Web Token back to the Application Router. This Web Token is then passed to the application runtime. This uses a trust relationship between the service and IdP, primarily through a public-private key pair.

A summary of this authentication concept is depicted in Figure 1. For more details, visit this SAP Help Portal document.

Fig 1: User Authentication in SAP Cloud Platform, Cloud Foundry

SAML 2.0 Bearer Assertion

It is important to note that SAP Cloud Platform Cloud Foundry supports Basic Authentication.

When it is required to authenticate Business Users using SAML 2.0 Bearer Assertion Flow, then they are first authenticated to the SAP Cloud Platform from where they get an OAuth Token. Using this Token, it is now possible for them to access the required service on SAP Cloud Platform Cloud Foundry.

If the requesting application is from the Neo environment, then the following sequence of events takes place.

  1. The Business User is authenticated to concerned application in the Neo environment.
  2. The application issues a SAML Bearer Assertion.
  3. The assertion is sent to the User Account and Authentication Service (UAA) in Cloud Foundry.
  4. The UAA responds with a JSON Web Token.
  5. With this token in hand, the concerned application is allowed to access the required service on Cloud Foundry.

Destination Configuration

Unlike SAP Cloud Platform Neo, the Cloud Foundry environment does not offer a Destination API that application developers may use directly to connect to resource over the web. But this limitation can be easily overcome through User-Provided Environment Variables, and consuming them in your application.

This is how it works on the Cloud Foundry environment.

  • In your SAP Cloud Platform Cockpit, access the application.
  • Define a new “User-Defined Variable”. An example could be: key = “ServiceDestination”. Value = [{name: “ServiceDestination”, url: “”, username: “Username”, password: “LoginPassword”}].
  • In your application, use this variable to call the respective service.


This blog is an attempt to present a simple view of common questions faced by application developers on SAP Cloud Platform Cloud Foundry. In the subsequent blog posts, more topics will be added, including some deep dives as well. Your feedback and comments are highly welcome.

Assigned Tags

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


      Thank you for the article! Can you please provide in more details about defining a new “User-Defined Variable”. Especially, of where do we describe in our app this variable.

      Author's profile photo Akhil Agarwal
      Akhil Agarwal
      Blog Post Author
      Hi Tatiana,
      Thanks for your question.

      In the meantime, Destination Service is available in the Cloud Foundry environment of SAP Cloud Platform. Therefore, there is no need of a “User-defined variable” anymore.

      Read through the official documentation here:

      Best regards,



      Author's profile photo Gokulraj Ramdass
      Gokulraj Ramdass

      Nice Article. I would like to try this. Do you have any example implementation where the NEO gives the SAML Bearer Assertion and passing it on to CF?