IBM Support

TroubleShoot: WebSphere WS-Security Trace analysis

Troubleshooting


Problem

This document contains troubleshooting information for Web Services Security (WS-Security) problems in the WebSphere® Application Server. This can help address common issues with this component before calling IBM support and save you time.

Resolving The Problem


Troubleshooting topics:

Overview
This topic contains error messages and common issues that require a WS-Security trace to determine the root cause of the problem. The instructions to obtain a WS-Security trace are in the 'Collecting data manually' section of the

Collect data tab. If a trace string different than what is on the Collect data is required for a specific problem, that trace string will be noted in the steps to diagnose the problem. In most cases, it is best to obtain a WS-Security trace from application server startup.

This topic focuses on JAX-WS issues.

Note: This document uses the term full profile to refer to WebSphere Application Server v9.0 traditional, WebSphere Application Server v8.5 full profile, WebSphere Application Server v8.0 and earlier, WebSphere classic, traditional WebSphere, traditional WAS and tWAS.

How can I see the inbound and outbound SOAP messages?

One way to see see inbound and outbound SOAP messages is to use a tool provided with the application server called tcpmon. The tcpmon tool is similar to a wire trace where you can capture the messages that are going into and out of a port without the interference of the application server.

The tcpmon tool is configured to listen on a particular port, such as 9088, and it redirects messages to another port, such as 9080 or port 80. The client is then configured to send messages to the tcpmon listener port instead of the application server's. Because of this, in order to use the tcpmon tool, you must be able to modify the URL on the client that you use to access web services.

For information on how to set up and use tcpmon, see Tracing SOAP messages with tcpmon in the Knowledge Center.



Note: You can only use tcpmon when you are not using SSL.

 

How can I see the SOAP messages without a wire trace?

The com.ibm.ws.webservices.trace.*=all:com.ibm.ws.websvcs.trace.*=all elements in the WS-Security trace spec will ensure that the inbound and outbound SOAP messages are logged to the trace.log file. The former is for JAX-RPC and the latter is for JAX-WS. If all you want to see is your SOAP messages, this is the only trace setting that you need.

When you have a trace that includes this spec, you can find your inbound and outbound SOAP messages for either runtime by searching for 'bound HTTP'. Repeated searches for this string will alternate, on the same thread, between Inbound HTTP SOAP Request/Outbound HTTP SOAP Response for a provider and Outbound HTTP SOAP Request/Inbound HTTP SOAP Response for a client.

These are translated messages; if you are running with a language other than English, you will not be able to search for these strings. Alternatively, you can use the message IDs:
WSWS3569I: Inbound {0} {1} request:
WSWS3570I: Inbound {0} {1} response:
WSWS3571I: Outbound {0} {1} request:
WSWS3572I: Outbound {0} {1} response:


 

How can I get the WS-Security error that occurred on a server returned to the client?

By default, when the an error occurs in the web services engine or WS-Security, a SOAP message like this will be returned to the client:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"><soapenv:Body><soapenv:Fault xmlns:axis2ns1="http://schemas.xmlsoap.org/soap/envelope/"><faultcode>axis2ns1:Server</faultcode><faultstring>Internal Error</faultstring><detail></detail></soapenv:Fault></soapenv:Body></soapenv:Envelope>

This behavior results in a more secure system, preventing detailed information regarding why inbound message processing failed from being returned to message senders.

For debugging purposes, you may want to disable this behavior so that you can see error responses returned to client applications. To do this, set the the webservices.unify.faults JVM custom property to false.

For more information on the webservices.unify.faults custom property, see the Java virtual machine custom properties topic in the Knowledge Center.

Running with webservices.unify.faults=false in a production environment that is a risk to attackers is not recommended.

 

How can I tell if a trace is from server startup?

IBM support requires that traces be gathered from server startup. If you want to make sure that your traces are gathered from server startup, check for one of the following strings in your trace:

Server type
Search string
Full message
WebSphere Traditional e-business WSVR0001I: Server {0} open for e-business
Liberty smarter planet CWWKF0011I: The server {0} is ready to run a smarter planet.


 

How can I tell if an application is JAX-WS or JAX-RPC from a trace?

  1. In a WS-Security trace, search for 'bound HTTP' to find one of the messages referenced above.
  2. If you hit 'Inbound HTTP SOAP request', look forward a few lines
    • If you see lines like the following, the application is JAX-RPC
      [4/18/17 10:12:07:384 CDT] 00000099 GlobalSecurit > GlobalSecurityResponseHandler() Entry
      [4/18/17 10:12:07:384 CDT] 00000099 GlobalSecurit < GlobalSecurityResponseHandler() Exit
    • If you see lines like the following, the application is JAX-WS:
      [4/18/17 10:23:08:980 CDT] 0000009d WSSecurityCon > invoke(MessageContext msgContext) Entry
      [4/18/17 10:23:08:980 CDT] 0000009d SAMLTokenCach > cacheSAMLToken(MessageContext msgContext) Entry
  3. If you hit 'Outbound HTTP SOAP request', look back a few lines
    • If you see lines like the following, the application is JAX-RPC
      [4/18/17 10:12:07:306 CDT] 00000098 GlobalSecurit < handleRequest6(SOAPMessageContext, Object) Exit
      [4/18/17 10:12:07:306 CDT] 00000098 GlobalSecurit < handleRequest Exit
    • If you see lines like the following, the application is JAX-WS and WS-Security constraints are active:
      [4/18/17 10:32:16:624 CDT] 000000bb WSSecurityCon > removeContext() Entry
      [4/18/17 10:32:16:624 CDT] 000000bb WSSecurityCon < getThreadId returns [187] Exit
      [4/18/17 10:32:16:624 CDT] 000000bb WSSecurityCon < removeContext Exit
      [4/18/17 10:32:16:624 CDT] 000000bb WSSecurityGen < invoke(MessageContext mcontext,WSSGeneratorConfig config) Exit
      [4/18/17 10:32:16:624 CDT] 000000bb WSSecurityGen < invoke(MessageContext msgContext) Exit
    • If you see lines like the following, the application is JAX-WS and WS-Security constraints are not active:
      [4/18/17 10:23:08:464 CDT] 000000ba WSSecurityGen 3 No PolicyType Binding
      [4/18/17 10:23:08:464 CDT] 000000ba WSSecurityGen 3 Application Generator Policy=null
  4. If there is some error that has caused the SOAP message to not be sent, a little more searching is required because many of the JAX-RPC and JAX-WS classes have the same base name. Here are some indicators that you may see in trace entries or stack trace outputs that can help you determine if an application is JAX-RPC or JAX-WS:
    • JAX-WS only:
      Axis2Util SecurityConte SAML*
      PrivateGenera *GenerateLoginModule *GenerateCallbackHandler
      PrivateConsum *ConsumeLoginModule *ConsumeCallbackHandler
      org.apache.axis2.*
    • JAX-RPC only:
      WSEMFRequestC WSEMFResponse *TokenConsumer
      WSEMFRequestG GlobalSecurit JAXRPCHandler
 

Finding the SOAP message that the WS-Security runtime will operate on

