Tips for troubleshooting the Liberty profile.
Check that your JDKs are at a supported
level
If you experience problems that are not readily explained,
check that the JDKs you are using are compliant with Java Version 6 or later, and are at a current
service level. See Minimum supported Java levels.
Note: A
deadlock can occur when using Oracle based JVMs using Java Version 6. If you are using an affected
JVM or JDK, the following settings can help prevent the deadlock from
occurring:
- Enable the following VM option: -XX:+UnlockDiagnosticVMOptions
-XX:+UnsyncloadClass
- Set the Equinox framework option to use classname locking for classloading
by setting the following Equinox configuration option: -Dosgi.classloader.lock=classname
These can be set in a Java properties
file, for example
jvm.options, when starting
the Liberty server.
Troubleshooting security
This section
describes some common security problems and solutions you can choose.
- SESN0008E: A user authenticated as anonymous has attempted to
access a session owned by user:LdapRegistry/cn=steven,o=myCompany,c=US.
- This error happens when an unauthenticated user tries to access
a session created by an authenticated user. Session security that
is enabled by default prevents unauthorized access of the sessions.
Only the user who created a session can access it. See session
security for more information.
This error can happen when you use a JSP (login.jsp for
example) for your form-login and the SSO token sent by the browser
is expired. Because the SSO token is expired, the user is prompted
to log in again using the login.jsp page configured
for the form-login. The jsp page, by default, tries to get a session.
This session was originally created by the user whose token is expired.
However, the token is expired and the user is not authenticated, no credentials are
established when accessing this session that results in this error.
To
avoid this error, restart the browser that starts a new session, or
configure the login.jsp file to not create the
session by default. If you choose to update the login.jsp file,
set <%@ page session="false" %>.
- CWWKS9104A: Authorization failed for user {0} while invoking {1}
on {2}. The user is not granted access to any of the required roles:
{3}.
- This error occurs when you do not have authorization to the roles
required by the application. Make sure that the user or the group
it belongs to is mapped to at least one of the roles that are mentioned
in the error message. A user-to-role mapping defined in the ibm-application-bnd.xmi/xml file
takes precedence over a mapping defined in the server.xml file.
Check both resources to ensure that the correct mapping is defined.
See Configuring authorization for applications on the Liberty profile.
- CWWKZ0013E: It is not possible to start two applications called
{0} followed by unexpected security behavior and error messages such
as CWWKS9104A.
- This error occurs when you specify your application in both the server.xml by
using theapplication element and in the dropins folder.
As a result, the application is attempted to be installed twice and
the security configuration in the server.xml file
might or might not take effect. To fix this, you must remove your
application from the dropins folder and copy
it to another directory. If you have to leave it in the dropins folder,
you must disable the application monitoring by using the following
code in your server.xml file:
<applicationMonitor dropinsEnabled="false"/>
- An unauthenticated user was able to access my servlet or JSP.
- A user with a principal of UNAUTHENTICATED (or
the unauthenticated SAF user on z/OS®)
is created when authentication fails or when your servlet or JSP is
unprotected. An unauthenticated user can access your servlet or JSP
if you do not define any security constraints or if you map the EVERYONE
special subject to the role required by your application. Review the
user-to-role mappings in the ibm-application-bnd.xmi/xml and server.xml files.
Take one of the following options:
- If your servlet or JSP is unprotected, add security constraints
to the deployment descriptor of your application. See Liberty profile: Authentication.
- If you do not want any unauthenticated user to access your application,
remove the EVERYONE special subject from the
mapping for that role. See Configuring authorization for applications on the Liberty profile.
- If a certain user cannot be authorized to your servlet or JSP,
review who is mapped to that role by examining the ibm-application-bnd.xmi/xml and server.xml files.
You can map a role to a user, group, or special subject. If your role
is mapped to the EVERYONE special subject, any
user is granted access. If your role is mapped to the ALL_AUTHENTICATED special
subject, any authenticated user is granted access. Remove these special
subjects if you want to further limit who can access your servlet
or JSP. Finally, check what group the user belongs to. Although the
user might not have explicit access, the group might be mapped to
the role. In this case, remove the user from the authorized group
or remove the group from role mapping. See Configuring authorization for applications on the Liberty profile.
- Single sign-on (SSO) does not work.
- If SSO does not work, make sure that the different Liberty profile
servers that use the same LTPA keys, password, and ssoCookieName attribute
of webAppSecurity element have the same Universal
Time (UTC) and share the same user registry. Also, if the token expires
or if the cookie is sent from a web browser after changing the user
registry in a manner that is inconsistent, like modifying the realm
or removing the user the cookie represents, the SSO fails and the
user is prompted to enter the credential information again. See Customizing SSO configuration using LTPA cookies for the Liberty profile.
- Debugging security public APIs.
- WSSecurityHelper and RegistryHelper are
loaded even if security is not enabled, for example, if a security
feature - appSecurity-1.0, appSecurity-2.0 or zosSecurity-1.0 -
is not specified. If security is not enabled, then WSSecurityHelper.isServerSecurityEnabled() and WSSecurityHelper.isGlobalSecurityEnabled() methods
both return false, and RegistryHelper.getUserRegistry() method
returns null.
Other security public API classes might not be loaded if security
is not enabled. If you try to access these classes and call a method on
one of these classes, you might get a java.lang.NoClassDefFoundError exception.
-
To avoid getting java.lang.NoClassDefFoundError exceptions,
you must first test to see whether security is enabled by calling
the WSSecurityHelper.isServerSecurityEnabled() or WSSecurityHelper.isGlobalSecurityEnabled() class,
and then call other security public API classes only when security
is enabled. See Liberty profile: Security public APIs for examples
of this coding technique.
Note: This behavior is different from the full profile. In full profile, all
classes are always loaded regardless of whether security is enabled
or not.
Troubleshooting LDAP
This section
describes some common LDAP problems and solutions you can choose.
- FFDC1015I: An FFDC Incident has been created: javax.naming.ServiceUnavailableException: myldapserver.mycompany.com:636;
socket closed com.ibm.ws.security.registry.ldap.internal.LdapRegistry
298
- This message in messages.log indicates that
the configured LDAP server cannot be reached. Check your LDAP server
to verify that it is running and that its IP address can be accessed
from the Liberty profile server.
- The javax.naming.CommunicationException: simple bind failed: myldapserver.mycompany.com:636
[Root exception is javax.net.ssl.SSLHandshakeException: com.ibm.jsse2.util.g:
PKIX path building failed: java.security.cert.CertPathBuilderException:
unable to find valid certification path to requested target]
- If you enable SSL on your LDAP server without copying the signer
of the LDAP server into the truststore referenced in the LDAPSSLSettings element,
a connection with the LDAP server fails with an SSL handshake error.
Make sure that you copy the signer of the LDAP server into your truststore.
- The javax.naming.CommunicationException: myldapserver.mycompany.com:389
[Root exception is java.net.BindException: Address already in use:
connect]
- This message might appear in the FFDC logs and indicates that
the usable sockets on the local server are exhausted, which can result
in a failure when connecting to your LDAP server. Make sure that the
socket is not used and try again.
- CWWKS1100A: Authentication did not succeed for user ID xxxxx.
An invalid user ID or password was specified
- This FFDC exception might happen on the server even though the
user mentioned in the message is a valid user on the LDAP server under
heavy load. With the LDAP configuration, you can add the reuseConnection=false
property or disable it by using the developer tools. To fix the problem,
set this property to the default value of true.
Troubleshooting SSL
This section
describes some common SSL problems and solutions you can choose.
- CWWKS9105E: Could not determine the SSL port for automatic redirection.
- This error occurs when you try to access an application that redirects
to an SSL port and the SSL port is not available. The port might not
be available because of a missing SSL configuration or some error
in the SSL configuration definition. Check the SSL configuration in
the server.xml file to make sure that it exists
and is correct. See Securing communications with the Liberty profile.
- FFDC1015I: An FFDC Incident has been created: "java.lang.IllegalArgumentException:
Unknown, incomplete configuration: missing id field com.ibm.ws.config.internal.cm.ManagedServiceFactoryTracker
aSyncReadNupdate. Exception thrown while trying to read configuration
and update ManagedServiceFactory. Exception = java.lang.IllegalArgumentException:
Unknown, incomplete configuration: missing id field" at ffdc_12.04.18_16.09.42.0.log
- This error occurs when a keystore element exists
in the configuration without an ID field. If you use a minimal SSL
configuration, set the ID field to defaultKeyStore.
- You might get an exception if using a LDAP user registry with
sslEnabled and a sslRef value is not specified.
- For example, a configuration has sslEnabled set
to true but there is not a sslRef value, as shown
in the following example:
<ltldapRegistry id="ldap" realm="SampleLdapIDSRealm"
host="ccwin12.austin.ibm.com" port="636" ignoreCase="true"
baseDN="o=ibm,c=us"
bindDN="cn=root"
bindPassword="rootpwd"
ldapType="IBM Tivoli Directory Server"
idsFilters="ibm_dir_server"
sslEnabled="true"
searchTimeout="8m" />
You must enter a
sslRef value.
If you are using a minimal SSL configuration that is similar to the following:
<ltkeyStore id="defaultKeyStore" location="key.jks"
password="mypassword" />
the
sslRef field should
be set to
defaultSSLConfig.
If a custom SSL
configuration is configured, the name of that configuration should
be placed in the sslRef field.
- If you use a JDK from the WebSphere® Application
Server, you might see the following error if SSL is enabled on your
Liberty Server.
java.net.SocketException: java.lang.ClassNotFoundException: Cannot find the specified class com.ibm.websphere.ssl.protocol.SSLSocketFactory
at javax.net.ssl.DefaultSSLSocketFactory.a(SSLSocketFactory.java:11)
at javax.net.ssl.DefaultSSLSocketFactory.createSocket(SSLSocketFactory.java:6)
at com.ibm.net.ssl.www2.protocol.https.c.afterConnect(c.java:161)
at com.ibm.net.ssl.www2.protocol.https.d.connect(d.java:36)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1184)
at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:390)
at com.ibm.net.ssl.www2.protocol.https.b.getResponseCode(b.java:75)
at com.ibm.ws.jmx.connector.client.rest.internal.RESTMBeanServerConnection.loadJMXServerInfo(RESTMBeanServerConnection.java:142)
at com.ibm.ws.jmx.connector.client.rest.internal.RESTMBeanServerConnection.<init>(RESTMBeanServerConnection.java:114)
at com.ibm.ws.jmx.connector.client.rest.internal.Connector.connect(Connector.java:315)
at com.ibm.ws.jmx.connector.client.rest.internal.Connector.connect(Connector.java:103)
This
error occurs because the WebSphere Application
Server SSL socket factories are not supported by the Liberty profile. You
can get past this problem by editing the
java.security file
from the JDK and comment out the two lines that set the SSL socket
factories to the WebSphere Application
Server SSL socket factories. The following example shows the two lines
in the
java.security file that must be commented
out:
#ssl.SocketFactory.provider=com.ibm.websphere.ssl.protocol.SSLSocketFactory
#ssl.ServerSocketFactory.provider=com.ibm.websphere.ssl.protocol.SSLServerSocketFactory
Troubleshooting logging and tracing
This section
describes some common problems with logging and tracing.
- The java.util.logging -- Java logging programming interface.
- The Liberty profile does not support using the logging.properties file to
configure java.util.logging. Use java code, for
example in a deployed application or user feature, to create and add
java.util.logging handlers, filters, or
formatters.
- Since the Liberty profile server manages the java.util.logging logger
levels in accordance with the traceSpecification attribute
of the logging configuration element, you should avoid using the Logger.setLevel method.
Troubleshooting
JAX-WS
This section describes some common JAX-WS problems
and solutions you can choose.
- The org.apache.cxf.bus.extension.ExtensionException occurred when deploying
web services application on the Liberty Profile.
- If your application has CXF libraries and configurations embedded
already and you want to deploy the application to the Liberty Profile,
you must make sure that the jaxws-2.2 server feature
is disabled by removing the feature from the server.xml file.
- The java.lang.NoClassDefFoundError exception occurred when running IBM fastpath with the Oracle JVM.
- To use IBM fastpath Java Architecture for XML Binding
(JAXB), you can configure the com.ibm.xml.xlxp.jaxb.opti.level custom
property to control whether optimization methods are enabled for JAXB
unmarshalling (deserialization) and marshalling (serialization). If
you are experiencing the java.lang.NoClassDefFoundError exception when running IBM fastpath JAXB with the Oracle
JVM, you can change the value of com.ibm.xml.xlxp.jaxb.opti.level property
to 0 to turn off the optimization. For example,
you can use the -Dcom.ibm.xml.xlxp.jaxb.opti.level=0 property
in the command line, or add the following line to the jvm.options file:
# Turn off the JAXB optimization
-Dcom.ibm.xml.xlxp.jaxb.opti.level=0
- See more information of the com.ibm.xml.xlxp.jaxb.opti.level property
on the Java virtual machine
custom properties page.
- The java.lang.NoClassDefFoundError : com.ibm.CORBA.iiop.ORB exception
occurred when running the full profile thin client with the Oracle
JVM.
- This error occurs when you try to run the full profile thin client
with the Oracle JVM and the jaxws-2.2 feature is
already enabled on the Liberty profile. To resolve this problem, you
can use the -Dcom.ibm.websphere.thinclient=true property when running
the full profile thin client as follows:
java -Dcom.ibm.websphere.thinclient=true
-cp <classpath_entries_including_tWAS_thinclient_jar> <WebServicesClientEntryClass> <any_more_parameters>
- See the similar information of the com.ibm.websphere.thinclient property
on the PM39777: ADMINISTRATIVE THIN CLIENT USING SOAP CONNECTOR
AND SUN JDK DOES NOT WORK page.
- An Empty file returned when retrieving binary files from an MTOM
service to a MTOM client.
- This scenario happens when a MTOM client sent binary files successfully
to an MTOM service, but an empty file is returned when retrieving
the same binary files back from the MTOM service.
- As a workaround, you can create a new DataHandler and
initialize the DataHandler by filling the content
of the binary file. For example, use a FileDataStore object
to read from I/O and return the newly created DataHandler back ,
and then pass the DataHandler to other web services.
...
File f = new File("received_image");
if (f.exists()) {
f.delete();
}
FileOutputStream fos = new FileOutputStream(f);
img_in.writeTo(fos);
FileDataSource fos_out = new FileDataSource(f);
DataHandler img_out = new DataHandler(fos_out);
return img_out;
...
- The javax.xml.ws.soap.SOAPFaultException: Unmarshalling Error
occurred when using XMLGregorianCalendar in xsd:gMonth format with
the Oracle JVM.
- This error occurs when you use the XMLGregorianCalendar class
to store gMonth format constants as part of your
SOAP request on client side and the jaxws-2.2 feature
is enabled on the Liberty profile with the Oracle JVM. The root cause
is that the Oracle JVM supports the new standard format --MM for
the xsd:gMonth type while the latest JAXB RI (Reference
Implementation) only supports the format of --MM--.
- To resolve this problem, you can change the Oracle JVM to the IBM JVM for both the client side
and the server side applications.
- The java.io.FileNotFoundException occurred when resolving WSDL
files specified by the wsdlLocation attribute.
- This error occurs when you specify the WSDL file as in the code wsdlLocation
= "file:/WEB-INF/wsdl/a.wsdl" and the
WSDL file is packaged within your application. If you want to refer
to the WSDL file that is packaged in your application, you must use
relative URIs for the wsdlLocation attribute defined
in the @WebService, @WebServiceProvider, @WebServiceClient or @WebServieRef annotation.
- The relative URI for the wsdlLocation attribute
must be one of the following values:
- wsdlLocation = "/WEB-INF/wsdl/a.wsdl"
- wsdlLocation = "WEB-INF/wsdl/a.wsdl"
- A large number of "Creating service" messages occur in the messages.log
file.
- This scenario happens when you call the getPort or
related methods in the generated client stub classes. The Liberty
profile is configured with the default logging configuration, and
all the infomation messages are written into the messages.log file. There are
lots of occurrences of messages that might be similar to the following
one:
00000037 org.apache.cxf.service.factory.ReflectionServiceFactoryBean I Creating Service {http://www.echo.org/}EchoService from WSDL:
wsjar:file:/wlp/usr/servers/default/workarea/org.eclipse.osgi/bundles/100/data/cache/
com.ibm.ws.app.manager_gen_15a42559-f979-4ee6-b488-9fa1fb212c96/.cache/Echo.war!/WEB-INF/wsdl/Echo.wsdl
- To suppress these infomation messages, you can change the logging
configuration in the server.xml file as follows:
<logging traceSpecification="org.apache.cxf.*=warning=enabled"/>
- The SOAPFaultException: The given SOAPAction test does
not match an operation occurred when a client application sent a SOAP
Action.
Note: test is the value of the soapAction attribute
in the request HTTP header.
Each operation in a SOAP web service
can be associated with a SOAP Action String, such as in the WSDL binding
or via an annotation. The web service client sends the SOAP Action
string as a header with the request to match the operation of the
web service provider. The error message is displayed in either of
the following scenarios: - When the SOAP action sent by the client does not match the SOAP
action of the operation.
- When using the full profile as the JAX-WS client and the Liberty
profile as the JAX-WS service and the soapAction defined
in the WSDL file equals empty value "".
- To resolve this problem:
- If it's because Make sure that you specify the exact same SOAP
action for both the web service client and service provider.
- Provide a valid value to the soapAction attribute
that is defined in the WSDL file or do not use soapAction in
the WSDL file.
- The javax.xml.ws.WebServiceException occurred when using the
Service.create() method to create service.
- This error occurs when you use the Service.create() method
to create a service while the WSDL document is not provided. If you
want to use the Service.create() to create a service
and getPort() method to get the port number, you
must use the addPort() method to provide the binding
information.
- A sample example code is provided as follows on how to use the addPort() method:
QName serviceName = new QName("http://test.com/wssvt/acme/InsBusiness/", "MTOM11Service");
QName portName = new QName("http://test.com/wssvt/acme/InsBusiness/", "MTOM11Port");
// Setup the necessary JAX-WS artifacts
Service svc = Service.create(serviceName);
// Add the port in the service instance
svc.addPort(portName, SOAPBinding.SOAP11HTTP_MTOM_BINDING, mtom11URL);
port = svc.getPort(portName, MTOMInterface.class);
- The Null Response returned when the name attribute in @WebResult
annotation is different from the name element in the WSDL document.
- This problem occurs when you use a SEI class to define the name attribute
for @WebResult annotation, and the SEI class has supplied
WSDL location as follows:
@WebService(wsdlLocation="WEB-INF/wsdl/WebServiceIfc.wsdl")
public interface WebServiceRuntimeIfc {
@WebMethod
@WebResult(name="nononoreturn")
public String echo (String parm);
}
But the XML element declaration in the supplied WSDL
document is as follows:<xs:element name="echoResponse">
<xs:complexType>
<xs:sequence>
<xs:element name="return" type="xs:string" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
</xs:element>
Then the web service client will get a
NULL response when the echo() method is called.
- To resolve this problem, you must make sure that the name attribute of @WebResult annotation match
the value of name element in the WSDL document.
- The JAX-WS client application failed to get the WSDL document
changes from the server side.
- The problem occurs when the web service client and service provider
are in two different applications on the Liberty profile, and the
client needs to retrieve the WSDL document from the service provider dynamically.
Because the Liberty profile caches the WSDL definition when the WSDL
document is accessed for the first time, which is different from the
behavior in the full profile. By caching the WSDL definition in the
Liberty profile, applications can avoid connecting and parsing the
WSDL document frequently.
- To solve this problem, you have to restart the client application
so that the updated wsdl definitions can be reloaded.
- WebApp in the Liberty profile hangs if a web service refers to
itself.
- If you use annotation @WebService for a web service
and the annotation @WebServiceRef to refer to itself,
the service endpoint publishing fails. For example,
@WebService
public class Test {
@WebServiceRef
private Test selfservice;
public String echo(String msg) {
return selfservice.invoke();
}
public String invoke() {
return "hello world";
}
}
- To avoid this issue, use the service-stub (TestService as
is shown in the following example) to get the service instance instead
of using the @WebServiceRef to refer to self-service.
For example,
@WebService
public class Test {
private Test selfservice;
public String echo(String msg) {
TestService ts=new TestService();
selfservice=ts.getTestPort();
return selfservice.invoke();
}
public String invoke() {
return "hello world";
}
}
- Different behavior of the full profile and the Liberty profile
when policies are attached to both of the service level and the operation
level
- The behaviors of the full profile and the Liberty profile are
different when policies are attached to both of the service level
and the operation level. When both policies of service and operation
level are applied, as is shown in the following example,
<wsdl:binding name="UrnMustUnderstandBinding2" type="tns:MustUnderstand">
<wsp:PolicyReference URI="#UserNameToken1" />
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="invoke">
<soap:operation soapAction="" style="document"/>
<wsdl:input name="getVerRequest">
<soap:body use="literal"/>
<wsp:PolicyReference URI="#UserNameToken2" />
</wsdl:input>
<wsdl:output name="getVerResponse">
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
- For the full profile, the excepted behavior is that if the operation
name in SOAP request matches the operation name of <wsdl:input>
like "getVerRequest", the policy of operation level "#UserNameToken2"
is applied only.
- For Liberty profile,
- If some SOAP requests match the expectation of "#UserNameToken2",
the "#UserNameToken2" policy is applied.
- If some SOAP requests do not match the expectation of "#UserNameToken2",
the "#UserNameToken1" policy is applied.
- If you want the behavior in the Liberty level to be the same as
in the full profile, declare the policies which have the same or similar
function at one level only, either at the service level or at the
operation level.
Troubleshooting
WS-Security
This section describes some common solutions
that you can use to solve WS-Security problems.
- Check the server.xml file to make sure that
the required JAX-WS (jaxws-2.2) and security (appSecurity-2.0)
features are configured correctly.
- To protect your web service application with WS-Security, your
JAX-WS application must contain a WSDL file that has an embedded WS-Security
policy. There must be a PolicyReference to the embedded WS-Security
policy in either the wsdl:binding or wsdl:operation sections
or both.
- If you use a callback handler for retrieving passwords to generate
UsernameTokens or for retrieving passwords for private keys from keystore
files, the password callback handler must be packaged and deployed
as a user feature in the Liberty profile.
Enabling WS-Security trace
If the cause of the problem
cannot be determined by the information in the error message, you
can use the Liberty profile’s trace and logging facility to collect
trace for the WS-Security component. See Liberty
profile: Trace and logging.
You can use the following
trace string to collect trace to debug WS-Security failures:
org.apache.ws.security.*=all=enabled:
org.apache.cxf.ws.security.*=all=enabled:
org.apache.cxf.ws.policy.*=all=enabled
org.apache.xml.security.*=all=enabled:
com.ibm.ws.wssecurity.*=all=enabled
This section
described some common WS-Security problems and solutions you can choose.
- org.apache.cxf.ws.policy.PolicyException: None of the policy alternatives
can be satisfied.
- This error usually occurs when the WS-Security feature wsSecurity-1.1 is
not defined in the server.xml file. To avoid
this error, you must define the wsSecurity-1.1 feature
in the server.xml file as follows:
<featureManager>
<feature>usr:wsseccbh-1.0</feature>
<feature>servlet-3.0</feature>
<feature>appSecurity-2.0</feature>
<feature>jaxws-2.2</feature>
<feature>wsSecurity-1.1</feature>
</featureManager>
- org.apache.cxf.ws.policy.PolicyException: No callback handler
and no password available.
- This error occurs when the WS-Security run time cannot retrieve
a password that is required to generate a UsernameToken or to access
a private key from the keystore. To avoid this error, check the following
configuration:
- Ensure that the password callback handler feature wsseccbh-1.0 is
defined as a user feature in the server.xml file:
<featureManager>
<feature>usr:wsseccbh-1.0</feature>
<feature>servlet-3.0</feature>
<feature>appSecurity-2.0</feature>
<feature>jaxws-2.2</feature>
<feature>wsSecurity-1.1</feature>
</featureManager>
- Ensure that the callback handler property ws-security.callback-handler is
defined in the <wsSecurityClient> or <wsSecurityProvider> elements
of the server.xml file:
ws-security.callback-handler="<full class name of the callback handler>"
example:
ws-security.callback-handler="com.ibm.ws.wssecurity.example.cbh.CommonPasswordCallback"
- Ensure that the password callback handler returns the correct
password for the user name or the key alias that is specified in the server.xml file.
The password must be clear text and not encoded or encrypted.
- org.apache.ws.security.WSSecurityException: The signature does
not cover the required elements (soap:Body).
- This error occurs when a web service provider application expects
the SOAP body in the request message to be signed, but the received
SOAP message does not have the SOAP body signed. To avoid this error,
ensure that your web service client is configured with the correct
WS-Security policy that matches the web service provider’s policy.
- org.apache.ws.security.WSSecurityException: The signature or decryption
was invalid.
- This error occurs when the WS-Security run time fails to validate
the signature or decrypt an encrypted message part in the received
SOAP message. To avoid this error, verify that the correct keys are
used when you configure WS-Security in the <wsSecurityClient> and <wsSecurityProvider>
elements of the server.xml file. If a web service
client uses Bob’s public key to encrypt a message part, then the web
service provider must have access to Bob’s private key to decrypt
the message. Similarly, if a web service client signs a message part
by using Alice’s private key, then the web service provider must use
Alice’s public key to validate the signature.
- org.apache.cxf.ws.policy.PolicyException: These policy alternatives can not
be satisfied.
- This error occurs when the WS-Security run time cannot process
the incoming SOAP message successfully by using the WS-Security policy
that is configured to process this request. To avoid this error, look
at the messages that follow this exception to determine the specific
WS-Security policy assertions that are causing this exception. For
example, the log file might contain the following messages:
Caused by: org.apache.cxf.ws.policy.PolicyException: These policy alternatives can not be satisfied:
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}AsymmetricBinding: The encryption algorithm does not match the requirement
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}InitiatorEncryptionToken
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}RecipientEncryptionToken
at org.apache.cxf.ws.policy.AssertionInfoMap.checkEffectivePolicy(AssertionInfoMap.java:167)
at org.apache.cxf.ws.policy.PolicyVerificationInInterceptor.handle(PolicyVerificationInInterceptor.java:101)
In
this case, the error occurred because the encryption algorithm that
is used by the web service client does not match the encryption algorithm
that is specified by the AlgorithmSuite assertion. The algorithm suites
that are specified in the WS-Security policy of both the web service
client and the web service provider must specify the same encryption
algorithm.
- javax.xml.ws.soap.SOAPFaultException: The message has expired
(WSSecurityEngine: Invalid timestamp The security semantics of the
message have expired).
- This message occurs when the message timestamp is expired or the
message was created with a timestamp in the future.