This guide contains advanced configuration information for system administrators working with the Authorization Framework. It provides references to information on procedures typically performed by system administrators, including installing, configuring, deploying, and testing the installation.

	Important
	This information is in addition to the basic Globus Toolkit prerequisite, overview, installation, security configuration instructions in the GT 4.1.1 System Administrator's Guide. Read through this guide before continuing!

This component determines the authorization enforced on the server and the client side. Admin configuration could include determining the container/service level authorization mechanism and setting up and managing authorization policy, e.g. entries in grid map file and so on.

The Section 3, “Configuring ” describes how to configure an authorization mechanism.

2. Building and Installing

This component is built and installed as a part of Java WS Core. See "Building and Installing" in the Java WS Core Admin Guide for more information.

3. Configuring

3.1. Configuration overview

Security descriptors are mechanism used to configure authorization mechanism and policy. The authorization on the server side cna be configued at container, service or resource level.

On the client side, authorization can be configured using security descriptors or as property on the stub. This configuration can be done on a per invocation granularity

3.2. Syntax of the interface

The server side authorization can be configured at container, service or resource level using

Security descriptors using files. Refer to Section 3.1, “Configuring Using Files”
Security descriptors programmatically. Refer to Section 3.2, “Configuring Programmatically ”

To write and configure server-side custom authorization mechanism refer to Section 4.6.2.3, “Writing a custom server-side authorization mechanism”.

The client side authorization can be configured for each invocation.

Security descriptors using files. Refer to Section 4.1, “Configuring Using Files”, specifically Section 4.1.2.2, “Configuring authorization mechanism ”.
Security descriptors programmatically. Refer to Section 4.2, “Configuring Programmatically ”
Properties on the Stub. Refer to Section 4.6.2.1, “Configuring client-side authorization on the stub”

To write and configure custom authorization mechanism refer to Section 4.6.2.2, “Writing custom client-side authorization scheme”.

If no authorization mechanism has been specified, HostOrSelf authorization is used. In this scheme host authorization is tried first, if it fails, self authorization is attempted

4. Deploying

This component is deployed as a part of Java WS Core.

5. Testing

To execute security tests ensure that Ant with JUnit is configured.

All the security tests require a valid credential. Refer to Security section of GT Administrator guide for details on acquiring credentials.

The security tests are included in $GLOBUS_LOCATION/lib/wsrf_test_unit.jar. This jar contains tests for both the Java WS Core component and the WS Authentication and Authorization components contained in the Java WS Core package.

To execute the tests, pass the above jar file to the test script as described in Section 5.4.2, “Running Tests”. To ensure that only security tests are run, set -DsecurityTestsOnly=true.

By default the tests require that the container and the tests use the same credentials, i.e self authorization is done on secure calls.

The tests allow for another configuration in which the container can be configured with host credentials and the tests can be run with any credentials.

Configure the container to use host credentials using the security descriptor as described in the container descriptor section.
Edit $GLOBUS_LOCATION/etc/globus_wsrf_test_unit/server-config.wsdd.
- Comment out the configured descriptor in SecurityTestService, RPParamTestService and AuthzCalloutTestService that specifies self authorization.
```



```
- Uncomment the configuration for identity authorization.
```


<parameter name="securityDescriptor" 
    value="@config.dir@/identity-security-config.xml"/>
```
- In $GLOBUS_LOCATION/etc/globus_wsrf_test_unit/identity-security-config.xml, set the value of the property identity to the subject DN of the credentials used to run the tests.
```


<param:parameter name="identity" 
    value="Identity used by client"/>
```

Edit $GLOBUS_LOCATION/etc/globus_wsrf_test_unit/test-container-security-config.xml to add the following element, before <reject-limited-proxy value="true"/>

    <credential>
      <cert-key-files>
        <key-file value="path to container key"/>
        <cert-file value="path to container cert"/>
      </cert-key-files>
    </credential>

Start a secure and insecure standalone container.

    $ cd $GLOBUS_LOCATION
    $ bin/globus-start-container -nosec

On another window,

    $ cd $GLOBUS_LOCATION
    $ bin/globus-start-container

To run tests against external containers, secure and insecure, on localhost ports 8180 and 8181 respectively, the command would be:

ant -f share/globus_wsrf_test/runtests.xml runServer 
       -Dtests.jar=$GLOBUS_LOCATION/lib/wsrf_test_unit.jar 
       -DsecurityTestsOnly=true
       -Djunit.jvmarg=-Dsecurity.test.client.authz=host 
       -Dsecurity.test.authz.identity="container/suject/DN" 
       -Dsecurity.test.enc.cred="/server/public/certificate"
       -Dsecurity.test.server.cert="/server/public/certificate/file"
       -Dsecurity.test.server.key="/server/key/file"
       -Dtest.server.url=http://127.0.0.1:8181/wsrf/services/ 
       -Dsecure.test.server.url=https://127.0.0.1:8180/wsrf/services/

For example, if the container security descriptor has credentials configured as /etc/grid-security/containercert.pem and /etc/grid-security/containerkey.pem and the DN of the credential is /DC=org/OU=Services/CN=-testDN/CN=some.host.edu, the command to run would be:

ant -f share/globus_wsrf_test/runtests.xml runServer 
       -Dtests.jar=$GLOBUS_LOCATION/lib/wsrf_test_unit.jar 
       -DsecurityTestsOnly=true 
       -Djunit.jvmarg=-Dsecurity.test.client.authz=host 
       -Dtest.server.url=http://127.0.0.1:8181/wsrf/services/ 
       -Dsecure.test.server.url=https://127.0.0.1:8180/wsrf/services/ 
      -Dsecurity.test.authz.identity="/DC=org/OU=Services/CN=-testDN/CN=some.host.edu" 
       -Dsecurity.test.server.cert="/etc/grid-security/containercert.pem"
       -Dsecurity.test.server.key="/etc/grid-security/containerkey.pem"
    -Dsecurity.test.enc.cred=/etc/grid-security/containercert.pem

6. Security Considerations

6.1. Client side authorization

Client authorization of the server is done after the completion of the operation when GSI Secure Message authentication is used. If you require client authorization to be done prior, use GSI Secure Conversation or GSI Transport security.

6.2. Host authorization

During host authorization, the toolkit treats DNs "hostname-*.edu" as equivalent to "hostname.edu". This means that if a service was setup to do host authorization and hence accept the certificate "hostname.edu", it would also accept certificates with DNs "hostname-*.edu".

The feature is in place to allow a multi-homed host folowing a "hostname-interface" naming convention, to have a single host certificate. For example, host "grid.test.edu" would also accept likes of "grid-1.test.edu" or "grid-foo.test.edu".

	Note
	The wildcard character "*" matches only name of the hostand not domain components. This means that "hostname.edu" will not match "hostname-foo.sub.edu", but will match "host-foo.edu".

	Note
	If a host was set up to accept "hostname-1.edu", it will not accept any of "hostname-*.edu".

A bug has been opened to see if this feature needs to be modfiied.

7. Troubleshooting

Prev	Up	Next
GT4 WS AA Authorization Framework Release Notes	Home	GT4 WS AA User's Guide