GT 3.9.4 Message/Transport-level Security: System Administrator's Guide
- Introduction
- Building and Installing
- Configuring
- Deploying
- Testing
- Security Considerations
- Troubleshooting
Introduction
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.
Building and Installing
[information about installing the component - may link to Installation Guide]
Configuring
Information on configuration settings and environment variables can be found in the public interface guide.
Deploying
Tomcat & Transport Security
To deploy into Tomcat with transport security run:cd $GLOBUS_LOCATION
ant -f share/globus_wsrf_common/tomcat/tomcat.xml deploySecureTomcat -Dtomcat.dir=<tomcat.dir>
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
- 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.
- Add a HTTPS Valve in the <Engine name="Standalone" ... > section:
<Valve className="org.globus.tomcat.catalina.valves.HTTPSValve"/>
- Add a HTTPS Connector in the <Service
name="Tomcat-Standalone"> section and update the parameters
appropriately with your local configuration:
- Tomcat 5
- 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.
- Add a HTTPS Valve in the <Engine name="Catalina" ... > section:
<Valve className="org.globus.tomcat.coyote.valves.HTTPSValve"/>
- Add a HTTPS Connector in the <Service
name="Catalina"> section and update the parameters
appropriately with your local configuration:
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
Usegrid-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
Usegrid-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 (withgrid-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.