Skip to Content

Authentication and Single Sign-On with SAP NetWeaver Business Client (NWBC)

This blog attempts to explain authentication and Single Sign-On mechanisms with the SAP NetWeaver Business Client. Before we go into these details, it is mandatory to explain some technicalities of the SAP NetWeaver Business Client and give a short introduction into SAP’s own product for Single Sign-On, SAP NetWeaver Single Sign-On.

SAP NetWeaver Business Client (or NWBC in short) brings together web-based and Dynpro-based applications, potentially running on multiple systems, in one single shell. It therefore needs to adopt a combination of different authentication techniques to abstract the user from multiple logins and offer a seamless end user experience.

NWBC is shipped in two variants:

  1. NWBC for Desktop is a MS Windows/.NET-based application that needs a local installation. It uses SAP GUI for Windows under the hood to run Dynpro-based transactions and integrates Web applications using the Internet Explorer control in its shell.
  2. NWBC for HTML is a browser based version using HTTP/s for connecting to a SAP NetWeaver Application Server ABAP backend. SAP GUI transactions are rendered using the SAP GUI for HTML.

For Single Sign-On functionality SAP ships its own product SAP NetWeaver Single Sign-On, which allows customers to implement standard token based SSO for the web browser and for SAP GUI for Windows. It also offers a password manager for Enterprise Single Sign-On.

Let us now focus on the question of authentication and Single Sign-On with NWBC for Desktop. With NWBC for HTML, the standard web SSO mechanisms, listed further in the blog apply.

The NWBC approach to authenticate a user against a system is to use the ICF logon which is a browser-based authentication. When the user during the course of his work calls a web-based application, authentication is handled by the standard Internet Explorer control which the NWBC embeds for rendering Web content. This is however different in case of a classic Dynpro screen. For a Dynpro screen, the authentication is handled by the under the hood instance of SAP GUI for Windows.

So what are the available options of authentication mechanisms with NWBC?

The following initial authentication mechanisms are used in SAP products and apply to NWBC authentication depending on the scenario you are running:

  • User ID and passwords
  • X.509 Client Certificates
  • SAML assertions
  • SAP Logon Tickets
  • SPNEGO and Kerberos

Let us now examine each method in a little more detail.

User ID and password is the easiest of course, but you need to roll-out and offer password reset and recovery functionality for your end-users and it is strongly recommended that you have implemented encryption of the communication path (https) or else your end users send the passwords in clear text making sniffing them extremely easy.

X.509 Client Certificate requires a Public Key Infrastructure (PKI), which issues and handles the whole certificate management for your users. You have the option to implement SAP NetWeaver Single Sign-On instead, which generates certificates on the fly without the need to implement and deploy a costly PKI.

SAML assertions are a modern standard for web-based and cross domain Single Sign-On. You need a so-called Identity Provider to issue SAML assertions for your users, which is also part of SAP NetWeaver Single Sign-On.

Logon Tickets are an SAP proprietary mechanism. In the form of a digitally signed cookie they offer authentication and Single Sign-On. You can generate Logon Tickets with NWBC, with the SAP NetWeaver Portal or with SAP NetWeaver Single Sign-On.

SPNEGO with Kerberos is the web variant for Kerberos and you need SAP NetWeaver Single Sign-On to implement that.


NWBC together with SSO, offers you multiple options for authentication. These options differ depending on the scenario you have implemented with NWBC. The table below  provides some details:


SSO Method

NWBC for Desktop embedding Web applications only

X.509 certificates, SAML assertions, SPNEGO with Kerberos, Logon Tickets

NWBC for Desktop embedding Dynpro applications (SAP GUI for Windows)

SNC + X.509 certificates, SNC + Kerberos, Logon Tickets

NWBC for Desktop embedding Dynpro and Web applications

SNC + X.509 certificates, SNC + Kerberos, Logon Tickets

So in short, if you’re running only web applications with the NWBC then you can use the standard web SSO mechanisms as listed further up in the blog.

