The container and each service can each be configured with a separate set of credentials. The credentials can be set using either: a) the path to a proxy file, or b) the path to a certificate and key file. If the configured credential file is modified/updated at runtime, the credentials will be automatically reloaded. The credentials can be configured by adding one of the following blocks to the container or service security descriptor.

Example for option (a):

<serviceSecurityConfig xmlns="http://www.globus.org/descriptor/server">
   ...
   <proxy-file value="proxyFile"/>
   ...
</serviceSecurityConfig>

Example for option (b):

<serviceSecurityConfig 
            xmlns="http://www.globus.org/security/descriptor/service">
   ...
   <credential>
       <cert-key-files>
              <key-file value="keyFile"/>
              <cert-file value="certFile"/>
       </cert-key-files>
   </credential>
   ...
</serviceSecurityConfig>

	Note
	The above examples show use of service security descriptor. If setting in container security descriptor, set namespace and outer element as shown in Section 4, “ Security Descriptor Schemas ”.

Credentials can be configured at resource, service or container level and the framework will look for credentials in the following order:

For message level security one may also set the amount of time for which to track received messages for the purpose of preventing replay attacks. Messages outside of this window will be rejected automatically, whereas messages within this window are checked against recently received messages through the use of the message UUID.

	Note
	The above examples show use of service security descriptor. If setting in container security descriptor, set namespace and outer element as shown in Section 4, “ Security Descriptor Schemas ”.

This parameter can be used to configure if clients that present limited proxies can be allowed to authenticate successfully. By default, limited proxes are accepted.

<serviceSecurityConfig 
            xmlns="http://www.globus.org/security/descriptor/service">
   ...
       <reject-limited-proxy value="true"/>
   ...
</serviceSecurityConfig>

	Note
	The above examples show use of service security descriptor. If setting in container security descriptor, set namespace and outer element as shown in Section 4, “ Security Descriptor Schemas ”.

When GSI Secure Conversation is used, a security context is established and by default the life of the context is determined by the least lifetime of the chain of certificates used in establishing the context. The value of the lifetime can be altered to be lesser than the above value by setting the value for following parameter in milliseconds.

<serviceSecurityConfig 
            xmlns="http://www.globus.org/security/descriptor/service">
   ...
       <context-lifetime value="1000"/>
   ...
</serviceSecurityConfig>

	Note
	The above examples show use of service security descriptor. If setting in container security descriptor, set namespace and outer element as shown in Section 4, “ Security Descriptor Schemas ”.

The container and each service/resource can be configured with a chain of interceptor, where each interceptor is a Policy Decision Points (PDPs) or Policy Information Points (PIPs). The element authzChain can be used to configure it.

The following PDPs are a part of the toolkit and are configured as shown. The framework maps and plugs in the scoped name of the PDP at the time of authorization.

Other than these, any custom authorization scheme could be configured with its own configuration information. Refer to Section 5.6, “Writing a custom authorization mechanism”, for details on writing a custom authorization mechanism.

The authorization handler can be configured to call out to a custom authorization class. The class must implement the interface org.globus.wsrf.security.PDP.

Example:

package org.foobar;

import ....;

public class FooPDP implements PDP
{
    private Principal authorizedIdentity;

    /* Not used by the current code */
    public String[] getPolicyNames() {
        return new String[0];
    }

    /* Not used by the current code */
    public Node getPolicy(Node query)
        throws InvalidPolicyException {
        return null;
    }

    /* Not used by the current code */
    public Node setPolicy(Node policy)
        throws InvalidPolicyException {
        return null;
    }

    public boolean isPermitted(Subject peerSubject,
                               MessageContext context,
                               QName operation)
        throws AuthorizationException {

        if (peerSubject == null) {
            return false;
        }

        Set peerPrincipals = peerSubject.getPrincipals();

        if ((peerPrincipals == null) || peerPrincipals.isEmpty()) {
            return false;
        }

        /* Check if the peer identity and the authorized
         * identity match
         */

        return peerPrincipals.contains(this.authorizedIdentity);
    }

    public void initialize(PDPConfig config,
                           String name,
                           String id)
        throws InitializeException {

        /* Read the initialization information from the service
         * specific WSDD parameter <name>-authorizedIdentity
         */

        this. authorizedIdentity =
            new GlobusPrincipal((String) config.getProperty(
                name, "authorizedIdentity"));
    }

    public void close() throws CloseException {
        this. authorizedIdentity = null;
    }
}

To use the above PDP one would configure a service security descriptor with the following authorization settings:

