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.
Type the previous three lines as one continuous line.
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:
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.
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.
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])
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
(in the Additional Properties section).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.
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.
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.
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.
Cause:
Solution:
If you specify one of the previous value type local names, do not enter a value for the Value type URI field.
Cause:
Invalid URI: The format of the URI could not be determined.
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.
Cause:
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.
Cause:
com.ibm.wsspi.wssecurity.SoapSecurityException: WSEC5502E: Unexpected element as the target element: wsse:BinarySecurityToken
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.
Cause:
This situation only occurs when signing using trust anchors and without certificate stores only on Sun Solaris.
WSEC5085E: Unable to build a valid CertPath: java.security.cert.CertPathBuilderException: unable to find valid certification path to requested target>
The request should fail because of the incorrect key. However, the invalid CertPath is returned as valid because only the DN was checked. Web services applications on Sun Solaris could incorrectly build a valid CertPath if given invalid input that is different in every respect from a key on the server side, except for the DN.
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.
Cause:
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();
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:
Cause:
The certificate path setting is not configured properly.
Solution:
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.