If you have to access SAP Dynpro applications via the NWBC for Desktop and you want this to be secured via encryption then you have to configure SNC (Secure Network Communication), encrypting the communication path and use either X.509 certificates or Kerberos for Single Sign-On. For both options we recommend the SAP NetWeaver Single Sign-On solution that can generate X.509 certificates or support Kerberos.

Logon Tickets are not recommended by SAP any more unless you need to implement SSO for lower releases (SAP NetWeaver Application Server <7.00).

If you have a hybrid implementation meaning that some of your users will be using NWBC for Desktop and others will be using NWBC for HTML to access the same system, then we strongly recommend that you leverage SAP NetWeaver Single Sign-On as you can implement X.509 and Kerberos for both NWBC types (Desktop and HTML).

For more information on SAP NetWeaver Single Sign-On, please check out the following page on SCN:

For more information on SAP NetWeaver Business Client, please check out the following page on SCN:

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

    Since the NWBC for desktop logs in via an ICF node, you could use a SSO solution to bypass the login page, right?

    (let's say, portal or something)

    Once that login is complete, all GUI Dynpro's in the NWBC no longer require an extra logon, correct?

    - create a dummy node on the portal (https://portal/sap/bc/nwbc)

    [edit: - NWBC is configured to authenticate against this dummy node ]

    - portal creates you a logon ticket and redirects to your backend (https://backend/sap/bc/nwbc)

    - NWBC authenticates with logon ticket

    - NWBC now has full access to sapgui screens, BSP pages and webdynpro screens from that specific backend

    Is this a realistic scenario?

      • Ah, but it's not another browser session.

        When you logon with the NWBC, you get a popup, from the NWBC with a web-logon. It's that pop-up which I want to redirect first over a portal, or Ticket issuer.

        So there's no separate browser involved. It's all in the NWBC.

        would that be possible?

        • I tried this option and it did not work. We used SAP JAva -SPNego to create the ticket.What happened was the SPNEGO authentication worked. But it got "stuck" in the logon window loading the NWBC for HTML.

          But when closing the window and just selecting the logon again. The ticket was in the session and it worked.

        • So instead of the standard /sap/bc/nwbc/TicketIssuer redirect you would redirect to the portal instead? That would work assuming you could change the standard redirect. Since the standard implementation assumes that the ticket is generated within the same stack, there might some other impact also even if the portal issuing the ticket is trusted. Just saying it might be more complicated.

  • Hello

    I'm curious if you can recommend documentation on setting up SAML to work with NWBC?  We don't currently own Netweaver SSO, but we do have Microsoft Active Directory Federation Services that serves as an Identify Provider and handles SAML assertions I think.

    Thanks in advance!


    • From the link above: "NWBC supports all authentication processes that run in a browser on the server". You could setup SAML for the ICF node /sap/bc/nwbc and see if it works.

  • We are using SAML to achieve logon to NWBC through SSO. From there I do not see any issue navigating to Dynpro or WebDynpro screens. System is not prompting for any userid / password when we go to Dynpro or WebDynpro. This blog says for the scenario

    "NWBC for Desktop embedding Dynpro and Web applications"  we have to use SNC + X.509 certificates, SNC + Kerberos, Logon Tickets. In our case we used SAML, but it is working fine for both Dynpro and WebDynpro. Can you please help if there is anything we could not decipher?

    • Hi Surendranath,

      I am also surprised not to see SAML 2.0 listed as an option for all the scenarios listed above. The initial NWBC desktop logon is through the ICF so I would have thought that any ICF supported logon mechanism should work (including SAML 2.0)

      I notice that Nikhil hasn't included it here and also Matthias hasn't included it in his list of supported options here.

      I assume you are still using it...? Have you run into any problems?



      • Hi,

        so SAML is from my point of view theoretically possible if you use only Web
        based content in NWBC. But SAP GUI for Windows do not support SAML since this
        is only a Web based standard. So most customers are using Web and SAP GUI
        transactions within NWBC. That is the cause why it is not on the list from my perspective.



        • Hi Matthias,

          Since NWBC connects initially to the ABAP system over HTTP (which can authenticate using SAML) and after the initial authentication the user will have a valid SAP Logon Ticket which can then be used for both Web and GUI access - I don't see why SAML isn't a supported scenario?

          Am I missing something? In my mind there is no GUI only NWBC scenario since the NWBC desktop client itself always connects over HTTP(s) in the first instance to logon and build the user menu....

          Sorry to keep harping on this, but I really want to understand this completely.


          • I think SNC or encryption in general is the reason. SAML and DIAG don't play well together. I guess if SNC is not a concern, SAML could be used. SAP however can't provide semi solutions, especially since SNC is their proprietary technology.

          • Thanks Samuli, I will try to find some documentation that explains this restriction - am still not 100% convinced, but I haven't much experience with using SNC.

            Update: I think this note explains exactly the issue


            Looks like when SNC is enabled the MYSAPSSO2 cookie (Logon Ticket) is disabled. So unless you use SAP NW SSO (product) or only use the HTML GUI you can't use SAML in for SSO in NWBC when you intend to use SNC to secure the SAP GUI traffic.

          • Hi Simon,

            Since NWBC connects initially to the ABAP system over HTTP (which can authenticate using SAML) and after the initial authentication the user will have a valid SAP Logon Ticket which can then be used for both Web and GUI access - I don't see why SAML isn't a supported scenario?

            This theoretically works. But there are 3 issues:

            1. SNC encryption will not work in the E2E scenario

            2. SAP Logon Tickets was invented many years ago. I recommend to customers to use SSO based on public standards (Kerberos, SAML, Certificate, OAUth,....) when possible.

            3. Since PAM do not officially mention SAP GUI as a client for SAML, you will probably have support issues if something will not work




            I wanted to bring everyone up to speed with where I am in the SAML NWBC SSO.

            Web Version #

            HTTP is working via OKTA (SAML-Identity Provider) SSO as expected.

            HTTPS fails on the first attempt and prompts me for a user name/password, but if I refresh the same web browser, HTTPS also works on the second attempt.

            Any suggestions how to get past this issue?

            Desktop client Version#

            Whenver I access web dynpro app via the client version, I get a security warning from the NWBC client, as my SAP server and Identity provider are on two different domains. I know reading through the blogs and as per note # 1378659 &

            there is a way to bypass this security warning in the older versions of NWBC client. However, we are at the latest version NWBC 4.0 and the solution to bypass the security warning doesn't work. I did open an OSS message with SAP for this issue and they are suggesting this to be a consulting issue. The URL that I am calling from the NWBC client is the my Identity provider's SSO URL.

            In case I use SAP's nwbc sicf URL with HTTP, it looks like the authentication takes place via the SAML assertions, but the client pop-up just hangs with a blank screen.

            Any suggestions on this issue? Thanks in advnace.



  • Hello Nikhil,

    we are running a PKI infrastructure and have implemented "SAP Netweaver Single Sign-On 2.0" to enable SNC/SSO for our SAP GUI connections. According to there should be a "Use Secure Login Client" setting available if the administrator allowed this setting. However I was not able to find these mentioned settings, neither for the user nor for the administrator.We are on NWBC 4.0 PL 10 so the prerequisites are ok. Can you please provide more insight and point me to the mentioned admin configuration file? Also it is not quite clear if the "SAP Netweaver Single Sign-On 2.0 Secure Login Server" is also needed to issue X.509 these temporary tickets or if this is handled by the Secure Login Client.

    Best regards,


    • At least I managed to identify the settings to enable "Use Secure Login Client" thanks to the "Secure Login for SAP NetWeaver Single Sign-On Implementation Guide". This can be achieved by adding

      <SingleOptions>      <ShowSecureLoginClientAttribute>True</ShowSecureLoginClientAttribute>


      to the user's NwbcOptions.xml file or the admin one in \ProgramData (if it exists). The runtime connection info will then be amended by <UseSecureLoginClient>True</UseSecureLoginClient>.

      However, SSO does not yet work in our environment. My guess is that a Secure Login Server is needed to issue the X.509 tickets. Please share your thoughts about that with me.

      Best regards,


      • Hi Michael,

        when NWBC connects to the backend, this is initially done using HTTPS. Only later will NWBC switch to the SNC protocol of the native SAP GUI. So you also need to enable X.509 based SSO for HTTPS, in addition to SNC.

        Best regards,


        • Hi Christian,

          thanks for your response, this confirms what I figured out by myself. Meanwhile I found a reference to the Secure Login Server as a prerequisite in a newer version of the Implementation Guide.

          Best regards,


  • Hi Nikhil (and others),

    This has been a great discussion for me to learn from, however I am curious if I am missing something with my understanding of NWBC Desktop and SAP GUI limitations of SAML SSO for NWBC Desktop and SNC for SAP GUI.

    I have been tasked with implementing SAML SSO for NWBC Desktop Client and any form of SSO for SAP GUI, specifically without the use of SSO 2.0.

    ABAP = NW 7.4 SP9

    NWBC = 5.0 PL7

    SAP GUI = 740 final release

    SAML SSO for NWBC desktop is working using ADFS as the identity provider, and in the SAML service provider settings on the ABAP server we have legacy support enabled to send a SAP Logon Ticket to the NWBC Desktop client once successfully authenticated using SAML.

    At the same time, SAP GUI is configured to use SNC (NTLM SSP) SSO for authentication only (no integrity or privacy protection).

    Currently I can successfully single sign on to the ABAP system using both NWBC Desktop and SAP GUI (on the same Windows client).

    I created a test role with standard transactions, test webdynpro and test bsp apps.

    When using the NWBC Desktop with the test role assigned, I can navigate to and run:

    Standard transactions (PFCG, SUIM, SU01, SM59 etc...)

    BSP test app IT00 and run all the tests

    Webdynpro test apps demo_bg_gantt_2, demo_flash_flight, wdr_test_p00004 and wdr_test_p00007

    When doing this, I do not get re-authentication prompts.

    They are all launching inside the NWBC Desktop client and not calling separate browser sessions outside the client. (just in case you were wondering)

    From reading the discussion, I was expecting that I would be prompted for re-authentication when switching between standard dynpro and webdynpro transactions in NWBC Desktop due to configuring the ABAP server with snc/enable = 1 and SAP GUI to use SNC for authentication.

    Might this be due to using the lowest level of SNC protection?

    snc/data_protection/max = 1

    snc/data_protection/min = 1

    snc/data_protection/use = 1

    What are your thoughts on this?

    The reason I ask, is that I want to ensure there isn't some additional testing that I should be performing or that I might be missing some crucial understanding of the SSO concepts discussed here.

    • Hi Patrick,

      I've been tasked to do pretty much exactly what you did. I'm having some difficulty implementing the NWBC desktop SSO.(without NW SSO2) How did you do it? I'm stumped 😕



      • I used SAML as the SSO authentication protocol.

        SAML requires an Identity Provider, Service Provider and Client.

        The Client is your NWBC application.

        The Service Provider is your ABAP server (provides services consumed by your client).

        The Identity Provider can be an ADFS server (a free component of Windows Server 2012).

        What is your email address? I can send you some helpful docs.

        • Hi Patrick,

          I am also approaching a similar task.

          I would appreciate it if you can share helpful docs/info on the same to my email address:

          Thanks in Advance.

          Best Regards,
          Mohamed Awny

    • Hi Patrick

      Apologies in advance for replying to such an old thread....


      Could you possibly please send me any notes or documentation on the technical setup of your NWBC SAML SSO implementation.


      I am also looking at implementing the same scenario, and it looks very much like you have been successful with this.


      Thanks again

  • Hi Nikhil,

    Thank you for such a nice blog. I have a query , if BPC settings and work  can run smoothly in NWBC for desktop. any specific configuration to be taken care.

    Please let me know