SOAP interface via extension with Client Certificate for authentication

SOAP interface via extension with Client Certificate for authentication

  

Hi there,

I am on OS platform 9.0.1.75 on-premise and am working on SOAP references to another system. I am unable to consume the SOAP service via OS as the corresponding WSDL contains complex structures which is not supported. This resulted in me having to compile the web service into a .Net assembly and import it into OS as an extension.

I understand that it is possible to perform mutual authentication to be performed while calling web services https://www.outsystems.com/forums/discussion/9471/configure-and-use-web-service-client-side-certificates/ however it seems that i am unable to do so for a reference imported as an extension via OS.

Is it possible to allow the extension to utilise the certificate via OS or i would have to amend the code in the .Net assembly to get each method to present the client certificate to the server?

I would opt for the latter, it's what we do for our complex SOAP stuff. It's imho much easier to get the certificate from the certificate store in .NET than to try to pass it via the normal code (if that is at all possible, which I doubt).

Kilian Hekhuis wrote:

I would opt for the latter, it's what we do for our complex SOAP stuff. It's imho much easier to get the certificate from the certificate store in .NET than to try to pass it via the normal code (if that is at all possible, which I doubt).

Hi Kilian,


Thanks for your input. Due to some infra constrain, i have opt-ed to call the .cer file as opposed to accessing the certificate store. Would like to check if you have previously encountered issues with client authentication? All my authentication is done via .NET. The code works perfectly and can authenticate if i am running it as a .NET Console application however when i use the exact same code as an Outsystems application, it does not authentication and subsequently returns a 403. (Console app returns intended response, Outsystems app returns 403)


Hi Nathaniel,

We did use the certificate store, but if you're using .NET, you should be able to get it working, as in the end it doesn't matter much where the certificate is coming from. I would expect something to go wrong in a detectable way inside the .NET extension, have you tried debugging it (e.g. by putting LogMessages in)?

Kilian Hekhuis wrote:

Hi Nathaniel,

We did use the certificate store, but if you're using .NET, you should be able to get it working, as in the end it doesn't matter much where the certificate is coming from. I would expect something to go wrong in a detectable way inside the .NET extension, have you tried debugging it (e.g. by putting LogMessages in)?

Technically the .NET codes are functioning correctly however after converting them and importing them as a extension in outsystems, IIS keeps returning 403.7. Attempting to debug however this does not make sense as running on a .NET console app there are no issues, once Outsystems attempts to run the same code, i am getting 403.7

It should also be noted that Outsystems has no issue accessing the .cer file and returns the correct error messages if the file is not found. There is no indication that it is unable to access the .cer file.

Well, the extension runs as an IIS user in ASP.NET, not as a local user under Windows, so there's quite some differences with regards to priviliges etc. Don't assume that when it works as a .NET test app, it also works as an extension.

403.7 indicates IIS doesn't get a client certificate at all, so I would assume that whatever way you think you are serving it, it doesn't actually work. That's why I would recommend putting LogMessages in the code, to see whether you actually have the right certificate etc. when it runs in IIS.

Kilian Hekhuis wrote:

Well, the extension runs as an IIS user in ASP.NET, not as a local user under Windows, so there's quite some differences with regards to priviliges etc. Don't assume that when it works as a .NET test app, it also works as an extension.

403.7 indicates IIS doesn't get a client certificate at all, so I would assume that whatever way you think you are serving it, it doesn't actually work. That's why I would recommend putting LogMessages in the code, to see whether you actually have the right certificate etc. when it runs in IIS.

Thats what i thought too, until LogMessages indicated i presenting the correct certificate via Outsystems. It seems that it might not be an Outsystems issue as coincidentally similar developments not on Outsystems are also facing a similar issue. 

As this seems not to be an Outsystems issue, i doubt i should keep searching for an answer here. Will update this post with an answer to my query when i manage to resolve this.

Thanks, Kilian for the time taken and responses.


Hi Nathaniel,

Thanks for the feedback. Please keep us posted!

Solution

The issue is confirmed not to be an outsystems issue however it still was puzzling on why the issue occurred.

A separate ASP.NET console line app could access the .CER file perfectly and authenticate with the server however when outsystems ran the extension it could not.

Apparently the console line app did not require the private key in the client certificate whereas the extension did. The extension could not access the private key and thus when the server presented the certificates for authentication to the extension, outsystems did not recognize the certificate and thus did not present the correct client certificate. This was resolved by presenting outsystems with a .PFX file containing the private key.

The issue has thus been resolved however it still puzzles me that a console line app requires only the .CER file whereas the extension required the private key. Could be that the console app could access the windows store and was accessing it to verify the .CER attached however both apps ran with the same rights and at one point of time i allowed outsystems to access the relevant keys in the cert store.

Debugging was done by looking at packet communications to the server.

Solution