Skip to Content
Technical Articles
Author's profile photo Tobias Lejczyk

Single Sign-On for SAP Gui

Overview

The SAP Gui has been around for quite a while. Even today, where the road takes us more and more into the territory of browser based applications, it is still widely used, especially by administrators and power users. With the criticality of these users, it is no surprise that passwordless authentication or even multi factor authentication is something that is often times required by policies.

This blog seeks to describe the authentication options for SAP Gui with their advantages and limitations. It also gives links to the implementation steps for different scenarios.

SAP Gui Single Sign-On scenarios

For the SAP Gui, we can distinguish four basic SSO scenarios:

  1. SSO with Kerberos
  2. SSO with x.509 certificates
  3. SSO with a certificate from Secure Login Server
    1. Authentication happens between Secure Login Client and Secure Login Server
    2. Authentication happens by triggering a browser based authentication at the Secure Login Server using a JavaScript Web Client

Multi-factor authentication

The most important thing to determine is: What constitutes multi-factor authentication (MFA) and what should the scenario look like.

Generally, multi-factor authentication consists of several credentials out of “something you know”, “something you have”, “something you are”.

However, sometimes an email is considered a second factor, sometimes it isn’t. Sometimes, the authentication at the workstation is already considered as two factors (sometimes because of the workstation itself, sometimes because of a multi-factor authenticaton at some web interface or at the VPN tunnel). The other question is if the workstation authentication is sufficient or if a multi-factor authentication at the application itself is necessary and if that is the case, how often this multi-factor authentication must happen.

It is of utmost importance to define the scenario before determining the specific implementation possibilities.

Multi-factor authentication for SAP Gui

In this paragraph we will be talking about the options for multi-factor authentication during the SAP Gui authentication.

A multi-factor authentication directly at the AS ABAP is not possible. Hence, all MFA scenarios for SAP Gui rely on a MFA for receiving a or using a credential to authenticate at the AS ABAP. This means, that scenario 1 does not support MFA.

The following scenarios are possible:

MFA with Option 2 (Smartcard)

In this scenario, a certificate that is already available in the windows certificate store is used by the SLC. To access this certificate, a second factor is required.

Flow:
Smartcard%20Scenario

  1. Secure Login Client accesses the Certificate via windows certificate store
    Smartcard driver recognizes access and requests a PIN to authenticate access
  2. Secure Login Client uses certificate for authentication at the backend

The most common scenario here is a smartcard, where the smartcard driver makes the certificate available in the certificate store. When the certificate is accessed by the SLC, a popup requiring some credential (usually a PIN) is shown to the user.

MFA with Option 3.1 (Secure Login Client direct)

In this scenarion, the Secure Login Client itself communicates with the Secure Login Server, authenticates the user and fetches a certificate based on that authentication.

Flow:

  1. Secure Login Client connects to Secure Login Server and authenticates user
  2. Secure Login Server issues a certificate and sends it to the Secure Login Client
  3. Secure Login Client puts the certificate into the windows certificate store and uses it for authentication at the backend

This option supports Kerberos, User/Password, TOTP or Radius authentication. The TOTP login module can be used to send out and/or validate One Time Passwords, for example based on an authenticator app (RFC 6238) or sent out via SMS. Since it is scriptable it can support almost any interface for validating one time passwords. Most of the time however, it is used to either validate TOTPs or send out a code via SMS or email.

MFA with Option 3.2 (JavaScript Web Client)

In this third scenario, the flow is quite different. Here, the Secure Login Client triggers a browser which then takes care of the authentication at the Secure Login Server. When that was successful, keymaterial and a signing request is created by the Secure Login Client which then is sent by the browser to the Secure Login Server. The resulting certificate is then handed over to the Secure Login Client.

Flow:

  1. Secure Login Client opens browser with a specific Secure Login Server URL
  2. Browser authenticates at the Secure Login Server
  3. Secure Login Server issues a certificate and sends it to the JavaScript Web Client running in the browser
  4. JavaScript Web Client sends the certificate to the Secure Login Client
  5. Secure Login Client puts the certificate into the windows certificate store and uses it for authentication at the backend

This means that this scenario supports any authentication method that is supported by the Netweaver AS Java, especially SAML. So in this scenario it is possible to use an existing MFA at a SAML IdP.
However, there is one big restriction: The browser needs to be able to talk to the Secure Login Client, and hence the Secure Login Client opens a TCP port bound to localhost. Since ports are interfacespecific and not user specific, this scenario is not supported in environments where more than one user is logged on to a system, as for example in Citrix scenarios, WTS or VDI scenarios.

Pros and Cons

These are the Pros and Cons for different SAP Gui Single Sign-On scenarios:

Kerberos

