GT4 WS AA Admin Guide

Home -> Toolkit -> Docs -> 4.0 -> Security -> Authzframe	Website Email Lists Search:

Table of Contents

1. Introduction

2. Building and Installing

3. Configuring

3.1. Configuration overview
3.2. Syntax of the interface

4. Deploying

5. Testing

6. Security Considerations

6.1. Client side authorization
6.2. Host authorization

7. Troubleshooting

1. Introduction

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.0 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 Security Descriptors document describes how to configure an authorization mechanism, as well as the configuration required for each of the mechanisms that are distributed with GT 4.0.

2. Building and Installing

This component is built and installed as a part of Java WS Core.

3. Configuring

3.1. Configuration overview

The authorization framework can be configured at the resource, service or container level. Configuration settings are specified in security descriptors. The descriptors can be read from a file or can be created programmatically. Refer to Configuring Client Security Descriptor for more details.

Authorization configuration involves setting a chain of authorization schemes (also known as Policy Decision Points (PDPs)). When an authorization decision needs to be made the PDPs in the chain are evaluated in turn to arrive at a permit or deny decision. The combining rule for results from the individual PDPs is currently "deny overrides"; that is, all PDPs have to evaluate to permit for the chain to evaluate as permit.

3.2. Syntax of the interface

Refer to Section 4.2, “Configuring authorization mechanism ”.

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 the Java WS Core Developer's Guide. To ensure that only security tests are run, set -DsecurityTestsOnly=true.

By default the tests require that the container and the tests are using 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 and AuthzCalloutTestService that specifies self authorization.

<!-- Does self authz by default -->

<!-- parameter name="securityDescriptor" 
    value="@config.dir@/security-config.xml"/ -->

Uncomment the configuration for identity authorization and set the value of the property idenAuthz-identity to the subject DN of the credentials used to run the tests.

<!-- For use only when identity authz is used-->

<parameter name="securityDescriptor" 
    value="@config.dir@/identity-security-config.xml"/>

<parameter name="idenAuthz-identity" 
    value="Identity used by client"/>

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/key"
       -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.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.