+

Search Tips   |   Advanced Search

 

Web services security troubleshooting tips

 

To troubleshoot Web services 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, 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:

  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 WAS 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:

 

"CWWSI5061E: The SOAP Body is not signed" error message displays

[V5 only]

Cause:

This error usually occurs whenever the SOAP security handler does not load properly, and does not sign the SOAP body. The SOAP security handler is typically the first validation that occurs on the server-side, so many problems can cause this message to display. The error might be caused by invalid actor URI configurations.

Solution:

You can configure the actor Universal Resource Identifier (URI) at the following locations within the assembly tool:

The actor information on both the client and the server must refer to the same string. When the actor fields on the client and the server match, the request or response is acted upon instead of being forwarded downstream. The actor fields might be different when you have Web services acting as a gateway to other Web services. However, in all other cases, verify that the actor information matches on the client and server. When the Web services implementation is acting as a gateway and it does not have the same actor configured as the request passing through the gateway, this Web services implementation does not process the message from the client. Instead, it sends the request downstream. The downstream process that contains the correct actor string processes the request. The same situation occurs for the response. Therefore, it is important that you verify that the appropriate client and server actor fields are synchronized.

Additionally, the error can appear when you do not specify that the body is signed in the client configuration. To sign the body part of the message using the Web service client editor in the assembly tool, click Security Extensions > Request Sender Configuration > Integrity and select the message parts to sign.

 

"CWWSI5075E: No security token found that satisfies any one of the authentication methods" error message displays

[V5 only]

Solution:

Verify that the client and server login configuration information matches in the security extensions. Also, verify that the client has a valid login binding and that the server has a valid login mapping in the security bindings. You can check this information by looking at the following locations in the assembly tool:

Also, make sure that the actor URI specified on the client and server matches. You can configure the actor URI at the following locations within the assembly tool:

 

"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. To configure the client for identity assertion, consult the following topics:

To configure the server for identity assertion, consult the following topics:

 

"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 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. For more information, consult the following topics:

 

"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:

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 WAS

Cause: The following exception message might display when you use a Microsoft .NET client that accesses a Web service for WAS. 

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 WAS, Web services security is enabled and uses the ActorURI attribute. This error occurs because Microsoft .NET Web Services Enhancements (WSE) V2.0 Service Pack 3 does not support a relative URI value for the ActorURI attribute. WSE V2.0 Service Pack 3 supports an absolute URI for this attribute only.

Solution:

To work with a Microsoft .NET client, 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 WAS, use either the Rational Application Developer (RAD) or the Application Server Toolkit (AST) 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.

 

"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 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 drop-down lists.

  4. Click OK and Save to the master configuration.

 

"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 WAS 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 WAS. 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 WAS V6.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 we need. For example, if 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 WAS 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 WAS 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 WAS security configuration information to a JSR-101 client. The Web services security implementation works according to the following guidelines:

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

 

Related tasks


Configure the client for identity assertion: specifying the method
Configure the client for identity assertion: collecting the authentication method
Configure the server to handle identity assertion authentication
Configure the server to validate identity assertion authentication information
Configure the client security bindings using an assembly tool
Configure the security bindings on a server acting as a client using the console
Configure the server security bindings using an assembly tool
Configure the server security bindings using the console
Use PolicyTool to edit policy files
Troubleshooting Web services

 

Related Reference


Installation problems

 

Reference topic