Web services security troubleshooting tips

To troubleshoot Web services security (WS-Security), review the configurations with assembly tools to match the client and server request and the response configurations.

Troubleshooting Web services security is best done by reviewing the configurations with assembly tools so that you can match up the client and server request and the response configurations. These configurations must match. A client request sender configuration must match a server request receiver configuration. For encryption to successfully occur, the public key of the receiver must be exported to the sender and this key must be configured properly in the encryption information. For authentication, you must specify the method used by the client in the login mapping of the server. The following includes a list of generic troubleshooting steps that you can perform.

Steps for this task

  1. Verify that the client security extensions and server security extensions match on each downstream call for the following senders and receivers:
    • Request sender and request receiver
    • Response sender and response receiver
  2. Verify that when the Add Created Time Stamp option is enabled on the client-side that the server has the Add Received Time Stamp option configured. You must configure the security extensions with an assembly tool.
  3. Verify that the client security bindings and the server security bindings are correctly configured. When the client authentication method is signature, make sure that the server has a login mapping. When the client uses the public key cn=Bob,o=IBM,c=US to encrypt the body, verify that this Subject is a personal certificate in the server key store so that it can decrypt the body with the private key. You can configure the security bindings using an assembly tool or the WebSphere Application Server administrative console.
  4. Check the SystemOut.log file in the ${USER_INSTALL_ROOT}/logs/server1 directory (server1 changes depending upon the server name) for messages that might provide information about the problem.
  5. Enable trace for Web services security by using the following trace specification: com.ibm.xml.soapsec.*=all=enabled:com.ibm.ws.webservices.*=all=enabled: com.ibm.wsspi.wssecurity.*=all=enabled:com.ibm.ws.security.*=all=enabled: SASRas=all=enabled

    Type the previous three lines as one continuous line.

Errors when securing Web services

The following errors might occur when you secure Web services:

WebSphere Application Server version 5.1 Web Service client does not interact successfully with a Web Service running in WebSphere Application Server version 6.1

Cause:

When using WS-Security and signing, the following exception may occur:
com.ibm.wsspi.wssecurity.SoapSecurityException: WSEC5174E:
Signature verification failed; the last error message is: Core
validity=false Signed info validity=true Signed info
message='null'
Ref 0 (validity=false message='Digest value mismatch:
calculated:
O5T+FiwHiIT9LRxXGLuhh9pwO6Q='
uri='#wssecurity_body_id_9017935113444468728' type='null')

When a WebSphere Application Server version 5.1 Web Services consumer utilizing WS-Security XML Digital Signature sends a SOAP message that includes empty namespaces to a WebSphere Application Server version 6.1 provider, the provider is unable to process the message because of a digest value mismatch.

Solution:

The following web services security custom property has been added to WebSphere Application Server version 5.1:
com.ibm.wsspi.wssecurity.xss4j.digSig.C14N.removeEmptyNamespaces 
This is a system property and can be set in the administrative console or using the consumer's Java or launchClient command line. The valid values of the property are true and false. The default value is false. This property is only available in WebSphere Application Server version 5.1. The property indicates to Web Services Security that empty namespaces should not be included when calculating the digest value for XML Digital Signature.
Mixed-version environment Mixed-version environment: When this property is set, SOAP messages using XML Digital Signature that also contain empty namespaces can be consumed properly by WebSphere Application Server version 6.1.x, but are no longer consumed properly by WebSphere Application Server version 5.x or version 6.0.x.mixv

Unable to configure the mustUnderstand attribute in the Web Services SOAP security header

Cause:

Previously, the mustUnderstand=1 attribute in the <wsse:Security> tag in the SOAP header on the request from the Web Services client was hardcoded, so it was not possible to configure the mustUnderstand attribute in the SOAP Web Services security header. An update has been implemented to allow a WebSphere Application Server administrator to configure the attribute using outbound generator custom properties.

Solution:

The following generator/outbound Web Services security custom properties have been added:
  • com.ibm.wsspi.wssecurity.config.request.setMustUnderstand
  • com.ibm.wsspi.wssecurity.config.response.forceMustUnderstandEqualsOne
The com.ibm.wsspi.wssecurity.config.request.setMustUnderstand 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 in outbound consumer requests. The default value of the attribute is 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.

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

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, both properties can be specified in the following locations in the administrative console:
  • Click Servers >Application Servers > server name >Web services: Default bindings for Web services security, then under Additional Properties, click Properties.
  • Click Servers >Application Servers > server name >Web services: Default bindings for Web services security, then under Default Generator Bindings, click Properties.

If using an assembly tool with a JAX-RPC WS-Security version 1.0 application, the com.ibm.wsspi.wssecurity.config.request.setMustUnderstand property can be set as a property on the security request generator extension or binding. The com.ibm.wsspi.wssecurity.config.response.forceMustUnderstandEqualsOne property can be set as a 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, the com.ibm.wsspi.wssecurity.config.request.setMustUnderstand property can be set as a parameter on the port qualified name binding. The com.ibm.wsspi.wssecurity.config.response.forceMustUnderstandEqualsOne can be set as a parameter on the port component binding.

If using a JAX-WS application with the Web Services Feature Pack for WebSphere Application Server version 6.1, the custom properties can be set as outbound binding properties or parameters on the application using wsadmin. The following property names are used:
  • application.parameters
  • application.securityoutboundbindingconfig.properties
Properties in application.securityoutboundbindingconfig.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])

"WSEC5601E: An exception while decrypting the message: java.lang.NullPointerException: null" error message is displayed

Cause:

This problem occurs when a hardware cryptography card is being used to improve keystore security, but hardware acceleration has not been enabled.

Solution:

A new property has been provided for configuation at the server level instead of the application level. The property is com.ibm.ws.wssecurity.config.hwKeyStoreName and the value of the property should be the name of the hardware keystore. Set the property using the administrative console by clicking Servers > server name > Web services > Default bindings for Web services security > Properties (in the Additional Properties section).

"CWWSI5094E: No UsernameToken of trusted user was found or the login failed for the user while the TrustMode is BasicAuth" error message displays

Cause:

This situation occurs when you have IDAssertion configured in the login configuration as the authentication method.

Solution:

On the sending Web service, configure a trusted basic authentication entry in the login binding. Then, on the server side, verify that the trusted ID evaluator has a property set that contains the user name of this basic authentication entry.

"CWSCJ0053E: Authorization failed for /UNAUTHENTICATED..." error message displays

Cause:

The following authorization error occurs with UNAUTHENTICATED as the security name: CWSCJ0053E: Authorization failed for /UNAUTHENTICATED while invoking (Home)com/ibm/wssvt/tc/pli/ejb/Beneficiary findBeneficiaryBySsNo(java.lang.String):2 securityName: /UNAUTHENTICATED;accessID: null is not granted any of the required roles: AgentRole

This situation occurs because a login configuration is not being configured or Web services Security is not configured from a client to a server. When the request arrives at the server and authentication information is not received, the UNAUTHENTICATED user is set on the thread. Authorization returns this error if there are any roles assigned to the resource except for the special "Everyone" role, which supports access by anyone.

If the client successfully authenticates to an Enterprise JavaBeans (EJB) file, but the EJB file calls a downstream EJB file that is not configured with Web services security or transport security, such as HTTP user ID and password, an error can occur for this downstream request.

Solution:

Using the assembly tool, verify that the enterprise archive (EAR) file for both client and server has the correct security extensions and security bindings.

"WSWS3243I: Info: Mapping Exception to WebServicesFault." error message is displayed when you specify the value type local name and the URI for a token consumer or the token generator

Cause:

The Value type URI is not required for the following predefined value type local names:
  • Username token
  • X509 certificate token
  • X509 certificates in a PKIPath
  • A list of X509 certificates and CRLs in a PKCS#7

Solution:

