SSO with NWBC: How NWBC and SAP SSO 2.0 should help each other out

[former_member182046]

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.