Technical Articles
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:
- SSO with Kerberos
- SSO with x.509 certificates
- SSO with a certificate from Secure Login Server
- Authentication happens between Secure Login Client and Secure Login Server
- 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.
- Secure Login Client accesses the Certificate via windows certificate store
Smartcard driver recognizes access and requests a PIN to authenticate access - 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.
- Secure Login Client connects to Secure Login Server and authenticates user
- Secure Login Server issues a certificate and sends it to the Secure Login Client
- 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.
- Secure Login Client opens browser with a specific Secure Login Server URL
- Browser authenticates at the Secure Login Server
- Secure Login Server issues a certificate and sends it to the JavaScript Web Client running in the browser
- JavaScript Web Client sends the certificate to the Secure Login Client
- 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.
Hi Tobis, great stuff, hope you're doning fine.
Just a short update to this.
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
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
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
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
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:
Cheers Carsten
Great information, thank you! I look forward to trying this new functionality.
Regards, Nelis
Hello Carsten,
Great information, thanks for this. This is something we are looking to implement in our environment. Is this available now or any tentative date when this will be available?
Regards,
Prasanna
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
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
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.
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):
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)
Disadvantages
I hope that helps!
Cheers Carsten
Thanks Carsten for your detailed reply appreciated
Really great blog, thank you Tobias
Also, thanks Carsten - handy to see what is coming up in 2023
My goal is to evolve our current SAP SSO 3.0 & SAP Java AS IdP implementation, instead to use Azure AD as the IdP and enforce MFA in the case where users are outside corporate networks or have specific roles
Once the SSO is enabled for a user, how do you resolve if a user wants to log on to GUI using a TestID to conduct testing?
I am trying to understand when you click the client, does the user have the option to enter the name or does it automatically trigger SSO and pass on the logon ticket to the GUI? What if I have multiple clients, will it allows me to select the client?
Hi Kathleen,
the identifier in the credentials is fixed (for a certificate for example: CN=USER123, OU=SAP, O=COMPANY, C=DE). However, this string is set in the SNC Name of a user. And you can have multiple users with the same SNC name.
When SSO is enabled, the system searches over all clients and users, where the specific name is set (well, it is searching for a normalized hash of that value, the so called canonical name, but that's just details 😉 ). If multiple matches are found (either because of multiple clients or of multiple users in the same client or a combination...) the user is shown an overview of all matches and can select the desired logon user/client combination.
Best regards,
Tobias
Hello Tobias.
Congratulations for your blog.
We have a customer that wants to work with SSO SAP GUI desktop + Azure MFA. I understand that we have in "MFA with Option 3.2 (JavaScript Web Client)" scenario.
Are there any blog or guide to how to completed this scenario? We have SAP SSO 3.0 license.
Thank you and kind regards.
Juan
Hi Juan,
unfortunately, I don't have an exact guide at the moment. If I come to it, I'll try to write something up. But that will definitely take some time.
In addition, the solution using IAS is also quite close on the roadmap. The restriction regarding multi-user environments will probably be removed there. So depending on your project plan, it might be a good idea to wait a little bit longer and have a first look at the new solution.
Best regards,
Tobias