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:

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.