This section describes configuration of the container security descriptor.

To configure container level credentials, refer to Section 1, “Credentials”

To configure authorization at container level for use if not overridden by service or resource level policy, refer to Section 5, “Authorization”

Other than the container/service/resource authorization, an administrative-level authorization chain can be configured using the <adminAuthz> element. If the administrator's authorization chain returns a deny, the rest of the configured authorization (at container/service/resource) is not evaluated and the operation is denied. If the administrator'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 inSection 5, “Authorization”, with the outer element called adminAuthz in place ofauthzChain.

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, “Authorization” and allows for xsd:any as the 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>

Container can choose to require that clients use full proxies for access and reject limited proxies. To configure such a policy, refer to Section 2, “Reject Limited Proxy”

You can control the lifetime of the context with GSI Secure Conversation as an authentication mechanism, as described inSection 4, “Context lifetime”.

You can control the replay attack window for services that allow for GSI Secure Message, as desribed inSection 3, “Replay attack prevention”.

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 10 minutes.

<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 the 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>

If this configuration is not set, the underlying CoG JGlobus library is used to pick up trusted certificates. The library attempts to load the certificates as described in Section 1, “Trusted Certificates Location” .