Web services security custom properties

Web services security custom properties

We can configure name-value pairs of data, where the name is a property key and the value is a string value that we can use to set internal system configuration properties. Defining a new property enables you to configure a setting beyond that which is available through options in the console.
Custom properties for web services security can be set in various levels of the application server 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.
The web services security generic security token login module custom properties and the Web services security SAML token custom properties are documented in other information topics. Links to these topics are provided in the Related reference section of this topic.
We can define the following web services security custom properties:

(v8552) com.ibm.websvcs.client.serializeSecurityContext

When a JAX-WS client is run on an application server, service calls can be slower when base security is enabled than when base security is not enabled. To adjust service call speed, we can use the com.ibm.websvcs.client.serializeSecurityContext property. When the com.ibm.websvcs.client.serializeSecurityContext property is set tofalse in the request context on the binding provider for the service call, the WebSphere security context will not be serialized to the web services message context. The following example illustrates setting this property.
javax.xml.ws.BindingProvider bp;
 bp.getRequestContext().put("com.ibm.websvcs.client.serializeSecurityContext", "false");
The com.ibm.websvcs.client.serializeSecurityContext property cannot be used in conjunction with a Reliable Messaging policy set.

Information Value
Data type String
Data type String
Values True, False
Default True

com.ibm.ws.wssecurity.createSTR

The com.ibm.ws.wssecurity.createSTR property creates a security token reference to the security token in the SOAP security header when specified a True value.
We can set this property to True, the com.ibm.ws.wssecurity.createSTR property creates a security token reference to the security token in the SOAP security header. Set this custom property to True when the following conditions exist:

The referencing mechanism for the token signature is the STR Dereference Transform, http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#STR-Transform

The SignedParts element for the WS-Security policy contains an XPath value that represents the SecurityTokenReference.

This property is configured as a custom property on the SAML token generator. It is not configured on the callback handler.

Information Value
Data type String
Values True, False
Default False

The value for this property is case-insensitive.

com.ibm.ws.wssecurity.dsig.SignatureAlgorithm

Use this custom property to configure a digital signature, we can enable the web services security runtime to use SHA-2 signature algorithms.
For JAX-WS applications, set the following custom property in the signing information section of request or response to enable SHA-2 signature algorithms. Ensure that same value is used for both the client and provider when configuring this custom property.
The com.ibm.ws.wssecurity.dsig.SignatureAlgorithm custom property specifies the SHA-2 signature algorithms for XML digital signatures. By default, WAS uses SHA1withRSA or HMACSHA1 to generate digital signatures.

Information Value
Data type String
Values rsa-sha256, rsa-sha384, rsa-sha512, hmac-sha256, hmac-sha384, hmac-sha512, or dsa-sha256

For JAX-WS applications, we can configure the com.ibm.ws.wssecurity.dsig.SignatureAlgorithm custom property from either the outbound signing information or inbound signing information. To configure com.ibm.ws.wssecurity.dsig.SignatureAlgorithm...

Click Services > Service clients or Service providers.

Click the service_name > binding_name.

Under Policy, click WS-Security.

Under Message Security Policy Bindings, click Authentication and protection.

Under either Request message signature and encryption protection or Response message signature and encryption protection, click the signature_message_part_reference.
When you select the signature_message_part_reference name, you are accessing the configuration for the signed message part binding.

Specify the custom property. For example com.ibm.ws.wssecurity.dsig.SignatureAlgorithm and enter the desired algorithm as a property value with one of the values identified in the previous table.

com.ibm.ws.wssecurity.sc.FaultCode

Use this custom property in a JAAS login module to set the SOAP fault code in the event of an error. If this property is not specified, the SOAP fault code wsse:FailedAuthentication is always returned.
In the custom JAAS login module, set the com.ibm.ws.wssecurity.sc.FaultCode property on the wssecurity context to the QName of the fault code that you want to use. For example:
fcQname = new QName(
          "http://schemas.xmlsoap.org/ws/2003/06/secext","FailedCheck");  this._context = propertyCallback.getProperties();
 _context.put("com.ibm.ws.wssecurity.sc.FaultCode", fcQname);
Information Value
Data type String
Default none

