Network Deployment (Distributed operating systems), v8.0 > Reference > 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 you 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 admin 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. We can define the following custom properties:



Callback handler custom properties for generic security token login modules

When you configure a generic security token login module, you can specify configuration properties to control how the token is generated or consumed.

To configure these custom properties for the callback handler in the administrative console...

  1. Expand Applications > Application Types and click WebSphere enterprise applications.

  2. Select an application that contains web services. The application must contain a service provider or a service client.

  3. Under the Web Services Properties heading, click Service provider policy sets and bindings or Service client.policy sets and bindings.

  4. Select a binding. We must have previously attached a policy set and assigned an application-specific binding.

  5. Click WS-Security in the Policies table.

  6. Under the Main Message Security Policy Bindings heading, click Authentication and protection.

  7. Under the Authentication tokens heading, click the name of the authentication token.

    We can use the token, which is processed by the generic security token login module, for authentication only. We cannot use the token as a protection token.

  8. Under the Additional Bindings heading, click Callback handler.

  9. Under the Custom Properties heading, enter the name and value pairs.

The following tables list the custom properties for the callback handler.

Callback handler custom properties for both token generator and token consumer bindings. . This table contains the custom property name, its values, and a short description.

Name Values Description
clockSkew This custom property does not have a default value. Use this custom property to specify, in minutes, an adjustment to the times in the self-issued SAML token that the SAMLGenerateLoginModule creates.

The clockSkew custom property is set on the Callback handler of the SAML token generator that uses the SAMLGenerateLoginModule class. The value specified for this custom property must be numeric and is specified in minutes.

When a value is specified for this custom property, the following time adjustments are made in the self-issued SAML token that the SAMLGenerateLoginModule creates:

  • The new NotBefore time setting equals the initial NotBefore time setting, minus the amount of time specified for the clockSkew custom property.
  • The new NotAfter time setting equals the initial NotAfter time setting, plus the amount of time specified for the clockSkew custom property.

stsURI This custom property does not have a default value. Use this custom property to specify the Security Token Service (STS) address.

This custom property is required for the token consumer. However, this custom property is optional for the token generator if the requested token exists in the RunAs Subject and its verification is not required.

wstrustClientBinding This custom property does not have a default value. Use this custom property to specify the binding name for the WS-Trust client.
wstrustClientBindingScope We can specify an application or domain value. Use this custom property to specify the type of bindings that are used for the WS-Trust client.

The following conditions apply:

  • If you specify the domain value, general bindings are used.

  • If you specify the application value, custom bindings are used.

  • If you do not specify a value and application bindings exist, those application bindings are used.

  • If you do not specify a value and general bindings exist, those general bindings are used.

  • If neither application or general bindings exist, the default bindings are used.

This custom property is optional.

wstrustClientPolicy This custom property does not have a default value. Use this custom property to specify the policy set name for the WS-Trust client.
wstrustClientSoapVersion We can specify a 1.1 or 1.2 value. Use this custom property to specify the SOAP message version that the trust client uses to generate the SOAP message. The SOAP message is sent to the Security Token Service (STS). If you do not define this custom property, the generic security token login module uses the SOAP version of the application when it generates the SOAP message for the trust client request.

The default value corresponds to the SOAP version used by the application client.

This custom property is optional.

wstrustClientWSTNamespace Specify one of the following values:

Trust v1.3 (Default)

Specify 1.3 to use Trust v1.3 (Default):

Trust v1.2

Specify 1.2 to use Trust v1.2:

Use this custom property to specify which trust client namespace the generic security token login modules uses when it makes the WS-Trust request.
wstrustValidateClientBinding By default, the value for this custom property is the same value specified for the wstrustClientBinding custom property. Use this custom property to specify the bindings that are used by the WS-Trust Validate request.

If you do not specify this custom property, the WS-Trust Validate request uses the same bindings that are used by WS-Trust Issue, which are defined by the wstrustClientBinding custom property.

wstrustValidateClientPolicy By default, the value for this custom property is the same value specified for the wstrustClientPolicy custom property. Use this custom property to specify the policy sets to use with the WS-Trust Validate request.

If you do not specify a value for this custom property, WS-Trust Validate uses the same policy set as WS-Trust Issue, defined by the required wstrustClientPolicy custom property.

wstrustIssuer We can use any string value. Use this custom property to specify the issuer for the request token.

This custom property is optional

