Securing your geometry in Arcims

My biggest gripe with ArcIMS? Data security. I’m going to go out on a limb here and probably annoy those who actively exploit this method to download whole datasets off a remote AIMS server, attributes and all. It isn’t new, but yet it seems as though most people still don’t do much to prevent it. I am unsure on the status of v9 but certainly with v4, the default install enables the servlet connector by default and it seems as though a lot of users don’t know the implications of not securing it.

The Method
1. Fire up your Arcmap and drop in your favourite remote AIMS server.
2. Select some features from the service layers

3. Time to create a temporary layer with the selected features.

4. Right click on the new “local” layer and Data -> Export Data…

5. Edit the output path, and click OK

6. Congrats, you now have pilferred the geometry and all the attributes.

If you’re a purist from way back you would know that the export process is nothing more than a SPATIALQUERY. You can also easily extract the entire layer with nothing more than a ’select all’.

The Problem
ESRI support docs detail a few ways of preventing users from accessing the geometry; but none really giving total satisfaction. The best white paper I’ve found was titled “How To Manage the Data Sharing Capabilities of an ArcIMS Service”, . When i say no total satisfaction, i mean their solutions all come with strings attached.Lets have a look at a few common ways to combat the problem, some of which were covered in the above ESRI paper ..

1. Disable the Servlet connector.
The most obvious solution, but depends on the situation. It is as simple as removing the com.esri.esrimap.Esrimap servlet from your J2ee container. What a lot of people don’t realise is you’re also cutting yourself off from any client who requires the servlet container to function such as Arcexplorer, Arcmap and even the vanilla HTML Viewer (default config). A lot of people choose to use another connector, in which case you should disable it regardless. But remember, things like Arcims Administator also use the servlet so it is a two edged sword in some respects.

2. Alias the Servlet
Anyone with a security background knows that obfuscating a URL will eventually come unstuck. This method simply changes the standard path to the servlet so that the desktop clients that automatically append it to the domain will not be able to connect. I have seen this done on some custom web clients, but you can still easily get the new path from the javascript definitions. You may not be able to use arcmap to connect (although im sure you could find a way) but you can still manually send the SPATIALQUERY request.

3. Use the Access Control Lists (ACL) to limit access
By using the ACL file attached to the connector you can do things such as adding username and passwords for particular services, or in fact disabling certain ARCXML requests (such as spatialquery GET_FEATURES).

ESRI has a small ACL editor utility at which makes setup of the acl file a lot easier. It’s quite configurable in its options, but becomes tedious to maintain if given a large user base. However, adding GET_FEATURES to the blacklist of requests will also remove basic functionality such as identifying and querying. Not a good thing in most cases. I’d be interested to hear whether anyone has had any luck trying to separate the different requests.

4. Secure the physical access via a firewall
No doubt the most commonly used setup in production server installs. Limiting access to the core arcims servlets on the network layer lets you worry less about who can get access and whether you configured your long ACL correctly. Usually this involves creating a web frontend which has sole access to the application server.

AIMS < -> |=| < -> Frontend < -> |=| < -> Client

So long as the frontend is not configured to be able to send the offending GET_FEATURE requests, it’s a sure way to lock down your data or at least limit the clients in what they can do.

I think i better wrap this entry up as it’s getting on a bit. If you have any queries or would like to post your experiences with locking arcims down, please post a reply. There are obviously sections such as customised connectors that i did not touch on.

Just remember that Arcims is not the only GIS application which can be unknowingly disseminating your data … Geoserver (and to a lesser extent, Mapserver) is just as easily misconfigured to enable WFS on layers which you may only want disseminated as WMS images. WFS servers with no limits on the number, attributes or size of the response can be just as damaging to the custodian or licensee.

6 thoughts on “Securing your geometry in Arcims”

  1. Does enybody know where to fing guide or howto with impelmentation of mentioned “frontend” between Client and ArcIMS?

  2. Hi Stc,

    Please have a look through the ESRI support forums as there are a lot of new options available in the 9.2 series. Much of the concerns raised in this article has since been resolved (to some extent)

  3. Hi Chris
    Thanks for quick advice. Unfortunatelly we are still sticking with 9.0, so I was thinking to solve problem with downloadable geometry by so called “frontend” mentioned in this article.

  4. Stc, i’d advise asking your local ESRI rep for assistance if you have a maintenance contract.

    Otherwise, have a good look at what is possible with Access Control List’s. In most situations, limiting the GET_FEATURES call to a particular IP range solves most problems.

  5. Yes, we have maintanace contract, but I do not have confidence in local ESRI support, they won’t help as much… ACL would work well but I need GET_FEATURES in web-based client since I need to query, identify and search functions. I’m currently working on aliasing, but I know it can be penetrated. So I was thinking if I can make something like you mentioned in your article, but I have found nothing at all on internet about such a ‘frontend’. Could You enlight me, please?

Comments are closed.