com.ibm.wsspi.wssecurity.Caller.assertionLoginConfig

The com.ibm.wsspi.wssecurity.Caller.assertionLoginConfig property, which is configured on the caller part, specifies the name of the JAAS login configuration used by Web Services Security to obtain WebSphere Application Server authorization credentials. We must configure this property using an assembly tool such as the Rational Application Developer. For more information, see the Configuring 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.

Information Value
Data type String
Default system.DEFAULT

com.ibm.wsspi.wssecurity.config.disableWSSIfApplicationSecurityDisabled

When set the com.ibm.wsspi.wssecurity.config.disableWSSIfApplicationSecurityDisabled custom property to true, Web Services Security does not enforce the configured WS-Security constraints if application security is disabled on the application server. Use this custom property to debug services in a non-secure environment without needing to remove security constraints from web services applications.
Best practice: Use this custom property for diagnosis purposes only. Do not use it in a production environment.bprac

Information Value
Data type String
Values true, false
Defaultfalse false

We can set this custom property as an inbound custom property or an inbound and outbound custom property for the policy set bindings. Complete the following steps in the console to set the custom property:

Expand Services > Policy sets.

Click General provider policy set bindings or General client policy set bindings.

Click the binding_name.

Under the Policy heading, click WS-Security > Custom properties.

We can also set this custom property as a parameter or as an inbound binding property on the application using wsadmin tooling. The following WS-Security policy-type property names are used in setBinding:

application.parameters

application.securityinboundbinding config.properties

com.ibm.wsspi.wssecurity.config.gen.checkCacheUsernameTokens

The com.ibm.wsspi.wssecurity.config.gen.checkCacheUsernameTokens custom property specifies whether to cache UsernameTokens all of the time, which is the default behavior, or cache them as determined by a set of rules. We can configure this custom property for the token generator or as an additional property.
When the com.ibm.wsspi.wssecurity.config.gen.checkCacheUsernameTokens custom property is set to false, UsernameTokens are always cached on client threads. When you set this custom property to true, the web services security run time determines whether UsernameTokens are cached based on the following rules:

Never cache UsernameTokens if the application is running on an application server.

Cache UsernameTokens if the token generator for the UsernameToken has the following callback handler configured: com.ibm.wsspi.wssecurity.auth.callback.GUIPromptCallbackHandler.

This custom property applies to the JAX-RPC run time only. Use an assembly tool, such as Rational Application Developer, to set the custom property within the encrypted message part bindings.

Information Value
Data type String
Values true, false
Default false

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

These two custom properties allow the administrator to control the setting of the mustUnderstand attribute in the SOAP Security header. These properties are set as outbound custom properties.
We can configure the following outbound generator custom properties for Web Services Security:

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

The com.ibm.wsspi.wssecurity.config.request.setMustUnderstand custom property 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.

Information Value
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.
Avoid trouble: The instructions for setting the com.ibm.wsspi.wssecurity.config.request.setMustUnderstand property are the same as the instructions for setting com.ibm.wsspi.wssecurity.config.response.forceMustUnderstandEqualsOne and are listed below.gotcha

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

The com.ibm.wsspi.wssecurity.config.response.forceMustUnderstandEqualsOne custom property 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.

Information Value
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-WS applications, we can set the com.ibm.wsspi.wssecurity.config.request.setMustUnderstand and com.ibm.wsspi.wssecurity.config.request.setMustUnderstandEqualsOne custom properties as outbound custom properties or as inbound and outbound custom properties for the policy set bindings. Complete the following steps in the console to set the custom properties:

Expand Services > Policy sets.

Click General provider policy set bindings or General client policy set bindings.

Click the binding_name.

Under the Policy heading, click WS-Security > Custom properties.

We can also set the com.ibm.wsspi.wssecurity.config.request.setMustUnderstand and com.ibm.wsspi.wssecurity.config.response.forceMustUnderstandEqualsOne custom properties as parameters or as an outbound binding properties on the application using wsadmin tooling. The following WS-Security policy-type property names are used in setBinding:

application.parameters

application.securityinboundbindingconfig.properties

For JAX-RPC applications, we can specify both properties in the following locations within the console:

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