wstrustValidateTargetOption The default value is the WS-Trust Base element extension.

You can specify a token value or a base value, which is also the default value.

Use this custom property to specify whether the WS-Trust client passes the validation token to the WS-Trust Security Token Service using the ValidateTarget or the Base element extension.

The following conditions apply:

  • If you do not specify a value for this custom property, the token is wrapped in the Base element extension within the RequestedSecurityToken element.

  • If you specify the token value, the token is wrapped in the ValidateTarget element within the RequestedSecurityToken element.


Callback handler custom properties for token generator bindings only. . This table contains the custom property name, its values, and a short description.

Name Value Description
useRunAsSubject We can use a True or False value. By default, a True value is used.

This value for this custom property is case sensitive.

Use this custom property to specify whether the generic security token login modules use the token from the RunAs Subject for the outgoing request. By default, the login module uses the validated tokens in the RunAs Subject first.

The following conditions apply:

  • If you set this custom property to a false value, the generic security token login module does not use WS-Trust Validate to exchange the token for the outbound request. Instead, it uses WS-Trust Issue to request a token.

  • If you do not specify this custom property, the generic security token login module attempts to use a token from the RunAs Subject and WS-Trust Validate to exchange the token.

  • If a token does not exist in the RunAs Subject, the generic security token login module uses WS-Trust Issue and is protected by the trust client.policy sets.

useRunAsSubjectOnly We can use a True or False value. By default, a False value is used.

This value for this custom property is case sensitive.

Use this custom property to disable or enable WS-Trust Issue in the generic security token login module. If you set this custom property to a true value, the generic security token login module uses the token from the RunAs Subject and WS-Trust Validate to exchange the tokens. The generic security token login module does not use WS-Trust Issue to request a token even if WS-Trust Validate fails or it does not find a matching token in the RunAs Subject.
useToken We can use any string value of the ValueType value for the security token. When you use a security token in a RunAs Subject to validate and exchange tokens for an outbound request, you can use this custom property to specify which token ValueType value in the RunAs Subject to validate and exchange for the requested token.

For example, you might have a token with a ValueType value of Token_1 in the RunAs Subject. However, the ValueType value of Token_2 is the required token. We can set this custom property to Token_1 .

If you do not define this custom property, the validation token is the token from the RunAs Subject that has the same ValueType value as the required token.

This custom property is optional.

validateUseToken We can use a True or False value. By default, a True value is used.

This value for this custom property is case sensitive.

Use this custom property to specify whether the token generator uses WS-Trust Validate to validate the token from the RunAs Subject.

By default, the generic security token login module validates a token from the RunAs Subject against the Security Token Service (STS) before sending the token in the SOAP message to the service provider.

If you set this custom property value to false and the generic security token login module finds a matching token from the RunAs Subject, the login module does not invoke WS-Trust Validate to validate the matching token. Instead, it sends the matching token to the downstream service provider without validation.

wstrustIncludeTokenType We can use a True or False value. By default, a True value is used.

This value for this custom property is case sensitive.

Use this custom property to specify whether the WS-Trust RequestedSecurityToken token includes the requested token ValueType value.

If you do not specify this custom property, the generic security token login modules includes the requested token type in the WS-Trust RequestedSecurityToken token.

This custom property is optional.


Callback handler custom properties for token consumer bindings only.. This table contains the custom property name, its values, and a short description.

Name Value Description
exchangedTokenType The valid value for this custom property is the string ValueType value for the token that is supported by the system default login modules. Use this custom property to specify the new token with the defined ValueType value, which the trust service must return after successful validation.

If you do not specify a value for the custom property, the generic security token login module accepts whichever token the trust service returns.

This custom property is optional.



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 you specify 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:

Data type String
Values True, False
Default False

The value for this property is case-insensitive.


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 WAS authorization credentials. Configure this property using an assembly tool such as the Rational Application Developer. 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.

Data type String
Default system.DEFAULT


com.ibm.wsspi.wssecurity.config.disableWSSIfApplicationSecurityDisabled

When you 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. We can use this custom property to debug services in a non-secure environment without needing to remove security constraints from web services applications.

Use this custom property for diagnosis purposes only. Do not use it in a production environment.

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 admin console to set the custom property:

  1. Expand Services > Policy sets.

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

  3. Click the binding_name.

  4. 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:



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:

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.

Data type String
Values true, false
Default false