If you specify one of the previous value type local names, do not enter a value for the Value type URI field.

"Invalid URI: The format of the URI could not be determined" error message might display when you use a Microsoft .NET client that accesses a Web service for WebSphere Application Server

Cause:

The following exception message might display when you use a Microsoft .NET client that accesses a Web service for WebSphere Application Server.
Invalid URI: The format of the URI could not be determined.
Exception type:
System.UriFormatException 
at System.Uri.Parse() 
at System.Uri..ctor(String uriString, Boolean dontEscape) 
at System.Uri..ctor(String uriString) 
at Microsoft.Web.Services2.SoapInputFilter.CanProcessHeader(XmlElement header, SoapContext context) 
at Microsoft.Web.Services2.Security.SecurityInputFilter.ProcessMessage(SoapEnvelope envelope) 
at Microsoft.Web.Services2.Pipeline.ProcessInputMessage(SoapEnvelope envelope) 
at Microsoft.Web.Services2.InputStream.GetRawContent() 
at Microsoft.Web.Services2.InputStream.get_Length() 
at System.Xml.XmlScanner..ctor(TextReader reader, XmlNameTable ntable) 
at System.Xml.XmlTextReader..ctor(String url, TextReader input, XmlNameTable nt) 
at System.Xml.XmlTextReader..ctor(TextReader input) 
at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, 
WebResponse response, Stream responseStream, Boolean asyncCall) 
Within WebSphere Application Server, Web services security is enabled and uses the ActorURI attribute. This error occurs because Microsoft .NET Web Services Enhancements (WSE) Version 2.0 Service Pack 3 does not support a relative URI value for the ActorURI attribute. WSE Version 2.0 Service Pack 3 supports an absolute Uniform Resource Identifier (URI) for this attribute only.

Solution:

To work with a Microsoft .NET client, you must configure this attribute as an absolute URI. An example of an absolute URI is: abc://myWebService. An example of a relative URI is: myWebService.

To configure ActorURI attribute for use with WebSphere Application Server, use either the Rational Application Developer (RAD) or the Application Server Toolkit to complete the following steps:
  1. Open the Web Service Editor, click the Extensions tab and expand Server Service Configuration.
  2. Enter the full absolute URI in the Actor field.
  3. Expand Response Generator Service Configuration Details > Details.
  4. Enter the full absolute URI in the Actor field.

"WSE567: The incoming Username token must contain both a nonce and a creation time for the replay detection feature" Microsoft .NET error displays

Cause:

In this scenario, you have a Web services client for WebSphere Application Server and a Microsoft .NET Web service. The Microsoft .NET Web service has a ws-security constraint for a username token configured. The following exception is thrown from the Microsoft .NET server:
WSE567: The incoming username token must contain both a nonce and a creation time 
for the replay detection feature.
.

By default, the Microsoft .NET Web service validates the nonce and the timestamp for the username token. However, it is optional for you to configure the nonce and timestamp properties for a Web service client that is using WebSphere Application Server.

Solution:

Complete the following steps to add the nonce and timestamp properties for a username token on a Web service client for WebSphere Application Server. These steps involve an assembly tool such as Rational Application Developer or the Application Server Toolkit. These steps involve an assembly tool such as Rational Application Developer or the Application Server Toolkit.

  1. Open the Web service client deployment descriptor and click the WS-Binding tab.
  2. Expand the Security Request Generator Binding Configuration > Token Generator sections.
  3. Click the name of the username token that you already created and click Edit.
  4. In the Properties section of the Token Generator window, click Add.
  5. Enter com.ibm.wsspi.wssecurity.token.username.addNonce in the Name field to provide the name of the nonce property.
  6. Enter true in the Value field.
  7. Click Add.
  8. Enter com.ibm.wsspi.wssecurity.token.username.addTimestamp in the Name field to provide the name of the timestamp property.
  9. In the Value field, enter true.
  10. Click OK and save the client deployment descriptor.

