Using OGSA-DAI with Globus Toolkit Security

The OGSA-DAI data service can be made secure using the security functionality provided by the Globus Toolkit. Please refer to the Globus Toolkit documentation for details regarding how to configure secure services. This page is designed to give some hints regarding security issues with OGSA-DAI WSRF but is in no way intended to replace the Globus documentation.

Configuring Tomcat

• For message-level security:
  • No special configuration of Tomcat is required if using message-level security.
• For transport-level security:
  • You must install Globus Toolkit into Tomcat using the deploySecureTomcat target.
  • You will also need to edit some files after this process.
  • For full details see the Globus Toolkit documentation on Deploying into Tomcat [1].

Configuring Service Security

1. Create a Security Descriptor

The security that each service expects clients to satisfy is configured server-side using a security descriptor. Security descriptors are used to configure either or both message-level and transport-level security settings for a service. An example security descriptor for a service is shown below:

<securityConfig xmlns="http://www.globus.org">

  <auth-method>
    <GSISecureConversation/>
    <GSITransport>
      <protection-level>
        <privacy/>
      </protection-level>
    </GSITransport>
  </auth-method>

  <run-as>
    <caller-identity/>
  </run-as>

  <!-- Do no authorisation, OGSA-DAI will do it -->
  <authz value="none"/>

  <!-- Locations of host credentials -->
  <credential>
    <key-file  value="/path/to/cert/hostkey.pem"/>
    <cert-file value="/path/to/cert/hostcert.pem"/>
  </credential>

</securityConfig>

This security descriptor specifies that all operations must be invoked using either message level security or encrypted transport-level security. The GSISecureConversation element specifies the former while the GSITransport with privacy sub-element specifies the latter.

Note that in the above example we set the authorisation to none. The authorisation setting in a security descriptor specifies how the invocation of service operations are to be authorised. This is separate from the authorisation that occurs within OGSA-DAI (for example OGSA-DAI's use of role mapping to authorise access to relational and XML data resources). OGSA-DAI does not control access to the data service nor any operations on the service, so you can use the authz element of the security descriptor to specify additional operation-level authorisation for your services and the Globus Toolkit will enforce this. Refer to the Globus documentation for a description of how to configure these authorisation mechanisms.

2. Update the Service Deployment Descriptor

The security descriptor to be used for a service is referenced in the server-config.wsdd file. This is done by setting a securityDescriptor parameter value the service in its service element: For example:

<service name="ogsadai/DataService" provider="Handler"
  use="literal" style="document">

  <!-- ... -->

  <parameter
    name="securityDescriptor"
    value="/absolute/path/to/descriptor/securityDescriptor.xml"/>

</service>

Transport level security within Globus container

To use transport level security from within the Globus container you must specify the host credentials within the container security descriptor.

To do this edit the GLOBUS_LOCATION/etc/globus_wsrf_core/global_security_descriptor.xml file. This file is the container security descriptor. Set the host key and certificate entries to refer to the appropriate files. You may also have to delete the gridmap element within this file.

You must now edit the container server-config.wsdd file to refer to the container security descriptor. To do this edit the GLOBUS_LOCATION/etc/globus_wsrf_core/server-config.wsdd file to add the following element within the globalConfiguration element:

<parameter name="containerSecDesc"
   value="/path/to/globus/location/etc/globus_wsrf_core/global_security_descriptor.xml"/>

Running Clients

To run a client that wishes to securely communicate with a secure OGSA-DAI WSRF service then, assuming that the client has been implemented to support secure communications, you need to ensure the client can pick up a client configuration file which can handle the setting of security onto client-server communications. This file is called client-config.wsdd and is provided in the top-level directory of the OGSA-DAI binary distribution. You should ensure that this file is in the working directory from which you run your client applications or is within a directory in your CLASSPATH.

You will also need to have a valid Grid proxy certificate. If you wish to access relational or XML data resources exposed by the service then you will need to ensure that the distinguished name (DN) of the certificate is specified in an entry of the rolemap configuration file for the relational or XML data service resources that expose the data resources of interest. If you support authorisation of access to resources or execution of activities then you should also ensure that the DN is in the related configuration files (see How To Authorize Access to Resources and Activities) for more details.

The Using Message and Transport Level Security tutorial describes how clients can be written to support invocation of secure services using the client toolkit.

Many of the OGSA-DAI clients have command line options to support invocation of secure services.

Activity and Resource Authorization

There is also a mechanism to provide authorisation control at the activity and resource level, for example to specify that some activities should be restricted to a limited set of users. Currently, access authorization is not supported "out of the box" but an extensibility point is provided which allows application developers to plug in extensions tailored to their requirements. Please refer to the tutorial How To Authorize Access to Resources and Activities for more details.

References

[1] http://www-unix.globus.org/toolkit/docs/4.0/admin/docbook/ch09.html#javawscore-admin-tomcat-deploying .