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, 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:
The Kerberos default policies Kerberos V5 SecureConversation and Kerberos V5 WSSecurity were introduced in version 7.0.0.1 of WebSphere Application Server. When interoperating with Microsoft .NET using these policies, Microsoft .NET fails to consume WSDL due to an incorrect value for the IncludeToken on the CustomToken. The value is set to http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512/IncludeToken/Always on the CustomToken in the WS-Security policy.
Solution:
Change the IncludeToken value on the CustomToken to http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512/IncludeToken/Once.
Cause:
com.ibm.wsspi.wssecurity.core.SoapSecurityException: CWWSS6521E: The Login failed because of an exception: javax.security.auth.login. LoginException: CWWSS6811E: The key identifier TVpC640XSSc= retrieved from the message is different from the key identifier QdZLf+KjrUg= acquired from the keystore Path: C:\WebSphere\AppServer\profiles\AppSrv01//etc/ws-security/samples/enc-receiver.jceks."
profile_root/etc/ws-security/samples/dsig-sender.ks
profile_root/etc/ws-security/samples/dsig-receiver.ks
profile_root/etc/ws-security/samples/enc-sender.jceks
profile_root/etc/ws-security/samples/enc-receiver.jceks
profile_root/etc/ws-security/samples/intca2.cer
app_server_root/etc/ws-security/samples/dsig-sender.ks
app_server_root/etc/ws-security/samples/dsig-receiver.ks
app_server_root/etc/ws-security/samples/enc-sender.jceks
app_server_root/etc/ws-security/samples/enc-receiver.jceks
app_server_root/etc/ws-security/samples/intca2.cer
Solution:
You can work around the key mismatch error by manually copying the keystore files from the Version 7.0 nodes in the mixed cluster to the Version 6.1 Feature Pack for Web services nodes. This ensures that Version 7.0 nodes and Version 6.1 Feature Pack for Web services nodes are using the same keystore files. Another workaround is to move the Version 7.0 keystore files to a common directory location, then modify all bindings to point to the common location for the keystore files.
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. You can configure the actor URI at the following locations within the assembly tool:
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, read about configuring the client for identity assertion when specifying the method and configuring the client for identity assertion collecting the authentication method.
To configure the server for identity assertion, read about configuring the server to handle identity assertion authentication and configuring the server to validate identity assertion authentication information
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:
To configure the client for identity assertion, read about configuring the client for identity assertion when specifying the method and configuring the client for identity assertion collecting the authentication method.
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:
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:
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 drop-down lists.
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:
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 Security 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 Security permission.
Solution:
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"; };
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.
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.
If the client requires Web services security, it must be a JSR-109 client.
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 a UsernameToken, 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:
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:
If application security is enabled on the application server that is hosting the Web service, ensure that the client is properly configured to send the security token that is required by the Web service in the Web Services Security consumer caller part configuration.
The com.ibm.wsspi.wssecurity.config.disableWSSIfApplicationSecurityDisabled property enables Web services security to not process the WS-Security header if application security is disabled. This allows system administrators and application programmers to debug aspects of their services in a non-secure environment without having to remove the WS-Security information from their deployment descriptors. The use of this property is only intended for diagnostic purposes and not for a production environment.
Valid values for this property are true and false. The default value is false.
Application-level, cell level and server-level are the levels of bindings that WebSphere Application Server offers.
Cause:
As specified in the OASIS standard titled Web Services Security Kerberos Token Profile v1.1, a base64 encoding of a SHA-1 transformed key value can be used to specify a key identifier for a Kerberos AP-REQ token. SHA-1 is a cryptographic hash function that transforms an input and returns a fixed size string. After the client and service provider have exchanged an initial Web services message, the SHA-1 key identifier is used to externally reference the Kerberos authentication token. To use SHA-1 for this purpose, you must configure a custom property in the policy bindings to generate and consume the SHA-1 key identifier. The custom property com.ibm.wsspi.wssecurity.kerberos.attach.hashKeySupportToken is added to the client token generator and service token consumer bindings. This property allows the application to correctly generate and consume the SHA-1 key identifier during subsequent exchanges of Web Services messages when the Kerberos token is used as an authentication token.
Solution:
If an application generates or consumes a SHA-1 key identifier for each Web services message exchange, set the com.ibm.wsspi.wssecurity.kerberos.attach.hashKeySupportToken custom property to true in the token generator and the token consumer bindings for the application.
Cause:
When Microsoft® Web service applications request messages using a Kerberos token, you must configure a custom property in the policy bindings for the Kerberos V5 AP_REQ token to generate and consume the token. Add the com.ibm.wsspi.wssecurity.kerberos.attach.apreq custom property to the client token generator and service token consumer bindings. Enabling this property allows the application to generate and consume the Kerberos AP_REQ token for each Web Services request message.
Solution:
Cause:
WS-Security enabled Web services applications on a Sun Solaris system may incorrectly build a valid certification path even though an invalid certificate has been used. When the key in the certificate in a request and the key in the certificate retrieved on the server do not match, an error message should be issued. However, when the certificates differ in every respect except for the DN, and the Sun security provider is used, the certification path is returned as valid. This problem does not occur when the IBMCertPath security provider is used. IBMCertPath is the default security provider on all systems except Sun Solaris, therefore Sun Solaris is the only system on which this problem occurs.
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 running on Sun Solaris could incorrectly build a valid CertPath if given invalid input that is different in every respect from a certificate 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 IBMCertPath 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:
Hardware cryptographic device-related exceptions might be seen when the machine is experiencing a heavy load. The requests complete successfully because cryptographic software is used instead for the particular operation that received the exception. However, the hardware cryptographic device is not used.
CWWSS5601E: The following exception occurred while decrypting the message: com.ibm.pkcs11.PKCS11Exception: Another operation is already activeand
CWWSS5601E: The following exception occurred while decrypting the message: Key handle is invalid: com.ibm.pkcs11.PKCS11Exception: Key handle is invalid
This problem only occurs when the hardware cryptographic card is handling a large number of operations.
Solution:
There are no known workarounds. However, the requests complete successfully because the software cryptography is used when the hardware cryptography fails for an operation.