You can generally find the message upon which the WS-Security runtime will operate by searching for 'bound http' as described above. However, sometimes you may want to look at the message that the JAX-WS WS-Security runtime is operating on directly. You can do this by searching a WS-Security trace for this message in the generator path:
[1/28/16 9:31:46:351 CET] 000000f7 WSSGenerator 3 The original message to be processed by WSSGenerator:
And this one in the consumer path:
 
[1/28/16 9:31:44:992 CET] 000000f7 WSSConsumer 3 The original message to be processed by WSSConsumer:
This is most interesting in the generator path because you can see the SOAP message as it exists before any security constraints have been added to it. You can also see if a Security header already exists on the message before the WS-Security handler starts working on it (this is not normal in the generator path).
 

In a WS-Security trace, where are the bounds when the WS-Security process stops and ends?

Knowing the strings to look for when the WS-Security processing starts and ends holds the most value when you have more than just WS-Security tracing turned on. Here are examples of the start/stop points for the JAX-WS WS-Security runtime in a trace:
  • Generator path:
    • Start of processing:
      [1/28/16 9:31:46:348 CET] 000000f7 WSSecurityGen > invoke(MessageContext msgContext) Entry
      [1/28/16 9:31:46:348 CET] 000000f7 WSSecurityGen 3 runningCommonComponent=false
      [1/28/16 9:31:46:348 CET] 000000f7 WSSecurityGen 3 mayCacheTokens=false
    • End of processing:
      [1/28/16 9:31:46:405 CET] 000000f7 WSSecurityCon > removeContext() Entry
      [1/28/16 9:31:46:405 CET] 000000f7 WSSecurityCon < getThreadId returns [137] Exit
      [1/28/16 9:31:46:405 CET] 000000f7 WSSecurityCon < removeContext Exit
      [1/28/16 9:31:46:405 CET] 000000f7 WSSecurityGen < invoke(MessageContext mcontext,WSSGeneratorConfig config) Exit
      [1/28/16 9:31:46:405 CET] 000000f7 WSSecurityGen < invoke(MessageContext msgContext) Exit
  • Consumer path:
    • Start of processing:
      [1/28/16 9:31:44:956 CET] 000000f7 WSSecurityCon > invoke(MessageContext msgContext) Entry
      [1/28/16 9:31:44:956 CET] 000000f7 SAMLTokenCach > cacheSAMLToken(MessageContext msgContext) Entry
      ...
      [1/28/16 9:31:44:989 CET] 000000f7 WSSConsumer > invoke(OMNode target[null], Map context) Entry
    • End of processing:
      [1/28/16 9:31:45:355 CET] 000000f7 WSSecurityCon < invoke(WSSMessageContext mcontext,WSSConsumerConfig config) Exit
      ...
      [1/28/16 9:31:45:355 CET] 000000f7 WSSecurityCon < _invoke(MessageContext msgContext) Exit
If you want to restrict your trace to the beginning/end of WS-Security processing to perhaps debug a performance problem, here is a suggested trace specification:
*=off:com.ibm.ws.wssecurity.handler.WSSecurityConsumerHandler=finer:com.ibm.ws.wssecurity.handler.WSSecurityGeneratorHandler=finer:com.ibm.ws.webservices.trace.*=all:com.ibm.ws.websvcs.trace.*=all

*=off will turn off informational messages for all components. ().trace.*=all will emit the inbound and outbound HTTP messages. The finer specification for WSSecurityConsumerHandler and WSSecurityGeneratorHandler will enable entry/exit tracing on those two classes so that you can follow the instructions shown above.
 

How can I see how much time is spent in my endpoint?

Part of the WS-Security trace specification is com.ibm.ws.websvcs.utils.SecurityContextMigrator=*=all. The thread migrators in the SecurityContextMigrator class run very close to when the endpoint is invoked. You can either use all or finer for the trace specification for this class. To see the time spent in the endpoint, you'll want to look for the time between migrateContextToThread Exit and migrateThreadToContext Entry:

[7/19/16 14:01:12:478 CDT] 0000008e SecurityConte < migrateContextToThread Exit
....
[7/19/16 14:01:12:525 CDT] 0000008e SecurityConte > migrateThreadToContext Entry
In this example, the endpoint took approximately .047 seconds to execute.
 

How to see an element before it is signed or encrypted (full profile)

In a full profile trace, to find information about elements that are signed or encrypted, search a WS-Security trace for the string ResourceShower. You'll see elements in the following conditions:
  • Before digest value calculation, but after canonicalization
  • Before signature value calculation, but after canonicalization
  • Before encryption
  • After decryption
Here is an example of an element shown when calculating a digest value for the Body for an outbound message:
[2/1/16 19:21:58:284 CST] 0000006c SignatureGene 3 ResourceShower logs sign-#wssecurity_signature_id_20:
[2/1/16 19:21:58:284 CST] 0000006c SignatureGene 3 <soapenv:Body xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="wssecurity_signature_id_20"><a:sayHello xmlns:a="http://samples"><name>a</name></a:sayHello></soapenv:Body>
[2/1/16 19:21:58:284 CST] 0000006c ReferenceProc 3 returning reference processors digestValue=lgmF3cOjRaIFkvISSAJuzBQYYVA=
Here is an example of an element shown when calculating a signature value for an outbound message. The signature value is calculated across the SignedInfo element only. Notice that the digest value is in this XML, but not the signature value.
 
[2/1/16 19:21:58:284 CST] 0000006c SignatureGene 3 ResourceShower logs sign-SignedInfo:
[2/1/16 19:21:58:284 CST] 0000006c SignatureGene 3 <ds:SignedInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:wsa="http://www.w3.org/2005/08/addressing" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"><ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#WithComments"><ec:InclusiveNamespaces xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="soapenv wsa wsse ds "></ec:InclusiveNamespaces></ds:CanonicalizationMethod><ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"></ds:SignatureMethod><ds:Reference URI="#wssecurity_signature_id_20"><ds:Transforms><ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"><ec:InclusiveNamespaces xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="a soapenv wsu "></ec:InclusiveNamespaces></ds:Transform></ds:Transforms><ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"></ds:DigestMethod><ds:DigestValue>lgmF3cOjRaIFkvISSAJuzBQYYVA=</ds:DigestValue></ds:Reference></ds:SignedInfo>

How to see an element after it is decrypted (Liberty)

In Liberty trace, to find information about elements after they are decrypted, search a Liberty WS-Secruity trace for the string "decryptElement Decrypted octets"