Java 2 Security exceptions occur when using the com.ibm.wsspi.wssecurity.auth.token package with Java 2 security enabled

Cause:

An application creates Java 2 Security exceptions while using the com.ibm.wsspi.wssecurity.auth.token.* package when Java 2 security is enabled.

New Java 2 permissions have been set for various public methods of the com.ibm.wsspi.wssecurity.auth.token.* package on WebSphere Application Server Version 6.1. If your application uses one of the public methods from these classes that are protected by Java 2 permissions and it does not have the appropriate permissions, the application will fail. The exception message provides information that identifies the classes and public methods that are affected with the corresponding new Java 2 permission.

Solution:

Grant permission in the was.policy file for the application:
  1. Use the PolicyTool to edit the policy files. Follow the appropriate steps for your operating system.
  2. Add all of the permissions to the was.policy file that gets packaged in the enterprise archive (EAR) file for your application. If you want finer granularity for the permissions in the was.policy file for your application, enable the permissions that are necessary for your application based upon the classes that you need.
    For example, if you need to access only the methods for the X509BSToken, you would add the following permissions to the was.policy file:
    grant codeBase "file:${application}" {
       permission com.ibm.websphere.security.WebSphereRuntimePermission
         "wssecurity.X509BSToken.setBytes";
       permission com.ibm.websphere.security.WebSphereRuntimePermission
         "wssecurity.X509BSToken.setCert";
      permission com.ibm.websphere.security.WebSphereRuntimePermission 
         "wssecurity.WSSToken.setTrusted";
      permission com.ibm.websphere.security.WebSphereRuntimePermission 
         "wssecurity.WSSToken.addAttribute";
      permission com.ibm.websphere.security.WebSphereRuntimePermission 
         "wssecurity.WSSToken.setUsedTokenConsumer";
    };
  3. Update the was.policy file in the EAR file for your application.
  4. Uninstall the application from WebSphere Application Server and reinstall it with the new EAR file and the updated was.policy file.

An exception might occur when integrity or confidentiality is asserted for a SOAP element

Cause:

If a client asserts integrity or confidentiality for a SOAP element but the element is missing from the message, an exception is issued.

If the client requires that the application of a signature or encryption to a SOAP element, the SOAP element must always be present. The presence of this element is not optional. For example, if the configuration specifies that integrity or confidentiality must be applied to the wscontext element. If wscontext is missing from the message, the following exception is issued:

com.ibm.wsspi.wssecurity.SoapSecurityException: WSEC5636W: Objects 
to be processed not found with the dialect 
[http://www.ibm.com/websphere/webservices/wssecurity/dialect-was] 
and the keyword [wscontext]

Solution:

Client developers must assure that the SOAP elements they target for integrity or confidentiality are always present in the SOAP message. If you cannot assure that the SOAP element is always present, do not target the SOAP elements for integrity or confidentiality.

Client output exceptions caused by the difference in JSR-101 and JSR-109 programming models

Cause:

Sometimes client output exceptions are produced when running the client. The client output exceptions might be caused by the differences in the JSR-101 versus JSR-109 programming models.

You can configure any of the Web services security constraints, such as: username token, X509 token, signing or encrypting the SOAP elements, and so on. For example, you can configure the username token on a WebSphere Application Server client and service. The client is configured to send a username token in the request, and the server is configured to expect a username token. But if the client does not send a username token, the server rejects the request. When the client does not perform a Java Naming and Directory Interface (JNDI) naming lookup, the client is probably not a JSR-109 client. If it is not a JSR-109 client, the client will not get the JSR-109 configuration information, including the security configurations, and the request will fail.

For the JSR-109 programming model, the invocation begins with the JNDI lookup, which allows the security configuration information to be attached. For the JSR-101 programming model, a JNDI lookup is not performed; the security configuration information cannot be attached.

Solution:

This behavior is not a problem with the JSR-101 and JSR-109 programming models. Web services security does not provide the WebSphere Application Server security configuration information to a JSR-101 client.

The Web services security implementation works according to the following guidelines:
  • Web services security is not supported for a JSR-101 client.
  • You can only configure a JSR-109 client to use Web services security.

If the client requires Web services security, it must be a JSR-109 client.

"WSEC5502E: Unexpected element as the target element" error message displays

Cause:

If the following error displays, the cause may be an X.509 token that is in a message, but doesn't have a matching token consumer configured. This error can occur on either consumer or provider JAX-RPC applications.
com.ibm.wsspi.wssecurity.SoapSecurityException: WSEC5502E: Unexpected element as the target element: wsse:BinarySecurityToken
The cause of this error is that either an X.509 token is configured, and an X.509v3 token is received, or an X.509v3 token is configured, and an X.509 token is received. This happens most often when receiving X.509v3 tokens from Microsoft .NET. To determine if this is the cause of the problem, follow these steps:
  1. Obtain a WS-Security trace for the process that is producing the message. For more information on how to implement the WS-Security trace, read the topic Tracing Web services.
  2. Check to see if the trace contains information about the incoming SOAP message:
    1. From the point of the exception, search backwards for the term soapenv:env.
    2. From that point, search backwards for the term X509.
    3. Note the type of the X.509 security token, either #X509 or #X509v3.
  3. If the trace does not contain information about the incoming SOAP message, for example, because the trace is incomplete, search backwards for the term Target's value type is, starting at the point of the exception. This search locates the part of the trace that shows which security token was being processed at the time of the error. Note the type of the security token, either #X509 or #X509v3.
  4. Check the type of X.509 security token that is specified in the consumer configuration:
    1. From the point of the exception, search backwards for the term WSSConsumerConfig.
    2. Now search forward for the term #X509.
    3. Note the type of the configured X.509 security token consumer, either #X509 or #X509v3.
  5. If the configured token consumer does not match the type of the incoming security token, then this confirms that a security token type mismatch is the cause of the error.

Solution:

The configured token consumer must match the type as specified for the inbound security token. If the cause of the error, as determined in the previous steps, is determined to be a security token type mismatch, then you must change either the consumer or the provider configuration for WS-Security to ensure that the token types match.

"WSEC5085E: Unable to build a valid CertPath" error message displays [Fix Pack 11 or later]

Cause:

This situation only occurs when signing using trust anchors and without certificate stores only on Sun Solaris.

Solution:

A new property has been added for WebSphere Application Server v 6.0.2 and later: com.ibm.wsspi.wssecurity.config.CertStore.Provider

This property allows Web services security, when running in WebSphere Application Server on Solaris, to use the IBM CertPath provider instead of using the Sun CertPath provider. This property is the security provider that Web services security should use when using trust anchors, and when the certificate store security provider was specified in conjunction with the certificate store.

If both the com.ibm.wsspi.wssecurity.config.CertStore.Provider is specified and a security provider is specified for the certificate store, the certificate store security provider will override the setting for com.ibm.wsspi.wssecurity.config.CertStore.Provider.

"WSEC5208E: Timestamp too far in the future" error message displays [Fix Pack 15 or later]

Cause:

This situation only occurs when Web services security code returns a different timestamp output because you are using a past date versus using a future date. Web services security code returns a different timestamp output if you are using a past date versus using a future date. However, when the time stamp is in the past, the following message is posted:

WSEC5323E: The message was expired:
           creation date of timestamp     Tue May 23 15:35:41 CEST 2006,
           expiration date of timestamp 	Tue May 23 15:36:41 CEST 2006,
           and machine's current date 	  Thu Aug 30 13:46:31 CEST 2007.

Currently, when a Web services timestamp is in the future, Web services security forces a Web services fault:

WSEC5206E: Current time on other party is 1189503042652,
           timestamp created time is 1211549741054. 
WSEC5514E: An exception while processing WS-Security message
           The fault string of the "WSWS3572I: Outbound HTTP SOAP response:"
           is com.ibm.wsspi.wssecurity.SoapSecurityException:

And, when the timestamp is too far in the future, you would ordinarily get the WSEC5208 exception back on the client:

WSEC5208E: Timestamp too far in the future.

Solution:

A new JVM system property has been added for WebSphere Application Server v6.1.0.15 and later to make some messages coming back to the client on a soapsecurityexception more consistent:

com.ibm.ws.wssecurity.config.useDateTimeFormatInClockSkewMsg=(true|false)

When you set the new system property as com.ibm.ws.wssecurity.config.useDateTimeFormatInClockSkewMsg=true, you will now get the following message accompanying the SoapSecurityException on the client:

exception: com.ibm.wsspi.wssecurity.SoapSecurityException: 
WSEC5208E: Timestamp too far in the future.  
WSEC5206E: Current time on other party is Wed Aug 01 15:32:20 CDT 2007,
           timestamp created time is Wed Oct 17 15:32:08 CDT 2007.)

