Securing Geoevent REST inputs

[MatthewLangley]

Hi there,

I have configured some geojson inputs in Geoevent Server 10.6 and have noticed that I am able to POST requests to these endpoints without supplying any authentication. 

i.e. I can POST an event to https://<host>:6143/geoevent/rest/receiver/geojson-device-location without providing any authentication and the request is processed ok.

Is this a bug or by design?

[DanWade]

Hello Matthew,

I want to first apologize for the wait time you have experienced with your post. To answer your question I can say what you are seeing is the out-of-the-box behavior, however, there is an enhancement for this topic.

[ENH-000125501: Provide additional security controls for the GeoEvent Server REST endpoints]

Kind regards,

Dan

[JamesMadden1]

Dan, can you provide a link to a document describing the enhancement you mentioned?  

[RJSunderman]

Hello James Madden –

Yes. By design GeoEvent Server REST receiver inputs allow an unauthenticated client / server to send POST requests to a running inbound connector. Recent releases ensure that such requests occur over HTTPS (not HTTP).

We have not considered this particularly troubling for several reasons. Production systems usually secure their servers with an authenticating proxy and ACLs. If they want to grant access to a specific data provider, they configure a tunnel through their firewall for that specific provider. Also, any data sent must pass through an inbound adapter which uses a strict GeoEvent Definition to interpret the data. The event definition cannot be modified without authenticating with the administrative API, so potentially malicious code will not survive adaption to create an event record which can actually be processed – malicious code or data will be discarded as unrecognized by the inbound adapter.

Over time, some users have voiced concern that information about a GeoEvent Server's configuration can be obtained by an unauthenticated user, via public REST endpoints, if they are able to reach a server machine via the machine's fully-qualified domain name and port. That's why production servers are secured using authenticating proxies and firewalls.

Dan Wade‌ has referenced an effort the product team is considering to move many endpoints reachable today via host.domain:6143/geoevent/rest by moving the endpoints beneath host.domain:6143/geoevent/admin so that authentication is required to reach them. There is some hesitation to secure the REST receiver endpoints. You cannot POST malicious XML, SQL, etc. to a GeoEvent Server receiver – the receiver's inbound adapter will not recognize the data's structure / schema and will discard the data.

In your opinion, should an external client / server application be required to authenticate before being allowed to send a POST request to a GeoEvent Server input? Given that communication is secured using HTTPS, access to the server can be secured using an authenticating proxy and firewall, and adaption requires a predefined and recognizable data structure / schema ... we don't want to unnecessarily inhibit inbound data flow.

– RJ

[JamesMadden1]

RJ,

Thanks for the reply.  We have GeoEvent Server installed on a box that is only available on our internal network.  I recall reading where ESRI recommends that architecture for GeoEvent.  That said, we would still like to require authentication internally but I am not sure how that would impact the data flow.  I imagine an extra level of processing might slow things down a bit.  I guess we could always hit the service's "add feature" endpoint directly from ArcGIS Server, if authentication is an absolute requirement.  Do you expect ESRI to add authentication options into future releases?  We are planning to migrate to 10.7 in the coming months.     

[RJSunderman]

James Madden –

Nothing we are discussing here will be included in the 10.8 release due out next week (Jan 20th). The product team continues to actively consider options for additional security and refactoring the product to implement features like authentication for REST requests or moving GeoEvent Server's open REST endpoints to its administrative API. I cannot say, however, which future release such work would target.

– RJ