Notes on Running a Globus 4 Web Application in the OMII-UK Secure Web Services Container

Bryan Carpenter

1. Introduction

The OMII-UK Secure Web Services Container is a Servlet container configured for convenient deployment of secure SOAP Web Services. More concretely it is an Apache Tomcat Web server, packaged with a set of installers that configure some default security policies. It also comes with installers for a suite of software components, most of which have been developed under the OMII-UK Commissioned Software programme. Most of these components run within the container.

Traditionally there are two central planks to security in the OMII-UK container―HTTPS and WS-Security. HTTPS transport-level security is configured at the Tomcat level, as part of the default installation. For convenience the OMII-UK installers automatically supply a temporary X.509 server certificate. WS-Security is configured at the level of an individual software component (or Web Application), using Apache Axis and Apache WSS4J. Suitable versions of these Apache projects are made available as shared Java libraries within the container. OMII-UK also suggests a default WS-Security policy, which is implemented in individual software components by following a suitable OMII-UK template for the application's Axis engine configuration―the file usually called server-config.wsdd[1].

Applications sometimes require security features more general than those supported by the default OMII-UK WS-Security configuration. Notably, “grid” applications often require the ability to delegate their credentials using Globus-style proxy certificates. This is not directly supported by the default OMII-UK set up.

A grid service supporting credential delegation may be implemented using Globus. A Globus 4 grid service is typically part of a Servlet Web application based on Axis. There is no obvious reason why such applications cannot simply be installed―or indeed developed―in the OMII-UK Web Secure Services Container. For sure they would not be using the OMII-UK template for WS-Security―Globus has its own templates for configuration of WS-Security and related matters. But―at least at the SOAP level―there is no obvious reason why Globus and traditional OMII-UK applications cannot co-exist in the same Tomcat Web server.

Problems could arise in this scenario at the transport level. The configuration of HTTP/HTTPS is dealt with at the container level. If we want Globus and traditional OMII-UK applications to co-exist in the same container[2], then certainly there is the possibility of conflicts in the configuration requirements at the transport level.

This technical report describes one approach to running Globus services and traditional OMII-UK Web services, both in a single OMII-UK Secure Web Services Container. The general idea is to leave the HTTPS configuration of the OMII-UK container unchanged, and to leave the SOAP configuration of the Globus application unchanged. So then the only challenge is to make the minimal changes to the HTTPS configuration of a typical Globus application so that it can run in the OMII-UK container.

My use case will be the Globus version of OGSA-DAI 3.0. We describe in detail an approach to installing ogsadai-3.0-gt-4.0.5 in the OMII-UK Secure Web Services Container, version 3.4.2, and show how to run some simple OGSA-DAI examples, including an example using delegation.

The focus is on the OMII-UK Secure Web Services Container, but it should be possible to adapt the instructions here to running a secured Globus service inside other Apache Tomcat installations with non-Globus HTTPS implementations (and perhaps even in other HTTPS servlet containers).

Section 2 briefly describes how relevant security handlers in Globus 4 work. Section 3 summarizes how a Globus client can be run against a Globus grid service running in a container that runs non-Globus HTTPS. As a concrete example, Section 4 describes in detail how I installed the Globus Toolkit distribution of OGSA-DAI 3.0 in the OMII-UK Secure Web Service Container and ran various examples against it.

2. Aspects of Security in Globus 4

This section provides a very selective overview of some features of security in a Globus 4 Web application. I only cover aspects relevant to the purpose at hand.

Since I will be using the default OMII-UK Web Services Container (or an unmodified Apache Tomcat) to deal with transport, I assume the Web application is configured to establish the Globus security context at the SOAP message level.

The way this typically works in Globus 4 is that a client wanting to talk to a Globus service first engages in a SOAP dialogue with an Authentication Service running in the same server (and probably in the same Web application context). The client will send a <RequestSecurityToken> message to the Authentication Service. This request follows the syntax for communicating with a Security Token Service, defined in the WS-Trust specification[3], though the extent to which that specification encompasses the kind of dialogue described here wasn't completely obvious to me. The Authentication Service responds with a <RequestSecurityTokenResponse> message (Figure 1).

Figure 1. Client Requests a Security Token

This is the opening exchange in a dialogue that continues with the client and Authentication Service exchanging a whole series of <RequestSecurityTokenResponse> messages (Figure 2).