com.ibm.wsspi.wssecurity.config.request.setMustUnderstand and 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 Web Services Security header. In an update to the product, an administrator can configure the attribute using outbound generator 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.

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

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, you can specify both properties in the following locations within the admin 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.

If you are using an assembly tool with a JAX-RPC WS-Security version 1.0 application, you 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 13–level application, you 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.

If using a JAX-WS application , you can set the 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 com.ibm.wsspi.wssecurity.config.request.setMustUnderstand property to false in the outbound binding configuration:

AdminTask.getPolicySetAttachments([-applicationName
HelloSvcClientEAR -attachmentType client])

AdminTask.setBinding([-policyType WSSecurity -bindingLocation "[
[application HelloSvcClientEAR] [attachmentId 1490] ]"
-attributes "[[application.securityoutboundbindingconfig.properties_999.name
com.ibm.wsspi.wssecurity.config.request.setMustUnderstand]
[application.securityoutboundbindingconfig.properties_999.value
false]]" -attachmentType client])


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

The com.ibm.wsspi.wssecurity.config.token.inbound.retryOnceAfterTrustFailure custom property specifies whether a trust store can be reloaded after an application server starts.

A trust store is a key store. 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. Therefore, if a trusted certificate, used by an X.509 token consumer, is added to a trust store after the application server starts, the trust validation fails.

If you 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 trust store and tries the trust validation one more time. The reloaded trust store 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 currency issues.

If the second validation attempt fails, a trust validation failure is returned to the client.

The default value for this property is false. 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 admin 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.


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 you can add the com.ibm.wsspi.wssecurity.consumer.timestampRequired custom property to your Web Services Security settings and set that property to false. When this property is set to 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. On the custom properties panel, you can set this property as either an inbound or an inbound/outbound custom property. It is not valid as an outbound custom property.

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. WAS, by default, includes the prefix in the digital signature for Web Services Security. We can set this custom property to false if you do not want inclusive namespaces set as an element. Some implementations of Web Services Security cannot handle this prefix list. If you 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 you disable this property.

For JAX-RPC applications, you can set the custom property in the admin 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, complete the following steps:

  1. Click Applications > Enterprise Applications > application_name.

  2. Click Manage Modules > module_name.

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

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

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

  6. Specify the custom property and its value.

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

To configure the custom property...

  1. Click Services > Service clients or Services > Service providers.

  2. Click the service_name > binding_name .

  3. Under Policy, click WS-Security

  4. Under Message Security Policy Bindings, click Authentication and protection

  5. 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.

  6. Specify the custom property and its value.


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 this property is set to true, WSS Objects are used to build the Security header. When this property is set to 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 this property is set to true, the WS-Security runtime is returns a SOAP 1.2 fault code in response to a SOAP 1.2 message.

When this property is set to 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 that is 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> 


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 you specify a value of true for this property, you enable this token for propagating to other servers. If you 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.username.addNonce and com.ibm.wsspi.wssecurity.token.username.addTimestamp

When configuring a username token for JAX-WS, to protect against replay attacks it is strongly recommended that you 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 you specify a value of true for this property, the password is preserved during propagation. If you 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 JAX-WS, to protect against replay attacks it is strongly recommended that you 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

This propery allows the user registry check to be skipped for identity tokens. 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 that contains a password. If bypass the registry check for a UsernameToken that contains a password, the UNTConsumeLoginModule provided with the product cannot be used. The following WS-Security custom property is added to the UNTConsumeLoginModule to allow the user registry check to be skipped for identity tokens:

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 admin console:

  1. Expand Services > Policy sets.

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

  3. Click the binding name.

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

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


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, if to force the run time to use LTPA (Version 1) tokens only, you can set the com.ibm.wsspi.wssecurity.tokenGenerator.ltpav1.pre.v7 custom property to true

To enable this custom property, complete the following steps in the admin console:

  1. Locate the binding to configure.

  2. Click the WS-Security policy in the Policies table.

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

  4. Click the token generator to configure.

  5. 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.

LTPA interoperability. Table of the com.ibm.wsspi.wssecurity.tokenGenerator.ltpav1.pre.v7 custom property and Enforce token version interoperability option values.

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.

See the documentation about enabling or disabling single sign-on interoperability mode for the LTPA token.
Configure custom properties to secure web services


Related


Inbound and outbound custom properties
http://www.w3.org/TR/xml-exc-c14n/

+

Search Tips   |   Advanced Search