
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.
Cloud Scalability | The ability to adapt computing capacity as needed, in terms of changing demand. The main approach is by having load balancing. |
Load Balancer | Entities 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 Methods | Commonly 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
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.
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.
Steps | Activities |
Pre-requisite | The SP has trusted the KDC |
Step 1 | The client requests access to the SP |
Step 2 | The client requests a Kerberos ticket from the KDC |
Step 3 | The KDC sends a Kerberos ticket to the client |
Step 4 | The SP verifies the Kerberos ticket from the client |
Step 5 | The client is authorized to access the service from the SP |
Steps | Activities |
Pre-requisite | The 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 2 | The IDP generates a SAML assertion |
Step 3 | The IDP sends the assertion to SP |
Step 4 | The client can SSO to the SP and other SP using the same method |
Step 5 | The client is authorized to access the service from the SP |
SP in OpenID & oAuth is been called RS (resource server). IDP in OpenID & oAuth is been called AS (authorization server)
Steps | Activities |
Pre-requisite | The RS has trusted the AS |
Step 1 | The client requests access to the RS |
Step 2 | RS redirect the request from the client to AS |
Step 3 | once the user client logged on to AS, AS shares the access token (and refresh token - optional) with the client. |
Step 4 | The client attaches the access token to the access request to the RS |
Step 5 | The client renews the access token with the refresh token from the AS |
Step 6 | The client is authorized to access the service from the RS |
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.
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-through | Load balancers will pass through the SSL request without processing |
SSL off-loading | Load 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 |
|
SP / IDP exists as a service |
|
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
Provider | Load Balancer Type | Remarks |
SAP (SAP RISE managed) | SAP Web Dispatcher |
|
Azure (SAP RISE managed) | Standard Load Balancer |
|
Application Gateway |
| |
AWS (SAP RISE managed) | Network Load Balancer |
|
Application Load Balancer |
| |
GCP (SAP RISE managed) | Internal HTTP(S) Load Balancing |
|
| External TCP Proxy Load Balancing |
|
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
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.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
12 | |
12 | |
9 | |
7 | |
7 | |
7 | |
6 | |
6 | |
6 | |
6 |