Figure 2. Establishing the Security Context

This dialogue is establishing a shared security context between client and server. This security context will include shared secrets, and may include delegated credentials on the server. How this is implemented in Globus is that there is effectively an SSL Handshake, but enacted in SOAP messages. The component messages of this handshake are embedded in <BinaryToken> elements in the exchanged <RequestSecurityToken> and <RequestSecurityTokenResponse> messages. As in a normal SSL Handshake, the exchanged messages may be intercepted by a third party without compromising the secrets established between the client and the server.

If GSI-style delegation has been requested, the initial handshake is followed by generation of a key pair and Certificate Signing Request (CSR) on server. The CSR is returned to the client in one of the <RequestSecurityTokenResponse> messages. The client signs the proxy certificate with its own certificate, and sends the proxy to the server in the next <RequestSecurityTokenResponse>. The server can now act on behalf of the client.

The client is now ready to perform secure operations on a service on the server, perhaps against an execution service (Figure 3).

Figure 3. A Secure Execution Request

Through the shared security context, parts of this exchange may, for example, be encrypted or signed using the shared secrets established previously. In fulfilling the request, the service may use its proxy certificate to act on behalf of the client.

For this to work the client request must identify the relevant security context on the server (which may of course be engaging with many clients simultaneously). As part of the earlier dialogue with the Authentication Service, a handle is returned to the client that identifies the established security context on the server side. This handle will be included in a WS-Security header in the SOAP envelope containing the <execute> operation. The header contains a <SecurityContextToken> element, following syntax defined in the WS-SecureConversation specification[4].

In a Java client using Apache Axis, the dialogue between client and the Authentication Service may be enacted by an Globus Axis handler in the request flow of the client. Figure 4 illustrates part of the client Axis engine configuration. The real configuration is likely to contain many more handlers, that do things like signing and encrypting parts of the messages produced by Axis invocations from the client application. The message is eventually sent and received by the transport handler labelled HTTPSSender (likely to implemented by the Globus class org.globus.axis.transport.HTTPSSender). In this configuration, the interesting handler is SecContextHandler in the request flow. This is where the dialogue described above with the Authentication Service―which establishes a shared security context―actually takes place. Here SecContextHandler is implemented by the Globus class org.globus.wsrf.impl.security.authentication.secureconv.SecContextHandler.

Figure 4. Axis Handlers in Possible Globus Client

3. Running a Globus Client Against a Container that Uses Standard Java HTTPS

The usual instructions for installing Globus applications to Tomcat, for example, involve installing a custom Globus implementation of HTTPS into the container. But none of the discussion in the previous section required any special behaviour in the HTTPS implementation. All the work of creating a shared security context between client and server, including delegation of credentials, occurred at the SOAP level (not the transport level). There doesn't seem to be an obvious reason why Globus secured Web application cannot sit in Tomcat running the standard Java implementation of HTTPS.

So long as the client is written as an Axis client following a standard Globus template for the client configuration, as in Figure 4, and the client uses an HTTPS implementation compatible with the the one in the container, there don't seem to be any particular problems implementing this scenario (none arose for me, anyway...)

It may also be possible to use pre-existing Globus clients to talk the same container, so long as they have the capability to use the “Secure Conversation” protocol to establish the shared security context through SOAP (presumably using the SecContextHandler handler). However I did encounter one problem in this case.

If such a Globus client application is expecting to use HTTPS, it may well explicitly load the class org.globus.axis.util.Util and (implicitly or explicitly) call its method registerTransport(). This installs special Globus java.net.URL protocol handlers in the JVM. Subsequently, custom Globus socket classes will be used to open connections to HTTPS URLs.

The Globus implementation of HTTPS on the client side is compatible with the standard Java implementation of HTTPS on the server, provided encryption is enabled in the HTTPS data stream. This is the “normal” situation when using HTTPS―for most applications there is little point using HTTPS unless the data stream is encrypted. However I encountered a problem in using the client configuration illustrated in Figure 4 against a Tomcat server using standard Java HTTPS, with Globus HTTPS enabled on the client side.

