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.
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.
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)
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. SP examples:
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 picture, you find all supported security mechanism with SAP Cloud Identity Services. The last 4 options allow you to reuse an existing security token. Do you remember my question what SSO means to you? Well if this means to reuse an existing authentication on the device level, the last 4 options – 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.
- 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.
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