Here is an example of a decrypted UsernameToken from a Liberty trace:
[8/24/16 14:29:36:079 EDT] 00000038 id= org.apache.xml.security.encryption.XMLCipherInput 1 getDecryptBytes Encrypted octets:
oJO5kWxJfAa66HRum+C6+HsESuU4MEa7N9AWXEWTrDV7V2VNc4PTkmHxDAeZXA7bC3CpCKmyHzKe1t81GP4oskAKwub4zXJHrvT9dBxlsvYQZl2M660o4ewbDHhBwtdSmbTm2BprTBftUsImpQ3DZfls4jCOmbart4wkOY3tipfk+0fZSF4P8ydomW0Arh1pB+sX+FH9vNETgOQsIhJlVO7h/peCWWNN165LJcTENE3GVrvNBGnvfLvf3gVnzqL+q8Eq+ZObn4tiELyj5ciIQbrNEEXalD3zgtUZC+XSXHREWU4N9CNjK3WLjEwTfv/NCBgV7a6cBU9FhVju/FFp9IgZWJQqBFAIVu+C3nIGsf8hWkjIxxnAIEFoaJvSi13x/a3nKtppTeNmTgbv3zDY7FVRsX9aJyTqrJapabRD6CugRmoQNfZHznLMRuSwNFXXN6s++epDHYpjlyQ/wXIqKI83AdBFdm4GZ4nOh+H375mkQJEs9wtUko7bo5PqYXmfOkeYhKdML/LyxfAhSk4Duw==
[8/24/16 14:29:36:079 EDT] 00000038 id= org.apache.xml.security.algorithms.JCEMapper 1 translateURItoJCEID Request for URI http://www.w3.org/2001/04/xmlenc#aes128-cbc
[8/24/16 14:29:36:079 EDT] 00000038 id= org.apache.xml.security.encryption.XMLCipher 1 decryptToByteArray JCE Algorithm = AES/CBC/ISO10126Padding
[8/24/16 14:29:36:080 EDT] 00000038 id= org.apache.xml.security.encryption.XMLCipher 1 decryptElement Decrypted octets:
<wsse:Username>barb</wsse:Username><wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">test</wsse:Password><wsse:Nonce EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary">WCLVMN6fIfPlCgL9F+YOjQ==</wsse:Nonce><wsu:Created>2016-08-24T18:29:28.804Z</wsu:Created>
 

Debugging a Must Understand check

A SOAP Security header looks like this:

<wsse:Security soapenv:mustUnderstand="1" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
When there is a Security header in the SOAP message, but the application is not expecting to receive one, this error will occur in the JAX-WS runtime:
 
org.apache.axis2.AxisFault: Must Understand check failed for headers: {http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd}Security

This error can originate from a client or provider application. When a WebSphere JAX-WS application emits this error, it is caused by one of the following:
  • No inbound WS-Security constraints applied to the application
  • The policy was not loaded properly
  • The inbound bindings were not loaded properly

When you see this error on a client application, you should determine if the error was received in a SOAP response or if the error originated from itself. To see if the error was received in a SOAP response, do the following steps with a WS-Security trace:
  1. Find the Must Understand check failed for headers error in the trace.
  2. Find the inbound SOAP message by searching backwards for "Inbound HTTP" on the same thread (or WSWS3570I if your messages are not in English).
  3. If the Must Understand check failed for headers error is in the inbound SOAP message, then the error originated on the service provider. If not, it originated on the client.
  4. Perform the rest of your problem determination on the point of origin.

If there is no inbound policy attached, you will see an entry like the following in a WS-Security trace:
WSSecurityCon 3 No PolicyType Binding

If you don't see that, search backwards in the trace from the error point for "not loaded properly". If you see this, there was an error loading the policy or bindings for the application.
 

Checking if Security constraints are applied for generating a request on a client

When you are expecting a SOAP message to contain a Security header, but it does not, you will most likely see entries like the following in a WS-Security trace. This trace entry means that there is no outbound policy set attached to the application.

 
A trace snip is from a client on the request message:
WSSecurityGen > invoke(MessageContext msgContext) Entry
Axis2Util 3 getAxisService().isClientSide() = true
WSSecurityGen 3 isServerSide=false
WSSecurityGen 3 Get policy for application
WSSecurityGen 3 No PolicyType Binding
WSSecurityGen 3 Application Generator Policy=null
WSSecurityGen < invoke(MessageContext msgContext) Exit
 

Checking if Security constraints are applied for consuming a response on a client

This trace snip is from a client on the response message:

