Log soap request and response using apache-cxf - cxf

I am working on Maven project in Intellij.I have generated wsdl to java using cxf-codegen-plugin. I have created a client and created a tester.java to test the client. I have to log the soap request and response. I have one cxf.xml, config.properties and a client.java files. I am not sure where to configure to log the soap messages. Also i have less idea about webservices. I have also copied log4j.xml to my METAINF.
I have tried all possible scenarios in stack overflow. Not sure which is going wrong.

Assuming you have the latest version of CXF (or fairly recent), the easiest way is to enable the logging feature on the CXF bus in the cxf.xml:
...
<cxf:bus>
<cxf:features>
<cxf:logging/>
</cxf:features>
</cxf:bus>
...
or only on your jaxws endpoint:
<jaxws:endpoint...>
<jaxws:features>
<bean class="org.apache.cxf.feature.LoggingFeature"/>
</jaxws:features>
</jaxws:endpoint>
Make sure you have cxf-rt-features-logging-XXX.jar on your classpath (XXX = your version of CXF).
And configure logging as described here:
http://cxf.apache.org/docs/general-cxf-logging.html
You need to be in INFO level at least.

Related

SAML - Service Provider could not handle the request

I am self learning SAML. I am learning using picket link quick starts: https://github.com/jboss-developer/jboss-picketlink-quickstarts.
I deployed picketlink-federation-saml-idp-basic-wildfly.war in wildfly 9.0.2 running in port 9080 and picketlink-federation-saml-sp-post-basic-wildfly.war deployed in wildfly 9.0.2 running in port 8080. I also updated standalone.xml to update security domain for IDP and SP.
The only change I had todo in sample, was to update dependency of picketlink-jbas7, since the version in sample 2.8.0.Beta1-SNAPSHOT cannot to resolved. The maven dependency I am using in IDP is:
<dependency>
<groupId>org.picketlink.distribution</groupId>
<artifactId>picketlink-jbas7</artifactId>
<version>2.7.0.Final</version>
<scope>provided</scope>
</dependency>
The issue I am facing is, when I login to IDP and click on the SP link I get following exception in SP logs:
23:05:55,833 ERROR [org.picketlink.common] (default task-5) Service Provider could not handle the request.: java.lang.NullPointerException
at org.picketlink.identity.federation.web.handlers.saml2.SAML2IssuerTrustHandler$SPTrustHandler.handleStatusResponseType(SAML2IssuerTrustHandler.java:143)
at org.picketlink.identity.federation.web.handlers.saml2.SAML2IssuerTrustHandler.handleStatusResponseType(SAML2IssuerTrustHandler.java:70)
at org.picketlink.identity.federation.web.process.SAMLHandlerChainProcessor.callHandlerChain(SAMLHandlerChainProcessor.java:67)
at org.picketlink.identity.federation.web.process.ServiceProviderSAMLResponseProcessor.processHandlersChain(ServiceProviderSAMLResponseProcessor.java:106)
at org.picketlink.identity.federation.web.process.ServiceProviderSAMLResponseProcessor.process(ServiceProviderSAMLResponseProcessor.java:88)
at org.picketlink.identity.federation.bindings.wildfly.sp.SPFormAuthenticationMechanism.handleSAML2Response(SPFormAuthenticationMechanism.java:516)
at org.picketlink.identity.federation.bindings.wildfly.sp.SPFormAuthenticationMechanism.handleSAMLResponse(SPFormAuthenticationMechanism.java:306)
at org.picketlink.identity.federation.bindings.wildfly.sp.SPFormAuthenticationMechanism.authenticate(SPFormAuthenticationMechanism.java:268)
at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:339)
at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:356)
at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:325)
at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:138)
at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:113)
at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:106)
at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51)
at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56)
at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58)
at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:72)
at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:282)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:261)
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:172)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:774)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Please let me know what I am doing wrong.
Thanks
I faced the same issue learning from picketbox quickstarts. I am working with wildfly 10.1.0.Final.
The first thing I noticed was that in order to get the "Basic" working is necessary (https://github.com/jboss-developer/jboss-picketlink-quickstarts):
IDP: picketlink-federation-saml-idp-basic
SP(s): picketlink-federation-saml-sp-post-basic and picketlink-federation-saml-sp-redirect-basic
I deployed all generated .war in one container for simplicity.
There were two things that helped me find what was going on:
enable TRACE debug
version of picketlink is 2.5.5.SP2 in Wildfly 10 and SAML2LoginModule was not found in that package in picketlink-wildfly8-2.5.5.SP2.jar.
In particular I had a problem with login module getting this error:
Class org.picketlink.identity.federation.bindings.wildfly.SAML2LoginModule not found from Module "deployment.picketlink-federation-saml-sp-post-basic-wildfly.war:main" from Service Module Loader
Login failure: javax.security.auth.login.LoginException: unable to find LoginModule class: org.picketlink.identity.federation.bindings.wildfly.SAML2LoginModule
What I did was change login module to: org.picketlink.identity.federation.bindings.jboss.auth.SAML2LoginModule and the quickstart started working.
I gave up on picketlink.
I used openSAML, and I was able to develop IDP initiated and SP initiated flows with no issues.
References:
https://wiki.shibboleth.net/confluence/display/OpenSAML/OSTwoUserManual#
https://github.com/rasmusson/webprofile-ref-project

Accessing OpenMQ JMS Broker from ServiceMix+Camel

I am trying to get ServiceMix+Camel talking to OpenMQ JMS Broker. I have a Camel route definition defined in Blueprint DSL which posts messages into an ActiveMQ JMS Queue. This is working fine, but I am now trying to convert this to post messages to an instance of OpenMQ running inside a Glassfish4 container.
I'm running the following configuration:
JDK 1.7.0_60
ServiceMix 5.1.1 (so Camel 2.13.2)
The documentation on this topic is somewhat minimal, but I've gathered various snippets from Google searches here and here and come up with the following (relevant parts only):
....
<!-- Post over JMS into Manager -->
<to uri="openmq:queue:resman"/>
</route>
</camelContext>
<bean id="openmq" class="org.apache.camel.component.jms.JmsComponent">
<property name="connectionFactory">
<bean class="com.sun.messaging.ConnectionFactory">
<property name="imqAddressList" value="localhost:7676"/>
</bean>
</property>
</bean>
I have the following JMS related "features" enabled in Servicemix/OSGI:
[installed ] [3.2.4.RELEASE ] spring-jms
[installed ] [2.13.2 ] camel-jms
and I have the following OSGI bundles installed and active:
[ 89] [Active ] [ ] [ ] [ 50] geronimo-jms_1.1_spec (1.1.1)
[ 126] [Active ] [ ] [ ] [ 50] camel-jms (2.13.2)
The problem I have is a ClassNotFoundException at the point I deploy the Came Route Blueprint into ServiceMix. Here are the relevant snippets from the Stacktrace logged:
org.osgi.service.blueprint.container.ComponentDefinitionException: Unable to instantiate components
Caused by: java.lang.NoClassDefFoundError: javax/jms/JMSContext
Caused by: java.lang.ClassNotFoundException: javax.jms.JMSContext not found by org.apache.geronimo.specs.geronimo-jms_1.1_spec [89]
So on the assumption this is an OSGI bundling issue, I've dug down into the Camel "features" just to confirm the dependencies:
karaf#root> features:info camel-jms
Description of camel-jms 2.13.2 feature
----------------------------------------------------------------
Feature has no configuration
Feature has no configuration files
Feature depends on:
spring [3.2,4)
spring-jms [3.2,4)
camel-core 2.13.2
Feature contains followed bundles:
mvn:org.apache.geronimo.specs/geronimo-jta_1.1_spec/1.1.1 start-level=50
mvn:commons-pool/commons-pool/1.6 start-level=50
mvn:org.apache.geronimo.specs/geronimo-jms_1.1_spec/1.1.1 start-level=50
mvn:org.apache.camel/camel-jms/2.13.2 start-level=50
So it appears that it is the "geronimo-jms_1.1_spec" that is causing the stack trace as it can't find JMSContext. I making a big assumption that as ApacheMQ must be using the same JMS class, so it must be in the environment somewhere. Also, JMSContext seems to be a JMS 2.0 API interface, so is the issue here that the geronimo-jms_1.1_spec bundle is trying to reference a JMS2 API?
I also have the issue of getting the client JARs for OpenMQ installed into the environment. The OpenMQ client JARs shipped with Glassfish4 are plain JARs and not OSGI bundles (see https://java.net/jira/browse/MQ-328), so I plan to either use the "file:wrap" feature to deploy this into ServiceMix, or otherwise unpack and re-pack into the JAR containing my Beans. I don't think this is related to this problem, but I could be wrong.
OK, managed to work this one out finally. The clue was in the reference to javax.jms.JMSContext which is new in the JMS 2.0 API. I was attempting to use the OpenMQ client libraries (imq.jar and jms.jar) taken from the Glassfish4 distribution, which is at JEE7 and hence JMS v1.1. ServiceMix 5.1.1 is still at JMS V1.1, hence the ClassNotFoundException.
Solution:
When connecting to an instance of OpenMQ running under Glassfish4, you need to download and use the OpenMQ client libraries from the previous Glassfish 3.2.2 release. You can obtain this release release from the Glassfish project archives here.
Tests so far show this to be working fine, so if I find anything of relevance going forward I'll come back and update this post.

Tomcat 6.0.35 - how to bypass new CSRF protection on the manager application?

I have a command line script (actually a git post-checkout hook) that reloads my Solr application by doing a cURL to:
http://localhost:8080/manager/html/reload?path=/solr
Since I upgraded to Ubuntu 13.04, it now fails, where it used to work before the upgrade.
The cause of the problem is that my newer version of Tomcat (6.0.35), has some new CSRF protection and it now returns 403 Access Denied.
How can I solve the issue and bypass the CSRF protection?
More info:
My /etc/tomcat6/tomcat-users.xml file:
<?xml version='1.0' encoding='utf-8'?>
<role rolename="manager"/>
<user username="tomcat" password="secret" roles="manager"/>
</tomcat-users>
The documentation for Configuring Manager Application access in tomcat mentions some new manager roles, however my error specifically mentions that the single "manager" role still exists for the moment (and I tried the other roles anyway without success).
(As I was writing the question, I found the answer.) Instead of cURLing to the HTML application, I needed to cURL to the "plain text interface".
i.e. instead of
http://localhost:8080/manager/html/reload?path=/solr
Use:
http://localhost:8080/manager/reload?path=/solr
It turns out:
The HTML interface is protected against CSRF but the text and JMX interfaces are not.
This fits with the new role called "manager-script". To ensure my app will work in the future I changed my /etc/tomcat6/tomcat-users.xml file:
<?xml version='1.0' encoding='utf-8'?>
<role rolename="manager-gui"/>
<role rolename="manager-script"/>
<user username="tomcat" password="secret" roles="manager-gui,manager-script"/>
</tomcat-users>

CXF Web service client not encrypting the SOAP Request XML message

I am learning Webservice security . I am using CXF framework for that. I have developed one test service it will just double up the value whatever we sent. Based on this tutorial
i have added the WS-Policy for XML encryption and signature.
Then i developed the web service client for this service as a eclipse project using CXF.
The following is my client configuration file
<jaxws:client id="doubleItClient" serviceClass="com.DoubleIt" address="http://localhost:8080/myencws/services/DoubleItPort?wsdl">
<jaxws:features>
<bean class="org.apache.cxf.feature.LoggingFeature" />
</jaxws:features>
<jaxws:properties>
<entry key="ws-security.callback-handler" value="com.ClientKeystorePasswordCallback"/>
<entry key="ws-security.encryption.properties" value="com/clientKeystore.properties"/>
<entry key="ws-security.signature.properties" value="com/clientKeystore.properties"/>
<entry key="ws-security.encryption.username" value="myservicekey"/>
</jaxws:properties>
I have generated all the keystore file , and i created the clientKeystore.properties file and placed in the src directory of my project.
But whenever i run this client the SOAP request message was not encrypted. So inn server side i am getting exception like
These policy alternatives can not be satisfied:
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}EncryptedParts
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}SignedParts
The following is my SOAP request
<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Body><ns2:doubleValue
xmlns:ns2="http://com/"><arg0>5</arg0></ns2:doubleValue></soap:Body></soap:Envelope>
I am using CXF2.7.3. I dont know whats wrong . Please help me.
I have a similar issue with my code before, what was missing was the jar dependencies which does the actual encryption when the security policy are read by your client from the WSDL.
My fix was to add certain maven dependencies in your POM to enable encryption. Check this url: http://cxf.apache.org/docs/using-cxf-with-maven.html
Also read "Enabling WS-SecurityPolicy" section in url http://cxf.apache.org/docs/ws-securitypolicy.html
I hope this helps
Make sure you are using the correct library. Try to include cxf bundle only, remove other cxf dependencies
If you are using maven, something like this:
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-bundle</artifactId>
<version>2.7.18</version>
</dependency>
I ran into the same issue and after much experimentation, the following guidelines help every single time.
Structure your cxf client config xml to have import of META-INF cxf.xml.
Define the cxf bus features (for logging)
Define the http conduits (if needed for TLS Handshake etc)
jaxws:client bean with name attribute as {targetNameSpaceWSDL)/PortName and createdFromAPI=true and abstract=true
Make client tag contain jaxws features. Remember to use latest "security" and not "ws-security"
In your java client class, use the SpringBus to load the cxf client config xml.SVN Link for SpringBus Client Config
Make sure all the required dependencies for WS policy processing is present in classpath like cxf-rt-ws-policy and cxf-rt-ws-security.jar and bouncycastle providers if needed
Note:
security.signature.properties and security.encryption.properties can be externalized as well and directly referred to with the absolute path in the xml value.

CXF Weblogic - Override CXF logger to Slf4j

We are using Apache CXF 2.5.2 for webservice client proxies. We use weblogic 10.3.4. To override the CXF logger we use the following option:
-Dorg.apache.cxf.Logger=org.apache.cxf.common.logging.Slf4jLogger
For the org.apache.cxf.common.logging.Slf4jLogger, we've included the cxf-common-utilities-2.5.2 in our build.
When we try to deploy to weblogic we get the following exception:
[ERROR] Target state: deploy failed on Server AdminServer
[ERROR] java.lang.NoClassDefFoundError: weblogic/wsee/jaxws/spi/WLSProvider
According to documentation, your WebService client should have wseeclient.jar as it's runtime dependency. If the problems is still there, then include wlfullclient.jar (see Creating a wlfullclient.jar for JDK 1.6 client applications ).

Resources