Fundamentals of Security in SAP BTP
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 Cloud Foundry environment of SAP BTP 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:
- Fundamentals of Security in BTP: Introduction [current blog]
- Fundamentals of Security in BTP: What is OAuth?
- Fundamentals of Security in BTP: Implement Authentication and Authorization in a Node.js App
- Run Node.js Applications with Authentication Locally
Is security in SAP BTP Complicated?
In my opinion, security in SAP BTP is a simple topic. All we need is a clear understanding of all the basic concepts.
Let’s be honest that most of the developers don’t design the application keeping security in mind at first place. We always try to prove the feasibility of use-case first. Once we succeed, then only we think about securing the application. One of the reasons, why people get on back foot when it comes to security implementation.
In SAP BTP, it’s super easy to develop a full-stack business application using sophisticated frameworks like SAP Cloud Application Programming Model, SAP Cloud SDK and many other out-of-the-box cloud services. With little bit effort on understanding the core concepts, you can also solve all the pieces of puzzle in security.
In this blog series, we will make it extremely simple. First, we will understand the basic concepts:
- Identity Provider (IdP)
- Application Router
- Authentication and Authorization Implementation etc.
Further, to get a hands-on experience, we will
- First deploy an Unsecured Hello World Node.js application in BTP Cloud Foundry.
- Then step-by-step we will implement authentication and authorization.
- We will also touch upon Identity Provider to be used for single-sign-on.
Note: This blog series is focused on SAP BTP, Cloud Foundry environment. I may skip mentioning Cloud Foundry every time.
Are there any prerequisites for this blog?
You should have basic idea of SAP BTP, BTP Cockpit and basic Node.js skill to understand these series. Even if you are new to Node.js, you should be managed to go through it.
Let’s start with the basic concepts.
Identity Provider (IdP)
Applications in SAP BTP does not store user information. Instead, the applications redirect the authentication to an Identity Provider. This concept makes it possible to decouple and centralize authentication functionality.
Below image shows a very high-level architecture of a typical Identity Provider.
In SAP BTP, there are 2 options for Identity Provider – SAP ID Service and SAP Cloud Identity Authentication service (IAS).
SAP ID Service
SAP ID Service is the default identity provider in SAP BTP. It is a pre-configured, standard SAP public IdP (account.sap.com) that is shared by all customers.
Few important points about SAP ID Service:
- Trust to SAP ID service is pre-configured in all BTP subaccounts.
- SAP ID Service is managed by SAP.
- SAP ID service manages the users of official SAP sites, including the SAP developer and partner community. It is the place where the S-Users, P-Users, and D-Users are managed.
You can view the SAP ID service pre-configured in BTP subaccounts in the cockpit, as shown below.
SAP Cloud Identity Authentication service (IAS)
For many customers, business users might be stored in corporate identity providers. SAP recommends using SAP Cloud Identity Services – Identity Authentication Service (IAS) as a hub.
We can connect IAS as a single custom identity provider to SAP BTP. Further use IAS to integrate with corporate identity providers.
IAS can be configured in SAP BTP cockpit, in the Trust Configuration section, as shown below.
To know more on establishing trust between SAP BTP and IAS, you may refer to the help document.
Why do we really need SAP Identity Authentication Service (IAS)?
Most customers already have huge on-premises or cloud ecosystem. Their business user data is already available in their corporate identity provider.
When these customers build applications on BTP, an important question comes up – “How can employees authenticate to the applications with known credentials?”
In simple words, customer needs to provide single sign-on for their custom solution on BTP, SAP S/4HANA Cloud, SAP SuccessFactors and other SAP solutions. The answer to this is SAP Identity Authentication Service.
As shown in the above image, IAS can either act as an IdP itself or delegate the authentication to a corporate identity provider. IAS acts a central hub to provide single-sign-on to all SAP cloud applications as well as BTP applications.
SAP Authorization and Trust Management Service (XSUAA)
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:
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.
Call Flow – Putting all the pieces together
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.
- User request for the resource from Application. The App Router takes incoming.
- Since user is not authenticated, App Router initiates an OAuth2 flow with the XSUAA.
- XSUAA forwards the request to Identity Provider to enforce the business user to authenticate.
- IdP prompts the user to authenticate himself. For Example, by entering username and password.
- User authenticates himself.
- 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.
- XSUAA consider this request as authenticated and generates an OAuth Token which is technically a JWT token.
- 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 Identity Provider, XSUAA and App Router. If you have any question, let me know in the comment.
Next blog in the series: