SAP Learning Journey

Securing the Extension Application

Objectives
After completing this lesson, you will be able to:

After completing this lesson, you will be able to:

  • Explain the components for securing applications in SAP BTP Cloud Foundry.

Authentication based on OAuth 2.0

Understanding the Terms "Authorization" and "Authentication"

Before we introduce security in SAP Business Technology Platform (BTP) Cloud Foundry, let us explore the basics of security. Any security mechanism are derived from two things: authentication, meaning identifying the user who gets the access, and authorization, meaning what access the authenticated user gets and what the user is allowed to execute.

In relation to security, we see how these two are used and applied to the application running in SAP BTP Cloud Foundry.

Securing Apps using OAuth 2.0 Authorization Framework

The applications running on SAP BTP rely on the OAuth 2.0 framework.

According to the Internet Engineering Task Force (IETF) definition, the OAuth 2.0 authorization framework enables a third-party application to obtain limited access to a HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. The following are some key components of the framework that are important when securing the application on SAP BTP Cloud Foundry.

All of these participants interact through flows. In the flow authorization code grant, OAuth 2.0 allows access tokens to be issued to the third-party clients using an authorization server with the approval of the user or resource owner. The third-party client then uses the access token to access the protected resources hosted by the resource server.

High-Level Authentication Setup with App Router and XSUAA

Now that we know the basics, we can map these standard OAuth2.0 terms to the real applications and services that implement this standard.

In the previous sections, we only considered a single Java-based (micro-)service, where our application consisted of a few back-end APIs and the UI. In this video, you will learn about the components that look after security. You will see how to map these components to the OAuth 2.0 specification. You will also learn how to code grant OAuth2.0 flow.

Setup Authentication Steps

Let's now try to sum up the steps that need to be performed to set up this flow.

Business Authorizations Concept on SAP BTP

In addition to the authentication we discussed previously, we also need to consider business authorizations that are provided to the users of the application. Business authorizations are more fine-grained controls of our exposed business capabilities. Consider for example, that we might only want to allow certain users read rights, while other users might be allowed write rights to an application. For this, we require authorization definitions at design-time and corresponding runtime checks. The following figure, Business Authorizations Concept on SAP Business Technology Platform, provides a high-level overview of how authorization concepts are modelled and handled on SAP BTP in the Cloud Foundry environment.

The developers or architects of the business application define role templates, which may contain multiple (OAuth) scopes. OAuth scopes here refer to very specific authorizations, such as, display or write grants, which are checked in the end by the microservice. The xs-security.json descriptor provides the scope and role template design while creating the XSUAA service instance.

The consumer of our application (for example, an administrator of the customer) can then instantiate the provided role templates into concrete roles in the subscriber accounts and may aggregate multiple roles (for example, from different providers) into role collections, which are finally assigned to individual users or groups of users. The role collections resolve all associated roles and return a union of all associated scopes as part of the JWT issued by the XSUAA.

Steps to Set up Authorization on SAP BTP

The figure, Steps to Set up Authorization on SAP Business Technology Platform, depicts the steps that the user (for example, an administrator of a customer) needs to perform to assign the corresponding roles to the users. These steps are performed in the SAP BTP Cockpit.

The following steps need be performed:

  1. Define a role collection.
  2. Add Role Template to Role Collection.
  3. Trust configuration: Assign Role Collection to a user.

After these steps, the application can be used with the authenticated and authorized user.

Approuter and authentication

The approuter is comprises the following set of components and files:

  • package.json file
  • xs-app.json file
  • manifest.yml File
  • xs-security.json File
  • web.xml File

package.json File

package.json is the descriptor that helps you install the correct version of the approuter using the Node.js Packet Manager (NPM) tool.

Note
The approuter is already installed. You can do this by following the provided description in the repository.

xs-app.json File

The figure, xs-app.json File, shows the design time configuration file for the approuter. The xs-app.json file contains two routes to our back-end microservice, one for our back-end APIs and a second one for the static front-end content. In the figure, xs-app.json File, the first route from line 5 to 7 is the back-end APIs and the line of code from 10 to 12 is the route for the front-end application.

During runtime, a route is identified through a matching pattern provided under the source path that is matched against the relative URL requested by the client. The relative URL for the back-end service is calculated based on the expression under target and combined with the base URL that is read from the destination variable, which is provided as an environment variable in the manifest.yml. You can flexibly change destinations later at runtime, when our deployment model changes but leave all design-time parameters constant.

The lines of code from line 14 to line 16 represent the URL that has been configured to be used for logging out and to remove the current session of the approuter.

manifest.yml File

manifest.yml is the deployment descriptor file.

To correctly deploy our approuter, we create a manifest.yml file.

Note
This file is already available in the downloaded app.

The manifest.yml file is used for the approuter to describe the basic metadata for deployment. This file contains two important user-provided environment variables, which are understood by the approuter. The first is the TENANT_HOST_PATTERN variable, which is used to define how tenants are identified in our application’s URL. The second is the destinations variable, which is used to declare the base URL of our app destination that we referenced earlier in the xs-app.json above.

Note
For your application, you need to replace the route parameter with your subaccount’s subdomain as well as the URL parameter of the destinations variable with the correct base URL of your previously deployed address manager microservice.

The third and most important component of this file is a binding to a service instance, named my-xsuaa. This binds our XSUAA service instance to the approuter so that JWTs) issued by the XSUAA can be verified and, therefore, is trusted by the approuter. However, before we can continue deploying the approuter, we need to create our my-xsuaa service instance.

xs-security.json File

To create such a service instance, we require the xs-security.json descriptor file, which is mentioned in our chosen destination location of the approuter. For authentication purposes, in the file we tell the XSUAA to create an instance with a unique identifier. The file contains additional parameters like role templates, which will be used for authentication purposes.

Note
You need to replace the placeholder <subaccount_id> with the subaccount trial account. You see this during the exercise where we implement authorization and authentication.

You can now see how we can protect the back-end microservice (that is, our address manager application), so that it only processes the requests coming through the approuter and is not accessible through a generated application link.

web.xml File

manifest.yml File

As you can see from the figure, the lines of code are used to protect the application.

In the manifest.yml file, we introduce an instance of the destination service and reference this instance. The binding to this destination service instance, as well as xsuaa, is done using the manifest file. Xsuaa service binding ensures that the application can validate the JWT when it receives the request from the app router. Make sure that the following two statements are uncommented by removing the # in front of them as follows:

  • my-xsuaa

  • my-destination

After configuring these parameters properly (follow the instructions in the exercise), these become visible in the SAP Cloud Foundry Cockpit under your space – dev. Then, choose Services from the left panel, and choose Service Instances. You can see that, for the service instances, my-destination and my-xusaa are there.

Log in to track your progress & complete quizzes