TroubleShoot: WebSphere WS-Security General Errors

Overview

javax.xml.ws.soap.SOAPFaultException: Internal Error -or- Exception: javax.xml.ws.soap.SOAPFaultException: Internal Error Message: Internal Error

This is what the response message will look like:

HTTP 401/403/404 Errors

When you receive an HTTP 403 from a service that means that the request failed authorization of the HTTP basic auth information in the HTTP header at the web container level. This could mean that either the authentication has failed, or the user is not authorized.

WSEC5524W: The server cannot find the Web service security header with actor: actor (JAX-RPC)

WSEC5524W will occur when there are security constraints defined for the application, but there is no WS-Security header in the inbound message.

Following are the explanation and action defined in the message file:

Explanation: The SOAP message might not have security constraints defined, or the actor on the server and client does not match.

Action: Verify that the client has Web services security configured and that the actor matches on both the client and the server. If you are using an IBM JAX-RPC Client, verify that the Java 2 Platform, Enterprise Edition (J2EE)-based Service Client (JSR-109) Programming Model is used to look up the service. For example, the service look-up process needs to use the Java Naming and Directory Interface (JNDI).

 

WSEC5048E: One of "SOAP Header" elements required. (JAX-RPC)

This means that there are WS-Security constraints on the application, but there are no SOAP headers in the inbound message.

CWWSS5048E: One of the SOAP Header elements is required. (JAX-WS)

This means that there are WS-Security constraints on the application, but there are no SOAP headers in the inbound message.

Validation of LTPA token failed due to invalid keys or token type. (JAX-RPC and JAX-WS)

When an LTPA token is sent from one WebSphere cell to another, the LTPA token will not authenticate unless the LTPA keys are exchanged. When the keys have not been exchanged and an LTPA token is sent from one cell to the other, you'll see a message like the following embedded within the fault string:

'java.security.InvalidKeyException: Illegal key size' when decrypting(JAX-WS)

When you get an Illegal key size exception when decrypting the message, it is probably because the message was encrypted using 192 bit (aes192-cbc) or 256 bit (aes256-cbc) encryption algorithm, but the consumer which is trying to decrypt the message does not have the unrestricted policy files installed. Here is the IBM Documentation documentation on unrestricted policy files: WebSphere Application Server security standards configurations.

CWWSS6095E: ... EncryptedKeySHA1 is found. (JAX-WS)

CWWSS7509W: The received SOAP request message is rejected becasue it does not correctly specify SOAP action and WS-Addressing action while there is at least one PolicySet attachment at operation level of the xyz service. (JAX-WS)

If you want to attach a WS-Security policy to a provider at the operation level, then either the inbound HTTP header must contain a SOAPAction or there must be a WS-Addressing header with an action in the SOAP message. In the case where there is no SOAPAction or WS-Addressing action, you can only attach a policy at the Application, Service or Endpoint level.

How can I see what policy and bindings are attached to my application without the admin console?

Avoid Trouble: The information in this section is intended to show you how to see the policy and bindings that are currently attached to an application. Altering the files referenced in this section with anything but the administrative console or the wsadmin tool is not supported.

I attached a policy and bindings to my client application, but no Security headers are in my SOAP message

I attached a policy and bindings to my provider application, but the provider is acting as if there is no policy attached

When no policy is in effect for a provider application, unsecured messages will pass without error and secured messages will result in a MustUnderstand failure:

The policy or bindings that is in effect does not appear to be what is configured

You can use this troubleshooting procedure to troubleshoot the following problems:

• You think policy A should be attached, but it appears that policy B is in effect at runtime.
• You think that a policy is attached, but no policy appears to be in effect at runtime.

