cancel
Showing results for 
Search instead for 
Did you mean: 

x509 Authentication in .net with an ABAP web service

Former Member
0 Kudos

All,

We have an ECC 6 system for which we are trying to establish x509 authentication to an ABAP web service. We’ve been attempting to follow the guide at: https://help.sap.com/saphelp_nwpi71/helpdata/en/a8/d9d53a9aa9e933e10000000a114084/content.htm. Our end goal is to call the web service from a .NET client, but we receive the following error when connecting from the application:

The HTTP request is unauthorized with client authentication scheme 'Anonymous'. The authentication header received from the server was ''.

In SOAMANAGER, the endpoint is configured for HTTPS and x509 HTTP Authentication. We are not using Message Authentication.

The certificates are issued by a local CA, which we have imported into both the SSL Server and System PSEs, and the browser displays a valid SSL connection. The server prompts for the client certificate, which we can select.  When navigating directly to the endpoint  we receive the following:

Call of URL terminated due to error in logon data.

Note

Logon performed in system.

Logon performed for client 100 and language EN.

When connecting to the endpoint with the browser, the ICM log shows the SSL handshake and that the certificate DN is mapped to a user.

When connecting with the .Net client, no ICM entry is generated.

Does anyone have suggestions to resolve this issue?

Accepted Solutions (0)

Answers (1)

Answers (1)

Former Member
0 Kudos

Some additional information:

If we've been issued a logon ticket already, we can connect to the service properly. If we set credentials directly on the sicf entry for the service, we can also connect, but x509 is still not working properly.

It's almost as though the certificate has been stripped away from the request at the web dispatcher and so the icm would see nothing but an unauthenticated request. Just in case this was actually occurring, we set the following profile parameters: icm/https/trust_client_with_issuer = * and icm/https/forward_ccert_as_header = true, but neither of those seemed to make a difference.

Does anyone have other ideas we might try?