A couple of weeks ago, I was sharing my screen for a SAP support ticket and I was going through multiple SAP systems and products without having to log in with my user. The support engineer who was watching my screen was telling me how he always wondered how Single Sign On works for SAP. I told him that in this case, the configuration is based on a product that SAP has for this purpose, SAP Single Sign On (currently version 3.0).
I might have promised that I would write a post on the topic. I was also wondering to what extent this product is known to the community at large because my impression was that it is not as well known as it should be. Why? Because it does deliver added value (quickly depending on the use-case) to the customers who leverage it.
This post is a quick introduction to SAP Single Sign On 3.0 and which components are specific to it for a single scenario that I cover here, be it high-level. If you already configured this solution and have worked with it, you can basically stop reading here.
The basic idea
Single Sign On (referred to as “SSO”) enables the end-user to log onto SAP without having to enter their username and password. For example, a user who logs on to his corporate laptop is authenticated against the corporate Windows domain. The authentication that took place can then be re-used to log onto SAP when the SAP Single Sign On solution is implemented.
The SAP Single Sign On product has extensive features/functions such as Mobile SSO: enabling the same concept for mobile app access on your mobile phone, two-factor authentication: to have an additional verification that you are in fact who you claim to be (more secure) and more.
One of the most used scenarios is authentication against a Windows domain which means the end-users re-use their Windows based authentication to automatically log into SAP products.
If the URL is obsolete at the time you read this post, search for SAP Single Sign On product overview site=sap.com in Google and you should find a good result in the top results of your search.
The product includes multiple applications, features and functions. It does come with a license cost (based on amount of users that will use the functionality) and from what I’ve seen, it’s a fair price for the functionality that you receive.
The product overview presentation (previously mentioned URL) has a number of simplified architectural drawings in the slides.
More elaborate architecture designs and technical details can be found in the secure login implementation guide, you can get a good idea of what the solution looks like. You can currently find the secure login implementation guide on the below URL. If it’s no longer available at the time of reading this post, look for SAP Single Sign On site=help.sap.com through Google to find the relevant page.
There are other features/functions inside of other programs such as password manager that I won’t discuss in this post. You can find them also on the help.sap.com page.
Breaking it down into components
I’ll briefly (high-level) go over the large (SAP specific) components which are used of the scenario described as “workflow with x.509 certificate request using secure login server” in the implementation guide which I’ve used at customer side to establish Single Sign On against Windows Active Directory for AS ABAP based SAP system – targeting SAP S/4 HANA (on-premise edition) customers for example.
As mentioned in the intro, I am not going to go into too much technical details here because the purpose of this post is to give a high-level idea of what the solution can look like. In this case, for just one, specific scenario. You can find a bunch of video’s on how-to configure specific scenario’s as well as extensive information in the guides that SAP provides.
For the techies, the message is: check the sources mentioned to get into the nitty gritty details. There are more simplified scenario’s, it depends on what you want to achieve in the end or what the target vision is of the solution going forward. Better yet would be that you configure this yourself if you haven’t done so already. That’s always a good way to learn something new.
S/4 HANA environment components (not specific to SAP Single Sign On)
The regular components of a S/4 HANA based environment include an AS ABAP stack that contains the core ERP coding (and more) and typically also an AS JAVA stack that is used for Adobe Document Services to generate PDF’s inside of SAP. As you can see in picture 1.0 those are present in the architectural drawing. SAPgui or WebGui based (browser based) access are also already present during a SAP implementation and are not specific to the SAP Single On product as such.
There are parts of the configuration for the scenario that are done inside of ABAP, like SNC enabling the ABAP stack and SPNEGO configuration which have been around for a long time already.
SAP Single Sign On specific components
SAP Secure Login Client & SAP Secure Login Server
There is the Secure Login Client which is a front-end component (installed on end-user laptop) that is part of the SAP Single Sign On solution. The Secure Login Client will point to the Secure Login Server (a back-end component) via a profile configuration (a URL that points to the Secure Login Server).
The SAP Single Sign On Server components run on a single AS JAVA instance. I say single here because the SAP Secure Login Client will point to one SAP Single Sign On Server installation/configuration. This could be the customers productive SAP S/4 HANA AS JAVA stack or it can be another AS JAVA stack (ensure it’s compatible though).
The Secure Login Server is configured against an authentication server such as Windows Active Directory. That way the secure login client can verify your credentials via the secure login server against the authentication server and provide (or deny) access based on that verification.
The SAP Secure Login Server components are installed on top of an AS JAVA stack and provide functionality to connect to authentication sources (such as Windows Active Directory) and configuration for the features/functions that the SAP Single Sign On product offers (mobile SSO, multifactor authentication and so on). After installation you can call up the respective applications and start your configuration. Once configured, the SAP Secure Login Client can be configured with a URL to pull relevant configuration (profile group that contains specific settings) from the SAP Secure Login Server.
What can be the case for example, is that specific user mapping is needed to map the user-id of the end-user in SAP against the user-id in Windows active directory. This is also then typical configuration that can be done inside of the SAP Secure Login Server application.
That’s it for the quick introduction
The combined components (non-specific SAP Single Sign On product) and the specific SAP Single Sign On product component make up the scenario once everything is configured properly. That configuration can still be a bit of a challenge the first time around or when specific scenario’s need to be enabled such as Mobile Single Sign On, things can get more complicated quickly.
It is definitely an interesting product that should be checked out by technical resources as it can quickly provide added value at customer side.