Web Service Authentication from .NET

[Former Member]

We are connecting to SAP ABAP web services (Netweaver 7.0) from a .NET application (3.5 framework). It works fine passing the Login and Password explicitly (basic authentication), but we need to connect with different credentials by user and don't have the password available to the program, only the Login. In our case, the user is outside the domain, so we can't rely on Integrated Windows Authentication. We have two different scenarios, one where the application is running inside a Portal iView, and one where the application is running outside the portal entirely.

I see two possible options:

1. SAP Logon Ticket

2. SAML Token

When we run inside the portal, is it possible to get the SAP Logon Ticket and use that to authenticate our connection to the SAP web service? Normally logon tickets are isolated to a single domain, and our .NET application resides in a different domain than our SAP system. I found some help documentation showing how to enable cross-domain logon tickets (essentially setting up the system to generate an additional cookie for the other domain), but that documentation says it will be replaced by sapssoext, and I can't find good documentation on the new approach. Also, I'm not sure of all the steps to get and pass the logon ticket once I am able to get over the cross-domain hurdle. What are the steps to configure a web service to accept a logon ticket instead of basic authentication with login and password?

If using SAP logon tickets is not viable, is SAML our only viable option? As I looked into this, I found that SAML is only supported in the Java stack, and not the ABAP stack until Netweaver 7.1 comes out (October?). Since our web services are fronting ABAP RFCs, I assume that means I can't pass a SAML token to an ABAP web service until Netweaver 7.1 comes out next month (or whenever it acutally comes out). Is that right?

Any help would be greatly appreciated.

[Privete_member__1247967]

Were you able to find any solutions?

[MartinRaepple]

Hi Todd,

let me start with your first question on how to use the SAP Logon Ticket in a .NET/ABAP scenario. On the ABAP (7.0) side, you'll find for each web service an ICF service that authenticates the underlying HTTP request of your WCF Web Service (WS) Consumer call. The ICF service is configured with the "Standard" logon procedure by default. This "Standard" logon procedure processes a number of authentication checks in a predefined order: First, it checks for HTTP header fields in the request with the names "sap-user", "sap-password" (and others) to authenticate the user. If that fails (e.g. because they are not present in the request), it searches for an MYSAPSSO2 cookie which contains the SAP logon ticket. Assuming your WCF WS consumer sends this cookie with the request and the issuer of the ticket is trusted, the request is authenticated. How can the WCF WS consumer get this ticket? A simple workaround is needed here: First, your client application must send a (dummy) HTTP request to a protected resource on the ticket issuing system (e.g. a simple servlet running on the SAP NetWeaver Portal). This request can use any authentication mechanism configured for the resource's login module stack on the issuing system, e.g. Windows Integrated Authentication by using the Kerberos ticket of the signed-in user using SAPu2019s SPNego Login Module. The HTTP response includes a new SAP Logon ticket which can be extracted by the client application. Before it submits the actual Web Service request using the generated proxy, it must set the previously retrieved cookie in the WCF proxy's cookie container and the SOAP request can be authenticated by the ABAP WS provider. My colleague Andre Fischer has published an [article|https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/5bc7e899-0e01-0010-cca9-84f45118dd17] that describes the complete scenario including a sample application.

Now to your next question on SAML: In general, SAML - or, to be more precise, the WS Security SAML Token Profile - is SAP's recommended approach to implement cross-domain SSO scenarios for Web Services in heterogeneous SOA landscapes, because it is based on a widely adopted industry standard. How is the SAML Token Profile supported in SAP NetWeaver AS ABAP? Starting with release 7.00 >= SP14, the ABAP stack supports the SAML Token Profile 1.0 on the consumer and provider side using the so-called Sender-Vouches Confirmation method. This confirmation method requires that the WS Consumer signs the SAML Token and the message using an asymmetric (private/public) key pair. .NET 3.x/WCF does not support the required method to sign this type of SAML Tokens in SOAP messages. However, signing another SAML Token (confirmation method) type is supported by .NET 3.x/WCF, which is called "Holder-of-Key". These Holder-of-Key SAML Tokens are usually issued to WS consumers by a third party, also known as a Security Token Service (STS). The STS generates a temporary key, includes it in the SAML Token and issues this token to the consumer. The consumer uses can use this temporary key to sign the message and the token and sends the request with the SAML token included in the SOAP security header. SAP NetWeaver AS ABAP 7.01 (i.e. EhP#1) SP2 will provide support to process requests using SAML tokens with Holder-of-Key confirmation method on the provider side. Support for WS Consumers requesting such Holder-of-Key SAML tokens from an external STS and sending authenticated requests to SAP/non-SAP WS Providers (accepting Holder-of-Key SAML Tokens) is currently planned for EhP#2. I have a 2h lecture at TechEd this year ([SIM207|http://www.sapteched.com/emea/edu_sessions/session.htm?id=1121]) that exclusively talks about this topic (Web Services SSO and SAML). An introductory [blog|https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/wlg/10764] [original link is broken] [original link is broken] [original link is broken]; with a link to the complete (WCF/ABAP) code archive used to implement the live demo of this session is available at [https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/com.sap.km.cm.docs/library/uuid/c094d013-de53-2b10-148e-b0c946069ff6].

HTH, best regards

Martin

[Former Member]

Martin,

Thanks for the detailed explanation. This is very helpful. A member of my team was at the TechEd event in Las Vegas but missed your presentation because we hadn't identified this issue yet and she was looking for sessions related to other topics. I only wish we'd been a few weeks farther along at that point so she could have attended your session. Unfortunately, we can't make it to Berlin or the other events, and my Virtual TechEd subscription doesn't show the 2008 content yet, presumably because the live events haven't finished yet.

One thing that you mentioned that provides some hope that I didn't have before is that the ABAP stack supports the SAML Token Profile 1.0 starting with release 7.00 >= SP14, so we don't have to wait for 7.1 as long as we upgrade to at least SP14 (I think we're at SP12).

Regarding the login ticket approach, we've been going down a path similar to what you've outlined, but we're still in the process of discovering the many intricacies and new challenges. I'm sure I'll be posting again with some requests for help from you or others that monitor this forum. I'll also try to post a final reply once resolved that explains more of what we've discovered, so others can benefit.

One thing about our configuration that I didn't mention is Web Dispatcher, and I'm not sure whether or how much that will impact our solution. Because our people access the system from our customers' computers and networks, we have to treat this as an extranet, which is posing the biggest part of this challenge. We're doing our development now in an intranet environment, but we know that we'll have to put a Web Dispatcher between our portal and the internet. That hasn't been set up yet, but my understanding is that it's the only way to avoid requiring a VPN connection to get to the portal from the outside (without opening our firewall in an insecure way). How does the Web Dispatcher help and/or complicate the solution? Will it matter whether it is configured for end-to-end SSL or SSL termination? Will it exhibit some form of proxy-like behavior that will allow us to use a security approach that wouldn't be available if we didn't have that in place?

Thanks again.

Todd