Fundamentals of Security in SAP BTP – Introduction Part 2

This blog series is mainly targeted for developers and administrators. If you are someone who has gone through the plethora of tutorials, documentation, and presentations on security topics in SAP BTP and still lacks the confidence to implement security for your application, you have come to the right place.

In this blog series, we will learn:

  • How to protect an app in SAP BTP, Cloud Foundry environment from unauthorized access
  • How to implement role-based features
  • How SAP Identity Provider and Single-sign-on works

For ease of reading, I have split this in multiple blogs, which are:

  1. Fundamentals of Security in BTP: Introduction Part 1 
  2. Fundamentals of Security in BTP: Introduction Part 2 [current blog]
  3. Fundamentals of Security in BTP: OAuth Concept (optional) [To be published]
  4. Fundamentals of Security in BTP: Implement Authentication in a Node.js App [To be published]
  5. Fundamentals of Security in BTP: Implement Authorization in a Node.js App [To be published]

The XSUAA is one of the most important components involved in security. Let’s get hold of this.

What is XSUAA?

SAP XSUAA is an internal development of SAP.

In Cloud Foundry, there is an open-source component called UAA. UAA is an OAuth provider which takes care of authentication and authorization. SAP took the base of UAA and extended it with SAP specific features to be used in SAP BTP.

Technically XSUAA is an OAuth server and uses JWT tokens.

If you are new to OAuth, refer to this blog to know more about it:

  • Fundamentals of Security in BTP: OAuth Concept [To be published] 

What problem does XSUAA solve?

XSUAA takes care of authentication and authorization in SAP BTP, Cloud Foundry.

Below image shows very high-level architecture of XSUAA. It’s important to note that, XSUAA does NOT store users data. This is why the XSUAA needs to trust an external Identity Provider (IdP). It can establish trust either with SAP ID Service or a Corporate Identity Provider via SAP Identity Authentication Service (IAS).

When a business application consists of several different apps (microservices), the application router is used to provide a single-entry-point to the business application.

Technically, Application Router is a Node.js App, available in public in NPM.

What is the purpose of Application Router?

App Router is used to:

  • Serve static content
  • Authenticate users
  • Dispatch request to backend applications(microservices)

Note that App Router delegates the authentication responsibility to XSUAA.

Now, since we have got clear idea on individual components, let’s understand how these all work together.

The above diagram showcases the call flow. Let’s break it down.

  1. User request for the resource from Application. The App Router takes incoming.
  2. Since user is not authenticated, App Router initiates an OAuth2 flow with the XSUAA.
  3. XSUAA forwards the request to Identity Provider to enforce the business user to authenticate.
  4. IdP prompts the user to authenticate himself. For Example, by entering username and password.
  5. User authenticates himself.
  6. If the authentication was successful, Identity Provider sends a SAML token to user (web browser). The web browser sends this new SAML token to the XSUAA for authentication.
  7. XSUAA consider this request as authenticated and generates an OAuth Token which is technically a JWT token.
  8. The App Router enriches each subsequent request with the JWT, before the request is routed to a dedicated application. The application verify the JWT token and send the requested resource to user.

The below image showcases the same thing as sequence diagram.

I hope you got the basic idea of XSUAA and App Router. If you have any question, let me know in the comment.

Next blog in the series:

  • Fundamentals of Security in BTP: Implement Authentication in a Node.js App [To be published]