• If your application was deployed with an assembly tool, such as IBM® Rational® Application Developer for WebSphere® Software (RAD):

  If you run into this condition and you have deployed your application with an an assembly tool, such as IBM® Rational® Application Developer for WebSphere® Software (RAD), the first thing that you should do is check to see if the publishing settings in your application server definition in RAD is set to 'Run server with resources on Server'. Do the following in your assembly tool: Window > Show view > Servers In the Servers pane, right click the server > Open On the right, expand 'Publishing settings for WebSphere Application Server' If it is currently set to 'Run server with resources within the workspace', do the following: Change the setting to 'Run server with resources on Server' Click File > Save After changing to 'Run server with resources on Server', you must uninstall, then re-install the application. Just doing a redeploy will not fix the issue. Do the following: In the Servers pane, right click the server > Add and Remove... In the Configured section on the right, select your application Click Remove Click Finish In the Servers pane, right click the server > Add and Remove... In the Available section on the left, select your application Click Add Click Finish You can now go back and reattach your policy and bindings to your application in the administrative console. If you already have 'Run server with resources on Server' set and you know that you installed the application after choosing this setting, proceed to the next section.

• If your application was not deployed with an assembly tool:

  If your application was not deployed with an assembly tool, or you completed the assembly tool section above without relief, do the following: In the administrative console, view the policy and bindings attachment for your application: For a provider navigate to Services > Service providers > (appName) For a client, navigate to Services > Service clients > (appName) Look at your attachment checkmarks on the panel and ensure that the attachments conform to this rule obtained from the Attaching a policy set to a service artifact topic in the IBM Documentation: Avoid trouble: Do not select all of the entries on the panel. The artifacts are Service, Endpoint and Operation. Only select the top-level parent of all artifacts that have the same attachment. For example, if all endpoints and operations are attached to the same endpoint, only select the Service entry. If you have more than one endpoint in your service, and the endpoints have different policies and all operations within each endpoint have the same policy, only select the parent endpoint for each set of operations that have the same policy attachment. If your attachments do not conform to the rules shown above, fix them, save the updates, restart your application and retest. If your attachments appear to conform, go back and view your attachments through the Applications path to see if you notice anything amiss there: Navigate to Applications > Application Types > WebSphere enterprise applications > (appName) Navigate the client or provider page: For a provider click Service provider policy sets and bindings For a client, click Service client policy sets and bindings

• Check the trace for a policy/binding load failure:

  From a trace that was gathered using the specification from Collect data, do the following: [1/30/17 20:33:43:891 UTC] 00000070 WSSecurityBin 3 Exception caught in loadCustom(). Error while loading PolicySet Bindings. Exception is: com.ibm.wsspi.wssecurity.core.SoapSecurityException: CWWSS7328E: Did not find a token generator for the supporting token of type [http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3]. There is additional debug information about the loadCustom error in the I created a general binding by copying my app specific binding on the file system and now my app won't runtopic later in this document. Search for the string "Exception caught in loadCustom()" If you find that string in the trace, note the exception, for instance: Fix the error that is causing loadCustom to fail then retest.

• If none of the items above solve your problem, see the section titled How can I see what policy and bindings are attached to my application without the admin console? earlier in this document.

CWWSS5043E: One Signature element is required.

You will get this message when a SAML token consumer is configured to require a Signature, but a token was received that does not contain a Signature. The SAML token consumer requires a Signature by default. The SAML token processing code is common to several WebSphere components. You may get this error from the following WebSphere components:

• WS-Security SAML token consumer
• SAML Web Single Sign-On
• SAML Web Inbound

1. Change the configuration of your SAML token consumer to not require a Signature.

   If you are consuming a SAML token in a SOAP message: Set signatureRequired=false in the SAML token consumer callback handler. See Web services security SAML token custom properties for more information. If you are consuming the token in the SAML Web SSO TAI: Set the property sso_<id>.sp.wantAssertionsSigned=false for the SAML Web SSO TAI. See SAML web single sign-on (SSO) trust association interceptor (TAI) custom properties for more information. If you are consuming the token in the SAML Web Inbound TAI: SAML Web Inbound requires that the SAML token be signed. There is no configuration option to turn off signature verification for the SAML Web Inbound TAI.

