A closer look at SOAP Sender authentication

[former_member184681]

The sender SOAP adapter authentication for SOAP sender scenarios in SAP PI is one of the most widely-discussed topics in the Process Integration SDN Forums. Recently I had a closer, technical look at this topic. Now I would like to share my most important conclusion with you. Let me follow the way I investigated it, step by step.

Let us start with how it works normally. In some systems (just like PI itself), when you configure a SOAP client, you have an option to provide a username and password to authenticate the call. These user credentials are then used every time the system tries to connect to the web service. This is the most standard approach and I would generally recommend this option every time the sender system can handle it.

But sometimes, you just do not have an option to provide the user credentials in the sender system. This is where people start to look for workarounds. There are two of them that I know of:

1. Posting the SOAP call directly to Integration Engine and putting the username and the password in the SOAP call URL. This approach was described by Stefan Grube in one of his blogs here: http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/4502.
   As a result, you post your SOAP calls to the following URL for SOAP calls:
   http://hostname:port/sap/xi/engine?type=entry&version=3.0&Sender.Service=<service>&Interface=<namesp...
2. Disabling Sender SOAP authentication, as described in details by William Li in this forum message:
   http://forums.sdn.sap.com/thread.jspa?threadID=236507&start=7

Frankly speaking, none of these solutions seems acceptable for me. Putting user credentials in the URL is a serious violation of the company’s security policy. As a result, I would say this is definitely not a recommended solution. And it is even worse with disabling the authentication totally, because in current PI versions you can only disable the authentication at the adapter level (not for a particular communication channel). So you immediately make your PI very vulnerable.

The question now arises: is there any other option? Initially I was thinking about using the AuthHeader property of the SOAP Header. But then I have read the following statement:

     The user authentication of the SOAP adapter is not part of the SOAP adapter but of the web container of the J2EE engine.[source]

So it is not the SOAP Header where the authentication takes place, but earlier (in terms of message processing), during HTTP request processing. The user credentials are then sent along with HTTP Header parameters of the SOAP-HTTP call. You can find a quite neat description of the HTTP Header authentication here: http://www.httpwatch.com/httpgallery/authentication/

Now, it appears that the point is to add the HTTP Header parameter named "Authorization" with a value "Basic (base64-encoded username:password)". Let me give you a small example of how it works. Assume that you have a user "someuser" with password "somepass" defined in PI, with sufficient authorization to authenticate SOAP calls. Here is how to use it in your client application. At first, you concatenate the user name and password with a colon as a separator to get: "someuser:somepass". Then you encode "someuser:somepass" (without quotes) with base64 encoding to get c29tZXVzZXI6c29tZXBhc3M=

You might find this online tool useful for base64 encoding of a string, for testing purposes: http://www.motobit.com/util/base64-decoder-encoder.asp.

Finally you add the HTTP Header parameter:

     Authorization: Basic c29tZXVzZXI6c29tZXBhc3M=

This is how this HTTP Header parameter looks \ like in the SOAP UI test tool:

Do you recognize this view? I bet you do, if you have ever used SOAP UI to test your PI scenario. It is the Aut tab where you have usually put the user name and password. And you have just accomplished an alternative configuration. Simple, isn’t it?

Finally, it is important to mention that you can use this method in any SOAP client that is capable of taking control of the HTTP header. It is not only SOAP UI where it can be used!

For instance, assuming that you have some JAVA application as a web service client, you could use the code under the link below to call the web service:

http://dpastov.blogspot.com/2010/11/very-nice-soap-client.html

All you need to do in order to add authentication is to use the httpConn.setRequestProperty() method one more time, comparing to the example, to add the Authorization header attribute. And no longer do you need to put the username and password in the URL or think of disabling authentication for the whole SOAP adapter.