Click Servers > Server Types > WebSphere application servers > server name . Under Security, click JAX-WS and JAX-RPC security runtime. Under Custom properties, click Custom properties.

For an assembly tool with a JAX-RPC WS-Security version 1.0 application, we can set the com.ibm.wsspi.wssecurity.config.request.setMustUnderstand custom property on the security request generator extension or binding. We can set the com.ibm.wsspi.wssecurity.config.response.forceMustUnderstandEqualsOne 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 specification draft 13level application, we can set the com.ibm.wsspi.wssecurity.config.request.setMustUnderstand custom property as a parameter on the port qualified name binding. We can set the com.ibm.wsspi.wssecurity.config.response.forceMustUnderstandEqualsOne custom property as a parameter on the port component binding.

com.ibm.wsspi.wssecurity.config.token.inbound.retryOnceAfterTrustFailure

The com.ibm.wsspi.wssecurity.config.token.inbound.retryOnceAfterTrustFailure custom property specifies whether a truststore can be reloaded after an application server starts.
A truststore is a keystore. By default, JAX-WS WS-Security does not acknowledge the refresh of any keystores while the application server is running. For performance reasons, keystores are cached in memory when each application is started. Because the cache is shared among applications, even if a single application is stopped, its keystores remain in the cache. If a trusted certificate, used by an X.509 token consumer, is added to a truststore after the application server starts, the trust validation fails.
If we set the com.ibm.wsspi.wssecurity.config.token.inbound.retryOnceAfterTrustFailure property to true, when a trust validation occurs, the WS-Security runtime reloads its configured truststore and tries the trust validation one more time. The reloaded truststore is only used for this single re-validation attempt. The keystore object in the cache is not replaced because replacing the keystore object might cause concurrency issues.
If the second validation attempt fails, a trust validation failure is returned to the client.
The default value for this property is false.
Avoid trouble: This property is set as a custom property on the Callback handler for an X.509, PKIPath, or PKCS#7 token consumer. To set this property in the console, click binding_name > WS-Security > Authentication and protection > token_name > Callback handler. For an application using the WS-Security WSS API, this property can also be set on the Callback handler for the token consumers that are previously listed.gotcha

com.ibm.wsspi.wssecurity.consumer.timestampRequired

The com.ibm.wsspi.wssecurity.consumer.timestampRequired property specifies whether Timestamp is not expected in the security header for the response when the Include timestamp in security header setting is selected for the WS-Security policy.
The JAX-WS WS-Security runtime is updated to comply with the OASIS WS-SecurityPolicy 1.2 specification Timestamp Required requirement. To configure an application to not require an inbound time stamp when an outbound time stamp is configured we can add the com.ibm.wsspi.wssecurity.consumer.timestampRequired custom property to the Web Services Security settings and set that property to false. When false, even if the Include timestamp in security header is selected as a setting for the WS-Security policy, a Timestamp is not expected in the security header for a response.
The default value for this property is true.
Avoid trouble: On the custom properties panel, we can set this property as either an inbound or an inbound/outbound custom property. It is not valid as an outbound custom property.gotcha

Information Value
Data type Boolean
Default true

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. WebSphere Application Server, by default, includes the prefix in the digital signature for Web Services Security. We can set this custom property to false if we do not want inclusive namespaces set as an element. Some implementations of Web Services Security cannot handle this prefix list. If we experience a signature validation failure when a signed SOAP message is sent and you are using another vendor in the environment, check with your service provider for a possible fix to their implementation before disabling this property.
For JAX-RPC applications, we can set the custom property in the console in the signing information or as a web services 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 Configuring custom properties to secure web services topic. To add the custom property to the signing information...

Click Applications > Enterprise Applications > application_name.

Click Manage Modules > module_name.

Under Web Services Security Properties, click Web services: Client security bindings or Web services: Server security bindings.

Under Request generator (sender) binding or Response generator (sender) binding, click Edit custom.

Under Required properties, click Signing information > signing_information_name > Properties.

Specify the custom property and its value.

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

Click Services > Service clients or Services > Service providers.

Click the service_name > binding_name.

Under Policy, click WS-Security

Under Message Security Policy Bindings, click Authentication and protection

