The first configuration task is to tell the container the location of the host certificate and key. The host certificate and key will normally be a pair of files called something like hostkey.pem and hostcert.pem.

Create a file called global_security_descriptor.xml with the following contents, remembering to replace PATH with the full file path to your .pem files:

<?xml version="1.0" encoding="UTF-8"?>
<securityConfig xmlns="http://www.globus.org">
    <credential>
        <key-file value="PATH/hostkey.pem"/>
        <cert-file value="PATH/hostcert.pem"/>
    </credential>
</securityConfig>

This file must specify the path to the host certificate and key files.

If using the GT container save this file to:

$GLOBUS_LOCATION/etc/globus_wsrf_core/global_security_descriptor.xml

If using Tomcat save this file to:

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

You now need to refer to this file from within the container's global configuration. To do this edit the global server-config.wsdd file.

If you are using the GT container this file will be at

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

If you are using Tomcat this file will be at:

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

Edit this file and add the following lines inside the <globalConfiguration> element, remembering to replace PATH with the full file path to your file:

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

The value attribute must contain the path to the global_security_descriptor.xml file.

Configuring the trusted CAs requires placing the appropriate CA certificates in the correct directory. CA certificates are named by a hash value and have an associated signing policy file. An example of the types of filenames in a CA directory are:

The Globus Toolkit searches in the following places for the CA directory, it will use the first one it finds searching in the order defined here:

	Note
	Option 1 did not appear to work in our testing with Windows.

To configure the authentication method and level to be used with each of the OGSA-DAI services requires the use of Globus Toolkit security descriptors. This section aims to provide enough information to configure a secure server but for more details regarding security descriptors see the Globus Toolkit documentation.

The Globus Toolkit provides three authentication methods. These are:

Each of these methods can have a choice of two protection levels. These are:

Once you have decided on the authorization level suitable for our installation you can write a corresponding security descriptor file. Some example of security descriptor files are shown here.

The following security descriptor file specifies that the clients must use GSI secure message with privacy:

<?xml version="1.0" encoding="UTF-8"?>
<securityConfig xmlns="http://www.globus.org">
   <auth-method>
     <GSISecureMessage>
        <protection-level>
          <privacy/>
        </protection-level>
     </GSISecureMessage>
   </auth-method>
   <authz value="none"/>
</securityConfig>

The following security descriptor file specifies that the clients must use transport level security with privacy:

<?xml version="1.0" encoding="UTF-8"?>
<securityConfig xmlns="http://www.globus.org">
   <auth-method>
     <GSITransport>
        <protection-level>
          <privacy/>
        </protection-level>
     </GSITransport>
   </auth-method>
   <authz value="none"/>
</securityConfig>

The following security descriptor file specifies that the clients must use GSI secure conversation with either integrity or privacy:

<?xml version="1.0" encoding="UTF-8"?>
<securityConfig xmlns="http://www.globus.org">
   <auth-method>
     <GSISecureConversation>
        <protection-level>
          <integrity/>
          <privacy/>
        </protection-level>
     </GSISecureConversation>
   </auth-method>
   <authz value="none"/>   
   <run-as>
     <caller-identity/>
   </run-as>
</securityConfig>

The run-as element specifies that requests should be run using the caller's identity. This is essential if delegation is to be used so that the OGSA-DAI service can call other services as if it were the original caller. Some OGSA-DAI activities such as DeliverToGFTP, ObtainFromDataSource and DeliverToDataSink require the use of delegation.

Note that all these example security descriptors specify no authorization. Authorization configuration will be covered below in Section 38.4, “Configuring authorization”.

The security descriptor files can be saved anywhere in the file system but it is sensible to place them in the OGSA-DAI server.

When using the GT container a sensible place is the following directory:

$GLOBUS_LOCATION/etc/dai/

When using Tomcat a sensible place is the following directory:

$CATALINA_HOME/webapps/wsrf/WEB-INF/etc/dai/

