Skip to Content

Many customers regard NetWeaver Business Client (NWBC) as very desirable. Yes, they do appreciate SAPGUI for being pretty robust, reliable, well-hung, and last but not least fast, a good working environment for heavy-duty backend users. —

But NWBC has the Side Panel, which is an awesome tool for enhancing the user experience while being minimally disruptive:

  • No need to change existing screens (SAP standard and custom) to enable the Side Panel
  • Makes good use of previously blank screen real estate
  • Standard Side Panel content is useful, and new Side Panels are extremely easy to create

Some other very good reasons to adopt NWBC:

  • At last: UI integration of Web Dynpro, SAPGUI, and Fiori in one shell
  • Comfortable configuration and personalization
  • Backend configuration is a breeze
  • Corbu Theme looks good

An SSO experience at least as good as Portal-to-SAPGUI is critical

At this point, clients sometimes work with me to help them evaluate, plan, and, if all goes well, implement NetWeaver Business Client in their SAP landscapes. When, invariably, the topic of SSO comes up, those customers who don’t have SAP Single Sign-On 2.0 licensed, make the following discovery:

  • Currently, they navigate from the Enteprise Portal to SAPGUI without having to enter a username and passwords. There’s an SSO in place between the Portal and their ABAP system as long as they use SAPGUI
  • When they switch from NWBC to SAPGUI, the same SSO no longer works. Navigating from the Portal to an ABAP system brings up a login screen

SAP customers rarely accept it that implementing a new technology or software should make things worse for them (tongue in cheek: Maybe they should know better by now). So a logon screen in a place where there used to be a seamless single sign-on experience is perceived as completely unacceptable, no matter how bad the logon screen per se really is. This is when they declare the issue a potential dealbreaker and start looking for possible solutions.

(For the sake of completeness, I should mention that one of these possible solutions is a rather tactical custom development project solution that has been implemented at a few clients, but I’m not going into that here because I want to comment on SAP’s standard software and not individual custom project solutions.)

Enter SAP SSO 2.0

The obvious solution is SAP’s own SAP SSO 2.0, which is a comprehensive solution for many different single sign-on requirements and able to provide seamless integration even in complex and heterogeneous scenarios. It allows customers to implement single sign-on solutions for on-premise systems, cloud-based systems, social networks, mobile devices, and so on. It combines the use of wide-spread industry standards such as SAML with SAP’s proprietary technologies and integrates SAP and non-SAP systems alike.

Because it is a separate product, SAP SSO 2.0 comes with a price tag. Just to get some indication: Although the actual quotes SAP gives seem to vary, my sources for pricing information all said that the quotes were in a range where,  for a company with 40,000 users, the bill can easily exceed 1,000,000 USD.

In my humble opinion as an enterprise architect, it is a reasonable price tag if you are looking for a strategic solution to address the growing SSO needs in a landscape that is becoming increasingly complex, and in which there is at least the perspective of needing to integrate more and more cloud solutions in the future.

However, when you are planning to test the waters with NetWeaver Business Client and are, for now, happy with your SSO and Identity Management architecture, and all you want is to give NWBC to a pilot department, and you don’t want them to have a logon screen with NWBC where they didn’t have a logon screen with SAPGUI, the price tag is too hefty. In my conversations with SAP customers and other consultants, I have learned that this is an actual problem for the adoption of NWBC.

I believe that SAP SSO 2.0, as a comprehensive solution, provides great value and it’s reasonable that a full-blown implementation should have a price tag that corresponds to the value it creates. It’s well-positioned as a strategic solution.

With NWBC, however, there is a need for a tactical solution that doesn’t address all the issues for which you would get SAP SSO 2.0, but that simply replicates the behavior of the Portal-to-SAPGUI integration with NWBC, so that using NWBC in lieu of SAPGUI doesn’t make things worse.

How can SAP fix this?

I can see two possible solutions for this, one that requires SAP to code and one that doesn’t.

1. Coding-based solution: Change the way Transaction iViews in the Portal work slightly.

  • Allow the administrator to configure an NWBC URL in the target system configuration.
  • Change the properties of the Transaction iView by adding a checkbox “Launch NWBC if possible.”
  • If the flag is checked, add the NWBC URL to the .SAP or .SSD file created for SAPGUI launch.
  • Modify NWBC so that it can find the NWBC URL in the .SAP or .SSD file and launch in NWBC mode, with the Side Panel enabled.

(I am actually thinking about building a prototype for a similar solution, but it’s early days. I hope SAP will beat me to it.)

2. Coding-free solution: Offer an NWBC-only license model for SSO 2.0

  • Offer a scaled-down SSO 2.0 license model that allows you to use only the Kerberos authentication in the ABAP backend in combination with NWBC.
  • Offer a “per NWBC user” pricing or include it in the Portal license, so that when you have a license for Enterprise Portal with SPNego and Kerberos, you can get the same SSO experience with NWBC at no extra license cost.