The problem appears to be this: the Authentication Service runs in the same container as the grid service(s) I am ultimately interested in, and is thus accessed through HTTPS. But the WS-Trust dialogue between SecContextHandler and the Authentication Service does not need to be encrypted, and encryption is an overhead. Presumably for this reason (in my experience with a default Globus client configuration) this dialogue is not encrypted. What exactly happens is that if a property called org.globus.gsi.GSIConstants.GSI_TRANSPORT (or "org.globus.security.transport.type") does not have the value org.globus.gsi.GSIConstants.ENCRYPTION (or the java.lang.Integer value 2), then the Globus implementation of org.ietf.jgss.GSSContext will only offer a single cipher suite:

  TLS_RSA_WITH_NULL_MD5 

in the opening Client Hello message of the SSL handshake. This forces the server to use this suite, if it supports it. Unfortunately, as of Java 6, the standard Java implementation of SSL does not support this suite. So the HTTPS session with (for example) standard Tomcat cannot be established when transport level encryption is not explicitly enabled in the Globus client.

Perhaps the simplest work around is to force the SOAP invocations made by SecContextHandler to redundantly enable encryption at the HTTPS transport level. According to the previous paragraph, this can be done by setting the org.globus.gsi.GSIConstants.GSI_TRANSPORT property (in the message context) to the value org.globus.gsi.GSIConstants.ENCRYPTION. Since SOAP invocations by the SecContextHandler will themselves use whatever Axis client configuration is in effect, this can be achieved by adding to the request flow one extra handler, which just sets the necessary property.

The end result is that it may be possible to use an unchanged Globus Java client to talk to the grid application running in (for example) the OMII-UK Secure Web Services Container. Only the client Axis engine configuration (typically the file client-config.wsdd) may need changing.

4. OGSA-DAI Globus Distribution in the OMII-UK Container

The application that motivated this investigation was OGSA-DAI 3.0. This section describes how the Globus distribution of this software can be installed in the OMII-UK Secure Web Services Container.

4.1. The Example Code

Some example software accompanies this discussion. If you are reading the Wiki form of this document, you can find this software attached to this page. The distribution contains client-side example code and one custom, client-side Axis handler that can be used to demonstrate running the Globus Toolkit version of OGSA-DAI 3.0 in the OMII Container.

For purposes of illustration it is assumed here that the OMII Certificate Authority and OMII host and client certificates are distinct from the Globus Certificate Authority and Globus host and client certificates. This is the general case. In practise it may well be natural to identify OMII and Globus certificates; the instructions below should still apply―just ignore adjectives “OMII” and “Globus” when applied to certificates!

4.2. Server Installation

You will need to install a Globus host certificate for your Globus services. You should copy the PEM form of the certificate and the PEM form of the unencrypted private key to files on the host computer. The exact locations of these files do not matter, so long as they are accessible to the account under whose identity the OMII-UK Secure Web Services Container will run (the key file should be suitably read-protected). The file paths will be used below in configuration of the service.

You will also have to install the certificate of the Certificate Authority (CA) that signed your Globus certificates. We assume the simplest case, where all your Globus certificates―host and client―are signed by the same CA. A simple possibility is to copy the PEM version of the CA certificate to a directory $HOME/.globus/certificates/, where “$HOME” is the home directory for the account under whose identiy the OMII-UK Secure Web Services Container will run.

If you happen to have a full Globus Toolkit installation on the server concerned, you will probably already have a CA certificate in /etc/grid-security/certificates/. But in this case be aware that if the $HOME/.globus/certificates/ directory exists at all, the /etc/grid-security/certificates/ directory will be ignored in searches for the Globus CA certificate.

Regarding the naming of the CA certificate file, you should follow the instructions appropriate to the version of the Globus toolkit you are using. In my case I just added a file called:

  $HOME/.globus/certificates/cacert.0 

but some versions of GT4 may have more restrictive policies about file names[5].

Now:

1. Install an OMII-UK Secure Web Services Container on your server using the stack installer from omii-server-3.4.2.tar. You do not need to install any of the optional Software Components, but you will find it convenient to install the OGSA-DAI 2.2 component. This component will not be used directly below, but a useful side effect of the associated component installer is to initialize an example database. This same database will be queried by the OGSA-DAI 3.0 SQL client in examples below.

2. Deploy Globus ws-core-4.0.5 to the OMII container (I have also successfully used ws-core-4.0.8).

Essentially you can follow instructions for doing this at the beginning of

Section 12.1 of the OGSA-DAI 3.0 Documentation:

Download and unpack ws-core-4.0.5-bin.zip.

Set the environment variable GLOBUS_LOCATION, e.g.:

  $ export GLOBUS_LOCATION=/home/omii/soft/ws-core-4.0.5 

The value of this variable should be the location where you unpacked the Globus WS-Core distribution.

Go to the $GLOBUS_LOCATION directory and do e.g.:

  $ ant -f share/globus_wsrf_common/tomcat/tomcat.xml deployTomcat \
        -Dtomcat.dir=/home/omii/OMII/apache-tomcat-5.5.23 

The value of tomcat.dir should be the Tomcat directory within your OMII-UK server installation.

Do not use the deploySecureTomcat target here. This would install various jars to the top-level Tomcat server/ and common/ directories. These might well disrupt the normal operation of OMII software components [6].

3. In your OMII-UK Development Kit Server installation directory, edit the file:

  webapps/wsrf/WEB-INF/etc/globus_wsrf_core/server-config.wsdd 

Near the comment:

  <!-- @CONTAINER_SECURITY_DESCRIPTOR@ --> 

add the element:

  <parameter name="containerSecDesc"
             value="etc/globus_wsrf_core/global_security_descriptor.xml"/> 

(Note there is a mistake in the OGSA-DAI documentation―the file at:

  $GLOBUS_LOCATION/etc/globus_wsrf_core/server-config.wsdd 

in ws-core-4.0.5 does not initially include these lines.)

4. In your OMII-UK Development Kit Server installation directory, edit the file:

  webapps/wsrf/WEB-INF/etc/globus_wsrf_core/global_security_descriptor.xml 

Replace the value attribute of the <cert-file> and <key-file> elements to reference the Globus host certificate installed above. Also, comment out the <gridmap> element (or make sure its value attribute references a valid Globus “grid-mapfile”, if you happen to have one on your server).

5. Check that the page:

  https://SERVER:18443/wsrf/services 

is accessible using a Web browser. Here SERVER is the name of the host where you have just installed the OMII container.

6. Deploy OGSA-DAI ogsadai-3.0-gt-4.0.5 to the OMII container.

Download and unpack ogsadai-3.0-gt-4.0.5-bin.zip.

Go to the ogsadai-3.0-gt-4.0.5-bin/ directory and do e.g.:

  $ ant -Dgt.dir=$GLOBUS_LOCATION \
        -Dtomcat.dir=/home/omii/OMII/apache-tomcat-5.5.23 \
        buildAndDeployGARTomcat 

The value of tomcat.dir should be the Tomcat directory within your OMII-UK Development Kit Server installation.

7. Restart the OMII-UK Secure Web Services container, and check that the pages:

  https://SERVER:18443/wsrf/services 

and

  https://SERVER:18443/wsrf/dai-manager.jsp 

are accessible using a Web browser.

8. For purposes of running the SQL client example below, deploy a test resource to the OGSA-DAI service.

For convenience I used the test database created by the software component installer for OGSA-DAI 2.2 (we are not using OGSA-DAI 2.2 itself). Create a file my.resource.config containing:

  dai.resource.id=TestResource
  dai.db.product=PostgreSQL
  dai.db.vendor=PostgreSQL
  dai.db.uri=jdbc:postgresql://localhost:5432/ogsadai_2_2
  dai.db.driver=org.postgresql.Driver
  dai.user=mp_user
  dai.password=mp 

Then in the ogsadai-3.0-gt-4.0.5-bin/ directory do e.g.:

  $ ant -Dtomcat.dir=/home/omii/OMII/apache-tomcat-5.5.23 \
        -propertyfile my.resource.config deployRelationalResource 

The value of tomcat.dir should be the Tomcat directory within your OMII-UK Development Kit Server installation.

You will also need an appropriate JDBC driver jar. Assuming you installed the OGSA-DAI 2.2 software component earlier, you can do something like:

  $ cp OMII/webapps/ogsadai/WEB-INF/lib/pg73jdbc3.jar \
       OMII/webapps/wsrf/WEB-INF/lib/ 

4.3. Client Installation

1. Download and unpack ogsadai-3.0-gt-4.0.5-bin.zip.

Set up the class path for OGSA-DAI by executing:

  $ source setenv.sh 

in the directory created from this zip.

