Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
cancel
Showing results for 
Search instead for 
Did you mean: 
mark_ma
Product and Topic Expert
Product and Topic Expert
Spoiler
updated date: 14.Dec.2023

Security is one of the top priorities for enterprise customers. For enterprise end users, having a seamless log-in process to different systems automatically without manually inputting credentials, can not only improve user experience but also increase enterprise security. With that being said, SSO plays a key role in the process.
In the previous article - 'Harmonized Single Sign-On for SAP RISE customers in Multi-Cloud Environment', we were talking about how RISE with SAP Private Cloud Edition customers harmonizes SSO across their multi-cloud landscape with having more than one IDPs. We were trying to simplify the SSO process by only addressing direct clients (end user devices) to servers (service providers) scenarios. Because, from enterprise end users' perspective, the log-on processes happened very seamlessly without been noticed what happened behind the processes. And this is exactly the purpose of Single Sign-On. While on the server side, behind the scene, the complexity is more than SP servers and IDP servers just receiving requests from client devices.
RISE with SAP Private Cloud Edition customers, typically have large landscapes. On the server side, server-to-server scenarios, for instance, SSO considering cloud scalability with load balancing, and service provider SSO through another service provider, should be considered when setting up SSO. In this article, we will demystify what is happening on the server side behind the scene, by explaining these server-to-server SSO scenarios.

1. Terminologies and Abbreviations

Cloud ScalabilityThe ability to adapt computing capacity as needed, in terms of changing demand. The main approach is by having load balancing.
Load BalancerEntities that realize load balancing. Commonly used load balancers in RISE with SAP Private Cloud Edition are: SAP Web Dispatcher, Azure Load Balancer, AWS Elastic Load Balancer, Google Cloud Load Balancing
Internet Protocol Suite
(see Fig. 1)
OSI seven layers framework
 TCP/IP five layers framework