WSSecurityCon > invoke(MessageContext msgContext) Entry
Axis2Util 3 getAxisService().isClientSide() = true
WSSecurityCon 3 isServerSide == false
WSSecurityCon 3 No PolicyType Binding
WSSecurityCon 3 Cannot find WSSAPI_CONFIG_KEY_CONSUMER on MessageContext Options. Look in WSS_PROPERTYMAP property map.
TokenHolder > getPropertyMapFromInboundMessageContext(MessageContext messageContext Entry
TokenHolder 3 Looking for WSS_PROPERTYMAP in the inbound message context
TokenHolder < getPropertyMapFromInboundMessageContext(MessageContext messageContext) returns = null Exit
WSSecurityCon 3 WSS_PROPERTYMAP map not found.
WSSecurityCon 3 WSSAPI consumer bindings not found. Response message will not be processed by web services security.
 

Authorization fails for a WS-Security protected EJB

When authorization fails for a WS-Security protected EJB, you'll see an error like the following (note the ??? in the message):

WSWS7179E: The system encountered the following exception during request processing:
org.apache.axis2.AxisFault: java.rmi.AccessException: ; nested exception is:
com.ibm.websphere.csi.CSIAccessException: SECJ0053E: Authorization failed for ???
while invoking (Bean)highavailabilityEcho#echo.jar#Echo echo:java.lang.String:5 null
An exception like the one above may appear in a trace or a SOAP response in the following conditions:
  • The endpoint is a JAXWS application
  • The endpoint is an EJB
  • There are authorization constraints on the EJB
  • The WS-Security policy set binding does not have a caller defined in the binding for the inbound token

We get into this condition when there are authorization constraints on the EJB, but there is no subject on the thread. When base security checks authorization, there is no subject on the thread resulting in an NPE on a toString method call. Here is an example FFDC:
 
Exception:java.lang.NullPointerException SourceId:com.ibm.ws.security.core.SecurityCollaborator.performAuthorization ProbeId:468 Reporter:com.ibm.ws.security.core.EJSSecurityCollaborator@5e085e08
java.lang.NullPointerException
at com.ibm.ws.security.core.WSAccessManager.checkAccess(WSAccessManager.java:436)
at com.ibm.ws.security.core.SecurityCollaborator.ejbCheckAuthorization(SecurityCollaborator.java:1479)
at com.ibm.ws.security.core.SecurityCollaborator.performAuthorization(SecurityCollaborator.java:515)
at com.ibm.ws.security.core.EJSSecurityCollaborator.preInvoke(EJSSecurityCollaborator.java:245)
at com.ibm.ejs.container.EJSContainer.preInvokeAfterActivate(EJSContainer.java:4058)
at com.ibm.ejs.container.EJSContainer.EjbPreInvoke(EJSContainer.java:3345)
at com.ibm.ejs.container.WSEJBWrapper.ejbPreInvoke(WSEJBWrapper.java:174)
at com.ibm.ws.websvcs.server.WSInvocationListener.requestReceived(WSInvocationListener.java:306)
at com.ibm.ws.websvcs.server.WSInvocationListener.notify(WSInvocationListener.java:86)
at org.apache.axis2.jaxws.server.EndpointController.requestReceived(EndpointController.java:606)

Remediation:

The solution to this is to add a Caller config to the WS-Security policy binding for the inbound token. For example, for an LTPA token:
  1. Edit the policy set bindings (default/general/custom)
  2. Click WS-Security->Main Policy->Caller->New
    • Name: ltpaCaller
    • Caller identity local name: LTPAv2
    • Caller identity URI: http://www.ibm.com/websphere/appserver/tokentype
  3. Save
  4. Reload the bindings
    • If using a general binding, restart the application server.
    • If using an application specific binding, restart the application.
Here is the knowledge center link for setting a caller in the WS-Security bindings: Caller Settings

CWWSS5612E: Encrypting the data produced the following exception: java.security.InvalidKeyException: Wrong length: 162 (JAX-WS)

This error occurs when 'Data Encryption' has been selected for the 'Usage of key information references' on the configuration for the encrypted part when doing asymmetric encryption. This error will not occur on JAX-RPC because there is no option to do symmetric encryption.

The problem is solved by changing the 'Usage of key information references' in the encryption part in the policy set bindings to 'Key encryption'. Here is a path for how to get there in the admin console:
Services->Service clients->(clientName)->(bindingName)->WS-Security->
Authentication and protection->(encPartName)

A sample trace file entry is:
 
WSSObjectEncr E CWWSS5612E: Encrypting the data produced the following exception: java.security.InvalidKeyException: Wrong length: 162
at com.ibm.ws.wssecurity.xml.xss4j.enc.EncryptionEngineImplAES128CBC.init(EncryptionEngineImpl.java:1820)
at com.ibm.ws.wssecurity.xml.xss4j.enc.EncryptionContext.getEncryptionEngine(EncryptionContext.java:692)
at com.ibm.ws.wssecurity.xml.xss4j.enc.EncryptionContext.getEncryptionOutputStream(EncryptionContext.java:647)

  Avoid trouble: When configuring an encryption part in the WS-Security application specific bindings, never change the value for 'Usage of key information references' from the default.
 

CWWSS6001E: Key object was not obtained.; WARNING: SecurityToken whose identifier is "x509Id1" was not found in the Subject. (JAX-WS)

One cause of 'CWWSS6001E: Key object was not obtained' is that a security token required by a digital signature appears after the Signature element instead of before it.


Debug procedure:

When you get CWWSS6001E: Key object was not obtained, you can do the following steps using a WS-Security trace to confirm this:

  1. From the error point, search backwards for 'WARNING: SecurityToken whose identifier is "xxxxx" was not found in the Subject.' on the same thread.
  2. If you have this, check the Security header in the SOAP message to see if the identifier is a reference from a digital signature.
    • Search backwards for 'Inbound HTTP' on the same thread to find the inbound message being processed.
  3. If the identifier is a reference from a digital signature, then check to see if the token that is being referenced appears befor or after the Signature element.

The WebSphere WS-Security runtime only supports a Signature with a Reference in a KeyInfo that points to a token that appears before the Signature element, not after. Here is an example of a KeyInfo element:

<ds:KeyInfo Id="kiId1">
<wsse:SecurityTokenReference wsu:Id="strId1">
<wsse:Reference URI="#x509Id1" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3">
</wsse:Reference>
</wsse:SecurityTokenReference>
</ds:KeyInfo>

Remediation:

If you find that your problem is that the referenced token appears after the Signature element and not before it, your only solution is to modify the partner so that it sends the message in the required format.

The OASIS Web Services Security: SOAP Message Security 1.0 specification (open this link in a new tab or window) says this:
960 For processing efficiency it is RECOMMENDED to have the signature added and then the 961 security token pre-pended so that a processor can read and cache the token before it is used.

The specification says recommended, but the WebSphere WS-Security runtime requires it.
 

Core validity=false Signed info validity=true Signed info message='null'(validity=false message='Digest value mismatch: calculated: KCuNwlUAk5+G2PYb8fZ+Y1hTMtw=' uri='#wssecurity_signature_id_23' type='null')

You may see this error prepended by "CWWSS5620E: Signature verification failed:" when using WS-Security or by "CWWSS8013E: The Signature element in the SAML Assertion is not valid." when using SAML Web Single Sign-on.
This error means that the digest value that the sender calculated and put in the message is different than what the WebSphere runtime calculated. The digest value is calculated from the canonicalized form of the message part being signed (in this case, wssecurity_signature_id_23).

You will get this error if the message part was changed in any way after it was signed. For example, this error is expected when a SOAP message is obtained from a trace or some other method, beautified, then sent to the server using a test client such as SOAPUI. If one or more of the message parts is signed, the signature verification step will fail every time. The way to fix this is to put the message back the way it was before it was beautified (usually all on one line).

Another common problem is when attributes or elements are added to the signed part after being signed. If you want to add attributes or elements to an existing signed part, the part must be re-signed. This can happen with SAML tokens. There are APIs available to re-sign SAML tokens in the application server. For additional information on using the SAML APIs to re-sign SAML tokens, see Adding attributes and re-signing existing SAML tokens by using the API topic in the Knowledge Center and the javadoc for the com.ibm.websphere.wssecurity.wssapi.token.SAMLTokenFactory class.

If you are sure that the message part was not modified after it was signed, then you may have some work on your hands. When there is no chance that the message was changed after signature, digest value mismatch errors are notoriously difficult to debug. In order to proceed, you must have the canonicalized form of the message part being signed from both sides. IBM support cannot debug these problems without a copy of the canonicalized form of the message part being signed from the partner. If you plan to call IBM support, if you do not have this information, you will be required to obtain it or the problem cannot be debugged.

Avoid trouble: When SOAPUI is a partner, digest value mismatch errors are very common. If you receive a digest value mismatch on the application server from a request sent from SOAPUI, it is recommended that you try another web services runtime with a WS-Security implementation, preferably the implementation that you intend to use in production. IBM support cannot debug digest value mismatch problems where SOAPUI is the partner because of its prevalence for instigating digest value mismatch errors.
Debug procedure:

To find the canonicalized form of the message part being signed by the WS-Security runtime in a WebSphere trace, do the following steps. Make sure that you use trace statements from the same thread.
  1. Find the instance of your 'Digest value mismatch' error in your WebSphere trace.
  2. Search backwards in the trace for 'resourceshower'; after this line is the canonicalized form of the message part that failed digest validation.
  3. Now is the hard part: you will need to obtain the canonicalized form of the message part being signed from the partner.
    1. If the partner is running on the WebSphere Application Server, client, or another product that uses the application server, you can find this information by finding the outbound message in a WS-Security trace, then searching backwards for resourceshower. You can find each inbound and outbound message by repeatedly searching for 'bound http'.
    2. If the partner is not running on some form of the application server, you will need to consult the documentation provided by your partner's implementation for how to obtain this information.
  4. After you have obtained the canonicalized form of the message from each side, compare them. You may be able to see the cause of the error when you do this (like the message was really changed).
 

Core validity=false Signed info validity=false Signed info message='SignatureValue mismatched.' Ref[0](validity=true message='Ok.' uri='#wssecurity_signature_id_20' type='null').

You may see this error prepended by "CWWSS5620E: Signature verification failed:" when using WS-Security or by "CWWSS8013E: The Signature element in the SAML Assertion is not valid." when using SAML Web Single Sign-on.

'IllegalBlockSizeException probably due to the wrong token factory.' when consuming an LTPA token(JAX-WS)

When you get an IllegalBlockSizeException when attempting to consume an LTPA token, it is probably because the LTPA keys are out of sync between the client and the app server. The following error is emitted from base security (com.ibm.ws.security.ltpa.*=all may have to be turned on):
[3/4/11 21:05:35:405 GMT-06:00] 00000013 LTPACrypto 3
IllegalBlockSizeException probably due to the wrong token factory.
javax.crypto.IllegalBlockSizeException:
If you think this is your problem, see Managing LTPA keys from multiple WebSphere Application Server cells for information on exchanging LTPA keys.

java.security.cert.CertPathBuilderException: unable to find valid certification path to requested target

-and-

java.security.cert.CertPathValidatorException: The certificate issued by EMAILADDRESS=test_it@us.ibm.com, CN=test_it, OU=AIM, O=IBM, ST=TX, C=US is not trusted; internal cause is: java.security.cert.CertPathValidatorException: Certificate chaining error

These two errors both occur during validation of trust. In effect, they both mean that the target certificate is not trusted.
  • The 'unable to find valid certification path to requested target' error occurs for self-signed certificates.
  • The 'Certificate chaining error' occurs for certificates that are not self-signed.
If you get this error and have a call stack that has information in it like one of the two sample stacks shown below, you can use a trace spec that includes the com.ibm.ws.wssecurity.util.CertificateUtil and class to debug the issue.
 
Caused by: java.security.cert.CertPathBuilderException: PKIXCertPathBuilderImpl could not build a valid CertPath.; internal cause is:
java.security.cert.CertPathValidatorException: The certificate issued by EMAILADDRESS=test_it@us.ibm.com, CN=test_it, OU=AIM, O=IBM, ST=TX, C=US is not trusted; internal cause is:
java.security.cert.CertPathValidatorException: Certificate chaining error
at com.ibm.security.cert.PKIXCertPathBuilderImpl.engineBuild(PKIXCertPathBuilderImpl.java:411)
at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:258)
at com.ibm.ws.wssecurity.util.CertificateUtil.buildCertPath(CertificateUtil.java:1163)
at com.ibm.ws.wssecurity.util.CertificateUtil.validateX509Certificate(CertificateUtil.java:991)
at com.ibm.ws.wssecurity.wssapi.token.impl.X509ConsumeLoginModule.validateX509(X509ConsumeLoginModule.java:1312)
Caused by: java.security.cert.CertPathBuilderException: unable to find valid certification path to requested target
at com.ibm.security.cert.PKIXCertPathBuilderImpl.buildCertPath(PKIXCertPathBuilderImpl.java:642)
at com.ibm.security.cert.PKIXCertPathBuilderImpl.engineBuild(PKIXCertPathBuilderImpl.java:357)
at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:258)
at com.ibm.ws.wssecurity.util.CertificateUtil.buildCertPath(CertificateUtil.java:1163)
at com.ibm.ws.wssecurity.util.CertificateUtil.validateX509Certificate(CertificateUtil.java:991)
at com.ibm.ws.wssecurity.wssapi.token.impl.X509ConsumeLoginModule.validateX509(X509ConsumeLoginModule.java:1312)
The signature validation code for WS-Security, SAML Web Single Sign-On, and SAML Web Inbound is common, so you may see these CertPath errors from any of these three components. The standard trace spec shown in the MustGathers for each of these three affected components include the CertificateUtil class. These two specific CertPath errors are debugged in the same manner for all three components.