"WSSecurityCon E WSEC5514E: An exception while processing WS-Security message" error displays

Cause:

The managed client has no access to the Web services deployment descriptor because the lookup() call did not use the Java Naming and Directory Interface (JNDI). Without the lookup() call, the client cannot access the deployment descriptor. The Web services security configuration is in the Web services deployment descriptor. The following is a detail exception that is created:
00000046 WebServicesFa 1 
com.ibm.ws.webservices.engine.WebServicesFault makeUserFault MakeUserFault: 
                                 com.ibm.wsspi.wssecurity.SoapSecurityException: WSEC5720E: 
A required message part [body] is not signed.
	at 
com.ibm.wsspi.wssecurity.SoapSecurityException.format(SoapSecurityException.java:143)
	at 
com.ibm.ws.webservices.wssecurity.dsig.VerifiedPartChecker.invoke(VerifiedPartChecker.java:
263)
	at 
com.ibm.ws.webservices.wssecurity.core.WSSConsumer.checkRequiredIntegrity(WSSConsumer.java:
1430)
	at com.ibm.ws.webservices.wssecurity.core.WSSConsumer.invoke(WSSConsumer.java:545)
	at 
com.ibm.ws.webservices.wssecurity.handler.WSSecurityConsumerBase.invoke(WSSecurityConsumerB
ase.java:85)
	at 
com.ibm.ws.webservices.wssecurity.handler.GlobalSecurityHandler.handleRequest6(GlobalSecuri
tyHandler.java:406)

Solution:

For the managed clients, the service lookup is through Java Naming and Directory Interface (JNDI) lookup. Read about setting up UserName token Web services security, digital signature Web services security and Lightweight Third-Party Authentication (LTPA) token Web services security. The following is an example of a context lookup that is JSR 109 compliant:

InitialContext ctx = new InitialContext();
FredsBankServiceLocator locator 
   =(FredsBankService)ctx.lookup("java:comp/env/service/FredsBankService");
FredsBank fb = locator.getFredsBank(url);
long balance = fb.getBalance();  

When you are instantiating a context lookup for a managed client, do not use new() for the service locator. Here is an example that is not JSR 109 compliant (new ServiceLocator):

Properties prop = new Properties();
InitialContext ctx = new InitialContext(prop);
FredsBankServiceLocator locator = new FredsBankServiceLocator();
FredsBank fb = locator.getFredsBank(url);
long balance = fb.getBalance(); 

"WSEC6500E: There is no candidate used to login" error message displays [Fix Pack 11 or later]

Cause:

This situation occurs if a Web service client is invoking Web Services by using Web Services Security and if global security is disabled on the application server that is hosting the Web service.

For example, a Web service might be configured for authentication by using a Username token or an LTPA token. However, it is deployed to an application server where global security is disabled. When the Web service is invoked by a Web service client, which correctly provides the required Username token or LTPA token, the Web service invocation will fail. The following fault might be returned back to the Web service client:

