The next few sections deal with writing server-side security descriptor files, that is, container, service and resource descriptor files to set various properties. Only the properties that are common to all these descriptors are discussed here. Other properties specific to each descriptor are discussed in sections specific to the container/service or resource descriptor.

When parameters are configured in multiple descriptors the order of predence as described in Section 3, “Security Descriptor Precedence”

1. Credentials

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/security/descriptor/service">
...
<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 in the service security descriptor. If setting in the container security descriptor, the namespace and outer element should also be set as shown inSection 1, “Security Descriptor Schemas”.

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

Resource credentials
Service credentials
Container credentials
Default credentials. If credentials are not configured using any of the above methods, then the underlying CoG JGlobus library is used. This will attempt to load the proxy certificate of the user that is running the container as described in Section 5, “Proxy file Location” .

2. Reject Limited Proxy

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

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

	Note
	The above example shows use in the service security descriptor. If setting in the container security descriptor, set the namespace and outer element as shown inSection 1, “Security Descriptor Schemas”. (fixme doublecheck link)

3. Replay attack prevention

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.

Parameter replay-attack-filter can be set to true or false to enable or disable replay attack prevention framework. By default, this feature is enabled.
```
<serviceSecurityConfig
     xmlns="http://www.globus.org/security/descriptor/service">
     ...
     <replay-attack-filter value="true"/>
     ...
</serviceSecurityConfig>
```

Parameter replay-attack-window can be set to the number of minutes the replay window should be. By default it is 5 minutes.

<serviceSecurityConfig
     xmlns="http://www.globus.org/security/descriptor/service">
     ...
     <replay-attack-window value="100"/>
     ...
</serviceSecurityConfig>

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

4. Context lifetime

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 less than the above value by setting the value for the following parameter in milliseconds:

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

	Note
	The above example shows use in the service security descriptor. If setting in the container security descriptor, the namespace and outer element must be set as shown inSection 1, “Security Descriptor Schemas”.

5. Authorization

The container and each service/resource can be configured with a chain of interceptors, where each interceptor is a Policy Decision Point (PDP) or Policy Information Point (PIP).Refer to Section 2, “Authorization framework overview” for details on the authorization framework. The element authzChain can be used to configure this.

Each chain can contain an optional list of Bootstrap PIPs, an optional list of PIPs and a list of PDPs (with at least one PDP).

Each interceptor name is scoped and the format is prefix:FQDN of the interceptor. For example, self:org.globus.wsrf.impl.security.authorization.SelfAuthorization . The prefix is used to allow multiple instances of the same interceptor to exist in the same PDP chain.

Example:

<serviceSecurityConfig
     xmlns="http://www.globus.org/security/descriptor/service">
     ...
     <authzChain>
         <pips>
             <interceptor name="scope2:org.globus.sample.PIP1"/>
         </pips>
         <pdps>
             <interceptor name="foo1:org.foo.authzMechanism bar1:org.bar.barMechanism"/>
         </pdps>
      </authzChain>
     ...
<serviceSecurityConfig/>

Bootstrap PIPs are optional and by default, org.globus.wsrf.impl.security.authorization.X509BootstrapPIP is used by the framework. Any other PIPs listed within the <bootstrapPips> element is appended to the default PIP. If the configuration should override it (that is, X5009BootstapPIP should not be used), the optional attribute overwrite can be set to true.

<serviceSecurityConfig xmlns="http://www.globus.org/security/descriptor/service">
    ...
    <authzChain combiningAlg="org.globus.sample.SampleAlg>
        <bootstrapPips overwrite="true"
             <interceptor name="scope1:org.globus.sample.BootstrapPIP1"/>
        </bootstrapPips>
        <pips>
             <interceptor name="scope2:org.globus.sample.PIP1"/>
        </pips>
        <pdps>
             <interceptor name="scope3:org.globus.sample.PDP1"/>
         </pdps>
     </authzChain>
     ...
</serviceSecurityConfig>

In the above case, X509BootstrapPIP will not be used and the BoostrapPIP1 will be used.

<serviceSecurityConfig
    xmlns="http://www.globus.org/security/descriptor/service">
    ...
    <authzChain combiningAlg="org.globus.sample.SampleAlg>
        <bootstrapPips>
            <interceptor name="scope1:org.globus.sample.BootstrapPIP1"/>
        </bootstrapPips>
        <pips>
            <interceptor name="scope2:org.globus.sample.PIP1"/>
        </pips>
        <pdps>
            <interceptor name="scope3:org.globus.sample.PDP1"/>
        </pdps>
     </authzChain>
     ...
</serviceSecurityConfig>

In the above case, X509BootstrapPIP followed by BoostrapPIP1 will be used.