Pro:

  • Usually readily available (unless clients are only Azure managed)
  • Simple implementation, low additional requirements

Cons:

  • MFA not supported
  • Dependency on Active Directory (Kerberos via Azure Active Directory – Domain Services not supported)

Certificates

Pro:

  • Simple implementation when available

Cons:

  • MFA has to be supported by certificate provider (i.e. by Smart Card driver)
  • Certificates have to be managed (usually done via Group Policy)

Secure Login Client direct authentication

Pro:

  • User experience (no additional programs opened)

Cons:

  • SAML not supported
  • Secure Login Server required

JavaScript Web Client

Pro:

  • SAML Supported

Cons:

  • Multi-User environments (often the case for example in Citrix, VDI, WTS environments) not supported
  • Opening of browser impacts user experience
  • Secure Login Server required

Step by step installation guides

Installation of Secure Login Client: https://blogs.sap.com/?p=1592339&preview=true
(valid for all scenarios)

Conclusion

Depending on your requirements, choose the most simple scenario.

 

This blog will be updated regularly with links to the implementation blogs for the different scenarios.

Assigned Tags

      9 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Carsten Olt
      Carsten Olt

      Hi Tobis, great stuff, hope you're doning fine.

      Just a short update to this.

      • SAP seems to have MFA solution in place for the Employee Central Payroll (ECP)
      • The solution is generally available for ECP customers (Link)

      For 2023 Q1 (IAS) SAP has on its roadmap:

      Planned feature: Enable Secure Login Client to authenticate users based on SAML-flow

      Allows customers to use Identity Authentication Service or a 3rd party identity provider as authenticating server not only for web applications but also for SAP GUI, with tight integration into SLC

      Planned feature: Offer a cloud-based solution for provisioning of short-lived user certificates

      Provides MFA support for SAP GUI without the need for an SAP NetWeaver AS Java instance Light-weight replacement for Kerberos scenario

      This is subject to be changed but sound very interesting.

      Highlights

      • Enables Secure Login Client to authenticate users based on SAML-flow
      • Provides MFA support for SAP GUI without the need for an SAP NW AS Java instance (SLS)
      • Light-weight replacement for Kerberos scenario (like for pure Azure AD environments)

      In Summary: We have implemented all three mentioned Options so far and from a UX perspective having HW-smartcards and PIN-protected strong authentication seems to be the best solution w/o SLS.

      For the future, I am really looking forward to the SLS in the Cloud (as part of the IAS) and having a nice solution as an alternative to Option 3.2

      Cheers Carsten

      Author's profile photo Tobias Lejczyk
      Tobias Lejczyk
      Blog Post Author

      Hi Carsten,

       

      thank you for the additional input. In my blog I am focusing on currently available solutions. When the IAS solution comes around, I'll definitely look into that.

      Regarding the Central Employee Payroll solution, I was not aware of that, but I'll check out what this is. From a first glance it looks like option 2.i, but I'll see if I find any more details or maybe even a test system.

       

      Since SAML is a rather browser focused protocol, I am really curious on how this will be implemented in SAP Gui and what the prerequisites will be here.

       

      Best regards,
      Tobias

      Author's profile photo Nelis Lamprecht
      Nelis Lamprecht

      Hi Carsten,

      I just came across this blog and saw your post. The below feature is what caught my eye and would be a really nice addition for those with existing IdP in place:

      Planned feature: Enable Secure Login Client to authenticate users based on SAML-flow

      Can I ask if this would work with Microsoft Azure ADFS and it's own MFA implementation ? Any details how this would work from a user perspective i.e. for login do they get redirected to organisation IdP login page ?

      We use the above extensively and are converting all on-premise systems to this. If we could add SAP's SSO to this it would be a real bonus for SAPGUI users. For the most part MFA has now become policy to implement and allowing SSO to integrate with existing environments through the use of SAML would be a really great feature.

      Glad to see SSO is still being actively developed with new functionality.

      Regards,

      Nelis

      Author's profile photo Carsten Olt
      Carsten Olt

      Dear Nelis,

      Please note currently this feature is on "Plan only". However, we have lots of customers waiting for this to be available 😉

      To answer your question, YES this works with your own MFA implementation. Here is how the auth-flow could look like in this scenario:

      1. When opening a new connection in SAP GUI, SAP Secure Login Client (SLC) calls the Secure Login Server app of the SAP PKI Certificate Service, which acts as a SAML Service Provider (SP)
      2. The SLC is redirected from the SP to the Identity Authentication Service (IAS), which (optionally) acts as a SAML Identity Provider Proxy
      3. IAS redirects the corporate IdP, in this case for example Azure AD, which authenticates the end user based on the configured authentication policies incl. your MFA implementation
      4. Azure AD (or your IdP) creates the SAML assertion and returns it to the IAS
      5. IAS returns the SAML assertion to the SLS app
      6. The SLS app accepts the SAML assertion and starts the user session for certificate enrollment
      7. After successful authentication, SLC calls the SLS API of the SAP PKI Certificate Service with a request to enroll a user certificate based on the provided public key, while the private key remains on the client
      8. SAP PKI Certificate Service adds the required attributes of the certificate and forwards the certificate signing request to the Cloud PKI, which may be either SAP- or customer-managed
      9. The Cloud PKI returns the signed certificate to the SLS app
      10. The SLC downloads the signed certificate from the SLS app
      11. SAP GUI opens the SNC connection based on the SLC SNC library and the enrolled client certificate

      Cheers Carsten

      Author's profile photo Nelis Lamprecht
      Nelis Lamprecht

      Great information, thank you! I look forward to trying this new functionality.

      Regards, Nelis

       

      Author's profile photo Omar Saad
      Omar Saad

      Hi Tobias,

       

      Thanks for your nice blog

      I have a question about using SSO TOTP along with SAP GUI Digital signature functionality, could we use it in Quality approval, please check image below

       

      BR

       

      Omar

      Author's profile photo Tobias Lejczyk
      Tobias Lejczyk
      Blog Post Author

      Hi Omar,

       

      thank you for your comment.

      This is a somewhat different scope than authentication for system access. I would have to double check what the capabilities in this scenario are. You could think about posting this as a question in the Community https://community.sap.com/topics/single-sign-on. That is probably the place where this question fits in better.

       

      Best regards,

      Tobias

      Author's profile photo Carsten Olt
      Carsten Olt

      Dear Omar,

      yes, this is possible. 

      You need to look at the keyword "SAP Secure Store and Forward" or SSF interface - which is the one responsible for secure re-authentication and digital signatures within SAP (ABAP) environments.

      • The SAP NetWeaver platform provides SSF mechanisms as an internal means to protect arbitrary data in the SAP system.
      • SAP applications can use SSF mechanisms to ensure secure data integrity, authenticity, and confidentiality.
      • The SSF Library for the ABAP Stack is used in applications that are written in ABAP. It supports the functions of creating and verifying digital signatures and functions for encrypting and decrypting documents and performing secure re-authentication.
      • SSF requires using a security product (SSF Library) on the SAP backend and the client frontend - to support additional security.
      • Typically the client side implementation is the SLC, and the server side SSF library is the SAP CommonCryptoLib.

      We have done this for some customers years ago and you can either use the SAP SSO 3.0 Secure Login Client in conjunction with HW smartcards - but you can also use the SLS together with SLS profiles and passcodes (TOTP as described by Tobias) for your SSF process. 

      Example (real project):

      • Payments are merged into batches and made available for reviewers within SAP BCM
      • These payments can be approved or rejected using BCM workflows that involve double / treble or quadruple levels of payment approvals
      • Reviewers have to perform an additional step of authentication as part of the approval process (involving two security factors)
      • Once released, payment files are generated - these are picked up and transferred to the banks using SAP PI/EDIX adapters and the likes...

      In general, SAP offers two different signature methods:

      1 System Signature

      After the user has authenticated himself or herself with login data, the system uses a digital signature. This means that the same SAP user ID password which is considered at the time of login by the user is used as transaction ID/password at the time of approving batches.

      2 User Signature (RECOMMENDED)

      The user writes the digital signature with his/her key. An external security product must be installed that implements the SAP SSF interface on the client = SAP Secure Login Client 3.0 – improves security, requires additional hardware components or passcode from the mobile app (TOTP)

      Digital signatures in SAP GUI with One-Time Passwords scenario are based on several components of the SAP Single Sign-On 3.0 product (license required)

      • Secure Login Client
      • Secure Login Server
      • SSO Authentication Library
      • SAP Authenticator mobile application (or any other passcode generator compatible with RFC6238)
      • Generation of such keys and certificates must be short-lived and considered for one-time usage
      • To receive such a signature certificate a user needs to authenticate with a one-time passcode against a central system
      • Once configured this works „out of the box“ (zero admin efforts)

      Disadvantages

      • Additional infrastructure components involved (AS Java for operating the Secure Login Server)
      • Single Point of Failure if no failover system (SLS) is set up
      • Self-Service enrollment of the SAP authenticator app is required
      • Certificate validity is short-lived and could require the user to enter the one-time passcode more often compared to PIN when using HW smartcards (usability might decrease)

      I hope that helps!

      Cheers Carsten

      Author's profile photo Omar Saad
      Omar Saad

      Thanks Carsten for your detailed reply appreciated