Security Protocol
(Application Layer)
The one been used in SSO processes is TLS/SSL protocol. TLS (Transport Layer Security) is an improved version of SSL (Secure Sockets Layer). SSO requests are encrypted in TLS/SSL protocol.
Data Communication Protocol
(Application Layer)
The one been used in SSO processes is HTTPS protocol.
SSO requests are encrypted under TLS/SSL protocol, then been transmitted through HTTPS protocol.
Authentication MethodsCommonly used methods in RISE with SAP Private Cloud Edition are Kerberos / X.509, SAML, OpenID & oAuth (rather than conventional authentication, it's more to be delegated authority).
In section 2, we will explain in detail.

Fig. 1: OSI Model vs. TCP/IP Model

2. Review of SSO key steps

In order to generalize SSO scenarios, even though different authentification methods been used, we call the three main parties correspondingly as user client, IDP (identity provider), SP (service provider). While in different authentification methods, some of them might have different names, which we will explain below. Nevertheless, the concepts are similar to each other even with different namings.

2.1. SSO using Kerberos / X.509 method

IDP in Kerberos is been called KDC (key distribution center), which is composed of three components: AS (authentication server), TGS (ticket-granting server), and Kerberos database.

StepsActivities
Pre-requisiteThe SP has trusted the KDC
Step 1The client requests access to the SP
Step 2The client requests a Kerberos ticket from the KDC
Step 3The KDC sends a Kerberos ticket to the client
Step 4The SP verifies the Kerberos ticket from the client
Step 5The client is authorized to access the service from the SP

2.2. SSO using SAML 2.0 method

StepsActivities
Pre-requisiteThe SP has trusted the IDP
Step 1

either - the client requests access to the SP (SP initiated)

or - the client accesses the IDP (IDP initiated)

Step 2The IDP generates a SAML assertion
Step 3The IDP sends the assertion to SP
Step 4The client can SSO to the SP and other SP using the same method
Step 5The client is authorized to access the service from the SP

2.3. SSO using OpenID & oAuth 2.0 method

SP in OpenID & oAuth is been called RS (resource server). IDP in OpenID & oAuth is been called AS (authorization server)

StepsActivities
Pre-requisiteThe RS has trusted the AS
Step 1The client requests access to the RS
Step 2RS redirect the request from the client to AS
Step 3once the user client logged on to AS, AS shares the access token (and refresh token - optional) with the client. 
Step 4The client attaches the access token to the access request to the RS
Step 5The client renews the access token with the refresh token from the AS
Step 6The client is authorized to access the service from the RS

3. Single Sign-On Explained from Server Side

We will explain in detail, SSO considering cloud scalability with load balancing, in section 3.1, and service provider SSO through another service provider, in section 3.2.

3.1. SSO considering cloud scalability with load balancing

Fig. 2: SSO server side, considering cloud scalability with load balancing

SSO requests are TLS/SSL encrypted, then are been transmitted under HTTPS protocol in a secure way. The content in this article focuses on SSO, hence detailed content around TLS/SSL encryption, transmission, and certificate & key management will be explained in a separate article.
In SSO processes, there are 2 ways how load balancers transmit SSL requests.

SSL pass-throughLoad balancers will pass through the SSL request without processing
SSL off-loadingLoad balancers will decrypt the SSL request within the load balancer


SSO requests (either authenticate requests, or access requests) reach IDPs and SPs with load balancing. And there are 2 ways how IDPs and SPs with load balancing could be constructed.

SP / IDP exists as a resource
  • SPs / IDPs are installation-based and are been deployed in VMs
  • Extended load balancing (hyperscaler load balancers, and SAP Web Dispatcher) setup is been used
  • SP examples for this setup could be SAP Netweaver, SAP Fiori, etc.
  • IDP examples for this setup could be SAP Single Sign On, Microsoft Active Directory
  • In section 3.1.1. we will reveal this setup in detail
SP / IDP exists as a service

3.1.1. Review on Load Balancing in RISE with SAP Private Cloud Edition

In this section, we will discuss 'SP / IDP exists as a resource' scenarios, which are managed by SAP RISE. SSO requests will go through hyperscaler load balancers, then go through SAP web dispatcher, and finally to Application Servers or DB servers.


In terms of hyperscaler load balancers, more specifically, there are 2 kinds of load balancers, OSI layer 4 load balancers and OSI layer 7 load balancers.


For requests from private connections, OSI layer 4 load balancers will be used. An example could be, a client desktop connected to the corporate VPN, accessing S/4HANA system (deployed in VM in RISE landscape) through SAP GUI, then the authentification method could be Kerberos / X.509, and the request will go through an OSI layer 4 load balancer. Another example of OSI layer 4 load balancers usage (not SSO specific) could be, IoT devices connected to corporate internet through VPN, doing data transmission to S/4HANA system (deployed in VM in RISE landscape), the requests are also going through an OSI layer 4 load balancer.


For requests from the internet, OSI layer 7 load balancers will be used. An example could be, a client using browser-based applications (eg. BTP applications, SaaS like SuccessFactors, Ariba, etc.) requesting access to S/4HANA system (deployed in VM in RISE landscape) through these browser-based applications, then the authentification method could be SAML 2.0, and the request will go through an OSI layer 7 load balancer.
In the below contents within this section, we will do a review of different load balancers been used in RISE, especially for hyperscaler load balancers, we will specify for each hyperscaler, which OSI layer 4 / OSI layer 7 load balancer service is been used.

Fig. 3: SSO with load balancing for RISE with SAP Private Cloud Edition on Azure

Fig. 4: SSO with load balancing for RISE with SAP Private Cloud Edition on AWS

Fig. 5 SSO with load balancing for RISE with SAP Private Cloud Edition on GCP

3.1.2. Review on Load Balancers used for SSO requests

ProviderLoad Balancer TypeRemarks
SAP
(SAP RISE managed)
SAP Web Dispatcher
  • Customers subscribe through SAP RISE


Azure
(SAP RISE managed)
Standard Load Balancer
    • Handle SSO requests from private connections
    • Take place in the transport layer (OSI layer 4)
    • Support SSL Passthrough
    • Customers subscribe through SAP RISE
 Application Gateway
    • Handle SSO requests from the internet
    • Take place in the application layer (OSI layer 7)
    • Support SSL Passthrough and SSL Offloading
    • Customers subscribe through SAP RISE
AWS
(SAP RISE managed)
Network Load Balancer
    • Handle SSO requests from private connections
    • Take place in the transport layer (OSI layer 4)
    • Support SSL Passthrough
    • Customers subscribe through SAP RISE
 Application Load Balancer 
    • Handle SSO requests from the internet
    • Take place in the application layer (OSI layer 7)
    • supports SSL/TLS Offloading, SSL/TLS passthrough, Mutual TLS verify mode, Mutual TLS passthrough mode and end-to-end SSL through decryption and re-encryption at the load balancer
    • Customers subscribe through SAP RISE
GCP
(SAP RISE managed)
Internal HTTP(S) Load Balancing
    • Handle SSO requests from private connections
    • Take place in the transport layer (OSI layer 4)
    • Support SSL Passthrough
    • Customers subscribe through SAP RISE

 

External TCP Proxy Load Balancing
    • Handle SSO requests from the internet
    • Take place in the transport layer (OSI layer 4)
    • Support SSL Passthrough
    • Customers subscribe through SAP RISE

3.2. SP SSO through another SP


The basic concept of these scenarios is, in case there are several SPs (SP1 and SP2) trusting the same IDP, and the authentication method (e.g. Kerberos / X.509, or SAML 2.0) being used is the same. Then once the client has been authenticated to SP1, then it can also access SP2.

In more advanced scenarios, instead of conventional authentication, it's more about authority delegation. More specific, the authentification method is OpenID & oAuth 2.0. In cases, when the users want to integrate a service from SP1 with a service from SP2, without sharing the user credentials with SP1, the user can only share it with SP2 and tell SP2 which level of information SP2 should share with SP1. Then by leveraging oAuth 2.0, the user client can SSO to SP1 through the delegated authentication on SP2.

Fig. 6: SSO server side, SP SSO through another SP

Disclaimer:

Spoiler

SAP takes no responsibility for managing and operating customers’ own data center, nor for customers’ own hyperscaler subscription

SAP takes no responsibility for provisioning and managing customers’ SSO

SAP product information is based on SAP official documentation online, as of this blog’s updated date of time.

The architecture designs that appeared in this blog, have been considered with each hyperscalers’ (Azure, AWS, GCP) reference architecture from hyperscalers providers’ (Microsoft, Amazon, and Google) official documentation online, as of this blog’s updated date of time.

Acknowledgment to contributors/reviewers/advisors:

Spoiler

Ke Ma (a.k.a. Mark), co-author, Senior Consultant, SAP IES AI CoE / RISE Cloud Advisory RA group
Frank Gong, co-author, Digital Customer Engagement Manager, SAP ECS
Jyothi Prakash Lakshmi, co-author, Network Engineer, SAP ECS
Mohamed Gharbi, Launch Advisor, SAP ECS
David Awankem, Cloud Architect & Advisor, RISE Cloud Advisory
Luc DUCOIN, Cloud Architect & Advisor, RISE Cloud Advisory
Richard Traut, Cloud Architect & Advisor, RISE Cloud Advisory
Kevin Flanagan, Head of Cloud Architecture & Advisory, RISE Cloud Advisory, EMEA North
Daniel Temming, Co-head of Cloud Architecture & Advisory, RISE Cloud Advisory, MEE
Sven Bedorf, Co-head of Cloud Architecture & Advisory, RISE Cloud Advisory, MEE
Special Thank You to external advisors:
Ferry Mulyadi, Partner Solution Architect, Amazon Web Services
Samuel Grevillot, Customer Engineer, Google
Konstantin Popov, Technology Specialist, Microsoft
Holger Bruchelt, Program Manager, Microsoft

Extended Reading:

Spoiler