<securityConfig xmlns="http://www.globus.org">
   ...
   <authz value="foo1:org.foobar.FooPDP"/>
   ...
<securityConfig/>

This security descriptor (identified as /.../foo-pdp-security-config.xml below) can then be used by a service. The association is created by adding a couple of parameters to the service's WSDD entry:

...
<service name="MyDummyService" 
             provider="Handler" 
             style="document">
   ...
   <parameter name="securityDescriptor" 
                     value="/.../foo-pdp-security-config.xml"/>
   <parameter name="foo1-authorizedIdentity" 
                     value="/DC=org/DC=doe/OU=People/CN=John D"/>
   ...
</service>

Note that the parameter <parameter>foo1-authorizedIdentity</parameter> in the above configures the identity the PDP uses for authorizing incoming requests. The parameter name is derived by composing the prefix (<parameter>foo1</parameter>) used when specifying the PDP in the security descriptor with the property (<parameter>authorizedIdentity</parameter>) used in the PDP code.

Other than the container/service/resource authorization, a administrative level authorization chain can be configured using the <adminAuthz> element. The decision returned by this chain, overrides subsequent authorization decision. That is, if the administator's authorizaiton chain returns a deny, the rest of the configured authorization (at container/service/resource) is not evaluated and the operation is denied. If the the administattor's chain returns the permit, the rest of the configuration is evaluated to see if the operation is allowed.

The element has the same schema as described in Section 5.5, “Configuring authorization mechanisms”, with the outer element called adminAuthz in palce of authzChain.

Example:

<containerSecurityConfig 
            xmlns="http://www.globus.org/security/descriptor/container">
   ...
<adminAuthz>

   <pips>
	<interceptor name="scope2:org.globus.sample.PIP1"/>
   </pips>
   <pdps>
        <interceptor name="foo1:org.foo.authzMechanism bar1:org.bar.barMechanism"/>
   </pdps>

</adminAuthz>
   ...
<containerSecurityConfig/>

This element is used to configure default properties for any interceptor configured in authorization chains. The schema for this is similar to the authorization chain specification as described in Section 5.5, “Configuring authorization mechanisms” and allows for xsd:any as interceptor parameter.

<defaultAuthzParam>
	<interceptor name="scope1:org.globus.sample.SamplePDP"/>
                    <parameter>
                        <param:nameValueParam>
                            <param:parameter name="policy-file" 
                                            value="/home/user1/samplePDPConfig"/>
                        </param:nameValueParam>
                    </parameter>
	</interceptor>
</defaultAuthzParam>

When GSI Secure Conversation is used, a security context is established and a worker thread cleans up expired contexts. This parameter sets the interval on the timer thread that collects expired contexts established when GSI Secure Conversation is used. The value is the number of seconds between each run and defaults to 10minutes.

<containerSecurityConfig 
            xmlns="http://www.globus.org/security/descriptor/container">
   ...
       <context-timer-interval value="100000"/>
   ...
</containerSecurityConfig>

This parameter sets the interval on the timer thread that collects expired message digest ids, stored to prevent replay attack in the case of Secure Message. The value is set in seconds and the default value is 1 minute.

<containerSecurityConfig 
            xmlns="http://www.globus.org/security/descriptor/container">
   ...
       <replay-timer-interval value="100"/>
   ...
</containerSecurityConfig>

This parameter sets location of trusted certificates to be used. The value should be a comma separated list of locations.

<containerSecurityConfig 
            xmlns="http://www.globus.org/security/descriptor/container">
   ...
       <trusted-certificates value="/home/user1/trustedCerts /home/user1/newCerts"/>
   ...
</containerSecurityConfig>

The authentication method required for accessing a service can be configured in the descriptor using the <auth-method> element. A per method configuration can also be done as described in Section 7.3, “Configuring per method authentication and run-as”.

Currently, the following authentication methods are supported:

Notes:

Example:

<serviceSecurityConfig xmlns="http://www.globus.org/security/descriptor/service">

   <!-- default auth-method for any other method -->
   <auth-method>
      <GSISecureConversation/>
   </auth-method>
</securityConfig>

The <run-as> element is used to configure the JAAS run-as identity under which the service method will be executed. The run-as identity can be configured on a per method basis also as described in Section 7.3, “Configuring per method authentication and run-as”. Currently, the following run-as identities are supported:

Notes:

Example:

<servicesecurityConfig xmlns="http://www.globus.org/security/descriptor/service">

   <!-- default run-as for any other method -->
   <run-as> 
      <service-identity/>
   </run-as>

