This article includes details on how to implement HTTP Basic or Digest authentic ation and HTTPS and how

to access these secured web services. You can access ArcGIS web services from SOAP clients or ArcGIS clients. ArcGIS w eb services secured through HTTP Basic or Digest authentication, HTTPS, or WS-Se curity can be accessed from any SOAP client; this functionality has been availab le since the initial release of ArcGIS Server 9.0. Refer to the table below for details on which version of ArcGIS clients can be u sed to access secured ArcGIS web services. Method of securing ArcGIS web service ArcGIS 9.0 clients ArcGIS 9.1 clients ArcG IS 9.2 clients HTTP Basic Authentication Supported Supported Supported HTTP Digest Authentication Not supported Supported Supported HTTPS Not supported Not supported Supported HTTP with Basic or Digest Authentication HTTP with Basic or Digest authentication uses HTTP headers to support authentica tion. HTTP Basic authentication provides an authentication mechanism, with usern ames and passwords, for web services. The user of the web service is challenged with a login dialog. If the user has logged in, the base-64 encoded credentials are in the HTTP header. Basic authentication is not considered strong authentica tion, it is trivial to decode the username and password. HTTP Digest authentication is more secure than Basic authentication, but it has been implemented differently by various browsers. HTTPS HTTPS is widely used for encrypting private information. You have probably used HTTPS when purchasing items on the Internet or accessing your company s email serv er. HTTPS provides a transport channel level security. HTTPS stands for HTTP via SSL (Secure Sockets Layer). SSL is a technology that allows web browsers and we b servers to communicate over a secure connection. In this secure connection, th e data that is being sent is encrypted before being sent, then decrypted upon re ceipt and prior to processing. Both the browser and the server encrypt all traff ic before sending any data. SSL addresses the following important security considerations: Identification Authentication Confidentiality Integrity Digital certificates are used with HTTPS to authenticate web servers and web cli ents. In the case of server authentication, the first time an attempt is made to communicate with the web server over a secure connection, the server presents a server certificate to the client. The certificate is a means to verify that the site is who it claims to be. You should note that HTTPS can be configured with fake certificates which enables encryption but does not provide reliable authent ication. In this case, you must be able to trust the applications on the HTTP en d-points. To overcome the limitation of not being able to authenticate the client, you cou ld implement mutual authentication where you have both server authentication and client authentication. Client-certificate authentication involves requesting a certificate from the client in order to verify that the client is who it claims to be. In the case of mutual authentication, the server and client authenticate one another with certificates. The client's identity is in a client certificate. The server's identity is in a server certificate, stored in a keystore file.

If you choose to secure your web service with client-certificate authentication, you should be prepared to incur the expense of time and resources to configure SSL support on the server and set up the public key certificate. While you can u se client-certificate based authentication with any SOAP client, a web service a uthenticated through this method will not be accessed from ArcGIS clients until 9.2. WS-Security The Web Services Security Specification (WS-Security) standard provides a framew ork for securing SOAP messages. The WS-Security Specification describes how to e xchange signed and encrypted messages in a SOAP environment in order to provide integrity and confidentiality. WS-Security can use Public Key Infrastructure (PK I), Kerberos, Basic or Digest authentication, and SSL to provide the security. WS-Security is an important standard that is still evolving and becoming widely accepted. It is not yet supported with ArcGIS web services but you can take adva ntage of it in your own application web services. Implementing HTTP with Basic or Digest Authentication HTTP authentication is the most familiar transport technique. It uses HTTP heade rs to support Basic or Digest authentication. Java Web Services with HTTP Basic or Digest To set HTTP with Basic or Digest authentication for Java web services, the roles should be defined for the servlet container you use. After this is done, the XM L deployment files for the server and the web service end points will be updated to reflect the user access and role mappings. Java web services are fully supported with any of the servlet engines or applica tion servers supported by the ArcGIS Server Java ADF. You can find a list of supported application serv ers on http://support.esri.com. The instructions in this article show code examp les for implementing a Java web service with Tomcat 5. Setting realms A realm is a "database" of usernames and passwords for identifying valid users o f a web application or web service. In addition to usernames and passwords, ther e is a list of roles associated with each valid user. In your %TOMCAT_HOME%\conf\server.xml, define a realm. As shown below, comment o ut the default realm in the server.xml file. <!-- Realm className="org.apache.catalina.realm.UserDatabaseRealm" debug="0" res ourceName="UserDatabase"/ --> Then add the following tag to define the realm for Basic authentication. <Realm className="org.apache.catalina.realm.MemoryRealm" pathname="conf/tomcat-u sers.xml" /> If you are setting the realm for Digest authentication, an additional attribute is needed. <Realm className="org.apache.catalina.realm.MemoryRealm" digest="MD5" pathname="conf/tomcat-users.xml" /> It is important to note that Tomcat cannot deploy applications using Basic and D igest at the same time. You must deploy two separate Tomcat instances with diffe

rently configured ports and realms to offer Basic and Digest authenticated web s ervices concurrently. To learn more about setting up realms, refer to http://jak arta.apache.org/tomcat/tomcat-5.0-doc/realm-howto.html. Setting roles You will define a list of roles associated with each valid user. The %TOMCAT_HOM E%\conf\tomcat-users.xml file is created during the install of Tomcat. It contai ns, in plain text, the user name, password, and roles that have been defined for this server, and any users or roles you added after installation. The roles wil l be used later to configure authorization for your web service. Initially, the tomcat-users.xml file looks like this: <?xml version='1.0' encoding='utf-8'?> <tomcat-users> <role rolename="tomcat"/> <role rolename="role1"/> <user username="tomcat" password="tomcat" roles="tomcat"/> <user username="role1" password="tomcat" roles="role1"/> <user username="both" password="tomcat" roles="tomcat,role1"/> </tomcat-users> You can edit the users file directly in order to add or remove users or modify r oles, or you can use admintool to accomplish these tasks. To learn more about To mcat s admintool, refer to http://java.sun.com/webservices/docs/1.3/tutorial/doc/A dmintool6.html#wp67613. Setting authentication and authorization Once you have created a web service catalog, edit the web service catalog s deploy ment descriptor, \WEB-INF\web.xml. The deployment descriptor is used to define t he security elements and general configuration information of a web application. Security in a web application is configured using the following elements of the deployment descriptor: <security-role> The element gives the roles that are authorized to access the we b service catalog. <security-constraint> The element is used to assign an authorization constraint to a collection of resources. <login-config> The element specifies the authentication method. For an example web service named wc_security , using Basic authentication and a rol e named role1 , add the following lines after the other elements in your deployment descriptor (web.xml): <web-app> <security-constraint> <web-resource-collection> <web-resource-name>wc_security</web-resource-name> <url-pattern>/*</url-pattern> </web-resource-collection> <auth-constraint> <role-name>role1</role-name> </auth-constraint> </security-constraint> <login-config> <auth-method>BASIC</auth-method> </login-config> <security-role> <role-name>role1</role-name> </security-role> </web-app>

Make sure that the that you specify in the deployment descriptor has a correspon ding entry in your tomcat-users.xml file. When using Digest authentication, you would change the auth-method element to ha ve the following value. <auth-method>DIGEST An updated version of the Java ADF arcgisant command is available from the 9.1 o nline version of ArcGIS Developer Help. The command has been updated to allow yo u to specify whether the web service is secured. When creating the web service c atalog with the arcgisant command, you can specify which role memberships have a ccess. The deployment descriptor will be populated with the necessary elements.