Skip to Content

SAML 2.0 and SAP GUI Single Sign-On in one and the same scenario

Have you already experienced benefits such as Web single sign-on (SSO) and identity federation using Security Assertion Markup Language (SAML)?  Do you know about the most common advantages of SAML? If yes, then you most probably know that SAML is an XML-based framework for user authentication, entitlement, and attribute information.

In the last decade, when all industry segments reconsidered their IT investments, focused heavily on Web solutions, and implemented their first cross-domain business processes, SAML was gaining more and more trust and supporters.

IT experts love SAML because it is secure, interoperable, easy to implement and support. But when it comes to heterogeneous landscapes, for which the IT team has to integrate large systems and applications with various old and new technologies, SAML could not be the standard of choice in all the cases.

Here SAP has a solution to offer to their customers by supporting a scenario in which the interoperable SAML assertion could be used for the issuance of a well-known X.509 client certificate and then the certificate to be used for authentication to applications such as SAP GUI that do not support SAML authentication mechanisms, but accept X.509 client certificates.

The main idea of the sample scenario is to implement SSO to the SAP AS ABAP systems, with SAP GUI as the frontend, using SAML 2.0 assertion. The SAML assertion is issued by the SAP NetWeaver Single Sign-On Identity Provider (SAP IDP) and is used for authentication to the Secure Login Server, and then the Secure Login Server issues an X.509 client certificate acceptable for authentication via the SAP GUI. This is an identity provider initiated single sign-on scenario.

The implementation of such scenarios is possible using the SAP IDP and the web-based Secure Login Web Client (SLWC) – a feature of the Secure Login Server. These components are available via the SAP NetWeaver Single Sign-On product.

The scenario includes the following steps:


  1. A user starts a browser
  2. The user authenticates at the SAP IDP. Here two cases are possible:
    1. Assertion is created automatically: If there is an actively running session for this user on the SAP IDP because of previous authentication request for another service provider, the user will get the new SAML 2.0 assertion for the respective service provider without additional authentication.
    2. Assertion is created after successful authentication to the SAP IDP: If the user has no running session at the SAP IDP, the authentication will be forced once the request for SAML 2.0 assertion is received. When the user authenticates successfully the assertion will be provided. The authentication to the SAP IDP could be basic authentication or other, for example authentication with a Kerberos token.
  3. A SAML 2.0 assertion for the SAP NW AS Java system is issued. (This is the system where the Secure Login Server is installed and configured.)
  4. The user is successfully authenticated at the SAP NW AS Java system with the SAML 2.0 assertion. A page which contains the Secure Login Web Client is loaded in the user’s browser. Secure Login Web Client generates a key-pair and issues a certificate signing request to the Secure Login Server.
  5. Based on the authentication at the previous step the Secure Login Server recognizes the user, issues a X.509 client certificate and returns it back to the Secure Login Web Client. The Secure Login Web Client imports the key-pair and the X.509 client certificate into the Windows Certificate Store.
  6. The user starts SAP GUI
  7. The user is authenticated automatically (through SSO) to a required SAP NetWeaver AS ABAP system using the X.509 client certificates imported in the previous step. The same X.509 client certificates can be used for Web SSO also to SAP and non-SAP systems if they do not support SAML 2.0 yet.

This scenario could be implemented also with SAML 2.0 identity providers from other vendors because SAP Secure Login Server capabilities include integration with different identity providers. However, we recommend the SAP IDP because of the competitive advantages the SAP product offers. For more information about these advantages, see Competitive advantages of SAP Identity Provider.

The SAP IDP also supports the service provider initiated single sign-on. Here the service provider will be the Secure Login Server, because the SAML 2.0 base communication for these scenarios is between the SAP IDP and the Secure Login Server. The service provider initiated single sign-on starts again from the browser but the second step is when the user requests the Secure Login Web Client, and based on this request the user is redirected to the SAP IDP for authentication. All steps afterwards are the same as with identity provider initiated single sign-on scenario, described in details above.

