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.
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â€™.
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
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.