Security descriptors contain various security properties like credentials, the grid map file location, required authentication and authorization mechanisms and so on. There are four types of security descriptors in the code base for setting container, service, resource and client security properties: container security descriptor determines the container level security requirement that needs to be enforced. service security descriptor determines the service level security requirement that needs to be enforced. resource security descriptor determines the resource level security requirement that needs to be enforced. client security descriptor determines the security properties that need to be used for a particular invocation. Each of these is represented as an object and can be altered programmatically. Service and container security descriptors can be configured as XML files in the deployment descriptor as shown below. Resource security descriptors can only be created dynamically, either programmatically or from a descriptor file. Client security descriptor can be configured as a XML file and set as property on Stub. If the security descriptor file is altered at runtime, it will not be reloaded

The following shows how the service and container security descriptor files are configured. The container security descriptor needs to be set in the core server-config.wsdd. That file is in wsrf/java/core/source/deploy-server.wsdd if editing source, prior to deploy or $GLOBUS_LOCATION/etc/globus_wsrf_core/server-config.wsdd in a binary install. The parameter element to be added is: <globalConfiguration> ... <parameter name="containerSecDesc" value="<path to global security descriptor>"> ... <globalConfiguration> A sample container security descriptor file, global_security_descriptor.xml is shipped as a part of the toolkit. The file can be edited to reflect the deployment security properties and the above parameter will be set as follows: <globalConfiguration> ... <parameter name="containerSecDesc" value="etc/globus_wsrf_core/global_security_descriptor.xml"> ... <globalConfiguration> Service security descriptor should be configured as follows: <service name="MyDummyService" provider="Handler" style="document"> ... <parameter name="securityDescriptor" value="org/globus/wsrf/impl/security/descriptor/security-config.xml"/> ... </service> If the security descriptor is configured to be read from a file, it is loaded as follows: As a file if an absolute file path is specified. As a resource (can be included as part of jar file). As a file, assuming that the specified path is relative to the installation root, typically pointed to by environment variable GLOBUS_LOCATION. The security descriptor files need to comply with the service security descriptor schema or container security descriptor schema as appropriate. The resource security descriptor file uses the same schema as the service security descriptor. In all cases, the security descriptor is contained within the <securityConfig xmlns="http://www.globus.org"> element.

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 next few sections deal with writing server side security descriptor files—that is, container, service and resource descriptor files to set various properties. Please note that not all parameters are applicable for all three types of descriptors and are appropriately annotated in the relevant sections. The few parameters relevant only for the container security descriptor are described in Section 7.

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 certificate and key file, or b) the path to a proxy 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: Resource credentials Service credentials Container credentials Default credentials. This uses the underlying security library to acquire the credentials. It will typically result in finding the proxy certificate of the user that is running the container.

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: <none/> Indicates that no authentication is required. This method cannot be specified with any other authentication method. <GSISecureMessage/> Indicates the GSI Secure Message authentication method. The <protection-level> sub element can be used to specify a protection level that must be applied to the message: <integrity/> Indicates that the message must be integrity protected (signed). <privacy/> Indicates that the message must be privacy protected (encrypted and signed). <GSISecureConversation/> Indicates the GSI Secure Conversation authentication method (with integrity or privacy protection). The <protection-level> sub element can be used to indicate a specific protection level that must be applied to the message: <integrity/> Indicates that the message must be integrity protected (signed). <privacy/> Indicates that the message must be privacy protected (encrypted and signed). <GSITransport/> Indicates the GSI Secure Transport authentication method. The <protection-level> sub element can be used to specify a specific protection level that must be applied to the message: <integrity/> Indicates that the message must be integrity protected (signed). <privacy/> Indicates that the message must be privacy protected (encrypted and signed). Notes: Multiple authentication methods can be specified under the <auth-method> element (except for the <none/> method, see above). As long as one of the specified authentication methods is used, access to the service is allowed. If no <protection-level> sub element is specified, then all protection levels are available to clients. However, if the <protection-level> sub element is specified, then the service will only accept the protection levels listed under said element. The org.globus.wsrf.impl.security.authentication.SecurityPolicyHandler handler must be installed properly in order for this to work. This handler is installed by default. If a security descriptor is not specified, authentication method enforcement is not performed. 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 findServiceData() operation does not require any authentication. the destroy() operation requires either GSI Secure Message authentication with either level of protection or GSI Secure Conversation authentication with integrity protection. all other operations must be authenticated with GSI Secure Conversation with either level of protection.

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: <caller-identity/> The service method will be run with the security identity of the client. The caller Subject will contain the following: If using GSI Secure Message: a GlobusPrincipal (the identity of the signer) is added to the principal set of the caller-identity Subject. Also, the signer's certificate chain is added to the public credentials set of the Subject object. If using GSI Secure Conversation: a GlobusPrincipal (the identity of the initiator) is added to the principal set of the Subject. If client authentication was performed, the client's certificate chain will be added to the public credentials set of the Subject object. Also, if delegation was performed, the delegated credential is added to the private credential set of the Subject object. If grid map file authorization was performed, a UserNamePrincipal is added to the principal set of the Subject object. <system-identity/> The service method will be run with the security identity of the container. <service-identity/> The service method will be run with the security identity of the service itself (if the service has one, otherwise the container identity will be used). <resource-identity/> The service method will be run with the security identity of the resource. If no resource is specified or if the resource does not have a configured subject, credentials in this order of occurrence will be used: service credential, container credential. Notes: resource-identity is the default setting. The org.globus.wsrf.impl.security.authentication.SecurityPolicyHandler handler must be installed properly in order for this to work. It is installed by default. If the security descriptor is not specified, then the run-as identity is not set and there will be no JAAS subject associated with the execution of the operation. This means that any method calls that require credentials and that are invoked by the service method itself will fail. 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 add()operation will be run with the caller's identity. the subtract() call will be run with the system identity. all other operations will be run with the service identity (if the service has one set).

