'Push JSON to an External Website' adapter does not work if external site requires mutual authenication

[lindarae]

Using version 10.5 on Linux.   I can  fix the Spatial Query processor to work with external secure sites as the source code is available.   What do I need to do to get this and other output/web adapters to work?

[MarkBramer]

Hi linda rae,

Can you please elaborate more on what you're asking?  You mention modifying a processor via changing its source code - I follow.  But then you ask about making outputs work.  Outputs are different entities in GeoEvent than processors.  Are you asking if outputs can be modified via editing source code (just like how processors can be)?  Or are you asking about to make GeoEvent outputs work in general?  Custom outputs?  

And you also mention "web adapters".  "Web Adaptor" is something very specific in ArcGIS Server terms.  What did you mean, specifically, when saying "web adapter"? 

Mark

[lindarae]

Hi mark,

Our system requires mutual authentication via certificates. We have our arcgis servers (geoevent, server and portal) setup to require client certs to access the web pages at this time (However we still require a userid/password to log in to the ArcGIS components as we have not lashed up our LDAP implementation). To get the Spatial query processor to work (to query arcserver for a layer), I had to modify the Spatial query processor source code to add an SSL connection that incorporated the servers client certificate store and truststore (I used apache http client). However the same issue would occur if I had to query a arcserver that was outside of our domain.

I am having the same issue when I try to use the 'Push JSON to an External Website' adapter. The OOB (out of the box) adapter works if I push to HTTP, but fails with PKIX errors when I use https.

I used the wrong words when I mentioned 'web adapters'. I meant the geoevent output adapters and processors, not the Arcserver or arc portal Web adapter. I have corrected my geonet question

Thank-you so much for replying.

Linda Rae

[MarkBramer]

linda rae‌, Ok, I generally follow.  Forgive me if I keep asking seemingly basic or annoyingly-detailed questions.  Also, I don't meant to sound patronizing in any way, so if any question I ask sounds like it is, I certainly didn't mean it to be!  The domain of HTTP/S, SSL, PKI, etc gets complex very quickly, as I'm sure you know.  It can sometimes be hard to be on the same page.

You mention that you updated the code for the Query Report Processor to utilize a certificate.  But then you mention you face the "same issue" with the Push/JSON adapter.  You say that the Push/JSON adapter works with HTTP but you get PKIX errors if you use HTTPS.  HTTPS connections don't necessarily require client certificates.  But they do always require a server certificate, and that the destination server's certificate is trusted.   The CA that signed the server certificate has a certificate that must exist as a trusted root in the calling client's trust store.  In most cases, this calling client is a browser, but in the case of a GeoEvent adapter, this would be a trust store (i.e cacerts) within the Java environment that hosts GeoEvent components.  

So in the QRP case, it sounds like you're talking about client certificates, but in the OOB HTTP case, it sounds like you're just talking about HTTPS (which entails server certificates and trusts but not necessarily client certificates).  Can you please set me straight?

If you are talking about needing an HTTP transport that supports HTTPS and needs a true client certificate, then I can give you one.  I thought we had it out on GitHub but I don't see it now.  

My hunch is that you're talking about HTTPS/SSL/server certs/trusts/etc and not true X.509 PKI client certificates, but of course I could be wrong!  I'm more than happy to keep this message volley going as long as it takes to get you to be successful.  I work a lot with SSL, X.509, certs/trusts, so I can definitely help.  

[lindarae]

Qualification to the above, by 'web adapters' I meant the geoevent output adapters and processors, not the Arcserver or arc portal Web adapter.