updated date: 19.Apr.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

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.

2.2. SSO using SAML 2.0 method

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)

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.

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.

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

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:

• 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:

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:

Extended Reading:
Harmonized Single Sign-On for SAP RISE customers in Multi-Cloud Environment 
Join our RISE with SAP community here