Table of Contents
This guide contains advanced configuration information for system administrators working with the Delegation Service. It provides references to information on procedures typically performed by system administrators, including installation, configuring, deploying, and testing the installation.
![[Important]](../../../../../docbook-images/important.gif) | Important |
|---|---|
This information is in addition to the basic Globus Toolkit prerequisite, overview, installation, security configuration instructions in the GT 4.0 System Administrator's Guide. Read through this guide before continuing! |
Refer to System Administrator's guide for installation instructions.
The security settings for Delegation Factory Service and Delegation Service can be configured by modifying the security descriptors. The descriptors allow for configuring the credentials that will be used by the services and the type of authentication and message protection required, as well as the authorization mechanism.
By default, the following configuration is installed:
Delegation Factory Service:
- Credentials are determined by the container level security descriptor. If there is no container level security descriptor or if it does not specify what credentials to use then default credentials are used.
- Authentication and message integrity protection is enforced for the
requestSecurityTokenoperation. Other operations do not require authentication. This means that you may use any of GSI Transport, GSI Secure Message or GSI Secure Conversation when invoking therequestSecurityTokenoperation on the delegation factory service. - Access is authorized using the grid map mechanism and no grid map is configured in the service by default. If a grid map is configured in the container level security descriptor, it is used. To configure a grid map file for this service refer to instructions in the next section.
Delegation Service
- Credentials are determined by the container level security descriptor. If there is no container level security descriptor or if it does not specify what credentials to use then default credentials are used.
- Authentication and message integrity protection is enforced for all operations. This means that you may use any of GSI Transport, GSI Secure Message or GSI Secure Conversation when interacting with the delegation service.
- Access to resources managed by the Delegation Service is managed using the gridmap mechanism. The gridmap used is resource specific and is populated with the subject of the client that originally created the resource. This implies that only the user who delegated can access (and refresh) the delegated credential.
![[Note]](../../../../../docbook-images/note.gif) | Note |
|---|---|
Changing required authentication and authorization methods will require corresponding changes to the clients that contact this service. |
| Important |
|---|---|
If the service is configured to use GSI Secure Transport, then container credentials are used for the handshake, irrespective of whether service level credentials are specified. |
To alter the security descriptor configuration refer to Security Descriptors.
To alter the security configuration of the Delegation Factory Service,
edit the file
$GLOBUS_LOCATION/etc/globus_delegation_service/factory-security-config.xml.
| Note |
|---|---|
To either specify a gridmap file different from the container level configuration or to add one if the container security descriptor does not specify one, the following needs to be added to the Delegation Factory security descriptor. <securityConfig xmlns="http://www.globus.org">
.
.
.
<gridmap value="path/to/gridmap/file"/>
</securityConfig> |
To alter the security configuration of the Delegation Service, edit the file
$GLOBUS_LOCATION/etc/globus_delegation_service/service-security-config.xml
The Delegation Service is deployed as part of a standard toolkit installation. Please refer to the System Administrator's Guide for details.
Delegation Service has been tested to work without any additional setup when deployed into Tomcat. Please follow these basic instructions to deploy GT4 services into Tomcat. Note that the Java WS Core module needs to be built and configured as described in the previous sections.
- Install the Delegation Service test package (gt4-cas-delegation-test-4.0.1-src_bundle.tar.gz) using GPT build.
To run the tests do:
$ cd $GLOBUS_LOCATION $ ant -f share/globus_wsrf_test/runtests.xml runServer \ -Dtests.jar=$GLOBUS_LOCATION/lib/globus_delegation_test.jar \ -Djunit.jvmarg="-Dorg.globus.wsrf.container.server.id=delegationTest"- The test report can be found in
$GLOBUS_LOCATION/share/globus_wsrf_test/tests/test-reports/TEST-org.globus.delegation.service.PackageTests.xml.
The current design re-uses the keys associated with the delegation service for each of the proxy certificates delegated to it. During a security review it was pointed out that while this was fine from a cryptographic standpoint, compromising this single long lived key pair may significantly extend the time for which a single intrusion (presuming an exploitable security flaw making the intrusion possible) is effective.
This can be remedied by either frequently regenerating the key pair used by the delegation service, which can be accomplished with a simple cron job, or by generating a new key pair for each new delegation. The later of these approaches requires changes to the design and may be adopted in future versions of the toolkit. For the time being we recommend the former approach should this issue concern you.
The delegation client that is distributed with the toolkit allows for delegation of credentials even when no authorization of the server is done. Also, when using secure message authentication the authorization of the server is done after the completion of the operation. These two scenarios could lead to the delegation of credentials to a malicious server.
To prevent this users should use secure transport (HTTPS) or GSI secure conversation and appropriate client side authorization.
Refer to the Globus Toolkit Administrator Guide - Security Overview troubleshooting section for details on some common security installation issues.
Also, for security related troubleshooting the CoG FAQ might prove useful (especially sections on configuring credentials, CAs and so on).