FAQ
I have a scenario where I want to add wss signing to an outgoing web
service call. I am trying to accomplish this by using a cxf consumer and a
cxf producer wired together by camel as a simple proxy.

The idea is this: a system sends an un-signed SOAP request to our CXF web
service requiring no security. The call is then routed to a CXF client,
which signs th eoutgoing message using wss. This way, the original caller
does not concern itself with any security related issues.

I have included our spring configuration below. The problem is that the
call gets routed as it should through the two CXF beans, but the outgoing
call leaves the CXF client without being signed. There is no trace of any
wss headers in the outgoing call.

Turning on debugging, I can see that the WSS4JOutInterceptor is invoked,
and it writes to the debug messages that it has created a
xmldsig:SignedInfo element, but this is never added to the outgoing
message. Can anyone here throw some light on this problem?

Here's the configuration:

<?xml version="1.0" encoding="UTF-8"?>

<beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="
http://www.w3.org/2001/XMLSchema-instance" xmlns:camel="
http://camel.apache.org/schema/spring"
xmlns:cxf="http://camel.apache.org/schema/cxf" xmlns:context="
http://www.springframework.org/schema/context"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/context
http://www.springframework.org/schema/context/spring-context.xsd
http://camel.apache.org/schema/spring
http://camel.apache.org/schema/spring/camel-spring.xsd
http://camel.apache.org/schema/cxf
" rel="nofollow">http://camel.apache.org/schema/cxf/camel-cxf.xsd">

<import resource="classpath:META-INF/cxf/cxf.xml" />

<cxf:cxfEndpoint id="receiveOutgoingMessageEndpoint"
wsdlURL="etc/SendOccupationalPensionService.wsdl"
address="/sendOccupationalPension"
serviceName="s:SendOccupationalPensionService" xmlns:s="
" rel="nofollow">http://ssek.ic.afa.se/">
<cxf:properties>
<entry key="dataFormat" value="MESSAGE" />
</cxf:properties>
</cxf:cxfEndpoint>

