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:

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

If using Tomcat save this file to:

We 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

If you are using Tomcat this file will be at:

Edit this file and add the following lines inside the <globalConfiguration> element:

<parameter name="containerSecDesc"
           value="/PATH/TO/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
	If using Tomcat, option 4 is not applicable.

	Note
	If using Windows: Option 1 did not appear to work in our testing. Option 2 translates into the Windows file system as: C:\Documents and Settings\USER\.globus. Option 3 has no Windows equivalent.

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 we have decided on the authorization level suitable for our installation we 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 in Section 14.1.4, “Configuring authorization”.

The security descriptor files can be saved anywhere in the file system but it is sensible to place them close to the rest of the OGSA-DAI configuration. When using the GT container a sensible place is the following directory:

When using Tomcat a sensible place is the following directory:

The final piece of the authentication configuration is to link the services to the security descriptors. To do this we 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 we edited in Section 14.1.1, “Configuring certificates”). If using the GT container this file is at:

If using Tomcat this file is at:

This file contains an entry for each of the OGSA-DAI services. To associate a security descriptor we need to add a new parameter element to the service element. An example parameter element is:

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

As an example the service entry for the data request execution service should look 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="/PATH/TO/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>

It is useful to note that the GT container 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 the globus-start-container program.

The implementation and configuration of authorization within an OGSA-DAI installation varies from project to project and depends on the security model adopted by the project. 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 any project using OGSA-DAI will have to develop their own plug-in security components. For this reason an in-depth discussion of authorization issues is included in the developer documentation (see Chapter 34, Authorization in OGSA-DAI GT) rather than here in the administrator documentation.

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 to configure OGSA-DAI authorization so that all dynamically created resources (request resources, session resources, data sink resources and data source resources) can only be accessed by the client that created them. It is possibly that this solution may form a part of a project's overall authorization strategy.

Our authorization model makes use of the following components:

We wish to add the resource authorizer as a plug-in object to the OGSA-DAI context. This plug in object has the following details:

Section 18.9.1, “Specifying miscellaneous objects” describes how to add miscellaneous objects to the OGSA-DAI context. We simply have to add the following XML fragment to the OGSA-DAI JNDI configuration file:

<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>

We now need to specify the PIPs and PDPs to use when authorizing requests to the data request execution service. We wish to use the Resource Authorizer PDP to determine if the caller is authorized to access the resources specified in the workflow. We need to precede this PDP by the DN PIP and the Resource IDs PIP to ensure we gather the information required by the PDP. To do this we need a security descriptor for the data request execution service that specifies this authorization chain. The security descriptor has the following contents:

<?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 we must alter the configuration for the service in the server-config.wsdd file to refer to this new security descriptor. Additionally we 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 the user to be able to access the static 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 we have configured the authorization chain for the data request execution service we now have to configure the authorization chain for the other services. Requests to these services must 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 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, we 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.