|This blog post series is about developing applications in a multicloud environment.
Any good? Post a comment, share on social media, and/or give a like. Thanks!
SAP Cloud Platform and Cloud Foundry
The SAP Cloud Platform Discovery Center lists close to 100 services, some small like Alert Notification, some large like SAP HANA Cloud, SAP Data Intelligence, or CI/CD. Each service shares security considerations common to the platform but also has security requirements specific to the service. In this blog we will zoom in on application security as provided by the following services:
- SAP Cloud Platform Application Runtime: provides the Cloud Foundry environment
- Authorization and Trust Management: to manage user authorizations and trust to identity providers.
The SAP Cloud Platform Discovery Center lists the features and service plans for the service with links to resources, tutorials, and support information.
Application Runtime Security
Although Cloud Foundry supports a large selection of development languages (buildpacks) including Go and .NET Core, for the SAP Cloud Platform the focus is on Java, Node.js, Python, and HTML5/SAPUI5. How to develop applications for these languages is extensively documented in the section Development in the Cloud Foundry Environment of the SAP Cloud Platform guide.
Regardless of the development language and runtime used, all share a common authentication and authorisation service called UAA, short for User Account and Authentication.
Cloud Foundry as a platform also has its security requirements. Think secure communications inside the Cloud Foundry vLAN, connectivity with external services, deployment and containers itself.
From the perspective of an application developer on the SAP Cloud Platform, however, these security concerns are the responsibility of the cloud service provider which, depending on where you have created your subaccount, will either be AWS, Azure, Google Cloud, or Alibaba (with SAP responsible for wiring it all together). For more information about Diego Brains, BOSH Directors, and jump boxes, see Security and Networking (Cloud Foundry).
SAP HANA XS Advanced
SAP HANA XS advanced model is a Cloud Foundry “distribution” specifically tailored to the SAP HANA platform. Although this environment is quite distinct from Cloud Foundry as hosted by the public cloud providers, we do encounter some similarities when we consider the security requirements of the platform as documented in the SAP HANA Security Guide: Security for SAP HANA Extended Application Services, Advanced Model.
The default IdP for XS advanced is the SAP HANA database, levering built-in database user management and XSA-specific authorisations (scopes, attributes, roles). On the SAP Cloud Platform, the default IdP is the SAP ID Service.
In case you are interested in setting up your own Cloud Foundry environment, see Deploying Cloud Foundry with cf-deployment about the steps to deploy the platform using BOSH.
If your computer is powerful enough, you can even consider to run Cloud Foundry locally. See the Tanzu (VMWare) CF Local project for instructions. The previous implementation, CF Dev is still available on Github but appears to have been discontinued.
Rolling your own requires a good understanding of the technology. See Cloud Foundry: The Definitive Guide by Duncan C. E. Winn (O’Reilly) for a comprehensive overview.
Authorisation and Authentication
UUA and RBAC
The User and Authentication (UAA) services provides role-based access control (RBAC) for both internal services and user-facing applications. Although the UAA can use an internal identity store (e.g. MySQL or SAP HANA), typically an external identity provider (IdP) is used.
The SAP Cloud Platform uses the SAP ID Service as IdP for RBAC to the platform. For business applications hosted in the Cloud Foundry environment we can leverage the same IdP but also configure alternatives. For this we use the Authorization and Trust Management service.
OAuth and JWT
UAA is an OAuth2 provider and what this means is that the UAA issues JSON web tokens (JWT) for client applications to act on behalf of Cloud Foundry users.
This is illustrated below in four steps
- App developer executes a cf login command to the CF CLI (command-line interface).
- CF CLI makes a RESTful API call (HTTP POST) to the UAA for validation
- UAA returns a token
- CF CLI uses the token for each subsequent request (until expiration)
The example shows the cf apps command to the CF Controller but this could be any API call. Instead of cf login we could also present the user with web page similar to the one below to request credentials. The key ingredient is that the client application (CF CLI) makes API calls with tokens and not with your credentials.
The get token flow is just one of several OAuth flows, including one involving the Open ID Connect (OIDC) protocol for authentication. Typically a token also includes a scope to control the actions the app can perform on your behalf. Below an illustration of the OAuth grant flow between client (application router), resource server (application service), authorization server (XSUAA) and the resource owner (you).
For more detailed information about how the UAA works, see
- UAA Overview (Cloud Foundry documentation)
The login page displayed provides self-service create account and reset password functionality. The UAA itself is a Java application and like all Cloud Foundry components open source. You can deploy it locally and adapt it as required:
- CloudFoundry User Account and Authentication (UAA) Server (GitHub)
- Quaa – Quick UAA deployment with Cloud Foundry (GitHub)
The RFC for OAuth is on IETF.org [tools.ietf.org/html/rfc6749] but for those a little less familiar, you might appreciate a more gentle introduction:
- What the Heck is OAuth? (Okta.com)
Business Application Pattern
Extended Services for UAA
For applications deployed on the Cloud Foundry environment of SAP Cloud Platform, SAP proposes the business application pattern, consisting of multiple microservices each deployed as separate applications. The diagram bellow illustrates the architecture with the XSUAA managing security.
XSUAA is short for extended services for UAA which sounds familiar to SAP HANA extended services (XS) but is not necessarily related as SAP HANA XS also references the classic model which has no relation to Cloud Foundry at all.
In brief, we have
- CFUAA: Cloud Foundry open source Java app
- Platform UAA: deployed to the SAP Cloud platform
- XSUAA: CFUAA extension as tenant service for a business app
For the details, see the SAP Cloud Platform documentation
- Business Application Pattern
- UAA, XSUAA, Platform UAA, CFUAA – What Is It All About? by Martin Blust
- Demystifying XSUAA in SAP Cloud Foundry by Jeffrey Groneberg
Authorization and Trust Management
Before we can create an instance of the XSUAA service, we first need to enable the service for our account. The XSUAA service is available on the Cloud Foundry Service Marketplace and provides four service plans. The documentation link references the SAP Cloud Platform guide, where we find the concepts explained, tutorials (see below), and information how to work with the service (development and administration).
Alternatively, we can enable the service and create a service instance using the command line.
cf create-service xsuaa application xsuaa -c xs-security.json
For the equivalent steps on the XS advanced environment of the SAP HANA platform, see
- Create an Instance of the XS UAA Service, SAP HANA Developer Guide for SAP HANA XS Advanced Model
SAP API Business Hub
The APIs for the Authorization and Trust Management services are also available on the SAP API Business Hub with a sandbox for you to try them out.
To get a grip on the matter, the XSUAA documentation references two tutorials on the SAP Developer Center, for Node.js and Java (using the SAP Cloud SDK).
- Secure a Node.JS Application and Make It Available to Other Subaccounts (Node.js)
- Secure Your Application on SAP Cloud Platform Cloud Foundry (Java)
SAP TechEd and GitHub
More code samples and material can be found on GitHub:
A particular elaborate example comes from SAP TechEd 2019 (SEC360)
OAuth grant flows in a microservices environment can get complex. Should not everything proceed as expected, consult the troubleshooting section of the SAP Cloud Platform guide:
Share and Connect
Enjoyed the blog? Post a comment, share on social media, and/or give a like. Thanks!
If you would like to receive updates, connect with me on
Denys van Kempen