The container and each service can be configured with a chain of authorization mechanisms (also known as Policy Decision Points (PDPs)) and attribute collection mechanisms (also known as Policy Information Points (PIPs)), using the authz element. PIPs are expected to collect attributes and store them for use by PDPs in authorization process or in the invocation chain. PDPs are expected to be enforce some authorization policy. The chain combines the decision from all the PDPs.Each PDP/PIP name is scoped and the format is prefix:FQDN of the PDP/PIP. For example, self:org.globus.wsrf.impl.security.authorization.SelfAuthorization. The prefix is used to allow multiple instances of the same PDP/PIP to exist in the same authorization chain. All the PIPs in the authorization chain are invoked in the order configured, before the PDPs are invoked. 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="pdp1:org.foo.PDP1 pdp2:org.foo.PDP2 foo1:org.foo.authzMechanism bar1:org.bar.barMechanism"/> ... <securityConfig/> Each PDP/PIP is instantiated with some configuration information that can be used to get any further information that the PDP/PIP 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. none No authorization is performed. self PDP Name: selfAuthz:org.globus.wsrf.impl.security.authorization.SelfAuthorization This scheme does not require any additional configuration information. Only clients that present the same identity as the identity in the current JAAS subject associated with the service are allowed to access the service. The current JAAS subject is determined by the value of the run-as element in the service security descriptor (see Configuring run-as mode). gridmap PDP Name: grimapAuthz:org.globus.wsrf.impl.security.authorization.GridMapAuthorization A grid map file must be configured as described in . Grid map file authorization is performed, i.e. a mapping must exist for the client identity in the configured grid map file. identity PDP Name: idenAuthz:org.globus.wsrf.impl.security.authorization.IdentityAuthorization The property idenAuthz-identity set to the expected identity must be configured in the service or container deployment descriptor in the case of service level or container level authorization respectively. The client identity must match the value of this property. host PDP Name: hostAuthz:org.globus.wsrf.impl.security.authorization.HostAuthorization The property hostAuthz-url set to the expected host name must be configured in the service or container deployment descriptor in the case of service level or container level authorization respectively. Host based authorization is done and should match the expected host set in the property. samlCallout PDP Name: samlAuthz:org.globus.wsrf.impl.security.authorization.SAMLAuthorizationCallout This scheme calls out to a configured OGSA-AuthZ compliant authorization service. When this PDP is specified via the samlCallout alias or the org.globus.wsrf.impl.security.authorization.Authorization.AUTHZ_SAML constant the prefix samlAuthz is used when acquiring configuration settings. The SAML authorization callout PDP can be configured by specifying parameters in the service entry in the deployment descriptor of the service that is using the callout. The available configuration properties are described in . userName PDP Name: userNameAuthz:org.globus.wsrf.impl.security.authorization.UsernameAuthorization This scheme does not require any additional configuration information. This uses the configured JAAS Login Module to authorize the user based on username and password. The PDP uses NameCallback and PasswordCallback to send user name and password information to the Login module. someScope:org.globus.wsrf.impl.security.authorization.LocalConfigPDP PDP Name: someScope:org.globus.wsrf.impl.security.authorization.LocalConfigPDP The property authzConfigFile should be set to a file containing mappings between users and their allowed operations. One user mapping is specified per line and multiple operations are separated by semicolon (;). The file may be modified without restarting the hosting environemnt. Example: /O\=Grid/O\=Globus/OU\=Sample\Org/CN\=AdminUser={http://www.globus.org/counter}add;{http://www.globus.org/counter}subtract /O\=Grid/O\=Globus/OU\=Sample\Org/CN\=User={http://www.globus.org/counter}query Note that white spaces and equal signs (=) need to be escaped with backslash (\) This parses the configure file to determine if a specific user is allowed to access an operation. <prefix>-authzService The URL of the authorization service. <prefix>-authzServiceIdentity The identity to use for authorizing the authorization service. If no identity was specified then the service is authorized using the identity associated with the entity performing the callout (self-authorization). <prefix>-authzServiceCertificateFile A filename identifying the certificate to use when encrypting messages and verifying responses signed at the SAML level. This is only required if using GSI Secure Message with privacy protection or if the user requested SAML signing. <prefix>-authzServiceCertificate This parameter is equivalent to the above, but can only be used programmatically. It must be set to a value of type java.security.cert.X509Certificate. <prefix>-securityMechanism The security mechanism to use. Recognized values are none, msg (GSI-Secure Message) and conv (GSI-Secure Conversation). Transport security may be indicated by specifying a HTTPS URL in the <prefix>-authzService property. This property defaults to transport security if indicated by the URL and GSI-Secure Message otherwise. <prefix>-protectionLevel The protection level to use. Recognized values are sig (integrity protection) and enc (privacy and integrity protection). Defaults to sig. <prefix>-samlAuthzReqSigned Determines if the request is internally signed or not. SAML requests can include a signature in the request and response documents. This is separate from any security mechanism applied at either the SOAP or transport level. Recognized values are true and false. Defaults to false. <prefix>-samlAuthzSimpleDecision Determines whether to request a simple decision statement or not. More information on this setting can be found here. Recognized values are true and false. Defaults to true. Other than these, any custom authorization scheme could be configured with its own configuration information. Refer to , for details on writing a custom authorization mechanism.

The authorization handler can be configured to call out to a custon PIP or PDP. The custom PDP class must implement the interface org.globus.wsrf.security.PDP and the custom PIP class must implement the interface org.globus.wsrf.security.PDP. Example PIP: package org.foobar; import ....; public class FooPIP implements PIP { public String CURRENT_TIME = "org.foobar.current.time"; public void collectAttributes(Subject peerSubject, MessageContext context, QName operation) throws AttributeException { // collect attributes, say attributes from certificate extension // store in message context with some property. // Example here stores current time. messageContext.setProperty(FooPIP.CURRENT_TIME, Calendar.getInstance()); } public void initialize(PDPConfig config, String name, String id) throws InitializeException { /* Read the initialization information */ } public void close() throws CloseException { this. authorizedIdentity = null; } } To use the above PIP one would configure a service security descriptor with the following authorization settings: <securityConfig xmlns="http://www.globus.org"> ... <authz value="foo1:org.foobar.FooPIP"/> ... <securityConfig/> Example PDP: 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 { // The parameters set by FooPIP can be accessed here. Calendar currentTime = (Calendar)context.getProperty(FooPIP.CURRENT_TIME); 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 .

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: none No authorization is done. self Self authorization is done, i.e the server should be running with the same credentials as the client. host Host authorization is done, i.e the server should be running with credentials that have the host name it is running on embedded in it. any other string Identity authorization is done using the value as the identity, i.e the server should be running with identity specified as value. The following sample configures self authorization: <securityConfig xmlns="http://www.globus.org"> ... <authz value="self"/> ... </securityConfig> Custom client authorization schemes can be written and plugged in. But security descriptors cannot be used to configure such authorization schems. Refer to 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 <integrity> Sets protection level to signature. <privacy> Sets protection level to encryption (signature is also done). <anonymous> Server is accessed as anonymous. <delegation value="type of delegation"> Determines the type of delegation to be done. The value can be set to full or limited. If the delegation element is not used, no delegation is done. 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: <integrity> Sets protection level to signature <privacy> Sets protection level to encryption (signature is also done) <peer-credentials value="path to file with credentials to encrypt with"> Sets the path to the file containing the credential to use if privacy protection is chosen. The following sample sets GSI Secure Message with integrity: <securityConfig xmlns="http://www.globus.org"> ... <GSISecureMessage> <integrity/> </GSISecureMessage> ... </securityConfig>

The security descriptor (container, security and resource) can be created and altered programmatically (as opposed to writing a security descriptor file). For the service and container descriptor, we recommend writing a security descriptor file so that the security properties are initialized at start up. Container Security Descriptor This is represented by org.globus.wsrf.impl.security.descriptor.ContainerSecurityDescriptor. If a container security descriptor file is configured as described in , then an object is created and stored. To alter the values, use the API provided in org.globus.wsrf.impl.security.descriptor.ContainerSecurityConfig. Service Security Descriptor This is represented by org.globus.wsrf.impl.security.descriptor.ServiceSecurityDescriptor. If a service security descriptor file is configured as described in , then an object is created and stored. To alter the values, use the API provided in org.globus.wsrf.impl.security.descriptor.ServiceSecurityConfig. Resource Security Descriptor This is represented by org.globus.wsrf.impl.security.descriptor.ResourceSecurityDescriptor. To initialize the descriptor, i.e. load credentials and gridmap, use the API in org.globus.wsrf.impl.security.descriptor.ResourceSecurityConfig. Refer to the description of resource security descriptors in for more details. Client Security Descriptor This is represented by org.globus.wsrf.impl.security.descriptor.ClientSecurityDescriptor. To initialize the descriptor, use the API in org.globus.wsrf.impl.security.descriptor.ClientSecurityConfig.

Resource level security can be set up using a resource security descriptor. A resource security descriptor overrides any service or container level security settings. To make a resource secure, it needs to implement org.globus.wsrf.impl.security.SecureResource. This interface has a method that returns an instance of org.globus.wsrf.impl.security.descriptor.ResourceSecurityDescriptor. If null is returned, it is assumed that no security is set on the resource. Secure resources must implement org.globus.wsrf.security.SecureResource interface. A ResourceSecurityDescriptor object can be created and initialized in the resource's constructor. The object should be returned as a part of the getSecurityDescriptor method. public MyDummyResource implements SecureResource { private ResourceSecurityDescriptor desc = null; public MyDummyResource() throws Exception { this.desc = new ResourceSecurityDescriptor(); // set security properties on the above object using get/set methods // in the API } public ResourceSecurityDescriptor getSecurityDescriptor() { return this.desc; } } A ResourceSecurityDescriptor object can be created similar to above, but initialized from a file and set in the constructor. public MyDummyResource implements SecureResource { private ResourceSecurityDescriptor desc = null; ResourceSecurityConfig securityConfig = new ResourceSecurityConfig("/path/to/security/file"); try { securityConfig.init(); } catch (ConfigException exp) { // handle exception } this.desc = securityConfig.getSecurityDescriptor(); } public ResourceSecurityDescriptor getSecurityDescriptor() { return this.desc; } } The resource security descriptor is identical to the service security descriptor and exposes an API to set and get all properties that are described in . A resource security descriptor object can also be created by reading settings from a descriptor file. The file needs to be written as described in . Examples: The following code snippet creates a resource descriptor object directly: ResourceSecurityDescriptor desc = new ResourceSecurityDescriptor(); desc.setRejectLimitedProxy("true"); The following code snippet creates a resource descriptor object from a file: ResourceSecurityConfig config = new ResourceSecurityConfig("resDescFileName"); config.init(); ResourceSecurityDescriptor desc = config.getSecurityDescriptor(); There are two attributes of the security descriptor, credentials and gridmap, that can be specified as objects (javax.security.auth.Subject and org.globus.security.gridmap.GridMap, respectively) or as paths to credentials and the grid map file. Similarly, the service authorization chain object or a comma separated list of PDP names can be specified. In each of these cases, if the properties are configured as filenames or PDP names as the case may be, the helper API in org.globus.wsrf.impl.security.descriptor.ResourceSecurityConfig can be used to load the classes. The credentials, grid map file and PDPs specified in the authorization chain are loaded if the property initialized in the descriptor is set to false. For example, the code snippet below creates a descriptor that has a grid map file and an authorization chain. When config.init() is called, the grid map file is loaded and an instance of the service authorization chain class is created. The configuration information for the service authorization chain is by default picked up from the global deployment descriptor. To provide for other PDP configurations it needs to be set programmatically, as shown below. ResourceSecurityDescriptor desc = new ResourceSecurityDescriptor(); desc.setGridMapFile("foo/bar/gridmap"); desc.setAuthz("customAuthz:org.globus.some.customAuthz foo1:org.foo.barAuthz"); ResourceSecurityConfig config = new ResourceSecurityConfig(desc); config.init(); If the descriptor property changes, a reload can be forced by setting setInitialized to false: desc.setInitialized(false); desc.setGridMapFile("foo/bar/newGridMap"); config.init(); GridMap and Subject objects can also be set directly, i.e. without configuring files to be read: desc.setInitialized(false); GridMap map = new GridMap(); map.map("Some user DN", "userid"); desc.setGridMap(map); Service Authorization can also be set directly by creating an object of type org.globus.wsrf.impl.security.authorization.ServiceAuthorizationChain. The chain needs to be initialized with one or more objects implementing the org.globus.wsrf.security.authorization.PDPConfig interface. The org.globus.wsrf.impl.security.descriptor.ResourceSecurityDescriptor class has an API to initialize a PDP using the PDPConfig class. The distribution has a few sample classes that implement the org.globus.wsrf.security.authorization.PDPConfig interface and are described below: org.globus.wsrf.impl.security.authorization.ContainerPDPConfig: Obtains configuration information from the global deployment descriptor. org.globus.wsrf.impl.security.authorization.ServicePropertiesPDPConfig: Obtains configuration information from a service's deployment descriptor. org.globus.wsrf.impl.security.authorization.ResourcePDPConfig: Obtains configuration information from a hashmap stored in memory. Examples: This sample creates a authorization chain and sets it on the resource security descriptor: // Create a resource security descriptorResourceSecurityDescriptor ResourceSecurityDescriptor desc = new ResourceSecurityDescriptor(); // Configure a chain of PDPsString String authzChain = "identityAuthz custom:org.something.CustomAuthz"; // Create configuration object that implements PDPConfig ResourcePDPConfig config = new ResourcePDPConfig(authzChain); // Set properties that are required by the PDPs on the configuration object. // Property used by Identity authorization: scope, property name, property value config.setProperty("idenAuthz", "identity", "O=this, OU=is expected, CN=identity"); // Property used by CustomAuthz: scope, property name, property value config.setProperty("custom", "someProp", "foo"); desc.setAuthzChain(authzChain, config, "Name of Chain", "Some id");

Other than the security properties that have been described in Security Descriptor, two more properties are exclusive to the container security descriptor. When GSI Secure Conversation is used, a security context is established. A sweeper task is run every 10 minutes to delete all expired contexts. This interval can be set (in milliseconds) in the container security descriptor as shown below: <securityConfig xmlns="http://www.globus.org"> ... <context-timer-interval value="10000"/> ... </securityConfig> 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. This window can be configured (in milliseconds) as shown below: <securityConfig xmlns="http://www.globus.org"> ... <replay-timer-interval value="100"/> ... </securityConfig>

The container security descriptor can be set up at the command line (rather than configured in the deployment descriptor as described here) by using the -containerDesc option when starting up the container using globus-start-container. bin\globus-start-container -containerDesc path/to/desc