Part 3 – NWBC Authentication & Single-Sign-On (SSO)
Introduction
This is the third in a series of posts I hope to write on the topic of NetWeaver Business Client. I am writing these posts from my own view point as a long time NetWeaver Portal consultant and I am trying to compare concepts that I am familiar with from the Portal with similar concepts in the NWBC. You can find out more about my motivation for writing this series of post by reading The NetWeaver Business Client (NWBC) – A Portal Consultants Guide. My goal is to show the way things are done in NWBC to other people already familiar with the Portal.
Background
Just like with the NetWeaver Portal it is very important in order to provide the best user experience that users can easily and securely access the system and any other system that they may need to jump off into.This holds true for NWBC as well. The first step is usually providing access based on something the user has already done (e.g. like log on to their desktop) or something they have installed (e.g. like a client certificate). The next sections will describe some options that apply to both NWBC and Portal.
Kerberos
In the portal the most common method I’ve seen used to authenticate a user is by implementing Kerberos based authentication using Active Directory. Based on the user’s Kerberos token they are either granted or denied access to the Portal.
The SPNEGO login module has been available for as long as I can recall on the NetWeaver Portal Java stack, but the equivalent wasn’t available on the ABAP side until the release of SAP NetWeaver SSO 2.0. Remember that the NWBC can connect to either a portal or an ABAP system, but the scenario I am discussing here is when NWBC connects to the ABAP system directly. With SAP NetWeaver SSO you now have the ability to do Kerberos authentication directly against the ABAP stack. This document http://scn.sap.com/docs/DOC-40178 is a great guide on implementing Kerberos based SSO on the ABAP stack.
SAML 2.0
So first of all SAML stands for “Security Assertion Markup Language“. I first used it in anger to provide Single-Sign-On from an on-premise SAP Portal to SuccessFactors in the cloud. It provides a means to do cross-domain SSO, so can be used both inside and outside your own security domain. SAML is a web based protocol so isn’t suitable for NWBC in the scenario where you have both Web and GUI transactions running side by side in your NWBC role. This has already been discussed in Authentication and Single Sign-On with SAP NetWeaver Business Client (NWBC) I don’t want to rehash all this here but you should only consider using SAML in pure web based scenarios.
X.509 Certificates
Sometimes referred to as client certificates, you can use X.509 certificates in both the Portal and NWBC. I like to think of X.509 certs as doing exactly what you do when you connect to a secure website, just in reverse. Instead of the website having an SSL certificate that “proves” the site is legitimate, in this case you have a certificate to prove who you are. You can use you certificate to authenticate yourself to multiple sites. If you use the SAP Passport service you are using this kind of certificate. One of the overheads associated with using X.509 is that you need to provision a certificate to each and every user (a so called Public Key Infrastructure PKI), this certificate provisioning can be a bit of a pain I hear (not having done it myself). Since X.509 is a very common standard you should check with your IT department and see if they already provision certificates to users – if they do that makes your job easier. I also hear that SAP NetWeaver SSO 2.0 has nice feature that lets you provision short lived X.509 certs very easily to your users.
SAP Logon Tickets
I wasn’t sure whether to include SAP Logon Tickets here, in one sense they aren’t really providing the initial authentication like the other options here, but they are capable of providing SSO between systems. So once you have a valid SAP Logon Ticket you are good to go, but you need to get one first. You should be careful however because if you enable SNC for GUI transactions this stops the SAP Logon Tickets from working this SAP Note explains it well.
Well there you have it, I have on purpose not gone into lots of detail here – again my goal is to help portal consultants understand the SSO options in NWBC.
As always I really like to get your feedback, so please add your comments and thoughts below. Thanks!
Hi,
thank you for the information. Just want to ask a clarification in the scenario with SAP Logon Tickets, is it required to have same user id and password on all multiple back-end system?
Hi Chris,
It is by far easier if user id's are the same, password doesn't matter, SAP Logon Tickets don't use the password at all.
Hth,
Simon
Hello Simon,
thanks for this good blog - i have one more detailed question with Logon tickets:
Say we have a portal issuing the ticket, and passing them over to multiple backend systems for SSO.
If I now want to connect NWBC desktop to the portal, will it also receive the Logon ticket and pass it to the backend systems so that the same SSO mechanism will be working, as without NWBC just in the portal ? (i require this to work with Webdynpro applications and Gui Transactions)
Thank you,
Johannes
Hello Johannes,
I am not sure if I completely understood your question, but I can explain some internals and maybe this answers the question anyway...
Logon tickets are simply cookies which are part of the HTTP/HTTPS protocol and are transfered within the requests and responses between client and server. If your portal is running inside any browser instance, then the browser stores this cookies in its internal cookie store which is splitted into global and internal stores. The global ones are persisted to the hard disk, but the internal ones are something which only exists inside the running browser process. You can start NWBC for HTML out of the portal and NWBC can reuse the internal logon tickets automatically through browsers internal cookie store, but NWBC for Desktop can not.
NWBC Desktop creates a new browser instance in a different process and has no access to internal cookie store of another browser process.
The same problem appears in that case you described in your question... if you start NWBC Desktop and you want to connect to the portal someone (client/server) has to check if you have a valid logon ticket or not. Because of the new browser process there is no ticket available on client side and the server needs to be asked for that, so as far as I know this cannot work automatically. I think you need to be redirected to some services which can check if you are authenticated and push the logon ticket again to the (new) client.
Best Regards,
Thomas
Hi Johannes Bacher
Firstly I'd like to apologise for taking so long to reply. To answer your question, yes, in fact I have seen the a portal being used exactly in this way, where the NWBC connected to the ERP system and on logon was redirected to the portal, after authentication the portal redirected back to the ERP system and since the NWBC now had a Logon Ticket the user was allowed in without any further authentication.
One word of warning though is that if you use SNC for your SAP GUI connections then SSO will not work for SAPGUI, apparently logon tickets and SNC don't work together (This is what I've been told/read - but I have never tried it)
Hth,
Simon
Hi Simon,
That is not entirely true, i have gotten this to work using NWBC for desktop and using the portal as authentication, even though the client used SNC for SAP GUI connections.
However it is not a supported way from SAP of doing it.
Sounds interesting Jakob. Thanks for adding it here, but it sounds like something you wouldn't necessarily recommend.
Hi Simon,
The solution is quite simple and are running productively with the client. But as mentioned if anything goes wrong SAP can't support it.