+

Search Tips   |   Advanced Search

WS-Security custom properties


Custom properties for WS-Security can be set in various levels of the appserver and for JAX-RPC versus JAX-WS applications.

The following list of custom properties provides information on where the custom property is set and how it is used.

 

com.ibm.wsspi.wssecurity.Caller.assertionLoginConfig

Configured on the caller part. Specifies the name of the JAAS login used by WS-Security to obtain WAS authorization credentials. You must configure this property using an assembly tool such as the Rational Application Developer.

See the "Set the caller in consumer security constraints" topic for Rational Application Developer. Within this topic, this custom property is set when you configure identity assertion.

Use this property with WS-Security V1.0 JAX-RPC applications only.

Data type String
Default system.DEFAULT

 

com.ibm.wsspi.wssecurity.config.request.setMustUnderstand
com.ibm.wsspi.wssecurity.config.response.forceMustUnderstandEqualsOne

In WAS prior to V6.1x, the mustUnderstand=1 attribute in the <wsse:Security> tag in the SOAP header on the request from the Web Services client was hardcoded. It was not possible to configure the mustUnderstand attribute in the SOAP WS-Security header. In an update to WAS ND, an administrator can configure the attribute using outbound generator custom properties.

Configure the following outbound generator custom properties for WS-Security:

com.ibm.wsspi.wssecurity.config.request.setMustUnderstand

Specifies the mustUnderstand setting in outbound consumer requests.

If the value of the property is set to zero (0), no, or false, then the mustUnderstand attribute is not set in the WS-Security header within outbound consumer requests.

Data type String
Value Zero (0), no, false
Default true

In SOAP messages, the default value for the mustUnderstand attribute is zero (0). According to the SOAP specification, if the intended value for the attribute is zero, then the attribute must not be present in the message.

com.ibm.wsspi.wssecurity.config.response.forceMustUnderstandEqualsOne

Specifies that the provider should always respond with a mustUnderstand="1" attribute in the SOAP security header.

If the value is set to one (1), yes, or true, the provider responds with the mustUnderstand="1" attribute in the WS-Security header. The default value of the attribute is false.

Data type String
Value One (1), yes, or true
Default false

By default, the response contains the same mustUnderstand attribute as the request. For example, if the inbound request has mustUnderstand="1", the response also includes mustUnderstand="1". If the request does not have a mustUnderstand attribute, the response does not include a mustUnderstand attribute. For JAX-RPC applications, we can specify both properties in the following locations within the admin console:

    Servers | Server Types | WebSphere application servers | server name | Security | JAX-WS and JAX-RPC security runtime | JAX-RPC Default Generator Bindings, click Properties.

    Servers | Server Types | WebSphere application servers | server name | Security | JAX-WS and JAX-RPC security runtime | Custom properties | Custom properties

For an assembly tool with a JAX-RPC WS-Security version 1.0 application, we can set the custom property...

...on the security request generator extension or binding. You can set the custom property...

on the response generator extension or binding. A setting in the binding takes precedence over a setting in the extension.

If using an assembly tool with a JAX-RPC WS-Security spec draft 13–level application, we can set the custom property...

...as a parameter on the port qualified name binding. We can set the custom property...

...as a parameter on the port component binding. If using a JAX-WS application , we can set custom properties as outbound binding properties or parameters on the application using wsadmin scripts.

The following property names are used:

However, properties values in the application.securityoutboundbindingconfig.properties properties take precedence over properties in application parameters. The follow example shows how to use Jython wsadmin commands to obtain the ID of the policy set attachment for a consumer, then set the custom property...

...to false in the outbound binding configuration:

 

com.ibm.wsspi.wssecurity.dsig.inclusiveNamespaces

This custom property, which applies to both the JAX-RPC and JAX-WS applications, specifies whether to disable the inclusive namespace prefix list for XML digital signatures.

WAS, by default, includes the prefix in the digital signature for WS-Security. We can set this custom property to false if we do not want inclusive namespaces set as an element.

Some implementations of WS-Security cannot handle this prefix list. If we experience a signature validation failure when a signed SOAP message is sent and we are using another vendor in the environment, check with the service provider for a possible fix to their implementation before you disable this property.

For JAX-RPC applications, we can set the custom property in the admin console in the signing information or as a WS-Security custom property in additional properties or in the default or custom generator bindings.

For more information, see the additional properties and generator sections of the Set custom properties to secure Web services topic.

To add the custom property to the signing information, complete the

For JAX-WS applications, we can configure this custom property in the outbound signing information.

When you click the signature_message_part_reference name, we are accessing the configuration for the signed message part binding.

  • Specify the custom property and its value.

     

    Related tasks


    Set custom properties to secure Web services
    Inbound and outbound custom properties
    http://www.w3.org/TR/xml-exc-c14n/