</serviceSecurityConfig>

A per method configuration can be used to define expected authentication method for the method and also a run-as configuration. The element methodAuthentication is used to list all the method configuration. For each method, element method with method name as attribute needs to be used. If a method does not have such a configuration, default configuration, described in the last two sections are used.

Example

<serviceSecurityConfig 
            xmlns="http://www.globus.org/security/descriptor/service">
 ...
   <method name="findServiceData">
      <auth-method>
         <none/>
      </auth-method>
   </method>

   <method name="subtract">
      <run-as>
         <service-identity/>
      </run-as>
   </method> 

   <method name="destroy">
      <auth-method>
         <GSISecureMessage/>
         <GSISecureConversation>
            <protection-level>
               <integrity/>
            </protection-level>
         </GSISecureConversation>
      </auth-method>
   </method>

   <!-- default run-as for any other method -->
   <run-as> 
      <system-identity/>
   </run-as>

   <!-- default auth-method for any other method -->
   <auth-method>
      <GSISecureConversation/>
   </auth-method>
...
</serviceSecurityConfig>

In the above example:

Client side credentials are configured similar to server side credentials as described in Section 5.1, “Configuring credentials”. The outer element and schema for client security descriptor as described in Section 4, “ Security Descriptor Schemas ” should be used.

The <authz> element is used to determine the mechanism to use to authorize the server that is being contacted. The following values are currently supported:

The following sample configures self authorization:

  <clientSecurityConfig xmlns="http://www.globus.org/security/descriptor/client">
     ...
     <authz value="self"/>
     ...
  </clientSecurityConfig>

The client can be configured to do GSI Secure Conversation using the element <GSISecureConversation>. The following subelements can be used to set various properties

The following sample sets GSI Secure Conversation with privacy and full delegation:

  <clientSecurityConfig xmlns="http://www.globus.org/security/descriptor/client">
     ...
     <GSISecureConversation>
            <protection-level>
         <privacy/>
         <delegation value="full"/>
     </GSISecureConversation>
     ...
  </clientSecurityConfig>

The client can be configured to do GSI Secure Message using the element <GSISecureMessage>. The following subelements can be used to set various properties:

The following sample sets GSI Secure Message with integrity:

  <clientSecurityConfig xmlns="http://www.globus.org/security/descriptor/client">

     ...
     <GSISecureMessage>
         <integrity/>
     </GSISecureMessage>
     ...
  </clientSecurityConfig>

This property cannot be set using security descriptor as yet. Refer to http://bugzilla.globus.org/bugzilla/show_bug.cgi?id=4535 . If the service endpoint starts with "https", then this mechanism with integrity is configured. To configure privacy, the descriptor needs to be modify programatically.

Username/password can be used for authentication by the client. This is configured using <username> and <passwordType> element. The usernam element allows for a string to be configured and the password configuration consists of a password and a type string.

Example configuration:

  <clientSecurityConfig xmlns="http://www.globus.org/security/descriptor/client">

  <usernameType>
     <username value="tester1"/>
     <passwordType>
        <password value="TY^*(Hyu"/>
        <type value="someType"/>
     </passwordType>
  </usernameType>

  </clientSecurityConfig>

Client side trusted credentials are configured similar to container security descriptor as described in Section 6.5, “Trusted Certificates”. The outer element and schema for client security descriptor as described in Section 4, “ Security Descriptor Schemas ” should be used.

The gridmap file is a common configuration in the toolkit and is typically configured within the GridmapPDP configuration. To specify a default value to be used across the toolkit, if not specified with in the GrimapPDP configuration, the defaultAuthz element in container security descriptor is used as described in Section 6.2, “ Default Authorization Chain”.

The gridmap authorization can be specified with any prefix, but the default configuration uses "gridmapAuthz" as shown in the example below.

Example:

<containerSecurityConfig xmlns="http://www.globus.org/security/descriptor/container" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.globus.org/security/descriptor name_value_type.xsd"
xmlns:param="http://www.globus.org/security/descriptor">

<defaultAuthzParam>
   <interceptor name="gridmapAuthz:org.globus.wsrf.impl.security.GridMapAuthorization">
                    <parameter>
                        <param:nameValueParam>
                            <param:parameter name="gridmap-file"
                                            value="/etc/grid-security/grid-mapfile"/>
                        </param:nameValueParam>
                    </parameter>
		</interceptor>
</containerSecurityConfig>

If the grid map file is updated at runtime, it will be updated.