(If, by any chance, you use Cygwin, you might want to run:

  $ CLASSPATH=`cygpath -w -p $CLASSPATH` 

after sourceing setenv.sh!)

For use below, set an environment variable DAI_LOCATION to point to this installation directory, for example:

  $ export DAI_LOCATION=g:/soft/ogsadai-3.0-gt-4.0.5-bin 

2. Since we are using Globus security at the message level, you need a user certificate from a suitable Certificate Authority (CA). Copy PEM versions of your Globus certificate and private key to files called usercert.pem and userkey.pem in the directory $HOME/.globus/.

Copy the PEM version of the associated CA certificate to the directory $HOME/.globus/―for example to the file $HOME/.globus/certificates/cacert.0.

3. Before running any of the examples described below, you will need to create a proxy certificate. You may, for example, download cog-jglobus-1.4-bin.zip from the download page at http://wiki.cogkit.org.

After unpacking it, you can generate a proxy by something like:

  $ $COG_INSTALL_PATH/bin/grid-proxy-init.bat 

where $COG_INSTALL_PATH is the directory created from the zip.

4.4. Running an Example Client using OMII-style SSL

At the transport level, there are two ways a client can communicate with a Globus-based application running in the OMII-UK Web Services Container. It can, implicitly or explicitly, use the default SSLSocket implementation built into the JDK. This is what OMII-based clients traditionally do, through the OMII version of Axis. Alternatively a client can use a custom GssSocket class implemented in the CoG Kit jGlobus module. This is what Globus-based clients traditionally do. In this latter case, instances of a custom GSIHttpURLConnection are created by special java.net.URL protocol handlers. These can be installed in the JVM by calling the registerTransport() method of the class org.globus.axis.util.Util. This class is bundled with the Globus version of Axis.

Which of these options you choose may depend on the history of your distributed application. If it was originally an OMII-UK application that you are adapting to use Globus SOAP handlers, the first approach may be more convenient. It it was originally a Globus application that you are adapting to use the OMII-UK container, the second approach may be more convenient.

Now, to use the first approach to transport:

1. Install an OMII-UK Development Kit client from omii-client-3.4.2.zip. For purposes of the immediately following example, this installation is only needed for the keystore containing the OMII Temporary CA certificate.

For convenience, you may set an environment variable OMIICLIENT to point at the directory where the OMII client is installed.

2. Now go to the "$DAI_LOCATION/" directory and do e.g.:

  $ java -Djavax.net.ssl.trustStore="$OMIICLIENT/omii.ks" \
         uk.org.ogsadai.client.toolkit.example.ServerClient \
         -u https://SERVER:18443/wsrf/services/dai \
         -c getVersion
         3.0 [GT 4.0.5] 