Under either Request message signature and encryption protection or Response message signature and encryption protection, click the signature_message_part_reference. When you click the signature_message_part_reference name, you are accessing the configuration for the signed message part binding.

Specify the custom property and its value.

com.ibm.wsspi.wssecurity.dsig.oldEnvelopedSignature

Use this property in conjunction with the com.ibm.wsspi.wssecurity.dsig.enableEnvelopedSignatureProperty JVM custom property to indicate to the WS-Security runtime twe want the WS-Security runtime to calculate the digest value as it did in Versions 7.0.0.21 and earlier for either outbound XML Digital Signature creation or inbound verification. For more information, see Java Virtual Machine (JVM) custom properties for a description of when you might want to use this JVM custom property.
This property is specified as either an Inbound, Outbound, or Inbound and Outbound custom property for the WS-Security policy set bindings.

com.ibm.wsspi.wssecurity.generator.useWSSObject

This custom property determines how the WS-Security run time builds the SOAP Security header that is sent in an outbound SOAP message. By default, the run time uses a fast path using internal web services security (WSS) object representations to build the Security header. Alternatively, the Axis2 run time and objects can be used to build the Security header.
This property is set in the WS-Security policy set bindings as an outbound custom property or an inbound and outbound custom property. This property can be set to true or false. When true, WSS Objects are used to build the Security header. When false, Axis2 objects are used to build the Security header.
When using both WS-Security and WS-Addressing policies for both inbound and outbound messages, a problem might occur where the Body element appears in the header element in the outbound SOAP message. If this error occurs, set the com.ibm.wsspi.wssecurity.generator.useWSSObject custom property to false.
The default value is true.

com.ibm.wsspi.wssecurity.login.useSoap12FaultCodes

The com.ibm.wsspi.wssecurity.login.useSoap12FaultCodes custom property specifies whether the WS-Security runtime is updated to emit the proper SOAP 1.2 fault code when a fault is returned in response to a SOAP 1.2 message.
When true, the WS-Security runtime is returns a SOAP 1.2 fault code in response to a SOAP 1.2 message.
When false, the WS-Security runtime returns a SOAP 1.1 fault code in response to a SOAP 1.2 message.
The default value for this property is true.
This property needs to be set as either a WS-Secrutiy Inbound or Inbound and Outbound custom properties for a specific binding.
Following is an example of a valid SOAP 1.2 fault returned when this property is set to true:
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv=" http://www.w3.org/2003/05/soap-envelope">    <soapenv:Body>      <soapenv:Fault>        <soapenv:Code>          <soapenv:Value>soapenv:Sender</soapenv:Value>
        <soapenv:Subcode>
          <soapenv:Value xmlns:axis2ns1="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
            axis2ns1:FailedAuthentication</soapenv:Value>
        </soapenv:Subcode>        </soapenv:Code>        <soapenv:Reason>          <soapenv:Text>CWWSS6521E: The Login failed because             of an exception: javax.security.auth.login.LoginException:             CWWSS7062E: Failed to check username [user1] and password in             the UserRegsitry: WSSUserRegistryProcessor.checkRegistry()=false          </soapenv:Text>        </soapenv:Reason>        <soapenv:Detail></soapenv:Detail>      </soapenv:Fault>    </soapenv:Body>  </soapenv:Envelope>
(V8502) com.ibm.wsspi.wssecurity.nonce.includeEncodingType

This JAX-WS custom property is added to the WebSphere WS-Security runtime to indicate that an EncodingType attribute should be added to nonce elements. When true, the EncodingType attribute is added to all nonce elements in the SOAP Security header.
Valid values for this property are true and false. The default is false. This property is a WS-Security custom property, and is specified in the WS-Security bindings in the following locations:

Outbound custom properties

Inbound and outbound custom properties

(WAS v8.5.0.1) com.ibm.wsspi.wssecurity.token.enableCaptureTokenContext

This property indicates whether a token consumer and/or token generator is enabled to obtain its token from the the tokenHolder on the message context.
This property is only valid for JAX-WS applications.
Valid values for this property are true and false. The default value is false.
To configure this property, in the console:

Expand Services > Policy sets.

Click General provider policy set bindings or General client policy set bindings.

Click the binding name.

Under the Policy heading, click WS-Security > Authentication and Protection > tokenName > Callback Handler.

