Hi there,
We tried out the JAXWSServerFactoryBean approach , and it worked however it
doesn’t fit our requirement.
Please look at this example we have tried out
package org.sopera.cxf.test;
import org.apache.cxf.Bus;
import org.apache.cxf.BusFactory;
import org.apache.cxf.bus.managers.DestinationFactoryManagerImpl;
import org.apache.cxf.jaxws.JaxWsServerFactoryBean;
import org.apache.cxf.transport.ConduitInitiatorManager;
import org.junit.Before;
import org.sopera.cxf.transport.SBBTransportFactory;
import org.talend.esb.HelloWorldImpl;
public class publishcxf1 {
@Before
public static void setUp() throws Exception {
Bus bus = BusFactory.getDefaultBus();
// Other way to fix the problem
// printRegistrations(bus);
DestinationFactoryManagerImpl dfm = new
DestinationFactoryManagerImpl(bus);
SBBTransportFactory sbbTransport = new SBBTransportFactory();
dfm.registerDestinationFactory("http://cxf.apache.org/transports/sbb";,
sbbTransport);
dfm.registerDestinationFactory("http://schemas.xmlsoap.org/soap/http";,
sbbTransport);
dfm.registerDestinationFactory("http://schemas.xmlsoap.org/wsdl/soap/http";,
sbbTransport);
ConduitInitiatorManager extension =
bus.getExtension(ConduitInitiatorManager.class);
extension.registerConduitInitiator("http://cxf.apache.org/transports/sbb";,
sbbTransport);
extension.registerConduitInitiator("http://schemas.xmlsoap.org/soap/http";,
sbbTransport);
extension.registerConduitInitiator("http://schemas.xmlsoap.org/wsdl/soap/http";,
sbbTransport);
}
/**
* @param args
*/
public static void main(String[] args) {
// TODO Auto-generated method stub
try{
setUp();
HelloWorldImpl hello = new HelloWorldImpl();
JaxWsServerFactoryBean sf = new JaxWsServerFactoryBean();
sf.setServiceBean(hello); // don’t want to do this
because we don’t have a bean and our design doesn’t allow it.
sf.setStart(true);
sf.setBus(BusFactory.getDefaultBus(true));
sf.create();
}catch(Exception e){
e.printStackTrace();
}
}
}
As I said previously we have custom layers which is a servlet based
implementation and we get hold of the request envelope.
I don’t want to use the service bean for the CXF framework to engage
interceptors as we don’t have the privilege to generate such a bean.
If I don’t use the bean its throwing error in DocLiteralInInterceptor in
private void validatePart(MessagePartInfo p, QName elName, Message m) {
if (p == null) {
throw new Fault(new
org.apache.cxf.common.i18n.Message("NO_PART_FOUND", LOG, elName),
Fault.FAULT_CODE_CLIENT);
}
Is it possible not to engage interceptors in the service side if we don’t have
a service bean. Basically not doing
sf.setServiceBean(hello);
we have evaluated CXF for our client side and able to leverage the power of
interceptors using dispatch API.
However we're kind of stuck at service side.
Please let us know how we could use this in our implementation which is not a
JAX-ws based implementation.
Thanks,
Santosh
-----Original Message-----
From: Daniel Kulp [mailto:[email protected]]
Sent: Monday, February 24, 2014 9:58 PM
To: [email protected]; Das, Santosh
Subject: Re: Information on using Interceptors in Service Side
On Feb 24, 2014, at 11:14 AM, Das, Santosh <[email protected]> wrote:
> Hi Andrei,
>
> While trying out the approach of custom conduit I wanted to know if
> the entry point of code can be anything other than
> Endpoint.publish()
Yes. Kind of.
You can use the JaxWsServerFactoryBean to create CXF server objects which
represent the service and manipulate that. The normal JAX-WS Endpoint object
pretty much just wrappers an Server object so MOST of the functionality would
be there. However, it’s not an “javax.xml.ws.Endpoint” object and thus code
that expects that could be problematic.
Alternatively, just "new org.apache.cxf.jaxws.EndpointImpl(….)”.
Dan
>
> What we saw is if we register create a custom destination and conduit and
> resister custom transport it eventually kicks in the interceptor chain.
> Is there any other way of engaging the interceptors?
>
>
>
> Thanks
> Santosh
>
> -----Original Message-----
> From: Andrei Shakirin [mailto:[email protected]]
> Sent: Monday, February 24, 2014 1:38 PM
> To: [email protected]
> Cc: Das, Santosh
> Subject: RE: Information on using Interceptors in Service Side
>
> Hi Santosh,
>
>
>> Excellent! That’s close to what we need.
>
> Nice, Btw I have the similar use case in the past: customer required the wire
> compatibility with legacy ESB applications (speaking SOAP with some
> proprietary extensions), but would like to use CXF and JAX-WS as frontend. It
> was resolved and implemented using CXF custom transport.
>
>> Also could you please guide to some articles which describes about saml
>> token validation at service side.
>
> I would start with a link to Glen's blog I already sent Renu: SAML using
> ws-policy: http://www.jroller.com/gmazza/entry/cxf_sts_tutorial . It covers
> obtaining and validation of SAML token using STS service.
>
> Regards,
> Andrei.
>
>
> So you are going to keep your own transport layer receiving and sending soap
> messages:
>> Servlet → getting the request soap envelope (custom layer ,don’t want
>> to use CXF) generate response (again custom layer and don’t want
>> CXF)
>
> Did I get that correctly?
>
> In this case I would consider to implement custom transport in CXF. You will
> be able to wrap your custom layer into CXF Destination and Conduit.
> The interceptor chain with security features will work natively in this case.
> Look my blog for details:
> http://ashakirin.blogspot.de/2012/02/custom-cxf-transport.html
>
> Regards,
> Andrei.
>
> From: Das, Santosh [mailto:[email protected]]
> Sent: Freitag, 21. Februar 2014 11:54
> To: Andrei Shakirin; [email protected]
> Subject: RE: Information on using Interceptors in Service Side
>
> Hi Andrei,
>
> No the idea is to swap out both XWSS api and SAML processing and use CXF
> layer in service side.
> So does CXF exposes API’s directly so that I could engage only interceptors I
> am interested in and get the functionality.
>
> The flow is like this
>
> Servlet → getting the request soap envelope (custom layer ,don’t want
> to use CXF)→engage CXF api’s directly or via interceptors(here we want
> to use CXF features like SAML validation, Ws-Security stuff) →generate
> response (again custom layer and don’t want CXF)
>
> Hope scenario is clear now.
>
> Please provide your suggestions.
>
>
> Thanks,
> Santosh
>
> From: Andrei Shakirin [mailto:[email protected]]
> Sent: Friday, February 21, 2014 4:01 PM
> To: [email protected]
> Cc: Das, Santosh
> Subject: RE: Information on using Interceptors in Service Side
>
> Hi Santosh,
>
> As I understood you are going to keep XWSS API on client and service sides,
> but would like to reuse some CXF functionality for SAML processing on the
> service side (SAML validation, holder of key check, etc).
> So the aim is not to migrate service side to CXF completely, but just reuse
> some security functionality from it.
> Is my understanding correct?
>
> I see three options here:
> A) Provide kind of CXF layer on the service side, that will receive messages
> from wire, validate security and SAML and pass SOAP messages to XWSS API
> implementation. Vice versa for outgoing chain: SOAP messages will be prepared
> in XWSS API service, CXF will be called with prepared message, apply
> necessary security and send message. CXF layer will include complete CXF
> interceptors chain and transport.
> B) Implement generic CXF gateway. CXF gateway will receive SOAP
> messages, validate them and redirect to XWSS services. Vice versa for
> outgoing chain
> C) Try to reuse only specific CXF interceptors functionality directly from
> XWSS services. Seems to be involved, because CXF security interceptors has
> some dependencies on CXF API and core.
>
> Regards,
> Andrei.
>
> From: Das, Santosh [mailto:[email protected]]
> Sent: Donnerstag, 20. Februar 2014 10:48
> To: Andrei Shakirin
> Cc: [email protected]
> Subject: FW: Information on using Interceptors in Service Side
>
> Hi Andrei,
>
> First of all many thanks for the help and support you have been providing.
>
> This is in continuation to the discussion below regarding CXF being used in
> server side.
>
> As Renu already mentioned we have a custom implementation of soap services
> which is not JAX-WS based , we are using XWSS API (a subproject of metro) and
> WSS4J directly for SAML processing.
>
> Is there any direct API which CXF exposes which can be used in the service
> side to do ws-security processing, saml validation , etc.
>
> Basically we want to use the INInterceptors in the service side and the
> engage the out interceptors after generating the soap response. Typically the
> highlighted portion of the diagram.
> We are not interested to publish the service either as we have our own
> implementation so cant use the Enpoint api.
>
>
> We are kind of stuck and wondering if CXF could be of any help Out of the box.
>
> Please advise.
>
>
>
>
>
> From: renu gupta [mailto:[email protected]]
> Sent: Thursday, February 20, 2014 2:49 PM
> To: Das, Santosh
> Subject: Fwd: Information on using Interceptors in Service Side
>
> FYI
>
> Thanks,
> Renu
> ---------- Forwarded message ----------
> From: Andrei Shakirin <[email protected]>
> Date: Thu, Feb 20, 2014 at 1:52 PM
> Subject: RE: Information on using Interceptors in Service Side
> To: "[email protected]" <[email protected]>
> Cc: renu gupta <[email protected]>
> Hi,
>
> If you will use ws-policy, it is enough to attach (embed) the policy into
> WSDL and configure necessary security parameters like keystores and alias.
> CXF will care about activation of necessary interceptors automatically.
>
> I would recommend you to look in Glen Mazza blogs:
> - UsernameToken security using ws-policy
> http://www.jroller.com/gmazza/entry/cxf_usernametoken_profile
> - SAML using ws-policy:
> http://www.jroller.com/gmazza/entry/cxf_sts_tutorial
>
> Just make that step by step, you will have a filling how it works CXF.
> If you like to understand internal ws-policy mechanisms in CXF, refer
> my blog:
> http://ashakirin.blogspot.de/2012/02/using-ws-policy-in-cxf-projects.h
> tml
>
> I hope it is helpful.
>
> Regards,
> Andrei.
>
>
> From: renu gupta [mailto:[email protected]]
> Sent: Donnerstag, 20. Februar 2014 06:09
> To: Andrei Shakirin
> Subject: Re: Information on using Interceptors in Service Side
>
> The link which you have given talks about configuration at connector end but
> I want to know how we can leverage the interceptors at services end. We are
> having our custom implementation which takes care of invocation of service,
> publishing it and doing authentication and we uses Metro for security
> feature, we want to use CXF instead of Metro and wss4j. So we don't want to
> change the whole implementation of the Services we have now , but just want
> to hook in CXF interceptors or API's if available to do the validation etc
> for the Security/ Addressing and SAML case.
>
>
> Thanks,
> Renu
>
> On Wed, Feb 19, 2014 at 9:50 PM, Andrei Shakirin <[email protected]> wrote:
> Hi,
>
> There are different ways to do that:
> a) using ws-policy – recommended way
> b) using features (WS-Addressing) and security actions configuration
> (security)
> c) configure interceptors in client/endpoint or bus level
> d) add interceptors dynamically for code
>
> I would prefer alternative (a) for WSA and SAML
> (http://cxf.apache.org/docs/ws-securitypolicy.html), but final decision
> depends on your requirements.
>
> Regards,
> Andrei.
>
> From: renu gupta [mailto:[email protected]]
> Sent: Mittwoch, 19. Februar 2014 16:31
> To: [email protected]; Andrei Shakirin
> Subject: Information on using Interceptors in Service Side
>
> Hi ,
>
> We are having our own custom service implementation which takes care of
> publishing the wsdl. We were using the Metro for the security feature and
> wss4j for the SAML support. As we are planning to leverage CXF. I have some
> doubts :
> How can we use the interceptors to achieve the particular feature like WS
> Addressing , SAML . Does CXF provides the API’s directly which we can hook ?
>
> Thanks,
> Renu
>
>
--
Daniel Kulp
[email protected] - http://dankulp.com/blog Talend Community Coder -
http://coders.talend.com
