A Single Sign-On Guide for SAP S/4HANA Cloud, Private Edition (RISE with SAP)
Well, it is now year-end, and I have some time to share my knowledge. In the past months I got many questions on how to enable SSO for SAP S/4HANA Cloud, Private Edition, so I decided to write a blog on it. I am including some SAP S/4HANA Cloud, Private Edition specifics related to the delivery/license model of the solution. The technology behind is not new and not even SAP S/4 HANA Cloud, Private Edition specific, but there is some demand for a comprehensive overview on the topic.
- Introduction – just skip it if you are already familiar with SSO for SAP on-premise systems
- User access via
- SAP GUI for Windows
- Web browser
- To keep this blog simple, I do not mention every available configuration option. I want to provide you a guide for the 90% case with recommendations.
- My graphics are not designed to explain the exact technical flow but to understand the overall concept.
- Even if I provide to you information about licenses, this blog is not legally binding or part of any contract.
Chapter 1: Introduction
What is SSO?
Perhaps a trivial question, but there is already a lot of potential for misunderstandings. Most customers I talked to expect an SSO experience across Microsoft Active Directory (MS AD) and SAP. Only a minority of the customers want to authenticate one time to SAP (additional user prompt) with a subsequent SSO only for the SAP landscape. This blog is mainly about SSO for SAP S/4HANA Cloud, Private Edition integrated with Microsoft Active Directory.
What do I mean with security token in this blog?
I often use the term security token. A security token is something like a flight ticket. You must show first your passport and then you get a flight ticket. This flight ticket can be used for a defined scope like travel from Frankfurt to Timbuktu on a special date. If you logon to your Windows computer via credentials or biometrics/passport against Microsoft Active Directory Server, you get a Kerberos security token/flight ticket. Many customers use Microsoft Active Directory Server with the Kerberos format as a security token. Kerberos was primary designed for native applications on a Windows computer. If this Kerberos Token is used within the browser, the token will be transferred to an SPNEGO token. SPNEGO is not something magical, it is just a wrapper around the Kerberos token, so it can be used by web browsers. There are also integration tools for Macintosh computers available.
Question: What about mobile devices?
Mobile devices are often a bit different from desktop devices. Why? Because they are not deeply integrated into the MS AD domain. Mobile devices were primarily designed to meet consumer expectations. Most companies do not expose their MS AD to the internet (Azure ADFS is here more appropriate for the cloud). It is just too critical to expose it. That is why enterprises must deploy X.509 certificates on the mobile devices, which are then used for SSO. An end user must authenticate to her mobile device via user/password or biometrics and can then use the X.509 certificate available on the device. This certificate could then be used to authenticate against many authentication authorities.
Question: Why is SSO so complex? Why are there so many options?
SSO depends on an interaction of various devices, operation systems, security systems, and the SAP systems. There are many options how a customer implemented this – in the end it is a large matrix of possibilities.
SAP supports the most important security tokens and concepts (Kerberos, SPNEGO, X.509…) and if required extension/interchange formats for SAP back-end usage. Therefore, SAP must provide different options to cover most of our customers’ use cases.
Chapter 2: SAP GUI for Windows
What is the biggest difference between SAP S/4HANA Cloud, Private Edition and SAP S/4HANA Cloud, Essential Edition from a pure single sign-on perspective?
SAP GUI for Windows (software component deployed on Windows clients) is still used by many power users for SAP S/4HANA Cloud, Private Edition. In opposite to SAP S/4HANA Cloud, Essential Edition, which is only accessible for users via the web browser.
Most business users are using the new Web based user interfaces (UI) as part of SAP S/4HANA Cloud, Private Edition. In fact, all new UIs are web browser-based UIs with SAP S/4HANA Cloud Private Edition, but end users will be accessing the solution via SAP GUI for Windows and the web browser.
20 years ago, most end users accessed the SAP systems via a Windows computer. SAP shipped SAP GUI for Windows to meet end users’ requirements with the challenges of that time (CPU, RAM, database). This changed over time. Now business users would like to access SAP applications via the web browser, with any device, running various operating systems. The SSO architecture changed from proprietary to open standards like SAML and OpenID Connect, which are supported across software vendors – a big achievement from my point of view – but these open standards cannot support all the proprietary User Interfaces like SAP GUI for Windows.
Authentication Options for SAP GUI
- If you are reading any notes or the help documentation. SAP Cryptographic Library and CommonCryptoLib is the same
- Secure Login Library and Secure Login Server are part of the SAP Single Sign-On documentation.
Kerberos provided by Microsoft Active Directory (second row of the table)
Chapter 3: Access to Web browser user interfaces (UI)
If you want to get an overview about user interfaces in SAP S/4HANA, the following resource is good. But you do not have to read it to understand this blog. Let us continue what choices you have regarding Web browser user interfaces (UI).
- Kerberos via SPNego
- 509 user certificate
I will provide again a table with all options, but I want to provide first some background information on SAML and SPNego.
SAP Cloud Identity Services – SAML
There is a standard used by many enterprises for web browser SSO: SAML.
- Best practice for authentication to web resources
- Supported by many software vendors
- Works also outside of your network without exposing critical infrastructure
- Mature standard
- No native client or configuration on the devices required
- Enables trust relationships between identity providers
- It is designed to support only web browser-based user interfaces
- The identity provider is an additional central component. If you would install it on your datacenter, you would have to spend a lot of resources to make this service reliable (high availability, disaster recovers, change management). In case you consume this as a service from a cloud vendor, you can neglect this point.
SAML defines two major components:
- The SAML identity provider (IDP) is a central component and responsible to manage or issue SAML tokens à SAP Cloud Identity Services
- The SAML service provider (SP) is a component of the business system like an SAP S/4HANA and responsible to accept/trust a SAML token for user authentication.
- You can configure an ABAP based system to accept SAML to authenticate for web-based user interfaces
- Within the SAP Business Technology Platform (SAP BTP) each subaccount represents an SP
SAP Cloud Identity Services is the default cloud IDP by SAP. SAP S/4HANA Cloud, Private Edition includes the usage of SAP Cloud Identity Services. In fact, there are no usage costs for any SAP cloud-based application (for an exact legal definition please check the SAP BTP service description guide). You can even integrate SAP on-premises systems without additional costs. Why? Well, this is only one contribution to SAP’s Intelligent Enterprise strategy.
How does SAP S/4HANA Cloud, Private Edition deliver the SAP Cloud Identity Services tenant? In this case there is no automatic delivery because we do not know which of the options for SSO you prefer. But SAP S/4HANA Cloud, Private Edition comes with an SAP Business Technology Platform (SAP BTP) Account and there you can get an SAP Cloud Identity Services tenant via a self-service.
Side remark: With the SAP S/4HANA Cloud, Essential Edition there is no SAP GUI and SAP delivers it automatically pre-configured with SAP Cloud Identity Services.
Do you remember my question in the first chapter about what SSO means? With this question in mind, let us talk about the following picture.
On the left side of the above picture, you find all supported security mechanism with SAP Cloud Identity Services. What means SSO to me? It was about the reuse of an existing authentication on the device level. SAML, X.509 and SPNego are here the candidates, if you want to have a SSO experience from a device level up to the SAP system. It is about the reuse of an existing security token and to extend this to the SAP landscape. I do not count a password manager which perhaps paste automatically a user and password into the forms of a web page as a enterprise ready SSO solution. Even if some analysts defined this market as ESSO (Enterprise Single Sign-On) which is a bit misleading to me. So do not stumble across this. Don’t get me wrong, I also have my password manager, but only for my personal accounts.
Kerberos via SPNego
- SPNego: Simple and Protected GSS API Negotiation Mechanism
- Mainly driven my Microsoft
- Needs to be supported by the web browser. It worked for me with Firefox, Chrome, and Edge, but I cannot provide you here with a list of web browser versions supporting it.
Kerberos/SPNego is not invented by SAP. SAP S/4HANA needs to understand what to do with a SPNEGO authentication request. It is a header protocol but let us not dig deeper in this standard. Again – SAP Cryptographic Library enables SAP S/4HANA to manage the authentication request via Kerbeos/SPNego. And again: SAP Cryptographic Library is part of the SAP S/4HANA Cloud, Private Edition subscription.
- It is a very straight forward solution
- No client on the user device required
- No additional central component
In most cases Microsoft AD is not accessible from the internet, so any of your mobile workers cannot use Kerberos for SSO (only via VPN). This is not a Microsoft Active Directory issue but there are many ways how it can be used and configured. With Microsoft Azure Active Directory Federation Services () there are also hybrid deployments available which also meet the requirement of mobile workers. AD and ADFS is in your company a journey and not a big bang implementation. Within most enterprises the SAP team is not responsible for AD/ADFS. They can influence the AD/ADFS journey, but they are often not the owner. SAP gives SAP operators options, which they can use and perhaps you will switch them depending on the AD/ADFS journey.
Well after I explained 2 technical methords (SAML and Kerberos), I would like to close the chapter “Access to Web browser user interfaces (UI)” with all options in one table.
Note: SAP Cloud Identity Services provides now also FIDO2 support. FIDO 2 helps you to reuse an on your device. In case of Windows, it is an integration with “Windows Hello” authentication stack. For Apple it is TouchId. This feature further simplifies the access via SAP Cloud Identity Services. It is also possible to use a hardware token like Yubikey as part of a Multifactor Authentication.
Chapter 4: Summary
In case you want to analyze your company’s situation first, keep the following topics in mind
- First you need to understand the available methods which are supported for authentication
- You need to differentiate SAP GUI and Web browser applications
- What is your integration strategy with Microsoft Active Directory or ?
- Use authentication whenever possible for SAP GUI for Windows in your corporate network.If you struggle with the disadvantage of Kerberos which is in most cases only available in the corporate network, there will be perhaps an additional service in 2022.
- Use SAP Cloud Identity Services as a central authentication point for SAP web-based applications. Integrate any existing corporate IDP with SAP Cloud Identity Services.
- SAP Cloud Identity Services is also about identity propagation for the Intelligent Enterprise
- One integration point for all SAP cloud applications within your corporate landscape
- It helps your SAP admin team to implement some SAP specifics for authentication (risk-based authentication, transformations or handling different IDPs based on use cases).
- No additional cost for usage with SAP cloud applications
SAP Cryptographic Library
Secure Login Client
Secure Login Server
SAP Cloud Identity Services – Identity Authentication
FIDO2 as part of SAP Cloud Identity Services – Identity Authentication
SAP Cloud Identity Services in SAP Community
SAP Single Sign-On in SAP Community
Very good blog, Matthias! Very good examples to easily understand the basics and why we do what. Absolutely love it!
Thanks Matthias for this comprehensive overview. Is there a mistake in the table in section “Authentication Options for SAP GUI”?
From my knowledge, SSO via Secure Login Client needs a license for SSO 3.0. So in row three column Price it should say ‘yes’.
What you say is true for any perpetual license (on-premise stuff). In case of SAP S/4HANA Private Cloud Edition the secure login client is included in the subsription.
Thanks for clarifying. I was not aware about this!
Excellent blog Matthias! Succinctly written and will greatly benefit presales community.
Good content and a simplifying of the concept.
As you know S/4 HANA can be implemented on promises ,on SAP Public Cloud (BTP) and on Private Cloud either by HEC (ECS) or any Hyperscalers.
As far as I dealt with many customers so far ,in order to have SSO beside traditional steps in ERP side you need to use external Load Balancer to be able to access from the internet and this is a big demanding requirement in the market nowadays. You deploy Fiori link on your LB ten only share the link with end users . As an example ,in Azure it can use Azure Application Gateway (with a public IP) as Ext LB. We can't skip external LB in our design when connecting from outside the corporate network because of the distributing of (https) traffic to the backend servers (web dispatchers) by round robin fashion .
There are many good blogs related to Azure for this topic, everyone can benefit I just have few of them here for reference:
Single Sign On for SAP NetWeaver and Azure Active Directory:
Azure Active Directory single sign-on (SSO) integration with SAP Fiori:
yes, but I focused on this blog only on SAP S/4HANA Cloud, Private Edition. If a customer want to access SAP S/4HANA on premise only via Fiori (only as one example), this blog is not the right one.
The moment you deployed S/4 your main method to connect to that is Fiori and that is the main advantages of S/4 vs ECC.
You may be meant SAP GUI bases ONLY connection to S/4 HANA then I suggest you may consider to modify your blog title.
what I am saying is that a customer has to think about SSO for SAP GUI and SSO for Web based authentication and this is not about an on-premise installation with SAP Fiori Only.
In addition our recommendation is a bit different like the links you shared.
very good news for our customers!
Is the conclusion with regards to not free (license needed): only if you use X.509 User Certificates?
So using sapgui with kerberos only is free?
<SAP Gui> still used => with Kerberos only => Free
are there already some more details available on the point "there will be perhaps an additional service in 2022." (from your recommendations).
Nothing which is ready for communication. But since SAP NW Java will propably run out of maintenance, and SLS is on SAP NW Java - the challenge here is clear.
Just checking whether there are something foreseen on that topic in 2023 or is it too early to tell ?
Can you please clarify, whether to access S4HANA cloud private edition system from Sapgui where SAP secure login sever provides x.509 certificate for SAPGUI sso has to travel through sap cloud identity service where as sapsecure login server is configured with saml and okta is IDP and has LDAP connection to Microsoft active directory.
Thanks for the blog, definitely it summarizes SSO options very well.
I see you have included OpenID along with SAML.I don't see additional details of it. I'm wondering if you could help me to understand if OpenID is only expected to be used with IAS and if SAP intended to develop the integration to be used with other Identity providers like Azure AD, Okta, etc. I have posted more details of the question here: https://answers.sap.com/questions/13822962/openid-for-s4hana-on-prem-for-user-login-without-u.html