2. Ensure that a Signature gets added to the inbound SAML token.

   If you want a Signature added to the SAML token, the Signature must be added at the token's point of origin. The configuration of the application that created the token at the point of origin must be modified to add the Signature: Did your partner obtain the token from a security token service (STS) or identity provider (IdP)? Did your partner generate the token itself? Did your partner receive the token from an upstream call?

java.security.InvalidKeyException: Wrong length: 634

If you have both asymmetric signature and encryption configured get an error like this in the SystemOut.log:

I created a general binding by copying my app specific binding on the file system and now my app won't run

If you're in this section, you're probably experiencing an error like one of the following:

Copying application-specific bindings to general bindings on the file system is not recommended. The best practice for WS-Security bindings is to copy an existing provider or client sample binding in the administrative console, then update the copy. After making a copy of the sample bindings, only customize the settings of your new copy to suit your purposes. Do not remove anything from your binding copy, such as token generators, token consumers, sign parts, or encrypt parts. You can add things to your binding copy if needed, but deleting information can cause unanticipated errors at run time.

My Kerberos client identity isn't being propagated in a cluster environment

To ensure that the Kerberos identity of the client is propagated and delegated for clustered Web services application providers, you must configure Kerberos to generate a forwardable and addressless ticket.

To configure Kerberos to generate a forwardable and addressless ticket, modify a Kerberos configuration file, such as the krb5.conf or krb5.ini file. For more information, see the Kerberos configuration information in the IBM Documentation: Kerberos (KRB5) authentication mechanism support for security.

Interoperation with SOAPUI is not guaranteed

IBM support does not debug interoperation issues with anything other than a customer's target production runtime.  SOAPUI is one of the most prevalent SOAP testing systems in use and it does not always behave as a WS-Security runtime should. 

If a problem is discovered via SOAPUI or any non-production testing tool, it must be reproduced with a production runtime before it can be submitted to IBM support for service.

WSEC0130W: Prompt com.ibm.wsspi.wssecurity.auth.callback.LTPATokenCallbackHandler CallbackHandler with no basic authentication information specified in the binding is not supported for application running on application server.

This warning is emitted by the JAX-RPC WS-Security runtime. It is emitted when the LTPACallbackHandler does not have basic authentication information (username and password) configured in the binding. If the basic authentication information was intentionally omitted from the binding because the application is expected to be able to obtain the LTPA token from the runAs identity, you can ignore the warning and no further action is needed.

If the application is not expected to obtain the LTPA token from the runAs identity, you must update the binding information to include basic authentication information.

CWWSS7062E: Failed to check username [user] and password in the UserRegsitry: password is null

If you get this error, you are receiving a UsernameToken that does not include a password.  If you intend for your UsernameToken to not have a password, your username must exist in the user registry, or you must take action to configure WS-Security to not check the registry, see Configuring a UsernameToken caller configuration with no registry interaction 

Take the following steps to remediate this problem:

1. Set com.ibm.wsspi.wssecurity.token.IDAssertion.isUsed=true in the UsernameToken callback handler custom properties:
   1. In the administrative console, open the bindings definition for your application.
   2. Navigate to WS-Security > Authentication and protection > (UsernameToken consumer) > Callback handler
   3. Under Custom properties, click New
      • Name=com.ibm.wsspi.wssecurity.token.IDAssertion.isUsed
      • Value=true
   4. Click OK
2. Perform one of the following actions:
   • If your user is not in the registry:
     • Perform the steps in Configuring a UsernameToken caller configuration with no registry interaction 
   • If your user is in the registry:
     1. In the breadcrumbs at the top, navigate to WS-Security > Callers 
     2. Click New
        • Name=caller1
        • Caller identity local part=http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#UsernameToken
     3. Click Use identity assertion
     4. Click Ok
3. Save your configuration and retest.