Validating caller in REST request
Application Type
Traditional Web
Service Studio Version
11.10.2 (Build 36429)
Platform Version
11.10.2 (Build 25738)

We are coming from a Java environment and recently migrated to OS11. Now what we had in java was a validation for a REST API in the OnRequest in an extension to get the certificate from the consumer of the API. By determining the organistion included in the certificate we were able to allow access to the REST API or not.

Now in C# I have no clue how I can manage this. I've tried SOOOO many things concerning clientcertificates, but they were all null. Tried via Request and RestRequest object, but not any result.

The weird thing is that all elements from RestRequest seems be resulting in a null, while the regular Request object has elements I expect. That's not what I expected when calling a REST API.

In java we were able to get the originating url and with that build a response to get the certificate from that server. But if I do that in C# the url I get is always the url of the REST API, resulting in an endless loop when trying to build the response with that URL (because the onrequest action is then called again over and over).

Also I have a problem unittesting request with certificate in C#.

Does anybody has similar functionality build and willing to share their solution?

Any help would be much appreciated.

Found the solution in an IIS setting. For SSL Settings I had to set it to 'Accept' instead of the default 'Ignore'. In the first try I had set it on Default Web Server level and immediately people were complaining that they had to enter certificate credentials when entering ServiceCenter and got an error when publishing. The trick was to set the SSL settings to 'Accept' only to the module where the REST API is defined.

So after setting the correct 'Accept' SSL setting I was able to receive the client certificate details in my PostMan request ;-)

I've created a test certificate (makecert/pvk2pfx) and uploaded that pfx-file to the certificate store of the server, where OutSystrems is running.

Also added that certificate to PostMan and calling the REST API with that client certificate (I can see in the console that the certificate is being used in the communication to the REST API)

But still in the OnRequest I cannot see any clientcertificates in the HttpContext.Current.Request object. What am I missing here?

In the meantime I found this (https://success.outsystems.com/Support/Enterprise_Customers/Maintenance_and_Operations/Installing_client_side_certificates_on_on-premises_environments#Troubleshooting_the_client_side_certificate_installation) document and have set the read-permissions correctly for the certificate, but still no luck in finding the client certificate in the OnRequest event.


B.t.w. in the document they mention exporting the certificate to d:\certificates, but I don't see where that is used anywhere.

Note that we are exposing the API, so that means we don't have the OnBeforeRequestAdvanced action (that is only used when you consume an API), so the whole documentation about REST API (https://success.outsystems.com/Documentation/11/Reference/OutSystems_APIs/REST_Extensibility_API) with RestRequest object is of absolutely no use to us.

I can read the headers coming from the HttpContext.Current.Request, with source the PostMan request, succesfully. The problem is that the clientcertificate is not coming over with the request.

Found the solution in an IIS setting. For SSL Settings I had to set it to 'Accept' instead of the default 'Ignore'. In the first try I had set it on Default Web Server level and immediately people were complaining that they had to enter certificate credentials when entering ServiceCenter and got an error when publishing. The trick was to set the SSL settings to 'Accept' only to the module where the REST API is defined.

So after setting the correct 'Accept' SSL setting I was able to receive the client certificate details in my PostMan request ;-)

Community GuidelinesBe kind and respectful, give credit to the original source of content, and search for duplicates before posting.