Home -> Toolkit -> Docs -> Development -> 3.9.5 -> Security -> Message -> Admin

GT 3.9.5 Message/Transport-level Security: System Administrator's Guide

• Introduction
• Building and Installing
• Configuring
• Deploying
• Testing
• Security Considerations
• Troubleshooting

Introduction

This guide contains advanced configuration information for system administrators working with Message/Transport-level Security. It provides references to information on procedures typically performed by system administrators, including installation, configuring, deploying, and testing the installation.

This information is in addition to the basic installation instructions in the GT 3.9.5 System Administrator's Guide.

The main administration issues for this component deal with configuring credential related settings. There are multiple mechanisms for doing this:

• Security Descriptors
• Container Security Descriptor: This is the preferred mechanism.
• Service Security Descriptor
• CoG properties
• Environment variables
• Relying on default behavior. The only default behaviors available concern the proxy file and trusted certificates locations.

More information on these mechanisms can be found in the public interface guide.

Building and Installing

[information about installing the component - may link to Installation Guide]

Configuring

Configuration overview

Configuration of service side security settings can be achieved in two ways. The preferred way is to provide these settings in a security descriptor, although it is also possible to manipulate security settings via CoG properties.

Syntax of the interface

Information on the syntax of security descriptors can be found here.

Information on available CoG security properties can be found here.

Deploying

Tomcat & Transport Security

To deploy into Tomcat with transport security if there are no previous secure or non-secure deployments in this Tomcat installation run:

 $ cd $GLOBUS_LOCATION
 $ ant -f share/globus_wsrf_common/tomcat/tomcat.xml deploySecureTomcat -Dtomcat.dir=<tomcat.dir>

If you are looking at updating a existing Tomcat deployment you should run:

 $ cd $GLOBUS_LOCATION
 $ ant -f share/globus_wsrf_common/tomcat/tomcat.xml redeploySecureTomcat -Dtomcat.dir=<tomcat.dir>

Please note that doing both a non-secure and a secure deployment into the same Tomcat installation will result in a non-working deployment

In addition to the above deployment step you will also need to modify the Tomcat <tomcat_root>/conf/server.xml configuration file. In particular you will need to add the following configuration entries:

• Tomcat 4.1.x
  
  
  1. Add a HTTPS Connector in the <Service name="Tomcat-Standalone"> section and update the parameters appropriately with your local configuration:
     

     <Connector
       className="org.apache.catalina.connector.http.HttpConnector"
       port="8443" minProcessors="5" maxProcessors="75"
       enableLookups="true" authenticate="true"
       acceptCount="10" debug="1" scheme="https" secure="true">
         <Factory
            className="org.globus.tomcat.catalina.net.HTTPSServerSocketFactory"
            proxy="/path/to/proxy/file"
            cert="/path/to/certificate/file"
            key="/path/to/private/key/file"
            cacertdir="/path/to/ca/certificates/directory"/>
     </Connector>
     

     In the above the proxy, cert, key and cacertdir attributes are optional. Furthermore, proxy and the combination of cert and key are mutually exclusive.

  2. Add a HTTPS Valve in the <Engine name="Standalone" ... > section:

      <Valve className="org.globus.tomcat.catalina.valves.HTTPSValve"/>
     

• Tomcat 5.0.x
  
  
  1. Add a HTTPS Connector in the <Service name="Catalina"> section and update the parameters appropriately with your local configuration:
     

     <Connector
       className="org.globus.tomcat.coyote.net.HTTPSConnector"
       port="8443" maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
       enableLookups="false" disableUploadTimeout="true" 
       acceptCount="100"
       debug="0" scheme="https"
       proxy="/path/to/proxy/file"
       cert="/path/to/certificate/file"
       key="/path/to/private/key/file"
       cacertdir="/path/to/ca/certificates/directory"/>
     

     In the above the proxy, cert, key and cacertdir attributes are optional. Furthermore, proxy and the combination of cert and key are mutually exclusive.

  2. Add a HTTPS Valve in the <Engine name="Catalina" ... > section:
     

     <Valve className="org.globus.tomcat.coyote.valves.HTTPSValve"/>
     

Testing

[procedures for how to test the configuration. must include examples of the tests ]

Security Considerations

[describe security considerations relevant for this component]

Troubleshooting

The following are some common problems that may cause clients or servers to report that credentials are invalid:

Your proxy credential may have expired

Use grid-proxy-info to check whether the proxy has actually expired. If it has, generate a new proxy with grid-proxy-init.

The system clock on either the local or remote system is wrong

This may cause the server or client to conclude that a credential has expired.

Your end-user certificate may have expired

Use grid-cert-info to check your certificate's expiration date. If it has expired, follow your CA's procedures to get a new one.

The permissions may be wrong on your proxy file

If the permissions on your proxy file are too lax (for example, if others can read your proxy file), Globus Toolkit clients will not use that file to authenticate. You can "fix" this problem by changing the permissions on the file or by destroying it (with grid-proxy-destroy and creating a new one (with grid-proxy-init). However, it is still possible that someone else has made a copy of that file during the time that the permissions were wrong. In that case, they will be able to impersonate you until the proxy file expires or your permissions or end-user certificate are revoked, whichever happens first.

The permissions may be wrong on your private key file

If the permissions on your end user certificate private key file are too lax (for example, if others can read the file), grid-proxy-init will refuse to create a proxy certificate. You can "fix" this by changing the permissions on the private key file; however, you will still have a much more serious problem: it's possible that someone has made a copy of your private key file. Although this file is encrypted, it is possible that someone will be able to decrypt the private key, at which point they will be able to impersonate you as long as your end user certificate is valid. You should contact your CA to have your end-user certificate revoked and get a new one.

The remote system may not trust your CA

Verify that the remote system is configured to trust the CA that issued your end-entity certificate. See the [TODO: add admin guide link] for details.

You may not trust the remote system's CA

Verify that your system is configured to trust the remote CA (or that your environment is set up to trust the remote CA). See the [TODO: add admin guide link] for details.

There may be something wrong with the remote service's credentials

It is sometimes difficult to distinguish between errors reported by the remote service regarding your credentials and errors reported by the client interface regarding the remote service's credentials. If you can't find anything wrong with your credentials, check for the same conditions (or ask a remote administrator to do so) on the remote system.