<cxf:cxfEndpoint id="sendOutgoingMessageEndpoint" address="
" rel="nofollow">http://localhost:8088/mockSendOccupationalPensionResponseToFKSOAPBinding">
<cxf:properties>
<entry key="dataFormat" value="MESSAGE" />
</cxf:properties>
<cxf:outInterceptors>
<bean
class="org.apache.cxf.ws.security.wss4j.WSS4JOutInterceptor">
<constructor-arg>
<map>
<entry key="action" value="Timestamp Signature" />
<entry key="user" value="myservicekey" />
<entry key="signatureKeyIdentifier"
value="DirectReference" />
<entry key="timeToLive" value="10800" />
<entry key="signaturePropFile"
value="classpath:etc/ssek.serviceKeystore.properties" />
<entry key="passwordCallbackRef">
<bean
class="se.afa.ic.ssek.ServiceKeystorePasswordCallback">
<constructor-arg>
<value>myservicekey</value>
</constructor-arg>
<constructor-arg>
<value>skpass</value>
</constructor-arg>
</bean>
</entry>
<entry key="signatureParts"
value="{Element}{
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd}Timestamp;{Element}{http://schemas.xmlsoap.org/soap/envelope/}Body"
/>
</map>
</constructor-arg>
</bean>
</cxf:outInterceptors>
</cxf:cxfEndpoint>

<camelContext id="camelContext" xmlns="
" rel="nofollow">http://camel.apache.org/schema/spring">
<route trace="true">
<from uri="cxf:bean:receiveOutgoingMessageEndpoint" />
<to uri="cxf:bean:sendOutgoingMessageEndpoint" />
</route>
</camelContext>

</beans>

Search Discussions

  • Daniel Kulp at Nov 20, 2012 at 8:31 pm
    With MESSAGE mode, camel-cxf pretty much keeps everything as a stream and bypasses much of the CXF interceptor chain and conversions and such. In some cases, that's very good. Performance and stuff works well. However, it also means a lot of CXF's processing capabilities are not used/usable.

    If you flip to PAYLOAD mode or the new CXF_MESSAGE mode, it will likely work find for you. Those will behave more like normal CXF clients/servers that would allow all the ws-security stuff to work.

    Dan


    On Nov 20, 2012, at 10:01 AM, Jesper Nygårds wrote:

    I have a scenario where I want to add wss signing to an outgoing web
    service call. I am trying to accomplish this by using a cxf consumer and a
    cxf producer wired together by camel as a simple proxy.

    The idea is this: a system sends an un-signed SOAP request to our CXF web
    service requiring no security. The call is then routed to a CXF client,
    which signs th eoutgoing message using wss. This way, the original caller
    does not concern itself with any security related issues.

    I have included our spring configuration below. The problem is that the
    call gets routed as it should through the two CXF beans, but the outgoing
    call leaves the CXF client without being signed. There is no trace of any
    wss headers in the outgoing call.

    Turning on debugging, I can see that the WSS4JOutInterceptor is invoked,
    and it writes to the debug messages that it has created a
    xmldsig:SignedInfo element, but this is never added to the outgoing
    message. Can anyone here throw some light on this problem?

    Here's the configuration:

    <?xml version="1.0" encoding="UTF-8"?>

    <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="
    http://www.w3.org/2001/XMLSchema-instance" xmlns:camel="
    http://camel.apache.org/schema/spring"
    xmlns:cxf="http://camel.apache.org/schema/cxf" xmlns:context="
    http://www.springframework.org/schema/context"
    xsi:schemaLocation="http://www.springframework.org/schema/beans
    http://www.springframework.org/schema/beans/spring-beans.xsd
    http://www.springframework.org/schema/context
    http://www.springframework.org/schema/context/spring-context.xsd
    http://camel.apache.org/schema/spring
    http://camel.apache.org/schema/spring/camel-spring.xsd
    http://camel.apache.org/schema/cxf
    " rel="nofollow">http://camel.apache.org/schema/cxf/camel-cxf.xsd">

    <import resource="classpath:META-INF/cxf/cxf.xml" />

    <cxf:cxfEndpoint id="receiveOutgoingMessageEndpoint"
    wsdlURL="etc/SendOccupationalPensionService.wsdl"
    address="/sendOccupationalPension"
    serviceName="s:SendOccupationalPensionService" xmlns:s="
    " rel="nofollow">http://ssek.ic.afa.se/">
    <cxf:properties>
    <entry key="dataFormat" value="MESSAGE" />
    </cxf:properties>
    </cxf:cxfEndpoint>

    <cxf:cxfEndpoint id="sendOutgoingMessageEndpoint" address="
    " rel="nofollow">http://localhost:8088/mockSendOccupationalPensionResponseToFKSOAPBinding">
    <cxf:properties>
    <entry key="dataFormat" value="MESSAGE" />
    </cxf:properties>
    <cxf:outInterceptors>
    <bean
    class="org.apache.cxf.ws.security.wss4j.WSS4JOutInterceptor">
    <constructor-arg>
    <map>
    <entry key="action" value="Timestamp Signature" />
    <entry key="user" value="myservicekey" />
    <entry key="signatureKeyIdentifier"
    value="DirectReference" />
    <entry key="timeToLive" value="10800" />
    <entry key="signaturePropFile"
    value="classpath:etc/ssek.serviceKeystore.properties" />
    <entry key="passwordCallbackRef">
    <bean
    class="se.afa.ic.ssek.ServiceKeystorePasswordCallback">
    <constructor-arg>
    <value>myservicekey</value>
    </constructor-arg>
    <constructor-arg>
    <value>skpass</value>
    </constructor-arg>
    </bean>
    </entry>
    <entry key="signatureParts"
    value="{Element}{
    http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd}Timestamp;{Element}{http://schemas.xmlsoap.org/soap/envelope/}Body"
    />
    </map>
    </constructor-arg>
    </bean>
    </cxf:outInterceptors>
    </cxf:cxfEndpoint>

    <camelContext id="camelContext" xmlns="
    " rel="nofollow">http://camel.apache.org/schema/spring">
    <route trace="true">
    <from uri="cxf:bean:receiveOutgoingMessageEndpoint" />
    <to uri="cxf:bean:sendOutgoingMessageEndpoint" />
    </route>
    </camelContext>

    </beans>
    --
    Daniel Kulp
    dkulp@apache.org - http://dankulp.com/blog
    Talend Community Coder - http://coders.talend.com
  • Jesper Nygårds at Nov 21, 2012 at 10:52 am
    Great thanks, Daniel!

    That solved the problem. I have a hard time finding any documentation about
    CXF_MESSAGE mode. What is the difference between this and the PAYLOAD mode?

    Jesper


    On Tue, Nov 20, 2012 at 9:31 PM, Daniel Kulp wrote:


    With MESSAGE mode, camel-cxf pretty much keeps everything as a stream and
    bypasses much of the CXF interceptor chain and conversions and such. In
    some cases, that's very good. Performance and stuff works well. However,
    it also means a lot of CXF's processing capabilities are not used/usable.

    If you flip to PAYLOAD mode or the new CXF_MESSAGE mode, it will likely
    work find for you. Those will behave more like normal CXF clients/servers
    that would allow all the ws-security stuff to work.

    Dan


    On Nov 20, 2012, at 10:01 AM, Jesper Nygårds wrote:

    I have a scenario where I want to add wss signing to an outgoing web
    service call. I am trying to accomplish this by using a cxf consumer and a
    cxf producer wired together by camel as a simple proxy.

    The idea is this: a system sends an un-signed SOAP request to our CXF web
    service requiring no security. The call is then routed to a CXF client,
    which signs th eoutgoing message using wss. This way, the original caller
    does not concern itself with any security related issues.

    I have included our spring configuration below. The problem is that the
    call gets routed as it should through the two CXF beans, but the outgoing
    call leaves the CXF client without being signed. There is no trace of any
    wss headers in the outgoing call.

    Turning on debugging, I can see that the WSS4JOutInterceptor is invoked,
    and it writes to the debug messages that it has created a
    xmldsig:SignedInfo element, but this is never added to the outgoing
    message. Can anyone here throw some light on this problem?

    Here's the configuration:

    <?xml version="1.0" encoding="UTF-8"?>

    <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="
    http://www.w3.org/2001/XMLSchema-instance" xmlns:camel="
    http://camel.apache.org/schema/spring"
    xmlns:cxf="http://camel.apache.org/schema/cxf" xmlns:context="
    http://www.springframework.org/schema/context"
    xsi:schemaLocation="http://www.springframework.org/schema/beans
    http://www.springframework.org/schema/beans/spring-beans.xsd
    http://www.springframework.org/schema/context
    http://www.springframework.org/schema/context/spring-context.xsd
    http://camel.apache.org/schema/spring
    http://camel.apache.org/schema/spring/camel-spring.xsd
    http://camel.apache.org/schema/cxf
    " rel="nofollow">http://camel.apache.org/schema/cxf/camel-cxf.xsd">

    <import resource="classpath:META-INF/cxf/cxf.xml" />

    <cxf:cxfEndpoint id="receiveOutgoingMessageEndpoint"
    wsdlURL="etc/SendOccupationalPensionService.wsdl"
    address="/sendOccupationalPension"
    serviceName="s:SendOccupationalPensionService" xmlns:s="
    " rel="nofollow">http://ssek.ic.afa.se/">
    <cxf:properties>
    <entry key="dataFormat" value="MESSAGE" />
    </cxf:properties>
    </cxf:cxfEndpoint>

    <cxf:cxfEndpoint id="sendOutgoingMessageEndpoint" address="
    http://localhost:8088/mockSendOccupationalPensionResponseToFKSOAPBinding ">
    <cxf:properties>
    <entry key="dataFormat" value="MESSAGE" />
    </cxf:properties>
    <cxf:outInterceptors>
    <bean
    class="org.apache.cxf.ws.security.wss4j.WSS4JOutInterceptor">
    <constructor-arg>
    <map>
    <entry key="action" value="Timestamp Signature" />
    <entry key="user" value="myservicekey" />
    <entry key="signatureKeyIdentifier"
    value="DirectReference" />
    <entry key="timeToLive" value="10800" />
    <entry key="signaturePropFile"
    value="classpath:etc/ssek.serviceKeystore.properties" />
    <entry key="passwordCallbackRef">
    <bean
    class="se.afa.ic.ssek.ServiceKeystorePasswordCallback">
    <constructor-arg>
    <value>myservicekey</value>
    </constructor-arg>
    <constructor-arg>
    <value>skpass</value>
    </constructor-arg>
    </bean>
    </entry>
    <entry key="signatureParts"
    value="{Element}{
    http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd}Timestamp;{Element}{http://schemas.xmlsoap.org/soap/envelope/}Body
    "
    />
    </map>
    </constructor-arg>
    </bean>
    </cxf:outInterceptors>
    </cxf:cxfEndpoint>

    <camelContext id="camelContext" xmlns="
    " rel="nofollow">http://camel.apache.org/schema/spring">
    <route trace="true">
    <from uri="cxf:bean:receiveOutgoingMessageEndpoint" />
    <to uri="cxf:bean:sendOutgoingMessageEndpoint" />
    </route>
    </camelContext>

    </beans>
    --
    Daniel Kulp
    dkulp@apache.org - http://dankulp.com/blog
    Talend Community Coder - http://coders.talend.com
  • Daniel Kulp at Nov 26, 2012 at 7:17 pm

    On Nov 21, 2012, at 5:51 AM, Jesper Nygårds wrote:

    Great thanks, Daniel!

    That solved the problem. I have a hard time finding any documentation about
    CXF_MESSAGE mode. What is the difference between this and the PAYLOAD mode?
    MESSAGE (or RAW) pretty much is equivalent to passing a raw InputStream through the system. Most of CXF's handling is bypassed. For the most part, this would be very close to just using the Jetty or other http component, although there are somethings that the CXF component can do in this scenario (like generate the WSDL).

    CXF_MESSAGE mode is similar to the JAX-WS Message mode for Provider/Dispatch clients where the entire message is available in the route. All of the CXF processing is available as this is handled internally just like the Provider/Dispatches. Downside is that the entire message is parsed and is likely in memory (SAAJ).

    PAYLOAD mode is somewhat similar to the PAYLOAD mode for Provider/Dispatches. The only information available in the route is the contents of the soap:Body. However, CXF's processing is more optimized for this use case which, in some scenarios, allows streaming to continue for this. However, it's a StAX based streaming, not input/output stream based streaming like in MESSAGE/RAW mode. Also, in PAYLOAD mode, I believe that since it's just the body pushed through the route, things like headers are, by default, stripped off. In CXF_MESSAGE mode, you may need to write some code to remove headers. (conversely, in PAYLOAD mode, you may need code to copy headers if needed)

    There are upsides and downsides for each of the three modes.


    Dan



    Jesper


    On Tue, Nov 20, 2012 at 9:31 PM, Daniel Kulp wrote:


    With MESSAGE mode, camel-cxf pretty much keeps everything as a stream and
    bypasses much of the CXF interceptor chain and conversions and such. In
    some cases, that's very good. Performance and stuff works well. However,
    it also means a lot of CXF's processing capabilities are not used/usable.

    If you flip to PAYLOAD mode or the new CXF_MESSAGE mode, it will likely
    work find for you. Those will behave more like normal CXF clients/servers
    that would allow all the ws-security stuff to work.

    Dan



    On Nov 20, 2012, at 10:01 AM, Jesper Nygårds <jesper.nygards@gmail.com>
    wrote:
    I have a scenario where I want to add wss signing to an outgoing web
    service call. I am trying to accomplish this by using a cxf consumer and a
    cxf producer wired together by camel as a simple proxy.

    The idea is this: a system sends an un-signed SOAP request to our CXF web
    service requiring no security. The call is then routed to a CXF client,
    which signs th eoutgoing message using wss. This way, the original caller
    does not concern itself with any security related issues.

    I have included our spring configuration below. The problem is that the
    call gets routed as it should through the two CXF beans, but the outgoing
    call leaves the CXF client without being signed. There is no trace of any
    wss headers in the outgoing call.

    Turning on debugging, I can see that the WSS4JOutInterceptor is invoked,
    and it writes to the debug messages that it has created a
    xmldsig:SignedInfo element, but this is never added to the outgoing
    message. Can anyone here throw some light on this problem?

    Here's the configuration:

    <?xml version="1.0" encoding="UTF-8"?>

    <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="
    http://www.w3.org/2001/XMLSchema-instance" xmlns:camel="
    http://camel.apache.org/schema/spring"
    xmlns:cxf="http://camel.apache.org/schema/cxf" xmlns:context="
    http://www.springframework.org/schema/context"
    xsi:schemaLocation="http://www.springframework.org/schema/beans
    http://www.springframework.org/schema/beans/spring-beans.xsd
    http://www.springframework.org/schema/context
    http://www.springframework.org/schema/context/spring-context.xsd
    http://camel.apache.org/schema/spring
    http://camel.apache.org/schema/spring/camel-spring.xsd
    http://camel.apache.org/schema/cxf
    " rel="nofollow">http://camel.apache.org/schema/cxf/camel-cxf.xsd">

    <import resource="classpath:META-INF/cxf/cxf.xml" />

    <cxf:cxfEndpoint id="receiveOutgoingMessageEndpoint"
    wsdlURL="etc/SendOccupationalPensionService.wsdl"
    address="/sendOccupationalPension"
    serviceName="s:SendOccupationalPensionService" xmlns:s="
    " rel="nofollow">http://ssek.ic.afa.se/">
    <cxf:properties>
    <entry key="dataFormat" value="MESSAGE" />
    </cxf:properties>
    </cxf:cxfEndpoint>

    <cxf:cxfEndpoint id="sendOutgoingMessageEndpoint" address="
    http://localhost:8088/mockSendOccupationalPensionResponseToFKSOAPBinding ">
    <cxf:properties>
    <entry key="dataFormat" value="MESSAGE" />
    </cxf:properties>
    <cxf:outInterceptors>
    <bean
    class="org.apache.cxf.ws.security.wss4j.WSS4JOutInterceptor">
    <constructor-arg>
    <map>
    <entry key="action" value="Timestamp Signature" />
    <entry key="user" value="myservicekey" />
    <entry key="signatureKeyIdentifier"
    value="DirectReference" />
    <entry key="timeToLive" value="10800" />
    <entry key="signaturePropFile"
    value="classpath:etc/ssek.serviceKeystore.properties" />
    <entry key="passwordCallbackRef">
    <bean
    class="se.afa.ic.ssek.ServiceKeystorePasswordCallback">
    <constructor-arg>
    <value>myservicekey</value>
    </constructor-arg>
    <constructor-arg>
    <value>skpass</value>
    </constructor-arg>
    </bean>
    </entry>
    <entry key="signatureParts"
    value="{Element}{
    http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd}Timestamp;{Element}{http://schemas.xmlsoap.org/soap/envelope/}Body
    "
    />
    </map>
    </constructor-arg>
    </bean>
    </cxf:outInterceptors>
    </cxf:cxfEndpoint>

    <camelContext id="camelContext" xmlns="
    " rel="nofollow">http://camel.apache.org/schema/spring">
    <route trace="true">
    <from uri="cxf:bean:receiveOutgoingMessageEndpoint" />
    <to uri="cxf:bean:sendOutgoingMessageEndpoint" />
    </route>
    </camelContext>

    </beans>
    --
    Daniel Kulp
    dkulp@apache.org - http://dankulp.com/blog
    Talend Community Coder - http://coders.talend.com
    --
    Daniel Kulp
    dkulp@apache.org - http://dankulp.com/blog
    Talend Community Coder - http://coders.talend.com
  • Willem jiang at Nov 27, 2012 at 2:53 am
    Just a comments for access the soap headers from other data format.

    PAYLOAD data format, you can access the soap header from CxfPayload which is store in the Camel Message body like this.
    CxfPayload payload = exchange.getIn().getBody(CxfPayload.class);
    List<SoapHeader> soapHeaders = payload.getHeaders();

    POJO data format, you can access the soap header like this
    List<SoapHeader> soapHeaders = CastUtils.cast((List<?>)exchange.getIn().getHeader(Header.HEADER_LIST));


    --
    Willem Jiang

    Red Hat, Inc.
    FuseSource is now part of Red Hat
    Web: http://www.fusesource.com | http://www.redhat.com
    Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) (English)
    http://jnn.javaeye.com (http://jnn.javaeye.com/) (Chinese)
    Twitter: willemjiang
    Weibo: willemjiang


    On Tuesday, November 27, 2012 at 3:16 AM, Daniel Kulp wrote:

    On Nov 21, 2012, at 5:51 AM, Jesper Nygårds (mailto:jesper.nygards@gmail.com)> wrote:

    Great thanks, Daniel!

    That solved the problem. I have a hard time finding any documentation about
    CXF_MESSAGE mode. What is the difference between this and the PAYLOAD mode?


    MESSAGE (or RAW) pretty much is equivalent to passing a raw InputStream through the system. Most of CXF's handling is bypassed. For the most part, this would be very close to just using the Jetty or other http component, although there are somethings that the CXF component can do in this scenario (like generate the WSDL).

    CXF_MESSAGE mode is similar to the JAX-WS Message mode for Provider/Dispatch clients where the entire message is available in the route. All of the CXF processing is available as this is handled internally just like the Provider/Dispatches. Downside is that the entire message is parsed and is likely in memory (SAAJ).

    PAYLOAD mode is somewhat similar to the PAYLOAD mode for Provider/Dispatches. The only information available in the route is the contents of the soap:Body. However, CXF's processing is more optimized for this use case which, in some scenarios, allows streaming to continue for this. However, it's a StAX based streaming, not input/output stream based streaming like in MESSAGE/RAW mode. Also, in PAYLOAD mode, I believe that since it's just the body pushed through the route, things like headers are, by default, stripped off. In CXF_MESSAGE mode, you may need to write some code to remove headers. (conversely, in PAYLOAD mode, you may need code to copy headers if needed)

    There are upsides and downsides for each of the three modes.


    Dan



    Jesper


    On Tue, Nov 20, 2012 at 9:31 PM, Daniel Kulp (mailto:dkulp@apache.org)> wrote:


    With MESSAGE mode, camel-cxf pretty much keeps everything as a stream and
    bypasses much of the CXF interceptor chain and conversions and such. In
    some cases, that's very good. Performance and stuff works well. However,
    it also means a lot of CXF's processing capabilities are not used/usable.

    If you flip to PAYLOAD mode or the new CXF_MESSAGE mode, it will likely
    work find for you. Those will behave more like normal CXF clients/servers
    that would allow all the ws-security stuff to work.

    Dan



    On Nov 20, 2012, at 10:01 AM, Jesper Nygårds (mailto:jesper.nygards@gmail.com)>
    wrote:
    I have a scenario where I want to add wss signing to an outgoing web
    service call. I am trying to accomplish this by using a cxf consumer and

    a
    cxf producer wired together by camel as a simple proxy.

    The idea is this: a system sends an un-signed SOAP request to our CXF web
    service requiring no security. The call is then routed to a CXF client,
    which signs th eoutgoing message using wss. This way, the original caller
    does not concern itself with any security related issues.

    I have included our spring configuration below. The problem is that the
    call gets routed as it should through the two CXF beans, but the outgoing
    call leaves the CXF client without being signed. There is no trace of any
    wss headers in the outgoing call.

    Turning on debugging, I can see that the WSS4JOutInterceptor is invoked,
    and it writes to the debug messages that it has created a
    xmldsig:SignedInfo element, but this is never added to the outgoing
    message. Can anyone here throw some light on this problem?

    Here's the configuration:

    <?xml version="1.0" encoding="UTF-8"?>

    <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="
    http://www.w3.org/2001/XMLSchema-instance" xmlns:camel="
    http://camel.apache.org/schema/spring"
    xmlns:cxf="http://camel.apache.org/schema/cxf" xmlns:context="
    http://www.springframework.org/schema/context"
    xsi:schemaLocation="http://www.springframework.org/schema/beans
    http://www.springframework.org/schema/beans/spring-beans.xsd
    http://www.springframework.org/schema/context
    http://www.springframework.org/schema/context/spring-context.xsd
    http://camel.apache.org/schema/spring
    http://camel.apache.org/schema/spring/camel-spring.xsd
    http://camel.apache.org/schema/cxf
    " rel="nofollow">http://camel.apache.org/schema/cxf/camel-cxf.xsd">

    <import resource="classpath:META-INF/cxf/cxf.xml" />

    <cxf:cxfEndpoint id="receiveOutgoingMessageEndpoint"
    wsdlURL="etc/SendOccupationalPensionService.wsdl"
    address="/sendOccupationalPension"
    serviceName="s:SendOccupationalPensionService" xmlns:s="
    " rel="nofollow">http://ssek.ic.afa.se/">
    <cxf:properties>
    <entry key="dataFormat" value="MESSAGE" />
    </cxf:properties>
    </cxf:cxfEndpoint>

    <cxf:cxfEndpoint id="sendOutgoingMessageEndpoint" address="
    http://localhost:8088/mockSendOccupationalPensionResponseToFKSOAPBinding

    ">
    <cxf:properties>
    <entry key="dataFormat" value="MESSAGE" />
    </cxf:properties>
    <cxf:outInterceptors>
    <bean
    class="org.apache.cxf.ws.security.wss4j.WSS4JOutInterceptor">
    <constructor-arg>
    <map>
    <entry key="action" value="Timestamp Signature" />
    <entry key="user" value="myservicekey" />
    <entry key="signatureKeyIdentifier"
    value="DirectReference" />
    <entry key="timeToLive" value="10800" />
    <entry key="signaturePropFile"
    value="classpath:etc/ssek.serviceKeystore.properties" />
    <entry key="passwordCallbackRef">
    <bean
    class="se.afa.ic.ssek.ServiceKeystorePasswordCallback">
    <constructor-arg>
    <value>myservicekey</value>
    </constructor-arg>
    <constructor-arg>
    <value>skpass</value>
    </constructor-arg>
    </bean>
    </entry>
    <entry key="signatureParts"
    value="{Element}{

    http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd}Timestamp;{Element}{http://schemas.xmlsoap.org/soap/envelope/}Body
    "
    />
    </map>
    </constructor-arg>
    </bean>
    </cxf:outInterceptors>
    </cxf:cxfEndpoint>

    <camelContext id="camelContext" xmlns="
    " rel="nofollow">http://camel.apache.org/schema/spring">
    <route trace="true">
    <from uri="cxf:bean:receiveOutgoingMessageEndpoint" />
    <to uri="cxf:bean:sendOutgoingMessageEndpoint" />
    </route>
    </camelContext>

    </beans>
    --
    Daniel Kulp
    dkulp@apache.org - http://dankulp.com/blog
    Talend Community Coder - http://coders.talend.com


    --
    Daniel Kulp
    dkulp@apache.org - http://dankulp.com/blog
    Talend Community Coder - http://coders.talend.com
  • Claus Ibsen at Nov 27, 2012 at 7:15 am
    Hi

    Could Dan's and Willems' comments be added as a FAQ, and a reference
    to it from the Camel CXF doc page?
    This is good details in there that end users of Camel and CXF likely
    would like to find more easier than what you can do today.

    On Tue, Nov 27, 2012 at 3:52 AM, Willem jiang wrote:
    Just a comments for access the soap headers from other data format.

    PAYLOAD data format, you can access the soap header from CxfPayload which is store in the Camel Message body like this.
    CxfPayload payload = exchange.getIn().getBody(CxfPayload.class);
    List<SoapHeader> soapHeaders = payload.getHeaders();

    POJO data format, you can access the soap header like this
    List<SoapHeader> soapHeaders = CastUtils.cast((List<?>)exchange.getIn().getHeader(Header.HEADER_LIST));


    --
    Willem Jiang

    Red Hat, Inc.
    FuseSource is now part of Red Hat
    Web: http://www.fusesource.com | http://www.redhat.com
    Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) (English)
    http://jnn.javaeye.com (http://jnn.javaeye.com/) (Chinese)
    Twitter: willemjiang
    Weibo: willemjiang


    On Tuesday, November 27, 2012 at 3:16 AM, Daniel Kulp wrote:

    On Nov 21, 2012, at 5:51 AM, Jesper Nygårds (mailto:jesper.nygards@gmail.com)> wrote:

    Great thanks, Daniel!

    That solved the problem. I have a hard time finding any documentation about
    CXF_MESSAGE mode. What is the difference between this and the PAYLOAD mode?


    MESSAGE (or RAW) pretty much is equivalent to passing a raw InputStream through the system. Most of CXF's handling is bypassed. For the most part, this would be very close to just using the Jetty or other http component, although there are somethings that the CXF component can do in this scenario (like generate the WSDL).

    CXF_MESSAGE mode is similar to the JAX-WS Message mode for Provider/Dispatch clients where the entire message is available in the route. All of the CXF processing is available as this is handled internally just like the Provider/Dispatches. Downside is that the entire message is parsed and is likely in memory (SAAJ).

    PAYLOAD mode is somewhat similar to the PAYLOAD mode for Provider/Dispatches. The only information available in the route is the contents of the soap:Body. However, CXF's processing is more optimized for this use case which, in some scenarios, allows streaming to continue for this. However, it's a StAX based streaming, not input/output stream based streaming like in MESSAGE/RAW mode. Also, in PAYLOAD mode, I believe that since it's just the body pushed through the route, things like headers are, by default, stripped off. In CXF_MESSAGE mode, you may need to write some code to remove headers. (conversely, in PAYLOAD mode, you may need code to copy headers if needed)

    There are upsides and downsides for each of the three modes.


    Dan



    Jesper


    On Tue, Nov 20, 2012 at 9:31 PM, Daniel Kulp (mailto:dkulp@apache.org)> wrote:


    With MESSAGE mode, camel-cxf pretty much keeps everything as a stream and
    bypasses much of the CXF interceptor chain and conversions and such. In
    some cases, that's very good. Performance and stuff works well. However,
    it also means a lot of CXF's processing capabilities are not used/usable.

    If you flip to PAYLOAD mode or the new CXF_MESSAGE mode, it will likely
    work find for you. Those will behave more like normal CXF clients/servers
    that would allow all the ws-security stuff to work.

    Dan



    On Nov 20, 2012, at 10:01 AM, Jesper Nygårds (mailto:jesper.nygards@gmail.com)>
    wrote:
    I have a scenario where I want to add wss signing to an outgoing web
    service call. I am trying to accomplish this by using a cxf consumer and

    a
    cxf producer wired together by camel as a simple proxy.

    The idea is this: a system sends an un-signed SOAP request to our CXF web
    service requiring no security. The call is then routed to a CXF client,
    which signs th eoutgoing message using wss. This way, the original caller
    does not concern itself with any security related issues.

    I have included our spring configuration below. The problem is that the
    call gets routed as it should through the two CXF beans, but the outgoing
    call leaves the CXF client without being signed. There is no trace of any
    wss headers in the outgoing call.

    Turning on debugging, I can see that the WSS4JOutInterceptor is invoked,
    and it writes to the debug messages that it has created a
    xmldsig:SignedInfo element, but this is never added to the outgoing
    message. Can anyone here throw some light on this problem?

    Here's the configuration:

    <?xml version="1.0" encoding="UTF-8"?>

    <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="
    http://www.w3.org/2001/XMLSchema-instance" xmlns:camel="
    http://camel.apache.org/schema/spring"
    xmlns:cxf="http://camel.apache.org/schema/cxf" xmlns:context="
    http://www.springframework.org/schema/context"
    xsi:schemaLocation="http://www.springframework.org/schema/beans
    http://www.springframework.org/schema/beans/spring-beans.xsd
    http://www.springframework.org/schema/context
    http://www.springframework.org/schema/context/spring-context.xsd
    http://camel.apache.org/schema/spring
    http://camel.apache.org/schema/spring/camel-spring.xsd
    http://camel.apache.org/schema/cxf
    " rel="nofollow">http://camel.apache.org/schema/cxf/camel-cxf.xsd">

    <import resource="classpath:META-INF/cxf/cxf.xml" />

    <cxf:cxfEndpoint id="receiveOutgoingMessageEndpoint"
    wsdlURL="etc/SendOccupationalPensionService.wsdl"
    address="/sendOccupationalPension"
    serviceName="s:SendOccupationalPensionService" xmlns:s="
    " rel="nofollow">http://ssek.ic.afa.se/">
    <cxf:properties>
    <entry key="dataFormat" value="MESSAGE" />
    </cxf:properties>
    </cxf:cxfEndpoint>

    <cxf:cxfEndpoint id="sendOutgoingMessageEndpoint" address="
    http://localhost:8088/mockSendOccupationalPensionResponseToFKSOAPBinding

    ">
    <cxf:properties>
    <entry key="dataFormat" value="MESSAGE" />
    </cxf:properties>
    <cxf:outInterceptors>
    <bean
    class="org.apache.cxf.ws.security.wss4j.WSS4JOutInterceptor">
    <constructor-arg>
    <map>
    <entry key="action" value="Timestamp Signature" />
    <entry key="user" value="myservicekey" />
    <entry key="signatureKeyIdentifier"
    value="DirectReference" />
    <entry key="timeToLive" value="10800" />
    <entry key="signaturePropFile"
    value="classpath:etc/ssek.serviceKeystore.properties" />
    <entry key="passwordCallbackRef">
    <bean
    class="se.afa.ic.ssek.ServiceKeystorePasswordCallback">
    <constructor-arg>
    <value>myservicekey</value>
    </constructor-arg>
    <constructor-arg>
    <value>skpass</value>
    </constructor-arg>
    </bean>
    </entry>
    <entry key="signatureParts"
    value="{Element}{

    http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd}Timestamp;{Element}{http://schemas.xmlsoap.org/soap/envelope/}Body
    "
    />
    </map>
    </constructor-arg>
    </bean>
    </cxf:outInterceptors>
    </cxf:cxfEndpoint>

    <camelContext id="camelContext" xmlns="
    " rel="nofollow">http://camel.apache.org/schema/spring">
    <route trace="true">
    <from uri="cxf:bean:receiveOutgoingMessageEndpoint" />
    <to uri="cxf:bean:sendOutgoingMessageEndpoint" />
    </route>
    </camelContext>

    </beans>
    --
    Daniel Kulp
    dkulp@apache.org - http://dankulp.com/blog
    Talend Community Coder - http://coders.talend.com


    --
    Daniel Kulp
    dkulp@apache.org - http://dankulp.com/blog
    Talend Community Coder - http://coders.talend.com


    --
    Claus Ibsen
    -----------------
    Red Hat, Inc.
    FuseSource is now part of Red Hat
    Email: cibsen@redhat.com
    Web: http://fusesource.com
    Twitter: davsclaus
    Blog: http://davsclaus.com
    Author of Camel in Action: http://www.manning.com/ibsen

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupusers @
categoriescamel
postedNov 20, '12 at 3:02p
activeNov 27, '12 at 7:15a
posts6
users4
websitecamel.apache.org

People

Translate

site design / logo © 2022 Grokbase