The authorization chain can be configured with a combining algorithm using the attribute combiningAlg. The value should be a FQDN of a class that implements org.globus.wsrf.security.authorization.AuthorizationEngineSpi. The attribute is optional and the org.globus.wsrf.impl.security.authorization.providers.PermitOverrideAlgorithm is used by default.
Other than PermitOverrideAlgorithm, FirstApplicableAlg , in the same package are supported. FirstApplicableAlg returns the first permit or deny decision from walking down the authorization chain in the order specified.
Example:
```
<serviceSecurityConfig
  xmlns="http://www.globus.org/security/descriptor/service">
  ...

    <authzChain combiningAlg="org.globus.sample.SampleAlg>
        <pips>
            <interceptor name="scope2:org.globus.sample.PIP1"/>
        </pips>
        <pdps>
            <interceptor name="scope3:org.globus.sample.PDP1"/>
            <interceptor name="scope4:org.globus.sample.PDP2"/>
        </pdps>
    </authzChain>
  ...
</serviceSecurityConfig>
```
In the above example, the default X509BootstrapPIP will be used (fixme - don't see x509..pip shown in above code). Following that, the PIPs, PIP1, will be invoked to collect attributes. Finally, the SampleAlg combining algorithm with the configured PDPs ( PDP1 andPDP2) are run to determine the decision.
Each interceptor can specify a parameter value and the schema defines it as xsd:any to allow for any user defined parameters. The parser extracts the elements in the <parameter> element and returns them as a DOM Element. It is left up to the interceptor to parse the element. The DOM object created is placed in the ChainConfig object passed to the authorization engine as a parameter called parameterObject. The prefix will be the scope specified in the interceptor name.
Since schema validation is done, a schema must be supplied for the user-defined parameters. The schema location is loaded as a resource and hence can be included in some jar placed in the GLOBUS_LOCATION lib directory.

The toolkit provides a parameter schema by default that allows for a name/value pair, where the value is a string. 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">
    <authzChain>
        <pdps>
             <interceptor name="gridmapAuthz:org.globus.wsrf.impl.security.GridMapPDP">
                 <parameter>
                     <param:nameValueParam>
                                <param:parameter name="gridmap-file"
                                value="/home/user1/grid-mapfile"/>
                     </param:nameValueParam>
                  </parameter>
              </interceptor>
         </pdps>
     </authzChain>
</containerSecurityConfig>

When the above is parsed, a DOM Element is constructed with element <param:nameValuParam> and stored in the ChainConfig object as parameter with name gridmapAuthz:parameterObject. The GridMap PDP, uses ObjectDeserializer to retrieve the name/value pairs.

All PDPs and PIPs shipped with the toolkit are provided here: ???? and????.

The following PDPs are included in GT and are configured using short tags. The framework maps and plugs in the scoped name of the PDP at the time of authorization.

Table 1. Builtin PDPs

Default Descriptor Configuration	Default Prefix	Reference
`acl`	`aclAuthz`	????
`none`	`noneAuthz`	????
`self`	`selfAuthz`	????
`gridmap`	`gridmapAuthz`	????
`identity`	`idenAuthz`	????
`host`	`hostAuthz`	????
`samlCallout`	`samlAuthz`	????
`userName`	`userNameAuthz`	????
`samlAssertion`	`samlAssertionAuthz`	????

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

6. Writing a custom authorization mechanism

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

Example Bootstrap PIP:

package org.foobar;

import ....;
import org.globus.security.authorization.BootstrapPIP;

public class FooBootstrapPIP implements BootstrapPIP {



    public void initialize(String chainName, String prefix_, 
                           ChainConfig config) throws InitializeException {

        logger.debug("Initialize called");
    }

    public void collectRequestAttributes(RequestEntities requestAttrs)
            throws AttributeException {

        // add attributes to RequestEntities
    }

    public NonRequestEntities collectAttributes(RequestEntities requestAttr) {
     
        // any attributes for non request entities
    }

    public void close() throws CloseException {
    }

}

To use the above Bootstrap PIP, configure security descriptor as follows

    <authzChain combiningAlg="org.globus.sample.SampleAlg>
        <bootstrapPips "
             <interceptor name="scope1:org.foobar.GooBootstrapPIP"/>
        </bootstrapPips>
    </authzChain>

Example PIP:

package org.foobar;

import ....;

public class FooPIP implements PIPInterceptor {

   public void initialize(String chainName, String prefix, ChainConfig config)
            throws InitializeException {
            // initialize
   }

    public NonRequestEntities collectAttributes(RequestEntities requestAttr)
            throws AttributeException {

            // collect attributes, both for request entities and others
    }

    public void close() throws CloseException {

    }

}

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

        <authzChain>
            <pips>
                <interceptor name="scope2:org.foobar.FooPIP"/>
            </pips>
        </authzChain>

Example PDP:

package org.foobar;

import ....;

public class FooPDP implements PDP {

    public void initialize(String chainName, String prefix_, 
                           ChainConfig config) throws InitializeException {

        // use to read in configuration
     }

    public Decision canAccess(RequestEntities requestEntities,
                              NonRequestEntities nonRequestEntities)
            throws AuthorizationException {
            
        // evaluate to see if Subject can access
    }

    public Decision canAdminister(RequestEntities requestEntities,
                                  NonRequestEntities nonRequestEntities)
            throws AuthorizationException {

        // evaluate to see if Subject can administer
    }

     public void close() throws CloseException {

     }
}

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

        <authzChain>
            <pdps>
                <interceptor name="scope2:org.foobar.FooPDP"/>
            </pdps>
        </authzChain>

Prev		Next
Writing Resource Security Descriptor	Home	Writing Client Security Descriptors