<soapenv:Fault>  
<faultcode xmlns:p55="http://docs.oasis-open.org/wss/2004/01/oasis-
     200401-wss-wssecurity-secext-1.0.xsd">p55: FailedAuthentication 
</faultcode>  
<faultstring>  <![CDATA[com.ibm.wsspi.wssecurity.SoapSecurityException:  
WSEC6500E: There is no candidate used to login.]]>  
</faultstring>  
<detail encodingStyle=""/>  
</soapenv:Fault>

Solution:

Enable global security on the application server that is hosting the Web service. Or, use the com.ibm.wsspi.wssecurity.config.disableWSSIfApplicationSecurityDisabled property. Valid values for this property are true and false. The default value is false.

To be used only for diagnostic purposes (not for a production environment), the com.ibm.wsspi.wssecurity.config.disableWSSIfApplicationSecurityDisabled property enables Web services security to not process the WS-Security header and also disables Web services security if the application security is disabled. This property provides system administrators and application programmers the ability to debug aspects of their services in a non-secure environment, without having to remove the WS-Security information from their deployment descriptors.

Application-level, cell level and server-level are the levels of bindings that WebSphere Application Server offers.

The information in the following implementation descriptions indicates how to configure your application-level bindings. If the Web server is acting as a client, the default bindings are used. To use the com.ibm.wsspi.wssecurity.config.disableWSSIfApplicationSecurityDisabled property, specify one of the following, in priority order:

"WSEC6664E: Null is not allowed to PKIXBuilderParameters. The configuration of TrustAnchor and CertStoreList are not correct" exception displays

Cause:

The certificate path setting is not configured properly.

Solution:

Configure the certificate path setting by completing the following steps:
  1. In the administrative console, click Security > Web services.
  2. Under the Default consumer binding heading, click Signing information > configuration_name.
  3. Select either the Trust any or Dedicated signing information option.

    If you select the Dedicated signing information option, select both a trust anchor and a certificate store from the configurations that are provided in the dropdown lists.

  4. Click OK and Save to the master configuration.

Attributes with no namespace prefix and no namespace declared on the EncryptedHeader element [Fix Pack 13 or later]

Cause:

When a custom policy set specifies a header to be encrypted by QName, an EncryptedHeader element gets generated in the message with an ID attribute, and possibly one or more of the following attributes: mustUnderstand, actor, role, or relay. All of these attributes have no namespace prefix and no namespace declared on the EncryptedHeader element. The lack of a namespace prefix and no namespace declared can cause interoperability problems. The attributes might not be recognized and might cause the message to be rejected.

This situation only occurs only when you use a custom policy set that encrypts a header by QName (Namespace and Local part) when using the Web services security IBM WebSphere Application Server Web Services Feature Pack.

Solution:

The Web services security code has been modified to specify the wsu prefix on the Id attribute and to declare the http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd namespace on the <EncryptedHeader> element. Also, the code has been modified to specify the soap prefix, as defined on the message, on the mustUnderstand, actor, role, and relay attributes on the EncryptedHeader element.

The following property has been added for WebSphere Application Server v6.1.0.13 and later to support the previous behavior for interoperability with previous versions:
com.ibm.wsspi.wssecurity.encryptedHeader.generate.WSS1.1.pre.fp13 = (true|false)

Set the following custom property on the encryptionInfo in the bindings file to true.




Related tasks
Using PolicyTool to edit policy files
Troubleshooting Web services
Related reference
[AIX HP-UX Linux Solaris Windows] [z/OS] Installation problems
Related information
http://www.ibm.com/developerworks/websphere/techjournal/0604_singh/0604
http://www.ibm.com/developerworks/websphere/techjournal/0606_singh/0606
http://www.ibm.com/developerworks/websphere/techjournal/0607_desprets/06
Reference topic Reference topic    

Terms and conditions for information centers | Feedback

Last updatedLast updated: Aug 31, 2013 2:56:59 AM CDT
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=pix&product=was-nd-dist&topic=rwbs_troubleshoot
File name: rwbs_troubleshoot.html