What would be in it for SAP?

  • Removing the SSO roadblock would be good for NWBC adoption. NWBC is obviously better in line with much of SAP’s UI and UX strategy than SAPGUI, and getting more customers to switch from SAPGUI to NWBC would create better alignment between SAP and their customers in the critical field of UI/UX.
  • Customers who have already deployed SAP SSO 2.0 for one scenario would be more likely to expand the scope of their SSO solution and get the full license. Creating a stepping stone between zero and a full-blown SSO solution would allow customers to take it one step at a time, breaking down a major financial and technical undertaking into two smaller ones. With this stepping stone in place, eventually more customers would license and implement the full-blown SAP SSO 2.0 solution.
  • Instead of SAP SSO 2.0being a problem for the adoption of NWBC and ultimately the acceptance of SAP’s UI strategy, NWBC and SSO could end up being enablers and catalysts for each other’s adoption.
To report this post you need to login first.

13 Comments

You must be Logged on to comment or reply to a post.

  1. Christopher Solomon

    Uh oh….Thorsten’s found another ant bed to kick. šŸ˜” šŸ˜ˆ hahaha

    KIDDING!!! šŸ˜€

    My friend, you have cranked out another great blog (yes, I read the whole thing! haha). This would not be the first (nor last?) time that the main hurdle for adoption of SAP products has been SAP themselves. They often miss the whole idea that the end justifies FREEING the means. haha

    Keep it up! šŸ˜‰

    (0) 
  2. Samuli Kaski

    Great write up Thorsten. The idea of having support for NWBC shortcuts in Transaction iViews of the portal is interesting. Rather than extending the existing SAP GUI shortcut, native support for NWBC Desktop icon makes more sense to me. I don’t want to be the pessimist here but I think SAP has already solved the NWBC adoption problem by removing or at least making it more difficult to deploy only SAP GUI in the latest NWBC and SAP GUI releases. SAP has had success with force feeding before. If they were to enable a free of charge SSO for NWBC, they would have to restrict the functionality to a very specific scenario such as the one you describe (SPNEGO for ABAP). Even then it would complicate support and maintenance of the product most likely having them to fork into two separate products. Pinging Regine Schimmer, Donka Dimitrova and Julie Plummer.

    (0) 
  3. Susan Keohan

    Hi Thorsten,

    You write so well, I really understand the problem!  As a customer (but not on NWBC) I can see how it would be considered a deal-breaker to get the SAP logon screen when navigating to the SAPGui (which I do happen to love, BTW, for all of its attributes and quirks). 

    Not understanding the underlying technology as well as Samuli Kaski clearly does, I would have to say that the option #2 would appeal to me – although full disclosure –  I am not authorized to make this type of decision!

    But being able to pilot NWBC with SSO at a reasonable cost, and understanding that a broader deployment would require licensing adjustments – that sounds like a win-win to me. 

    I’m hoping to see some more thoughtful comments on this blog (letting Christopher Solomon off the hook šŸ˜‰ ) – it will be interesting to see if/how SAP determines to resolve this issue.

    Keep up the good work,
    Sue

    (0) 
      1. Susan Keohan

        Of course, you did, Chris.  Just enjoying dragging you back into my world.  At the expense of the quality of comments on Thorsten’s blog – like any good friend.  šŸ™‚

        (0) 
  4. Ivan Femia

    Hi Thorsten,

    I had the possibility to implement the SSO2 w/ NWBC 5.0 and I was so impressed from an End User Point of view of the improvements in terms of UX that these can bring.

    I was not involved into the pricing issue and for sure for some customer it could be a road block.


    As Samuli Kaski stated “Offer an NWBC-only license model for SSO 2.0″ will limit all the capabilities of NWBC and the great idea of a unique entry point for all the Business Applciation (either no-SAP).

    NWBC + SSO2 could became a game changer for many companies!

    Ivan


    (0) 
  5. Jakob Marius KjƦr

    Hi Thorsten,

    Great blog, i think you hit an extremely valid point. I have had the same experience as you with customers, that have been using Kerberos and SNC for the GUI for years and when they saw NWBC, they were really excited. In the beginning it was “acceptable” with the login screen, but they quickly got tired of it and rolling it out to users was a pain, as they said “we don’t know our passwords, we haven’t been using them for years”.

    I love NWBC, but right now i see it as a major limitation to the NWBC for desktop that it doesn’t support SNC and you have to buy SSO 2.0 to get the SSO support. As i recall then NWBC for HTML supports Kerberos and therefore also support SNC. So if we as consultants are going to a customer, that runs SNC. We have to tell them that to get NWBC for desktop, then they have to change their entiere SSO architecture, which obviously isn’t an option for many clients.

    (0) 
    1. Siddhesh Ghag

      I have recently dealt with the same frustration that you cannot use SNC and NWBC if you don’t buy SSO 2.0, the customer refused to buy it and went for a less elegant solution adding to administrative hurdles.

      (0) 
      1. Jakob Marius KjƦr

        I ended up setting up the java portal to provide the user with a logon ticket to be authenticated on the ECC system. That worked out fairly well as a work around, but unfortunately and understandably this isn’t supported by SAP.

        (0) 
  6. Martin English

    Maybe my recent exposure to other platforms (i.e. Not SAP on Not HANA) has made me cynical, but…

    I wonder if you would get a better response if you couched the issue in terms of, I don’t know, ‘having the potential to interrupt the flow and simplicity of the UX between S4HANA and power users’ ?

    hth

    (0) 

Leave a Reply