Debug procedure:
  • From the error location in the trace, search backwards for this string on the same thread:
Final pkixParams before build
  • You should hit a line like this:
[6/20/16 11:06:21:358 CDT] 00000aa0 CertificateUt 3 Final pkixParams before build: [[
  • Immediately before that line is the SubjectDN of the target certificate that is being validated:
[6/20/16 11:06:21:358 CDT] 00000aa0 CertificateUt 3 CertPath Selector = java.security.cert.X509CertSelector
[6/20/16 11:06:21:358 CDT] 00000aa0 CertificateUt 3 SubjectDN = CN=myx509certP,OU=AIM,O=IBM,ST=TX,C=US
  • Immediately after 'Final pkixParams before build' is a dump of the pkixBuilderParameters object that will be passed to Java for certificate validation. It contains the 'Trust Anchors' (the trusted certificates from the configured trust store) and the CertStores (the configured intermediate certificates and CRLs).
  • The trust anchors are listed first. Example:
[6/20/16 11:06:21:358 CDT] 00000aa0 CertificateUt 3 Final pkixParams before build: [[
[
Trust Anchors: [TrustAnchor:
Trusted certificate: [
[
Version: V3
Subject: EMAILADDRESS=maruyama@jp.ibm.com, CN=SOAP 2.1 Test CA, OU=TRL, O=IBM, L=Yamato, ST=Kanagawa, C=JP
Signature Algorithm: SHA1withRSA, OID = 1.2.840.113549.1.1.5

Key: IBMJCE RSA Public Key:
modulus:
151815671200297152474531741886615989123851398406214888537347471732578193327842584827814067509810494992983852273819411989206435222009943977798309094853983586530095252209605320580841828903191753610454064740922273413324194562727499313145310057433925196905879003525759822291057367529079421182975263937478315157663
public exponent:
65537

Validity: [From: Wed Aug 06 12:46:29 CDT 2008,
To: Tue Aug 08 12:46:29 CDT 2023]
Issuer: EMAILADDRESS=maruyama@jp.ibm.com, CN=SOAP 2.1 Test CA, OU=TRL, O=IBM, L=Yamato, ST=Kanagawa, C=JP
SerialNumber: [24053590835798]
....
]]
  • After the trust anchors, you'll see a bunch of object settings. Example:
Initial Policy OIDs: any
Validity Date: null
Signature Provider: null
Default Revocation Enabled: false
Explicit Policy Required: false
Policy Mapping Inhibited: false
Any Policy Inhibited: false
Policy Qualifiers Rejected: true
Target Cert Constraints: X509CertSelector: [
AuthorityKeyIdentifier:null
BasicConstraints:-1
CertificateEquals:null
CertificateValid:null
ExtendedKeyUsage:null
IssuerAsString:null
KeyUsage:null
MatchAllSubjectAltNames:true
NameConstraints:null
PathToNames:null
Policy:null
PrivateKeyValid:null
SerialNumber:null
SubjectAlternativeNames:null
SubjectAsString:myx509certP,OU=AIM,O=IBM,ST=TX,C=US
SubjectKeyIdentifier:null
SubjectPublicKey:null
SubjectPublicKeyAlgID:null
]
 These settings will always be the same, with the exception of SubjectAsString and 'Default Revocation Enabled'. If there are any CRLs configured, revocation enabled should be set to true.
  • After the object settings, you can see if there are CertStores configured but you won't be able to see their contents:
CertStores: [[java.security.cert.CertStore@cdac2d64]]
  • Fortunately, when CertificateUtil trace is enabled, the code will loop through the CertStores and dump out the data. During this process, you'll see any configured intermediate certificates and CRLs. For instance:
[6/20/16 11:06:21:358 CDT] 00000aa0 CertificateUt 3 Certificate data in final pkixParams:
[6/20/16 11:06:21:358 CDT] 00000aa0 CertificateUt > listCertData(PKIXParameters pkixParams [not null]) Entry
[6/20/16 11:06:21:358 CDT] 00000aa0 CertificateUt 3 CertStore #1
[6/20/16 11:06:21:358 CDT] 00000aa0 CertificateUt > listCrlContents(Collection crlList [empty]) Entry
[6/20/16 11:06:21:358 CDT] 00000aa0 CertificateUt < listCrlContents(Collection) Exit
[6/20/16 11:06:21:358 CDT] 00000aa0 CertificateUt > listCertContents(Collection certList [populated]) Entry
[6/20/16 11:06:21:358 CDT] 00000aa0 CertificateUt 3 Subject: CN=Int CA2,OU=TRL,O=IBM,ST=Kanagawa,C=JP SN: 24053590835798=0x15e069bcc256
[6/20/16 11:06:21:358 CDT] 00000aa0 CertificateUt 3 [
[
Version: V3
Subject: CN=Int CA2, OU=TRL, O=IBM, ST=Kanagawa, C=JP
Signature Algorithm: SHA1withRSA, OID = 1.2.840.113549.1.1.5

Key: IBMJCE RSA Public Key:
modulus:
151815671200297152474531741886615989123851398406214888537347471732578193327842584827814067509810494992983852273819411989206435222009943977798309094853983586530095252209605320580841828903191753610454064740922273413324194562727499313145310057433925196905879003525759822291057367529079421182975263937478315157663
public exponent:
65537

Validity: [From: Wed Aug 06 12:46:29 CDT 2008,
To: Tue Aug 08 12:46:29 CDT 2023]
Issuer: EMAILADDRESS=maruyama@jp.ibm.com, CN=SOAP 2.1 Test CA, OU=TRL, O=IBM, L=Yamato, ST=Kanagawa, C=JP
SerialNumber: [24053590835798]
....
]
  • The last set of data you'll see is the complete target certificate. Example:
[6/20/16 11:06:21:358 CDT] 00000aa0 CertificateUt > listCertContents(Collection certList [populated]) Entry
[6/20/16 11:06:21:358 CDT] 00000aa0 CertificateUt 3 Subject: CN=myx509certP,OU=AIM,O=IBM,ST=TX,C=US SN: 14766=0x39ae
[6/20/16 11:06:21:358 CDT] 00000aa0 CertificateUt 3 [
[
Version: V3
Subject: CN=myx509certP, OU=AIM, O=IBM, ST=TX, C=US
Signature Algorithm: SHA1withRSA, OID = 1.2.840.113549.1.1.5

Key: IBMJCE RSA Public Key:
modulus:
95306119432043971238350080074805144703577410447453009619549837011144225476043184584412839578375342753734775209836161118573164405507805276060213787979718055461383171786713601185357039392565359202517338762175155317021016825993065895887980292683936785980390506314857602811956510374544653923234836835210637822189
public exponent:
65537

Validity: [From: Sat Feb 09 14:26:05 CST 2008,
To: Tue Feb 06 14:26:05 CST 2018]
Issuer: EMAILADDRESS=myx509root@us.ibm.com, CN=myx509root, OU=AIM, O=IBM, ST=TX, C=US
SerialNumber: [14766]
......
]
  • Then:
[6/20/16 11:45:40:576 CDT] 0000009a CertificateUt 3 listCertContents(Collection) Exit
[6/20/16 11:45:40:576 CDT] 0000009a CertificateUt 3 listCertData Exit
[6/20/16 11:45:40:576 CDT] 0000009a CertificateUt 3 Building the cert path...
followed by about 10 or so lines of trace, then the exception.

All the data that was dumped to the trace can be used to determine the cause of the error.
  • If you received the 'unable to find valid certification path to requested target' error, do the following:
  • Check to see if any of the trust anchors that are dumped match your target certificate.
  • Make sure that all the data matches, not just the SubjectDN string.
  • If you see a matching SubjectDN, check to see if the SerialNumbers match.
  • If you received the 'Certificate chaining error' error, do the following:
  1. Look at the information in your target certificate and note the Issuer.
  2. Check to see if its Issuer is either listed as a Trust Anchor or a CertStore.
    • If its not, then that is your problem.
  3. If it is, do the same thing for the Issuer's Issuer and so on.
    • Keep doing this until you find the one that is missing.
followed by about 10 or so lines of trace, then the exception.

You need to end up with an Issuer that is in the Trust Anchor list. For more information on this, see the 'Certificate Paths (CertPaths)' section on WebSphere WS-Security XML Digital Signature: Learning more about Web Services Security for WebSphere Application Server. There is a graphic on that page that describes what you are attempting to do with this process.


Remediation:
  Once you know what is wrong, how you go about fixing it is another matter. In the simplest sense:
 
  • If the certificate is self-signed, do one of the following:
    • Add the target certificate to the trust store.
    • Configure the component to trust any certificate.
    • Re-configure the partner to sign the message (or token) with a certificate that is already in the trust store.
  • If the certificate is not self-signed, do one of the following:
    • Add the target certificate to the trust store.
    • Add the missing Issuer certificates as an intermediate certificate.
    • Configure the component to trust any certificate.
    • Re-configure the partner to sign the message (or token) with a certificate that is already in the trust store.
You may already know what component is being run when the error occurred. However, if you don't, you can use the call stack to determine which component was being used when the error occurred. Look for one of the following methods in the call stack:
 
  • com.ibm.ws.wssecurity.saml.profile.saml20.sso.web.HTTPPOSTRequestConsumer.consumeSAMLResponse
  • com.ibm.ws.wssecurity.wssapi.token.impl.X509ConsumeLoginModule.login
    • If you see the X509ConsumeLoginModule.login method in the call stack, the runtime was processing a certificate in a SOAP message that was not inside a SAML token. Any adjustments to your config must be made to the X.509 token consumer.
    • If you want to add Trust any certificate to an X.509 token consumer, see step 6e-iii-1 in Configuring a policy set and bindings for Asymmetric XML Digital Signature and/or XML Encryption with client and provider general bindings. If you want to add intermediate certificates, see step 6e-iii-6 in the same document.
    • Note: For the X.509 token consumer, you need to look for the login method. If you look at the stack examples, you'll see that the X509ConsumeLoginModule class will appear in every stack that contains these two CertPath errors, no matter which of the three components is the originator.
  • com.ibm.ws.wssecurity.wssapi.token.impl.SAMLConsumeLoginModule.login
    • If you see the SAMLConsumeLoginModule.login method in the call stack, the runtime was processing a SAML token in a SOAP message when the error occurred. Any adjustments to your config must be made to the SAML token consumer.
    • If you want to add trustAnySigner or intermediate certificates to a SAML token consumer, see Web services security SAML token custom properties.
  • com.ibm.ws.security.web.inbound.saml.util.Decoder.createSAMLToken
    • If you see the Decoder.createSAMLToken method in the call stack, the SAML web inbound TAI is the originator of the error. The SAML web inbound TAI currently has no custom properties to support trust any, intermediate certificates or CRLs.
 

CWWSS5720E: A required message part [body] is not signed.

This message means that the policy says that Body of the SOAP message must be signed, but it was not signed in the inbound message. Here is another example; this one indicates that the WS-Addressing header was not signed:
CWWSS5720E: A required message part [http://schemas.xmlsoap.org/ws/2004/08/addressing] is not signed.
Here is the user action for the CWWSS5720E message:
Verify that the policies on both the client and the server specify the same SignedParts and SignedElements.

You will get this message in both of the following cases:
  • A Signature exists in the message, but the specific message part shown in the error message is not signed.
  • There is no Signature in the inbound message.
Debug Procedure:
  1. From the first occurrence of the CWWSS5720E message, search backwards for 'bound http' on the same thread:
    • If you hit 'Inbound HTTP SOAP Request', then this error is the result of the provider processing a client request.
    • If you hit 'Inbound HTTP SOAP Response', then this error is the result of the client processing a response from the provider.
  2. Inspect the inbound message to see if there is a Signature element:
    • If it exists then message is signed; the required part is just not signed.
    • If it does not, then look for EncryptedData in the inbound message.
      • If you see an EncryptedData block inside the Security header in the inbound message, the Signature is most likely encrypted so assumes its there.
Remediation:

You need to make the provider and client policies match.

As a general solution you can do one of the following if both the client and provider are running on WebSphere:
  • If the client and provider are running in the same profile:
    • Attach the same policy to both the client and provider.
  • If the client and provider are running in different profiles, do the following:
    1. Using the administrative console, export the provider's policy set from its profile.
    2. Using the administrative console, import the policy set to the client's profile.
    3. Attach the imported policy set to the client application.
    4. Restart your client application.
If the partner is not running WebSphere, or you just want to get surgical about the solution, do one of the following:
  • If the inbound message contains a Signature:
  • If the inbound message does not contain a Signature:
    Either remove the Signature from your policy or add it to the partner's policy:

    Avoid Trouble: If you need to add a Signature, its easier and safer to create a new policy from one that already has a Signature in it and customize the new policy the way you want it to be. If you follow through Step 1 and 2 of the document referenced below, you will end up with a customized policy that contains a Signature. You can then go back and add whatever you had in your old policy (like a UsernameToken or an LTPA token).
     
    1. If Message level protection is not checked, check it, then click Apply
    2. Click the protection part you want to add:
      • If you need to add a request signature, click Request message part protection
      • If you need to add a response signature, click Response message part protection
    3. Under Integrity protection, click Add
    4. Name of part to be signed = req_signpart
    5. You can now add parts to be signed. See step 2e-iii.

CWWSS5502E: The target element: saml:Assertion was not expected.

This message means that a SAML token was received, but one was not expected. Your first action would be to configure a SAML token consumer. But what if you already have a SAML token consumer? You probably have configured one type of SAML token in your policy and received the other type in the SOAP message (ie SAML11 vs SAML20).

Debug procedure:

  • In a WS-Security trace, find the first instance of the CWWSS5502E message. For instance:
[4/14/16 15:36:31:573 PDT] 000000f5 WSSConsumer E CWWSS5514E: An exception while processing WS-Security message: com.ibm.wsspi.wssecurity.core.SoapSecurityException: CWWSS5502E: The target element: saml:Assertion was not expected.
  •  Immediately before that line, you'll see a couple of trace statements that look like this that indicates the Assertion type:
[4/14/16 15:36:31:572 PDT] 000000f5 DOMUtil > getQualifiedName(OMNode node[org.apache.axiom.om.impl.llom.OMElementImpl --- {urn:oasis:names:tc:SAML:1.0:assertion}Assertion]) Entry
[4/14/16 15:36:31:573 PDT] 000000f5 DOMUtil < getQualifiedName(OMNode node) returns String[saml:Assertion] Exit
 
  • The SAML element namespace/localnames are:
    • SAML11: {urn:oasis:names:tc:SAML:1.0:assertion}Assertion
    • SAML20: {urn:oasis:names:tc:SAML:2.0:assertion}Assertion
  • If you want to go back to see the entire assertion, you can back up to 'getSecurityHeaders'.
  • Search backwards for WSSConsumerConfig on the same thread to see the current configuration. This configuration object is very dense. What you're looking for is the the entry for the SAML token consumer in the set of tokenConsumers. For example:
[com.ibm.ws.wssecurity.confimpl.PrivateConsumerConfig$TokenConsumerConfImpl(className=[com.ibm.ws.wssecurity.wssapi.token.impl.CommonTokenConsumer], type=[http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0], jaasConfig=[system.wss.consume.saml], jaasConfigProperties=[{}], callbackHandler=[com.ibm.ws.wssecurity.confimpl.PrivateCommonConfig$CallbackHandlerConfImpl(className=[com.ibm.websphere.wssecurity.callbackhandler.SAMLConsumerCallbackHandler], keyStore=[null], keyInformation=[null], trustAnyCertificate=[true], provider=[null], pkixBuilderParams=[null], userId=[null], userPassword=[XXXXXXXX], properties=[{crossDomainIdAssertion=true, trustedIssuer_0=http://any.com/adfs/services/trust,groupName_1=http://schemas.xmlsoap.org/claims/Group, trustStoreRef=name=IDPTrustStore managementScope= (cell):cell01, tokenRequest=propagation}])], usedForVerification=[false], usedForDecryption=[false], enforceTokenVersion=[false], certPathSettingsAcquired=[true], isDefault=[true], properties=[{}])]
  • The SAML token types are:
    • SAML11: http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV1.1
    • SAML20: http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0
  • You see in this example, a SAML20 token is configured, but a SAML11 token was received.
Remediation:

Do one of the following:
  1. Update your partner to send the SAML token type that you are expecting.
  2. Update your configuration to expect the SAML token type that is being received.
The SAML token type is stored in the WS-Security policy that is attached to the application. To find the token identifier, in the administrative console, navigate to Services > Policy sets > Application policy sets > (policySetName) > WS-Security > Main policy > Request token policies > (tokenIdentifier)
  • If you have attached an 'Editable' policy, you can change the Local part from http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV1.1 -to- http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0 and vice versa.
  • If you attached a 'Not Editable' policy set, you must locate the matching policy of the 'other' token type and attach that to your application in place of the one that has the wrong token type.

CWWSS5555E: The mustUnderstand attribute on the Security header does not have the required value: existing value=null, required value=true

This error message will only be emitted if a Security header exists in the SOAP header before the WS-Security generator handler is invoked. When the WS-Security generator scans the SOAP message before processing, if a Security header exists and it does not contain a mustUnderstand attribute whose value is '1', it will emit the CWWSS5555E error. You will get the error if the attribute does not exist or if attribute exists and its value is not '1'.

This condition can only happen if an application has added a Security header to the message before the WS-Security generator starts processing the message. Perhaps another handler is registered that added the Security header, or the wsdl for the application has information from the Security schema.

This issue can be confirmed with a WS-Security trace.
Debug procedure:
 
  • In a WS-Security trace, find the first instance of CWWSS5555E.
  • Search backwards for 'to be processed' on the same thread. You should encounter a line like this:
    [03.06.16 14:14:32:449 CEST] 0000009a WSSGenerator 3 The original message to be processed by WSSGenerator:
  • Look at the SOAP message that is dumped in the trace a couple of lines later; it probably has a Security header in it and that Security header most likely does not have a mustUnderstand='1' attribute. Examples:
    <wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" soapenv:mustUnderstand="0"><wsse:UsernameToken><wsse:Username>myuser</wsse:Username><wsse:Password>mypwd</wsse:Password></wsse:UsernameToken></wsse:Security>
    <ns3:Security xmlns:ns3="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns="http://super.something" xmlns:ns4="urn:big-island-types:v1.2" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:nil="true"></ns3:Security>
Remediation:
This cannot be 'fixed' by any configuration of the JAX-WS WS-Security runtime. You must make sure that the SOAP message is in a form that the handler can use before it is invoked.

Do one of the following:
  1. Modify your application to add the mustUnderstand='1' attribute to the Security header.
  2. Modify your application to not include a Security header in the message.

CWWSS5514E: An exception while processing WS-Security message: com.ibm.wsspi.wssecurity.core.SoapSecurityException: CWWSS6521E: The Login failed because of an exception: javax.security.auth.login.LoginException: Login Failure: all modules ignored

This is a 'catch all' error when an unexpected error occurs in one of the token generator or token consumer login modules. Unfortunately, the important call stacks are missing in most cases.

One error that we can easily diagnose from the trace is when you are using an LTPA token generator.
 
Debug procedure:
  • In a WS-Security trace, find the first instance of 'all modules ignored'. Make sure it is preceeded by the CWWSS6521E tag.
[6/24/16 16:08:06:378 CDT] 000000b6 WSSecurityGen E CWWSS5514E: An exception while processing WS-Security message: com.ibm.wsspi.wssecurity.core.SoapSecurityException: CWWSS6521E: The Login failed because of an exception: javax.security.auth.login.LoginException: Login Failure: all modules ignored
  •  Look back just a couple of lines in the trace to see if you see this:
[6/24/16 16:08:06:346 CDT] 000000b6 LTPAGenerateL 3 Obtaining LTPAv2 token.
[6/24/16 16:08:06:346 CDT] 000000b6 LTPAGenerateL 3 Could not find internally implemeted SSO token.
[6/24/16 16:08:06:346 CDT] 000000b6 LTPAGenerateL 3 tokenFromSubject: [null]
[6/24/16 16:08:06:346 CDT] 000000b6 LTPAGenerateL < login() Exit
[6/24/16 16:08:06:346 CDT] 000000b6 LTPAGenerateL > abort() Entry
[6/24/16 16:08:06:346 CDT] 000000b6 LTPAGenerateL < abort() Exit
  •  If you see that, then look back just a few more lines for this:
[6/24/16 16:08:06:346 CDT] 000000b6 WSSContextImp 3 Retrieving security context on MessageContext
[6/24/16 16:08:06:346 CDT] 000000b6 LTPAGenerateL 3 Subject: Subject:
Principal: /UNAUTHENTICATED
Public Credential: com.ibm.ws.security.auth.WSCredentialImpl@56bb01a2
If this is what you see, then your issue is that your LTPA token generator has nothing to generate. There is no username and password configured and there is no identity on the runAs subject. The LTPA token generator must have something to generate or an error will occur.
Remediation:
Do one of the following:
 
 
  1. Configure an username and password in the LTPA token generator callback handler.
  2. Ensure that the runAs subject is set before the LTPA token generator is invoked.
This is going to be the tricky part. Unless you mastered the entire flow yourself, you may not know who is supposed to be setting the runAs subject. It could be coming from several places:
  • An upstream web services invocation
  • The Web container via HTTP BASIC Authentication
  • An upstream TAI invocation (like SAML Web SSO)
  • A stacked product (like WebSphere Portal)
If the runAs subject was supposed to come from an upstream web service invocation, you need to make sure that you have a caller configuration for the identity token in the provider bindings. See Caller settings for more information.

If the runAs subject was supposed to be set by a component other than WS-Security, remediation is beyond the scope of this document. However, you now have more information about what is causing your problem.

CWWSS6500E: There is no caller identity candidate that can be used to login.

This error means that there is at least one caller configuration in the WS-Security bindings and there were no tokens in the inbound message that match any of the caller configurations. In simple terms for the most common case, the single token specified as a caller does not exist in the inbound message


The following debug procedure applies to debugging the CWWSS6500E error when you are using a direct token reference by token type. In other words, you are not using a signing part reference. Direct token reference is the most common scenario.

Debug procedure:
  1. In a WS-Security trace of the provider, find the first instance of CWWSS6500E.
    [10/30/17 17:26:49:485 EDT] 0000008b WSSecurityCon E CWWSS5514E: An exception while processing WS-Security message: com.ibm.wsspi.wssecurity.core.SoapSecurityException: CWWSS6500E: There is no caller identity candidate that can be used to login.
  2. Search backwards from that point for callerIdentity (it should be only a couple of lines up)
    [10/30/17 17:26:49:485 EDT] 0000008b LoginProcesso > invokeLoginModule(Set cconfigs[[com.ibm.ws.wssecurity.confimpl.PrivateConsumerConfig$CallerConfImpl(jaasConfig=[system.wss.caller], jaasConfigProperties=[{}], callbackHandler=[null], useIdentityAssertion=[false], trustAnyTrustedIdentity=[true], callerIdentity=[{http://www.ibm.com/websphere/appserver/tokentype}LTPAv2], trustedIdentity=[null], requiredSigningPartReference=[null], order=[1])]], Map context) Entry
  3. Note the caller identity, expressed as one of the following:
    • {namespaceURI}localPart : Only LTPA tokens are configured this way. Example:
      {http://www.ibm.com/websphere/appserver/tokentype}LTPAv2
    • localPart, example:
      http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#UsernameToken
  4. Search backwards for the inbound SOAP message on with same thread with 'bound http'.
    • If you don't get any hits for 'bound http':
      • Try searching backwards for 'to be processed by WSSConsumer'.
      • Check your trace spec
      • Make sure your trace was from app server startup
      • Check for trace rollovers
  5. When you find the inbound SOAP message for the thread where the CWWSS6500E occurred, check the following:
    1. Is there a Security header? : probably yes, or you would have gotten a different error
    2. Does the Security header contain a token that matches the caller identity that you noted on step #3?
      • If you think that the answer is yes, look very closely at the value type of the token to make sure that it matches the configured caller identity.
      • Did you use {namespaceURI}localPart when you should not have (or vice versa).
      • Copy the text from the callerIdentity trace statement and search for it in the inbound message. This is an easy way to catch misspellings.

Remediation:
  • If there is an error in the caller configuration (for example, spelling or namespace/local part), fix the caller configuration in the provider's WS-Security bindings, then restart the application server.
  • If the inbound message does not contain a token with the configured caller identity, do one of the following:
    • Ensure that the client sends the security token specified in the caller configuration.
    • Remove the caller configuration from the provider's WS-Security bindings, then restart the application server.

See the Caller settings topic in the Knowledge Center for additional information on how to configure a Caller in the WS-Security provider bindings.

[{"Product":{"code":"SSEQTP","label":"WebSphere Application Server"},"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Component":"Web Services Security","Platform":[{"code":"PF002","label":"AIX"},{"code":"PF010","label":"HP-UX"},{"code":"PF012","label":"IBM i"},{"code":"PF016","label":"Linux"},{"code":"PF027","label":"Solaris"},{"code":"PF033","label":"Windows"},{"code":"PF035","label":"z\/OS"},{"code":"PF013","label":"Inspur K-UX"}],"Version":"9.0;8.5.5;8.5;8.0;7.0","Edition":"Base;Network Deployment;Single Server","Line of Business":{"code":"LOB45","label":"Automation"}}]

Document Information

Modified date:
25 October 2019

UID

swg21975329

Page Feedback