ESRI Technical Paper DRAFT
March 15, 2004

How To Manage the Data Sharing Capabilities of an ArcIMS Service


Question: Using a number of ArcIMS clients, such as ArcMap and ArcExplorer, users can view, query, and even export features from ArcIMS services. I want to limit or disable the ability of certain clients to access my ArcIMS services. How can I do this?

Answer: There are a variety of ways to limit or disable access to your ArcIMS services. This document lists three different strategies and highlights the effects of each. Two appendices are also included at the end of this document to provide additional information on the administration and security of an ArcIMS site.  To get the most out of this document, you should first consider the following questions:


Strategy #1

Use the ActiveX, ColdFusion, or Java Connector

(At ArcIMS 3.1, AppServerLink is used instead of the ArcIMS Java Connector)



The ArcGIS desktop applications communicate with ArcIMS using the default ArcIMS Servlet Connector. ArcIMS provides additional server-side connectors to allow development of custom client-server solutions. Removing the ArcIMS Servlet Connector and employing one of the other connectors effectively bars access by any client that relies on the ArcIMS Servlet Connector, including ArcMap. As an added advantage, you as the developer have full control over the amount of data and the functionality exposed to your custom clients.








The basic idea behind this strategy is to use a different connector than the default ArcIMS Servlet Connector. ArcMap will then be unable to access ArcIMS services because ArcMap relies on the ArcIMS Servlet Connector to communicate with ArcIMS services. This strategy is the most secure and robust, but also requires the most developer time and skill. Use of the additional ArcIMS connectors requires proficiency in one of the following technologies:




While this strategy includes the a wide range of options, examples for two common solutions are listed below:



By default the HTML Viewer communicates through the ArcIMS Servlet Connector, using an HTML form. Beginning with ArcIMS 4.0, you have the option to send and receive ArcXML through the Java Connector deployed within a JSP page.  The steps for using the HTML Viewer with the Java Connector are as follows:


1.         The Java Connector consists of seven files:


arcims_jconnect.jar—contains the Object Model Java class files.

arcims_taglib.tld—the Tag Library Descriptor (TLD) file.—the Java Connector authentication file.

jsse.jar—dependent JAR file provided by Sun Microsystems, Inc.

jnet.jar—dependent JAR file provided by Sun Microsystems, Inc.

jcert.jar—dependent JAR file provided by Sun Microsystems, Inc.

sample_aimsacl.xml—a sample ACL file that can be renamed and used for authentication.


These files need to be deployed on a J2EE compliant application server.  All ArcIMS supported application servers (including servlet engines) are J2EE compliant. The methods for deployment differ depending on the specific J2EE application server.  Since the Java Connector adheres to the J2EE standard for packaging server-side Java components, it can be deployed as any other server-side Java component.   Refer to the specific J2EE application server documentation on deploying custom Java components as a server-side resource.  Note that the scope at which the Java Connector is available depends on how it is deployed.  It can be a server-wide resource accessible from any J2EE application (e.g. jsp, servlet) or it can be an application-level resource only available to a specific web application.  The ArcIMS Service Administrator (esriadmin) is an example of a web application using the Java Connector deployed as an application-level resource.  See the Customizing ArcIMS—Java Connector pdf document included with ArcIMS for more information.


2.   Once the Java Connector is deployed successfully, open the file “viewer.htm” in the HTML Viewer directory.  Look for the following three lines:

         var formURL = "jsForm.htm";

         var connectorType = "Servlet"; //Types are "Servlet" or "JSP"

         if (connectorType=="JSP") formURL = "jspForm.jsp";


Change the second line to:

         var connectorType = "JSP"; //Types are "Servlet" or "JSP"


When connectorType equals “JSP” then the jspForm.jsp file is loaded and used instead of the default jsForm.htm. This file contains Java scriplets that use the Java Connector ConnectorProxy object to send and receive ArcXML. Once configured, the ArcIMS Servlet Connector is not required and can be removed or disabled (see Appendix A). Note that, by default, the jspForm.jsp file does not contain any mechanism for filtering ArcXML requests. However, techniques to manage ArcXML strings (requests and responses) within the Java development environment can be developed and deployed with the jspForm.jsp file.




While an ACL (access control list) can prohibit specific requests from being sent to an ArcIMS service (see strategy 3), it cannot fully evaluate the contents of an ArcXML request before it is sent to an ArcIMS Application Server.  For example, if the GET_FEATURES request is forbidden in an ACL for a specific ArcIMS service and user, all GET_FEATURES requests sent to that service will be blocked.  The ArcIMS server-side components provide developers with the tools to create custom server-side solutions that evaluate any portion of an ArcXML request before it is processed by the ArcIMS Application Server.  The following document provides an example using the Java Connector with a custom servlet to filter ArcXML requests – it is available on the the ESRI Online Support Center:


For more information about using these additional connectors, please consult the documents provided on the ArcIMS installation media. At ArcIMS 3.1, these are the Customizing ActiveX, Customizing AppServerLink, and Customizing ColdFusion documents. At ArcIMS 4.x, these are the Customizing ActiveX, Customizing ColdFusion, and Customizing Java Connector documents. You should also review the technology discussions and how-to articles on the Microsoft (, JavaSoft (, and Macromedia ColdFusion ( Web sites.



Strategy #2

Create an Alias for the ArcIMS Servlet Connector



You can create an alias name and then disable the standard URL for the ArcIMS Servlet Connector. Once you have created an alias name, you can configure each Web site to point to the alias name rather than the standard URL. Correctly configured web sites will be able to access your ArcIMS services normally, but clients that use the default Servlet Connector cannot. Implementing this strategy requires minimal reconfiguration of the servlet engine and/or the Web server software.







Clients which use the Servlet Connector (such as ArcMap and ArcPad) attempt to connect to ArcIMS by appending "/servlet/com.esri.esrimap.Esrimap" to the ArcIMS server name. The aliasing option changes the URL for the Servlet Connector to something like "/servlet/arcims". While ArcMap cannot handle these name changes, other products, such as ArcExplorer Java and MapObjects Java, can access ArcIMS services using an aliased servlet name. ArcIMS browser clients, such as the HTML Viewer, can still view sites as long as the URL to the Servlet Connector is updated (for example, for the HTML Viewer the URL must be updated in ArcIMSparam.js and authorize.htm).


  • Note: Data features and attributes will be exposed when using this method

    The Data Interoperability Extension for ArcExplorer Java 9.x and ArcMap 9.x as well as client applications able to send raw HTTP requests (i.e. Java, .NET) will be able to access all feature data exposed in an ArcIMS service. Additional security mechanisms must be enabled to restrict or disable this functionality (i.e. authentication).



    See the white paper "Aliasing the ArcIMS Servlet Connector" in the Technical Papers section of at for complete implementation details.



    Strategy #3

    Use the forbiddentags attribute in an ACL File



    It is possible to set a forbiddentags attribute within an Access Control List (ACL). The forbiddentags attribute can be used for specific ArcIMS services to block requests containing the GET_FEATURES ArcXML element. Use of this attribute effectively prohibits the transfer of raw spatial data from the server to the client.







    By blocking all requests containing a GET_FEATURES element, this strategy ensures that feature geometry is not returned to the client. Note, however, that this effectively disables any query functionality that relies upon the GET_FEATURES tag, including the Identify, Query, and Find tools in the ArcIMS Viewers.



    For more information about setting up an ACL file and using the forbiddentags attribute, see the topic "Restricting user access to services” in the ArcIMS Help.


    Appendix A:

    ArcIMS Site Administration and Data Sharing Strategies



    While the data sharing strategies list above will limit client access to ArcIMS services, administration of the ArcIMS site must also be considered.  Two applications are available for ArcIMS site administration: the ArcIMS Administrator and the Service Administrator.  The pros and cons of using each tool are provided below.


    ArcIMS Administrator

    The ArcIMS Administrator application and command line administration tools require that the ArcIMS Servlet Connector be accessed via HTTP using the “/servlet/com.esri.esrimap.Esrimap” syntax on a Web server-servlet engine. 




    ·         If implementing strategies 1 or 2 above, the Servlet Connector should be disabled on the production server.  At this point Administrator will no longer work.  However, it can be installed on another (non-production) machine for administering the ArcIMS site. 

    Service Administrator

    The Service Administrator uses the ArcIMS Java Connector.  The custom Java classes enable direct (tcp) and Web (http) access to administer an ArcIMS site. These custom classes are contained in pre-packaged JAR files and can be deployed as any standard Java component. The Service Administrator Web application (included with ArcIMS in a directory named “esriadmin”) utilizes the Java Connector.





    Choosing the correct solution for your site depends on the resources and requirements of your site.  Evaluate the benefits and drawbacks of each administrative option before selecting a solution.


    Appendix B:

    Authentication and SSL



    Authentication is a process whereby an entity proves its identity to another entity. In a client-server environment such as the Internet, both the client and the server can authenticate one another before transferring information. For the client, authentication usually involves providing a username and password to an authenticating mechanism on the server. The server can authenticate itself with the client by establishing a secure socket layer (SSL) connection. This allows the server to manage communication securely.


    Implementing authentication on your Web server provides you with the ability to monitor and track access to ArcIMS services and their data. Authentication can be implemented by the Web server itself or through a component associated with the Web server. For example, IIS inherently provides a mechanism to manage user accounts for site access, whereas the ArcIMS servlet, accessible through IIS and a servlet engine, permits a servlet-specific mechanism for authenticating users.


    Once a client has been authenticated, information pertaining to your ArcIMS services flows across the communication link with the server. SSL allows you to establish a secure communication link between the client and the server over which feature geometry and attributes can be transferred without being compromised or intercepted. SSL must be configured on the Web server. By convention, URLs that require an SSL connection will start with "https://"-the "s" indicates that SSL is in use.


    Note that client authentication and SSL will not limit data access once the client has successfully been authenticated. This means that an authenticated ArcMap client can take advantage of the data sharing feature to extract data from your ArcIMS services unless other strategies are in place to disable the data sharing feature. Authentication and SSL are only appropriate for limiting initial access to your Web site and ensuring secure communication.



    Web servers and server-side technologies such as servlets or CGI scripts provide many options for authenticating clients before they gain access to information and services on your Web server. Find and follow the instructions for enabling authentication on your particular Web server or server-side technology. You can find information on enabling authentication via the ArcIMS Servlet Connector in the ArcIMS Help by searching for the keyword "authentication".


    Web servers also have specific methods for configuring and enabling SSL. In general, you must purchase a server certificate from a certificate authority such as Verisign-and implement the certificate with your Web server. Upon implementation, your Web server will use another port (the default is 443) to establish and maintain secure communications with clients. Consult your Web server documentation and certificate authority Web site for more details.