Client security descriptors are configured as shown below:

// Client security descriptor file 
String CLIENT_DESC = "org/globus/wsrf/samples/counter/client/client-security-config.xml";
//Set descriptor on Stub 
((Stub)port)._setProperty(Constants.CLIENT_DESCRIPTOR_FILE, CLIENT_DESC);

The client security descriptor files need to comply with the client security descriptor schema.

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):

<securityConfig xmlns="http://www.globus.org">
   ...
   <credential>
      <key-file value="keyFile"/>
      <cert-file value="certFile"/>
   </credential>
   ...
</securityConfig>

Example for option (b):

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

The framework will look for credentials in the following order:

The container and each service can be configured with a separate grid map file in each of their security descriptors as shown below:

<securityConfig xmlns="http://www.globus.org">
   ...
   <gridmap value="gridMapFile"/>
   ...
</securityConfig>

The framework will first look for a gridmap configured by the resource, then by the service and then by the container. For services configured to perform grid map file authorization, the grid map file can be updated dynamically using the SecurityManager API. Also, if the gridmap file changes at runtime it will be automatically reloaded.

This can only be done at service or resource level.

The authentication methods a service requires are specified using the <auth-method> element. The authentication methods can also be configured on a per method basis. This is done by specifying the <auth-method> element within a <method name="operation name"> element. The value of the name attribute can be set to either the operation name (preferred) or the operation name with a given namespace.

Currently, the following authentication methods are supported:

Notes:

Example:

<securityConfig xmlns="http://www.globus.org">

   <method name="findServiceData">
      <auth-method>
         <none/>
      </auth-method>
   </method>

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

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

In the above example:

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. Currently, the following run-as identities are supported:

Notes:

Example:

<securityConfig xmlns="http://www.globus.org">
   <method name="add">
      <run-as>
         <caller-identity/>
      </run-as>
   </method>

   <method name="subtract">
      <run-as>
         <system-identity/>
      </run-as>
   </method> 
   
   <!-- default run-as for any other method -->
   <run-as> 
      <service-identity/>
   </run-as>
</securityConfig>

In the above example:

The container and each service can be configured with a chain of authorization mechanisms (also known as Policy Decision Points (PDPs)), using the authz element. Each PDP name is scoped and the format is prefix:FQDN of the PDP. For example, self:org.globus.wsrf.impl.security.authorization.SelfAuthorization. The prefix is used to allow multiple instances of the same PDP to exist in the same PDP chain. The authorization is deemed to be a permit if each of the authorization mechanisms in the chain returns a permit.

Example:

<securityConfig xmlns="http://www.globus.org">
   ...
   <authz value="foo1:org.foo.authzMechanism bar1:org.bar.barMechanism"/>
   ...
<securityConfig/>

Each PDP is instantiated with some configuration information that can be used to get any further information that the PDP may need to make authorization decisions. If the authorization chain is configured at the container level, then the parameters are picked up from the global configuration section of the container deployment descriptor. If the authorization chain is configured at the service level, the PDPs will pick up parameters from the relevant service section of the deployment descriptor. Resource level configuration has to be done programmatically and is described here. In all three cases, the prefix specified in the authorization chain configuration is used to get the right property. For example, all properties for foo1:org.foo.authzMechanism are picked up from properties that have been scoped with the prefix foo1-.

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 3.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 foo1-authorizedIdentity in the above configures the identity the PDP uses for authorizing incoming requests. The parameter name is derived by composing the prefix (foo1) used when specifying the PDP in the security descriptor with the property (authorizedIdentity) used in the PDP code.

Client side credentials are configured similar to server side credentials as described in Section 3.1, “Configuring credentials”.

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:

  <securityConfig xmlns="http://www.globus.org">
     ...
     <authz value="self"/>
     ...
  </securityConfig>

	Note
	Custom client authorization schemes can be written and plugged in. But security descriptors cannot be used to configure such authorization schems. Refer to Section 5, “Semantics and syntax of domain-specific interface” for information on writing custom client-side authorization scheme.

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:

  <securityConfig xmlns="http://www.globus.org">
     ...
     <GSISecureConversation>
         <privacy/>
         <delegation value="full"/>
     </GSISecureConversation>
     ...
  </securityConfig>

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:

  <securityConfig xmlns="http://www.globus.org">
     ...
     <GSISecureMessage>
         <integrity/>
     </GSISecureMessage>
     ...
  </securityConfig>