Add this property and its value in the Custom Properties Name and Value fields.

(WAS v8.5.0.1) com.ibm.wsspi.wssecurity.token.enableCaptureTokenInboundMsg

This property indicates whether a token consumer and/or token generator is enabled to obtain its token from the set of SecurityTokens in the inbound message. If there is more than one token in the inbound message that matches the value type of the token generator, then the token selected will be indeterminate.
This property is only valid for JAX-WS applications.
Valid values for this property are true and false. The default value is false.
For more information on the tokenHolder list, see passThroughToken in com.ibm.wsspi.wssecurity.core.config.IssuedTokenConfigConstants
To configure this property, in the console:

Expand Services > Policy sets.

Click General provider policy set bindings or General client policy set bindings.

Click the binding name.

Under the Policy heading, click WS-Security > Authentication and Protection > tokenName > Callback Handler.

Add this property and its value in the Custom Properties Name and Value fields.

com.ibm.wsspi.wssecurity.token.forwardable

When configuring SecurityToken consumer bindings for the JAX-WS programming model, use this custom property to specify whether the receiving token is propagated to other servers. If we specify a value of true for this property, you enable this token for propagating to other servers. If we specify a value of false for this property, the token is not propagated to other servers. The default value is true, and the value is not case sensitive.

com.ibm.wsspi.wssecurity.token.IDAssertion.isUsed

This property is intended to be used in an identity assertion scenario. Set this property to true in the callback handler configuration for the identity token.
When true in a UsernameToken generator, it allows the generator to emit a UsernameToken without a password. The rest of the identity assertion configuration is not required to use this property with the UsernameToken generator or consumer.

Information Value
Data type String
Values true, false
Default false

com.ibm.wsspi.wssecurity.token.IDAssertion.useRunAsIdentity

This property is used by the UsernameToken generator. When true in the callback handler for the UsernameToken generator, the principal name from the current runAs subject will be used as the Username in the UsernameToken. When true, base security must be enabled and a runAs subject must be set on the current thread of execution in order for a non-null Username to be set in the UsernameToken.
IDAssertion.useRunAsIdentity=true requires IDAssertion.isUsed=true to also be set.

Information Value
Data type String
Values true, false
Default false

com.ibm.wsspi.wssecurity.token.username.addNonce and com.ibm.wsspi.wssecurity.token.username.addTimestamp

When configuring a username token for the JAX-WS programming model, to protect against replay attacks it is strongly recommended that we add custom properties, com.ibm.wsspi.wssecurity.token.username.addNonce and com.ibm.wsspi.wssecurity.token.username.addTimestamp, to the callback handler configuration for token generation. These custom properties enable and verify the nonce and timestamp for message authentication. The value of the properties must be set to true.

com.ibm.wsspi.wssecurity.token.username.password.forwardable

When configuring UsernameToken consumer bindings for the JAX-WS programming model, use this custom property to specify whether the password is propagated along with the UsernameToken to other servers during UsernameToken propagation. If we specify a value of true for this property, the password is preserved during propagation. If we specify a value of false for this property,the password must be removed prior to UsernameToken propagation. The default value is true, and the value is not case sensitive.

com.ibm.wsspi.wssecurity.token.username.verifyNonce and com.ibm.wsspi.wssecurity.token.username.verifyTimestamp

When configuring a username token for the JAX-WS programming model, to protect against replay attacks it is strongly recommended that we add custom properties, com.ibm.wsspi.wssecurity.token.username.verifyNonce and com.ibm.wsspi.wssecurity.token.username.verifyTimestamp, to the callback handler configuration for the token consumer. These custom properties enable and verify the nonce and timestamp for message authentication. The value of the properties must be set to true.

com.ibm.wsspi.wssecurity.token.UsernameToken.disableUserRegistryCheck

