Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

How to set the ANONYM PSE when consuming external Web Service with SSL

Former Member
0 Kudos

Dear all,

I wish to consume an external Web Service with HTTPS and basic authentication from an ABAP function module. The web service call works - but everytime a dialog for username and password pops up, even though the correct access data is already saved in the Logical Port.

Consequently, background processing fails with "Authentication required". We do not use client certificates, that´s why we need to draw the external server certificate from the ANONYM PSE which is configured in STRUST. When I set up an RFC destination (for testing purpose only) and set ANONYM as certificate list, then I can ping the web service without user data dialog. In SOAMANAGER the ping fails with 404 Not Found, even though the service calls are successful when user data is entered in the popup dialog.

In the call from the function module the DFAULT PSE is used, as I can see in the trace. I suspect that to be the reason for the unneccessary dialog which prevents successful background processing.

How can I configure usage of the anonymous keystore?

Who has any other idea why the pop-up might appear despite correct user data saved in the Logical Port?

Thanks a lot,

Ringo

1 ACCEPTED SOLUTION

0 Kudos

Hi Ringo,

ANONYM PSE CANNOT be selected as PSE in SOAMANAGER.

During execution of a SOAP request ANONYM PSE is AUTOMATICALLY used in the cases

- when SSL is configured

- but the authentication method differs from SSL client certificate.

Therefore the ANONYM PSE serves as trust anchor for the ssl server certificate.

I don't know by heart how the ping functionality in SOAMANAGER is implemented. It could be that it's using DFAULT PSE.

I usually test my web service clients with SE80 and selecting the client proxy here. Then I hit F8 and will be asked for the logical port that should be used in the call. This type of testing assures a call as it's being performed when the client proxy class is used in a real service invocation. And here the ANONYM PSE should be used.

Regards,

Mathias

8 REPLIES 8

Former Member
0 Kudos

Let me put it in other words to hopefully make it clearer:

When I create an RFC destination to an external server in SM59, then I can set the Certificate List to be used to check the server´s SSL certificate to ANONYMOUS:


How can I achieve the same setting for a Logical Port in SOAMANAGER?

Thanks in advance,

Ringo

0 Kudos


Hi Ringo,

I'm not an expert in SOAMANAGER however did you try the setup described for X.509 based auth just with the anonymous server PSE selected?

Regards, Patrick

0 Kudos

Hi Patrick,

Thank you, your hint is certainly correct. However, we use NetWeaver 7.4 (AS ABAP), where the SOAMANAGER navigation structure is different. At least in WSDL-based configuration I don´t have the chance to select the PSE.

Anyways, trusting in Mathias´ reply I shouldn´t worry about selecting the PSE manually, but look for other causes of the authentication problem.

0 Kudos

Hi Ringo,

ANONYM PSE CANNOT be selected as PSE in SOAMANAGER.

During execution of a SOAP request ANONYM PSE is AUTOMATICALLY used in the cases

- when SSL is configured

- but the authentication method differs from SSL client certificate.

Therefore the ANONYM PSE serves as trust anchor for the ssl server certificate.

I don't know by heart how the ping functionality in SOAMANAGER is implemented. It could be that it's using DFAULT PSE.

I usually test my web service clients with SE80 and selecting the client proxy here. Then I hit F8 and will be asked for the logical port that should be used in the call. This type of testing assures a call as it's being performed when the client proxy class is used in a real service invocation. And here the ANONYM PSE should be used.

Regards,

Mathias

0 Kudos

Hi Mathias,

Thank you for your answer, which tells me that I don´t need to worry about the PSE to solve the problem. However, then it is a bit misleading to see the DFAULT PSE in the error protocol. I got this error protocol when I closed the popup asking for access data again:

Three days ago the popup vanished in the testing landscape after I had re-created the Logical Ports. So far it looks like there must have been a mistake in my first Logical Port.

We are going to begin production in dialog mode first - if the authentication problem and the popup should occur there, than I would be glad to have the chance to come back to you. Of course, I would be much happier to be able to tell you everything is fine and close this thread...

0 Kudos

This LP above looks corrupted indeed. How was it created? Using WS single configuration? Or could it be that it got created after invoking the ping function? Was it possible for you to select the PSE that should be used in the tool you created the LP with? It could be that it's possible to create such an LP with the manual, non WSDL based configuration or with a special WS-Security-Policy template (with the goal to have two factors of authentication).

Former Member
0 Kudos

Ok, SAP Note 1720478 clearly states that it is not foreseen to manually change the PSE in SOAMANAGER. The correct PSE is derived based on the authentication method. If a WSDL-based configuration is used, the selected PSE will be influenced by WS-Policy settings for authentication settings, if such are contained in the WSDL file. The only known case where this is really required is for authentication with client certificates.

This means to me that a failed basic authentication can not be caused by configuring the wrong PSE. The mistake will rather be in username, password or in proxy settings.

0 Kudos

There must have been some issue with the logical port I created, and nothing else. After I recreated it in the Test System I never had problems again. By now the solution works in production without any authentication issues.