Scheming about authentication with ArcGIS for Java?

[RandallWilliams]

Most of us here are relatively familiar with ArcGIS Server for .Net. However, in support our exposure to the Java product is relatively limited, simply because it seems that fewer customers have implemented ArcGIS Server for Java. In this post, I'll try to cover a topic that comes up every now and then in support, how to secure both OGC and Esri GIS Service endpoints provided by the same instance of ArcGIS Server. This concept is similar to but implemented differently than the ArcGIS Server for .Net help topic "Multiple ArcGIS Server Web Instances for Security".



Before we begin, lets review a couple of best practices (things that are good to know) that we should understand prior to engaging in any configurations.

First, have a quick look at the documentation regarding exporting the ArcGIS Server 10 for Java web service and REST handlers. The Tomcat web server that ships with ArcGIS Server for Java should be used for development and ArcGIS Server administration. It's not really meant for handling the load of production work. We recommend using ArcGIS Server manager to export your REST, web service, and token applications out to a standard .WAR file and then deploying those .WAR files to your favorite J2EE web server for production use.

Second, regarding security and OGC services:

It's important to recognize that there is no provision in the OGC spec for token based authentication with OGC services. This means that if you'd like to secure your WMS, WFS, or WCS Services, you'll need to use a more standard authentication mechanism other than the Esri provided token service, like HTTP BASIC or DIGEST authentication.

Out of the box,  without deploying the GIS Server handlers to an external J2EE server, ArcGIS Server for Java will be limited to a single authentication mechanism. However, as we'll discuss below, we can work around this limitation by deploying multiple web services handlers - each with it's own authentication mechanism.

To accommodate this configuration, we'll use Tomcat 7 (either 32- or 64-bit is fine, just be sure that if you've got the same bit level Java installed as whichever Tomcat you choose).

While you're setting up Tomcat, since we'll be working with authentication, you'll also want to stand up HTTPS/SSL. Otherwise, your credentials and tokens will be passed in clear text over the wire. In my testing, I generally create a SSL repository and self signed certificate using the keytool command. SSL is required when working with the token service with ArcGIS Server for Java, and there is not a supported way to disable this requirement like there is in the .Net product.

After Tomcat is installed and configured with SSL, set up your security store. For this example, we'll set ArcGIS Server to use ArcGIS Token Authentication and enable security for your services. Test to verify that security is working.

Next, we'll export the SOAP (web services), REST, and token service handlers, and then deploy them to the external instance of Tomcat and test to verify that the services can be reached. When I export my web handlers, I usually stick with generic application names, like 'REST', 'Services', and 'Tokens'.

When you're configuring the SOAP and REST handlers, make sure that you enable authentication using the ArcGIS token service, and make sure that the token service URL is pointing to the token service handler deployed on the "external" instance of Tomcat.

After they've been successfully deployed to Tomcat, test to verify that you can reach your REST endpoints and service WSDLs. Keep in mind that unless a new context path is explicitly defined, these applications will deploy to the root of the web server. That means that your URLs to your service endpoints will look similar to these (using Tomcat's default HTTPS port):

https://myserver:8443/services?wsdl

https://myserver:8443/rest/services

Once you've tested to verify that the service handlers are working as expected, including requiring authentication to the secured services, it's time to deploy another services handler. This one we'll use to access our secure OGC services. In this case, since we know that OGC services do not support token based authentication, we'll configure the services handler to use basic or digest authentication. We can use the same security store created earlier when we secured the services, but we can't use the token service.

Export this application as a .WAR, and name it something like "OGC".

Keep in mind that since we're now using an external instance of Tomcat, we'll also need to make a quick modification to the tomcat-users.xml file. Otherwise, Tomcat won't be able to recognize the users and roles you set with the internal Tomcat and service handlers that were created using the ArcGIS Server Manager GUI experience. By default, you'll find that file here: C:Program FilesApache Software FoundationTomcat 7.0conf

Open Tomcat-Users.xml with a text editor and uncomment the users and roles section, then add lines to this file to match the users and you've created you created in the GIS Server security store, like this:

Finally, give the Apache Tomcat service a restart so that Tomcat recognizes the new users and roles.

You should then be able to pass credentials to reach your OCG services, like this:

https://myserver:8443/OGC/myservice/mapserver/wmsserver?request=getcapabilities

That's it!

To summarize, because OGC services do not support token based authentication, we essentially exported two sets of service handlers: one for our REST services using the token service, and another for our OGC services using basic or digest authentication. Services delivered over SOAP may be authenticated using either endpoint, depending on the requirements of the client application.Randall W. - Server Support Analyst

---