Allow the user registry check to be skipped for identity tokens in JAX-WS. This means that the user name associated with the identity token in an identity assertion scenario can pass through the UNTConsumeLoginModule without generating a registry error. Typically an identity token must not contain a password, and there might, or might not be a trust token. For example there might be a blind trust.
This property does not affect any UsernameToken containing a password.
(V8502) If we need to bypass the registry check for a UsernameToken containing a password, see the Replacing the authentication method of the UsernameToken consumer using a stacked JAAS login module topic. If a caller configuration is required for the UsernameToken, see the Configuring a UsernameToken caller configuration with no registry interaction topic.
When the property is set to true, the UNTConsumeLoginModule does not validate the inbound UsernameToken if, and only if, the UsernameToken does not contain a password.
Valid values for this property are true and false. The default value is false.
To configure this property, in the console:

Expand Services > Policy sets.

Click General provider policy set bindings or General client policy set bindings.

Click the binding name.

Under the Policy heading, click WS-Security > Authentication and Protection > tokenName > Callback Handler.

Add this property and its value in the Custom Properties Name and Value fields.

com.ibm.wsspi.wssecurity.auth.module.UsernameLoginModule.disableUserRegistryCheck

Allow the user registry check to be skipped for UsernameTokens in JAX-RPC. This means that the user name will pass through the UsernameLoginModule without generating a registry error.
Valid values for this property are true and false. The default value is false.
This property can be added to the custom properties of the com.ibm.wsspi.wssecurity.auth.module.UsernameLoginModule module in the wssecurity.UsernameToken JAAS configuration or in the custom properties of the JAAS configuration of the UsernameToken consumer for the provider application.
For more information on how to specify this property, see the topic Developing web services applications to use a UsernameToken with no registry interaction.

com.ibm.wsspi.wssecurity.tokenGenerator.ltpav1.pre.v7

Web services security supports both LTPA (Version 1) and LTPA Version 2 (LTPA2) tokens. The LTPA2 token, which is more secure than Version 1, is supported by the JAX-WS run time only. We can set the Enforce token version interoperability option on the token generator to determine whether an LTPA (Version 1) or an LTPA2 token is retrieved when a request message is received. However, to force the run time to use LTPA (Version 1) tokens only, we can set the com.ibm.wsspi.wssecurity.tokenGenerator.ltpav1.pre.v7 custom property to true
To enable this custom property...in the console:

Locate the binding to configure.

Click the WS-Security policy in the Policies table.

Click the Authentication and protection link in the security policy bindings section.

Click the token generator to configure.

Specify com.ibm.wsspi.wssecurity.tokenGenerator.ltpav1.pre.v7 to true in the Custom properties section.

The following table explains how combinations of this custom property and the Enforce token version interoperability option affect the runtime.

interoperability. Table of the com.ibm.wsspi.wssecurity.tokenGenerator.ltpav1.pre.v7 custom property and Enforce token version interoperability
com.ibm.wsspi.wssecurity.tokenGenerator.ltpav1.pre.v7 custom property value Enforce token version value Result
false Disabled The run time can use both LTPA (Version 1) and LTPA2 tokens.
not specified, which implies a false value Disabled The run time can use both LTPA (Version 1) and LTPA2 tokens.
true Disabled The run time can use LTPA (Version 1) tokens only.
true Enabled The run time can use LTPA (Version 1) tokens only.

For more information, see the documentation about enabling or disabling single sign-on interoperability mode for the LTPA token.

Related tasks
Configure custom properties to secure web services
Replace the authentication method of the UsernameToken consumer using a stacked JAAS login module
Configure a UsernameToken caller configuration with no registry interaction
Develop web services applications to use a UsernameToken with no registry interaction
Inbound and outbound custom properties
Web services security generic security token login module custom properties
Web services security SAML token custom properties

Related information:
Exclusive XML Canonicalization

Information	Value
Data type	String
Data type	String
Values	True, False
Default	True

Information	Value
Data type	String
Values	rsa-sha256, rsa-sha384, rsa-sha512, hmac-sha256, hmac-sha384, hmac-sha512, or dsa-sha256

com.ibm.wsspi.wssecurity.tokenGenerator.ltpav1.pre.v7 custom property value	Enforce token version value	Result
false	Disabled	The run time can use both LTPA (Version 1) and LTPA2 tokens.
not specified, which implies a false value	Disabled	The run time can use both LTPA (Version 1) and LTPA2 tokens.
true	Disabled	The run time can use LTPA (Version 1) tokens only.
true	Enabled	The run time can use LTPA (Version 1) tokens only.