The javax.net.ssl.trustStore system property is interpretted by the standard SSL factories built into the JDK. This ServerClient example from the OGSA-DAI distribution does not enable the GT socket factories (it doesn't load the org.globus.axis.util.Util class). Hence the standard SSL factories remain in effect in this example.

(Note that for certain client applications it should be possible to replace the transport handlers in the Axis engine client configuration―client-config.wsdd―replacing the Globus transport class, HTTPSSender with:

  uk.ac.omii.transport.http.OMIIHTTPSender 

It would then not be necessary to set the system property javax.net.ssl.trustStore.

For OGSA-DAI clients this is usually not sufficient, because they typically try to download the WSDL for the service directly from an https URL. Because this download doesn't go through Axis, specifying a custom Axis transport handler is insufficient here.)

4.5. Running an Example Client using Globus-style SSL

To use the second approach to transport:

1. In this approach we are using the Globus SSL support classes to communicate with the OMII container. First it is necessary to ensure that the certificate of the Certificate Authority (CA) that signed the OMII container's certificate is known to these Globus classes on the client.

Copy the PEM version of the associated CA to the directory $HOME/.globus/―for example to the file $HOME/.globus/certificates/omiica.0[7].

In an OMII-UK Development Kit client or server installation, this certificate is available in the subdirectory:

  pem_format_certs/ca_certs/cacert.pem 

under the installation directory.

2. The approach recommended here involves adding a custom handler to the client Axis engine configuration.

Build the example software associated with this document by ensuring the DAI_LOCATION environment variable is set, then running:

  $ ant 

in the top-level directory. Then add the classes to your class path, e.g.:

  $ CLASSPATH=$OGSADAI_GT_OMII_LOCATION/build:$CLASSPATH 

where $OGSADAI_GT_OMII_LOCATION is the path to the example software directory.

Now edit the file:

  $DAI_LOCATION/deploy/client-config.wsdd 

adding the element:

  <handler type="java:org.apache.axis.handlers.JAXRPCHandler">
   <parameter name="className" value="uk.ac.omii.globus.EnableTransportEncryptionHandler"/>
  </handler> 

to the <requestFlow> element.

It shouldn't matter where in the request flow you place this handler. All the handler does is define a property "org.globus.security.transport.type" with value Constants.ENCRYPTION in the message context. This property is interpretted by the Globus transport handler, HTTPSSender.

3. Go to the $DAI_LOCATION/ directory and do e.g.:

  $ java uk.org.ogsadai.client.toolkit.gt.example.GTSecureSQLClient \
         -u https://SERVER:18443/wsrf/services/dai   \
         -d TestResource \
         -q "SELECT * FROM littleblackbook where id < 10"
  DRER ID: DataRequestExecutionResource
  Data Resource ID: TestResource
  Base Services URL: https://SERVER:18443/wsrf/services/dai
  SQLQuery: SELECT * FROM littleblackbook where id < 10
  uk.org.ogsadai.resource.request.status.COMPLETED
  | id | name              | address                           | phone       |
  | 1  | Ally Antonioletti | 826 Hume Crescent, Southampton    | 01670061244 |
  | 2  | Amy Atkinson      | 583 Atkinson Drive, Southampton   | 06312054624 |
  | 3  | Andrew Borley     | 354 Jackson Road, Edinburgh       | 01057075166 |
  | 4  | Charaka Chue Hong | 750 Pearson Crescent, Southampton | 09945916393 |
  | 5  | Dave Hardman      | 079 Borley Gardens, Winchester    | 06725558505 |
  | 6  | George Hicken     | 398 Magowan Street, Winchester    | 09066873297 |
  | 7  | James Hume        | 801 Laws Gardens, Edinburgh       | 00246566355 |
  | 8  | Malcolm Jackson   | 743 Krause Lane, Edinburgh        | 04333719273 |
  | 9  | Mario Krause      | 026 Atkinson Gardens, Winchester  | 01922093483 | 

(It is possible to set the "org.globus.security.transport.type" property in the message context directly from the client application. In fact the GTSecureSQLClient application will do this if you add the command line argument -tls. With this argument specified, it is not necessary to add EnableTransportEncryptionHandler to the client handlers, in the way we did above.

This may seem like a simpler approach, but it is limited―it won't work in conjunction with the SecContextHandler handler, which is needed for delegation―see below.)

4.6. Running an Example with Delegation

The distribution of the example software contains a client:

  uk.ac.omii.ogsadai.client.example.GFTPClient 

This example uses an OGSA-DAI ObtainFromGFTP activity, run in an OGSA-DAI DataRequestExecution resource, to read a file from a GridFTP server.

The scenario we are interested in is one where the file on the GridFTP server is owned by the end user, running the client. The OGSA-DAI service is acting as a delegate of the client. The OGSA-DAI service needs a proxy certificate for the end user, in order to authenticate itself to the GridFTP server.

To run this example, you will need a suitable GridFTP service. We assume that the OGSA-DAI service runs on a server, SERVER, and the GridFTP service runs on a server SERVER2 (Figure 5).

Figure 5. Delegation Example from the Text

If a suitable GridFTP service is not already available to you, you may, for example, follow the instructions http://www.globus.org/toolkit/docs/4.0/admin/docbook/quickstart.html as far as the end of Section 2.4, Set up GridFTP.

For simplicity, we assume the host certificate for the installation of Globus and GridFTP on SERVER2 is issued by the same Certificate Authority (CA) as the personal Globus certificate you hold as client. (If, for example, you followed the Globus quickstart instructions just referred to, your personal Globus certificate might be issued by the CA set up on SERVER2 in the course of that Globus installation.)

Now:

1. If you haven't already done so, build the attached example software by ensuring the DAI_LOCATION environment variable is set, then running:

  $ ant 

in the top-level directory.

2. If you haven't already done so, edit the file:

  $DAI_LOCATION/deploy/client-config.wsdd 

as described in Section 4.5, Running an Example Client using Globus-style SSL, bullet 2.

(In this example it really is necessary to use an Axis handler like EnableTransportEncryptionHandler in the client request flow to set the property "org.globus.security.transport.type". This is because the handler SecContextHandler in the Globus client request flow will itself make direct Axis invocations on the Globus authentication service running on SERVER. The invocations made by this handler will not inherit the properties from the message context originally set up by the client programme. But they will pick up the request flow from the global client configuration, including the handler EnableTransportEncryptionHandler.)

3. Create a suitable file on SERVER2 for reading―as an example we use the file /home/omii/testDirectory/test1.

4. On SERVER2, ensure that the file:

  /etc/grid-security/grid-mapfile 

maps the Distinguished Name (DN) in your personal Globus certificate to a local account that has read access to the file test1 (say).

For example if the DN is:

  O=Grid,OU=GlobusTest,OU=simpleCA-blade11.omii.ac.uk,OU=omii.ac.uk,CN=OMII-USER 

then grid-mapfile might contain an entry:

  "/O=Grid/OU=GlobusTest/OU=simpleCA-blade11.omii.ac.uk/OU=omii.ac.uk/CN=OMII-USER" omii 

where omii is a suitable account name.

5. To run GFTPClient, work in the directory containing this README, ensure the DAI_LOCATION environment variable is set, and run grid-proxy-init again if necessary; then execute a command like:

  $ ant -Durl=https://SERVER:18443/wsrf/services/dai \
        -Dhost=SERVER2:2811 \
        -Dfile=/home/omii/testDirectory/test1 \
        runGFTPRead
  Buildfile: build.xml

  runGFTPRead:
       [java] DRER ID: DataRequestExecutionResource
       [java] Base Services URL: https://SERVER:18443/wsrf/services/dai
       [java] Host: SERVER2:2811
       [java] File: /home/omii/testDirectory/test1
       [java] Secure conversation with integrity
       [java] uk.org.ogsadai.resource.request.status.COMPLETED
       [java] junk 

In this example, the file test1 contains the single line junk.

In the example above, the client is using the Globus implementation of SSL. To use the OMII approach to SSL in the client, comment out the line:

  Util.registerTransport(); 

in GFTPClient.java, rebuild, set an environment variable OMIICLIENT to point at the OMII-UK Development Kit Client installation directory, e.g.:

  $ export OMIICLIENT="c:/Program Files/OMIICLIENT" 

and in step 5 run the Ant target runGFTPReadOMII rather than runGFTPRead.

In this case editting client-config.wsdd is redundant. But doing so is harmless.

---

[#1]See the section The Secured WS-Container → Configuration of WS-Security at http://www.omii.ac.uk/docs/3.4.2/user_guide/omii_user_guide.htm.

[#2]Especially if we want the two kinds of application to be accessed through the same IP port.

[#3]WS-Trust 1.3, OASIS Standard, http://docs.oasis-open.org/ws-sx/ws-trust/200512/ws-trust-1.3-os.html is the latest version. Globus 4.0 uses an earlier version of this specification, possibly http://download.boulder.ibm.com/ibmdl/pub/software/dw/specs/ws-trust/ws-trust052004.pdf.

[#4]WS-SecureConversation 1.3, OASIS Standard, http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512/ws-secureconversation-1.3-os.html is the latest version. Globus 4.0 uses an earlier version of this specification, possibly http://specs.xmlsoap.org/ws/2004/04/sc/ws-secureconversation.pdf.

[#5]See for example http://www.globus.org/toolkit/docs/4.0/security/prewsaa/admin-index.html#id2529844. The implementation of org.globus.gsi.TrustedCertificates in the the version of the Globus I was using was more liberal about CA certificates than that link implies, but your version may not be! Thanks to Tom Scavo for pointing this out.

[#6]The deployTomcat target will install the file xalan.jar in the subdirectory tomcat/common/endorsed/ of your OMII-UK Development Kit Server installation directory. There is a risk that endorsing this third party jar would cause issues with certain OMII-UK components that rely a different implementation of the XSLT APIs. On the other hand the version of Xalan shipped here is required for SAML APIs in Globus 4. See http://bugzilla.globus.org/globus/show_bug.cgi?id=5546 for a more complete discussion. Again, thanks to Tom Scavo for pointing out the potential issues here.

[#7]But see notes in the earlier footnote about CA certificates.