The final piece of the authentication configuration is to link the services to the security descriptors. To do this you need to edit the server-config.wsdd file that contains the OGSA-DAI services (note that this is a different file from the file with that same name that you edited before (in Section 38.1, “Configuring certificates”).

$CATALINA_HOME/webapps/wsrf/WEB-INF/etc/dai/server-config.wsdd

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

This file contains an entry for each of the OGSA-DAI services. To associate a security descriptor you need to add a new parameter element to the service element of the service you want to secure. An example parameter element is (remember to replace PATH with the full file path to your file):

<parameter 
    name="securityDescriptor" 
    value="PATH/my_security_descriptor.xml"/>

As an example the service entry for the data request execution service looks something like:

<service name="DataRequestExecutionService" provider="Handler" 
         use="literal" style="document">
  <parameter name="allowedMethodsClass" 
             value="uk.org.ogsadai.service.gt.execution.GTDataRequestExecutionServicePortType"/>
  <parameter name="className"
             value="uk.org.ogsadai.service.gt.execution.GTDataRequestExecutionService"/>
  <wsdlFile>share/schema/ogsadai/gt-specific-wsdl/dres/data_request_execution_service_service.wsdl</wsdlFile>
  <parameter name="handlerClass" 
             value="org.globus.axis.providers.RPCProvider"/>
  <parameter name="scope" value="Application"/>
  <parameter name="loadOnStartup" value="true"/>
  <parameter name="providers" 
             value="GetRPProvider GetMRPProvider QueryRPProvider"/>
  <parameter name="securityDescriptor" 
             value="/home/user/my_security_descriptor.xml"/>
  <typeMapping deserializer="org.apache.axis.encoding.ser.BeanDeserializerFactory"
               encodingStyle=""
               qname="dai:DataType"
               serializer="uk.org.ogsadai.service.gt.types.ODBeanSerializerFactory"
               type="java:uk.org.ogsadai.service.gt.types.DataType" 
               xmlns:dai="http://ogsadai.org.uk/namespaces/2007/04/types"/>
</service>

If using the GT container, note that it cannot support both transport level and message level security at the same time. To use message level security the container must be started using the -nosec flag to globus-start-container.

The implementation and configuration of authorization within an OGSA-DAI server will vary from user to user and depends on the security model required by the user. Over time the OGSA-DAI team hope to expand the range of authorization components bundled with OGSA-DAI. Currently this range is fairly limited and it is likely that users will have to develop their own plug-in security components. For this reason an in-depth discussion of developing application-specific authorization components is included in the developer documentation (see Chapter 126, Introduction to authorization components for OGSA-DAI GT) rather than here.

When using the Globus Toolkit any authorization model should be based on the use of policy information points (PIPs) and policy decision points (PDPs). Policy information points are used to discover information about the request or caller. This information is ultimately used by policy decisions points to determine if the request can be authorized. For more details on PIPs and PDPs see the Globus Toolkit documentation.

Here we will describe how you can configure OGSA-DAI authorization so that all dynamically created resources (e.g. request resources, sessions, data sinks and data sources) can only be accessed by the client that created them. It is possibly that this solution may form a part of your project's overall authorization strategy.

Our simple authorization model makes use of the following OGSA-DAI components:

First you need to declare the resource authorizer to the OGSA-DAI server. The resource authorizer has the following attributes:

To declare the resource authorizer, you simply have to add the following XML fragment within the global element of the OGSA-DAI JNDI configuration file

$CATALINA_HOME/webapps/wsrf/WEB-INF/etc/dai/jndi-config.xml

$GLOBUS_LOCATION/etc/dai/jndi-config.xml

The XML is:

<resource 
  name="ogsadai/misc/uk.org.ogsadai.resource.authorizer"
  type="uk.org.ogsadai.authorization.SimpleResourceAuthorizer">
    <resourceParams>
       <parameter>
          <name>factory</name>
          <value>org.globus.wsrf.jndi.BeanFactory</value>
       </parameter>
    </resourceParams>
</resource>

You now need to specify the PIPs and PDPs to use when authorizing requests to the data request execution service. The Resource Authorizer PDP is used to determine if the caller is authorized to access the resources specified in the workflow. This needs to be preceded by the DN PIP and the Resource IDs PIP to collect the information required by the PDP. You now need to declare this security chain in a authz element of a security descriptor. You saw security descriptors earlier in Section 38.3, “Configuring authentication methods and levels”. Here is an example with the OGSA-DAI authorization chain added.

<?xml version="1.0" encoding="UTF-8"?>
<securityConfig xmlns="http://www.globus.org">
  <authz 
     value="DNPIP:uk.org.ogsadai.service.gt.security.authorization.DNPIP 
            WorkflowResourceIDsPIP:uk.org.ogsadai.service.gt.security.authorization.WorkflowResourceIDsPIP 
            ResourceAuthorizerPDP:uk.org.ogsadai.service.gt.security.authorization.ResourceAuthorizerPDP"/>
  <auth-method>
    <GSISecureConversation>
       <protection-level>
         <privacy/>
       </protection-level>
    </GSISecureConversation>
   </auth-method>
</securityConfig>

Save this security descriptor to a file called DRES_security_descriptor.xml. Note that the authentication method used here is just an example. Any authentication method can be used. What is important is the authorization chain specified by the authz element.

To configure the data request execution service to use this security descriptor you must alter the configuration for the service in the server-config.wsdd file to refer to this new security descriptor. Additionally you must specify a parameter for the resource authorizer PDP to tell it to authorize all access to any unknown resources. This is required because the authorizer will only be aware of the dynamically-created resources but we still want clients to be able to access the existing data resources unknown to the authorizer. To do this the service element that corresponds to the data request execution service should contain XML fragments like the following:

<parameter name="securityDescriptor" 
           value="/PATH/TO/DRES_security_descriptor.xml"/>
<parameter name="ResourceAuthorizerPDP-AuthorizeUnknownResources"
           value="true"/>

Now that you have configured the authorization chain for the data request execution service you now have to configure the authorization chain for the other services. Requests to these services could be targeted at one of the dynamically created resources. Again we wish to the Resource Authorizer PDP to determine if the caller is authorized to use the specified resource. As before we use the DN PIP to obtain the caller's distinguished name but this time we can use the Resource ID PIP to obtain the ID of the resource the request is targeted at. To specify this authorization chain the following security descriptor can be used:

<?xml version="1.0" encoding="UTF-8"?>
<securityConfig xmlns="http://www.globus.org">
  <authz 
     value="DNPIP:uk.org.ogsadai.service.gt.security.authorization.DNPIP 
            ResourceIDPIP:uk.org.ogsadai.service.gt.security.authorization.ResourceIDPIP 
            ResourceAuthorizerPDP:uk.org.ogsadai.service.gt.security.authorization.ResourceAuthorizerPDP"/>
  <auth-method>
    <GSISecureConversation>
       <protection-level>
         <privacy/>
       </protection-level>
    </GSISecureConversation>
   </auth-method>
</securityConfig>

Save this security descriptor to a file called dynamic_security_descriptor.xml. Note that the authentication method used here is just an example. Any authentication method can be used. What is important is the authorization chain specified by the authz element.

Finally, you have to configure the appropriate services to use this security descriptor. To do this simply edit the server-config.wsdd so that this is the security descriptor associated with the following services:

The data resource information service should continue to refer to a security descriptor that specifies no authorization. This is because this authorization example only performs authorization on the dynamically-created resources that are exposed by the above list of services.