You must be Logged on to comment or reply to a post.
  • Hi Donka,

    Thanks for sharing this approach. My only concern here would be performance, there seems to be a lot going on during the initial creation of the X.509 cert - my experience using SAML right here on SCN isn't great (it's quite slow really). Do you have any comments regarding performance of such a scenario?

    How long would you recommend the X.509 certificates are valid for?

    Thanks again,


    • I have also reservations on having to open a browser to access Secure Login Web Client for the X.509 certificate to be issued. Maybe if the browser is opened minimized and closed as soon as the X.509 certificate is issued, it could work. All triggered by a logon script, for example. But then again why not use the native Secure Login Client (if running one of the supported platforms), maybe this solution is more theoretical for most customers. Nice nevertheless and I appreciate the contribution.

      • Hi Samuli,

        The question about "using" SAML 2.0 for SAP GUI came from customers who already have SAML 2.0 infrastructure for web browser SSO and would like to extend it for non-browser scenarios (SAP GUI). So the assumption is that you anyway use a browser as a starting point and in this case best integration point is in some Portal system (SAP or non-SAP). From there you can start SAP GUI using SAP shorcuts, you may be familiar with this feature in SAP Portal.

        SAML 2.0 support is not possible directly in SLC because the underlying DIAG protocol does not support it. If we extend it then it will be available only for the latest releases and its adoption will take "ages" 🙂 .

        Best regards,

        Dimitar Mihaylov

    • Hi Simon,

      You may experiense performance issues with SAML 2.0 only because of network delays, there are redirects between SP and IDP, but not because of the issuing or validation of the assertion. Especially in Intranet scenario this should not be a problem and Donka's blog describes such use case. You may see example performance measurements using SAP identity provider in the following blog:

      The default validity of short-lived X.509 certificates issued by SLS is 10 hours which should cover to a regular working day.

      Best regards,

      Dimitar Mihaylov

  • Hello

    I Installed  SAP NetWeaver AS Java 7.4 SR1 - 90 days trial version. We are  facing issue with   "Uploading Metadata File”.   Error mention below

    “Metadata contains trusted provider which is not an identity provider”

    We referred   following  document for Configuration ::::

    SAML ERROR.png

    Please suggest if   any configuration is require?

    Tejas Gandhi

    SAML ERROR.png
    • Hi,

      You are trying to import a metadata of a service provider system however you shall import metadata of an identity provider system. Make sure you have exported the metadata of the correct system and it is really acting as an SAML 2.0 identity provider. The metadata should contain the following descriptor in this case:

      <ns3:EntityDescriptor ID="Sf16ae1ea-bb87-49db-95ac-8df3e411b184" entityID="" xmlns:ns2="" xmlns="" xmlns:ns4="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:ns3="urn:oasis:names:tc:SAML:2.0:metadata">

      <ns3:IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">




      Best regards,

      Dimitar Mihaylov

  • Hello,

    I would like to integrate this scenarion with IVIEWS from the Java Portal to abap backend system, using saplogon for windows. Do you know any documentation that could help me?

  • Hi Donka !

    I would be interested if you continued to follow this approach especially in connection with saplogon.

    Is it possible to get in contact with you directly to discuss this topic?

    Best regards,


  • Hi Donka,

    I'm just trying to make sure SAML 2.0  is working with SAP ABAP only stack and it does support SAP WIN GUI.


    Osama Khalifa

  • Hi Donka

    We are trying to implement SSO 2.0. We are planning to use SAML 2.0 to authenticate SAP Portal and SAP GUI. Based on your blog, it looks like we will have to call SAP Secure Login Web Client first and then try to login to SAP Portal to log in. But instead, can we set up the below scenario?

    1. User tries to login to SAP Portal

    2. Portal checks for certificate in the browser, if the certificate exists, then the user gets logged in.

    3. If the certificate doesn't exist, then the user is redirected to the Secure Login Web Client. Once the user authenticates SLWC (using basic password or SPNEGO), the certificate is downloaded and added into the users browser and the user gets logged into the portal.

    Please suggest if this can be achieved or not.


    • Hello Sasi,

      If you want to use the SAML technology for authentication to SAP Portal it is not necessary to go over Secure Login Web Client & Secure Login Server. You can simply use the SAML assertion. You just need to configure the trust between SAP Portal (SAML SP) and the SAML IDP. The scenario here describes how to do this for SAP GUI.



  • Hello Donka,

    I am working on SSO 2.0 implementation. below is my scenario.

    1. NW sso 2.0 is available

    2. IDM 8 is available and it will be used as user source.

    3. there is no other user source available ex. AD etc.. so users are manually getting created in IDM with no further authentication.

    I am planning to use IDM as data source but my concern over is ...

    How IDM user will be verified by SSO with backend ABAP system?

    Can you give some thoughts over here?

    If you need any further information to understand this scenario, please let me know.


    Yatin Phad

  • Hi Donka, Secure Login Web Client relies on a JAVA plugin to be available in all users' browsers. All modern browsers have dismissed JAVA plugin support, so Secure Login Web Client has lost much of it's value. Are there any plans to modernise the web client (I have no idea how) to make it compatible with Edge, Chrome and Firefox again?



  • HI Donka

    We have  slightly unusual scenario. SPNego for ABAP is configured for SAP GUI as well as HTTP  I.E FIORI services that are called via browser. That works well. This is scenario for customers that are on internal network and have user IDs in our network AD.

    Now we also have customers that aren't in AD. Those are from other closed networks in need of access to our system. Those customers use SAML over ADFS to authenticate. They USER IDs are in SU01 of ABAP system

    In JAVA system this works well as we have ticket policy set as follows

    EvaluateTicketLogin Module







    Basically whatever is presented to in request get the authentication. No issues 🙂

    In ABAP however this doesn't work as expected. SPNego works well however when SAML is tested it authenticates but then attempts to do SPNego as well and fails. If I disable SPNego SAML works well.

    In short SPNEGO and SAML does't work well togheter. I wonder if there is a trick to stop SPNego kicking in while SAML is authenticating?


    Patrick Rezek



    • I wonder if there is a trick to stop SPNego kicking in while SAML is authenticating?

      Well, there's no trick - that's documented in note 1798979:

      It is also possible to disable SPNego authentication per request ("opt-out"). You can achieve that by adding a URL parameter "spnego" with value "disabled". When the ABAP server receives a request that contains this parameter, Kerberos authentication will be skipped even though it might be configured correctly.

      By intend, that's the same opt-out mechanism as used by the Java server.
      If you are using an Apache-style reverse proxy (like SAP Web Dispatcher) you can also use the RewriteEngine to modify URLs of requests (by adding such URL parameters).

      Alternatively you can modify the ICF service configuration (or create a so-called "external alias" in t-code SICF for the service - with identical path, resulting in an "overlay"): simply activate the option "[x] Use All Logon Procedures".

      By default only one logon attempt is made (with the first credential found in the order of the configured "Logon Procedure" - by default "SPNego" comes before "SAML 2.0"). If it fails, then immediately the configured "logon error" handling (either "Basic Authentication" or "FORM-based authentication" aka "System Logon") is triggered - and no attempt is made to evaluate / trigger other credentials / logon methods.


      I hope this answer helps you to solve the problem.
      Kindly keep in mind that SCN is not the channel to report issues - there's no SLA (Service Level Agreement), so don't expect any timely response.
      All answers are provided on a voluntary basis and without any warranty.


      Best regards, Wolfgang

    • Hi Patrick,

      I have similar scenario in my environment. I suppose to configure Single Sign-on using Secure login server (SSO 3.0).

      SPNego works fine for abap environment, but I am facing issues to authenticate Fiori services using SPNego Protocol (Embedded system).

      In my case, end-users will be accessing only Fiori services and they will not login to Abap application, so I am trying to configure SAML 2.0 Authentication for Fiori serices. My Fiori services is connected to stand-alone HANA engine, BOBJ and Tableau applications.

      SAML2 authenticates into Fiori services using windows AD credentials, but Single sign-on is not working for the same. I am wondering which profile need to be used for single sign-on.

      Experts, Please suggest your approach to achieve the result.

      Thanks in advance





  • Donka:

    We are working with an organization that has deployed the latest version of the SAP GUI.  This organization has also deployed the AS ABAP application server version 7.5.  SAP Hana FPS 12 is the database for the SAP solution.

    The organization has NOT deployed NetWeaver Secure Login Server.

    We have been asked to investigate how SSO might be provided for the SAP GUI users.

    We have been examining whether the AS ABAP server could be Used as an Identity Service Provider, working with a Third Party Identity Provider.  These 2 Entities, the Identity Provider and the Service Provider, would communicate via SAML 2.0.

    Would the AS ABAP server, through the use of SAP Logon tokens, be able to establish SSO with the SAP GUI?

    Is there a better approach that you are aware of to provide SSO to the SAP GUI?

    Would you be available for a discussion by phone the week of 8/28?