cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glen Mazza <gma...@talend.com>
Subject Re: wsdl_first_https
Date Tue, 26 Jun 2012 12:10:19 GMT
When I said Endpoint.publish() I was speaking generically, meaning the 
embedded Jetty, whether activated via Java API or via Spring (as you're 
doing).  For a standalone servlet container, you'd wrap your web service 
in a WAR, and a special CXF servlet is used to host the endpoint 
(http://www.jroller.com/gmazza/entry/web_service_tutorial#WFstep5).

With Tomcat your SSL configuration will be defined with Tomcat and the 
web.xml (http://www.jroller.com/gmazza/entry/ssl_for_web_services), and 
the jaxws:endpoint element (if it has anything left in it) having a 
createdFromAPI value to "true" (I presently have a question on the CXF 
IRC on the default value of createdFromAPI, as it's not given in your 
documentation: http://cxf.apache.org/docs/jax-ws-configuration.html, but 
I think that flag will need to be added when on Tomcat.)

Glen

On 06/26/2012 03:51 AM, Himanshu Gupta wrote:
> Hey Thanks Glen,
>
> Thats exactly the plan. When we migrate from standalone java server to a
> standard app server, we would no longer need this embedded jetty stuff.
>
> Just to clarify, when you say,  Endpoint.publish() is it a problem ?. We
> use end point spring beans now (using<jaxws:endpoint>. its a spring app),
> and I assume, this would still be the case when I use a standalone servlet
> container. Am I wrong with this assumption ?
>
> Thanks,
>
>
> On Mon, Jun 25, 2012 at 6:12 PM, Glen Mazza<gmazza@talend.com>  wrote:
>
>> Oh, no, CXF doesn't embed Tomcat in that manner, we use Jetty
>> behind-the-scenes for that only.  Sorry if I misunderstood your question.
>>
>> Regarding using embedded Jetty, that could just be me but I'm more
>> comfortable seeing secure solutions implemented behind a standalone servlet
>> container, JEE server or OSGi containers instead of relying on
>> Endpoint.publish().  However, using standalone containers may still provide
>> performance advantages, better logging, easier startup/shutdown, etc., so
>> you might choose to upgrade to them in the future anyway.
>>
>> Glen
>>
>>
>> On 06/25/2012 11:54 AM, Himanshu Gupta wrote:
>>
>>> Hello Glen,
>>>
>>>   From your blog it looks like, the embedded Tomcat could be used with
>>> test,
>>> and requires a war file or exploded war.
>>>
>>> I have a spring based java stand alone server. I intend to use the web
>>> server (embedded and in memory) in productive code. I cannot produce a war
>>> like structure. I am looking for something like
>>> "JettyHTTPTransportFactory"
>>> for Tomcat if possible.
>>>
>>> I would need something like<httpj:engine-factory>   and engine, for Tomcat.
>>>
>>> PS : Is it not recommended to use embedded jetty in prod over ssl ?.
>>> That's
>>> one of the key ("highlighted") document over the cxf website :(
>>>
>>> Thanks,
>>> Himanshu.
>>>
>>>
>>>
>>> On Mon, Jun 25, 2012 at 5:25 PM, Glen Mazza<gmazza@talend.com>   wrote:
>>>
>>>   Yes, Tomcat is embeddable: www.jroller.com/gmazza/entry/****<http://www.jroller.com/gmazza/entry/**>
>>>> junit_web_service_testing#****testtc<http://www.jroller.com/**
>>>> gmazza/entry/junit_web_**service_testing#testtc<http://www.jroller.com/gmazza/entry/junit_web_service_testing#testtc>
>>>> .
>>>>
>>>> Glen
>>>>
>>>>
>>>> On 06/25/2012 11:10 AM, Himanshu Gupta wrote:
>>>>
>>>>   Hello Glen,
>>>>> Thanks for the quick response. I am using scenario 2.
>>>>>
>>>>> With Scenario 2 and
>>>>>
>>>>> 1. not using "<sec:clientAuthentication want="true" required="true"/>"
>>>>> 2. importing the server sertificate on the JDK default keystore
>>>>> "cacerts"
>>>>>
>>>>> I could see the wsdl in the web browser. The client in the sample also
>>>>> works well. Also the Dynamic client also works, because it uses the
>>>>> default
>>>>> keystore (you cannot change it for dynamic clients).
>>>>>
>>>>> Everyone's Happy, but this means any one who needs to see the wsdl on
>>>>> the
>>>>> browser would need to do 2 (i.e. import server cert on the jre default
>>>>> keystore) :(( ...
>>>>>
>>>>> Problem seems to be solved, but any Insights (explanations) would be
>>>>> helpful.
>>>>>
>>>>> PS : Glen, to your previous question, we can not use standalone tomcat,
>>>>> as
>>>>> we have a standalone java server, and we need an embedded in memory
>>>>> solution. please let me know, if this could be done using tomcat just
>>>>> like
>>>>> jetty.
>>>>>
>>>>> Thanks,
>>>>> Himanshu.
>>>>>
>>>>> On Mon, Jun 25, 2012 at 4:42 PM, Glen Mazza<gmazza@talend.com>
   wrote:
>>>>>
>>>>>   Himanshu, of the wsdl_first_https sample, which of the four scenarios
>>>>> are
>>>>>
>>>>>> you running--per that sample's README, scenarios 1 and 3 are supposed
>>>>>> to
>>>>>> fail due to lack of client credentials, while scenarios 2 and 4 should
>>>>>> work.  Also, is the problem with the running of the sample or just
you
>>>>>> viewing it from the browser?
>>>>>>
>>>>>> The blog entry you're referencing is from 2008 and covers the
>>>>>> long-obsoleted CXF 2.1 (our lowest supported version is now 2.4),
I
>>>>>> would
>>>>>> be surprised if that code still worked.  I'm not much familiar with
the
>>>>>> Dynamic Client (I don't hear much about it today), whether it
>>>>>> can/should
>>>>>> work with HTTPS (the docs for it do not give that indication[1]),
>>>>>> hopefully
>>>>>> someone else can help you here or maybe the Nabble forums can help
(
>>>>>> http://cxf.547215.n5.nabble.******com/template/NamlServlet.**jtp?****
>>>>>> macro=search_page&node=547216&******query=dynamic+client+ssl<**htt**
>>>>>> p://cxf.547215.n5.nabble.com/****template/NamlServlet.jtp?**<http://cxf.547215.n5.nabble.com/**template/NamlServlet.jtp?**>
>>>>>>
>>>>>> macro=search_page&node=547216&****query=dynamic+client+ssl<htt**
>>>>>> p://cxf.547215.n5.nabble.com/**template/NamlServlet.jtp?**
>>>>>> macro=search_page&node=547216&**query=dynamic+client+ssl<http://cxf.547215.n5.nabble.com/template/NamlServlet.jtp?macro=search_page&node=547216&query=dynamic+client+ssl>
>>>>>>> ).
>>>>>>>
>>>>>>   You might be better off with the more standard JAX-WS Dispatch
>>>>>> method[2]
>>>>>> if you can't use stub-based calls.
>>>>>>
>>>>>> Glen
>>>>>>
>>>>>> [1] http://cxf.apache.org/docs/******dynamic-clients.html<http://cxf.apache.org/docs/****dynamic-clients.html>
>>>>>> <http://**cxf.apache.org/docs/**dynamic-**clients.html<http://cxf.apache.org/docs/**dynamic-clients.html>
>>>>>> <http://**cxf.apache.org/docs/**dynamic-**clients.html<http://cxf.apache.org/docs/dynamic-**clients.html>
>>>>>> <http://**cxf.apache.org/docs/dynamic-**clients.html<http://cxf.apache.org/docs/dynamic-clients.html>
>>>>>> [2] http://www.jroller.com/gmazza/******entry/calling_rpc_encoded_**
>>>>>> **web_**<http://www.jroller.com/gmazza/****entry/calling_rpc_encoded_**web_**>
>>>>>> <http://www.jroller.**com/gmazza/**entry/calling_**rpc_encoded_web_**<http://www.jroller.com/gmazza/**entry/calling_rpc_encoded_web_**>
>>>>>> services<http://www.jroller.****com/gmazza/entry/calling_rpc_****
>>>>>> encoded_web_services<http://**www.jroller.com/gmazza/entry/**
>>>>>> calling_rpc_encoded_web_**services<http://www.jroller.com/gmazza/entry/calling_rpc_encoded_web_services>
>>>>>>
>>>>>>
>>>>>> On 06/25/2012 10:02 AM, Himanshu Gupta wrote:
>>>>>>
>>>>>>   Hello Colm,
>>>>>>
>>>>>>> In the sample wsdl_first_https, I removed
>>>>>>> line<sec:clientAuthentication
>>>>>>> want="true" required="true"/>     from the server configuration.
The
>>>>>>> Client
>>>>>>> in
>>>>>>> the example works well. But the Firefox fails, and still gives
error
>>>>>>> "javax.net.ssl.******SSLHandshakeException: no cipher suites
in
>>>>>>> common"
>>>>>>> on
>>>>>>>
>>>>>>> the
>>>>>>> server.
>>>>>>>
>>>>>>> Please let me know, If you want me to try something specific.
>>>>>>>
>>>>>>> Sorry just looking for an appropriate solution :(
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Himanshu.
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Jun 25, 2012 at 3:57 PM, Colm O hEigeartaigh<coheigea@apache.
>>>>>>> ****
>>>>>>> **
>>>>>>> org<coheigea@apache.org>>****wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>   Colm : I did add the certificates to for e.g. in the Firefox
>>>>>>> explicitly.
>>>>>>>
>>>>>>>   Yes, you added the certificates so that the browser trusted
the
>>>>>>>> service
>>>>>>>> endpoint. However, as I explained in my previous mail, the
service
>>>>>>>> endpoint
>>>>>>>> requires that the client presents its own certificate + private
key
>>>>>>>> for
>>>>>>>> client authentication, hence the failure.
>>>>>>>>
>>>>>>>> Colm.
>>>>>>>>
>>>>>>>> On Mon, Jun 25, 2012 at 2:51 PM, Himanshu Gupta<
>>>>>>>> himanshu.kgp@gmail.com
>>>>>>>>
>>>>>>>>   wrote:
>>>>>>>>
>>>>>>>>> Hello Guys,
>>>>>>>>>
>>>>>>>>> Colm : I did add the certificates to for e.g. in the
Firefox
>>>>>>>>> explicitly.
>>>>>>>>>
>>>>>>>>> Following
>>>>>>>>>
>>>>>>>>>   http://aruld.info/programming-******ssl-for-jetty-based-cxf-******<http://aruld.info/programming-****ssl-for-jetty-based-cxf-****>
>>>>>>>>>
>>>>>>>> services/<http://aruld.info/**programming-**ssl-for-jetty-**
>>>>>>>> based-cxf-**services/<http://aruld.info/programming-**ssl-for-jetty-based-cxf-**services/>
>>>>>>>> <http://aruld.info/****programming-ssl-for-jetty-****
>>>>>>>> based-cxf-services/<http://aruld.info/**programming-ssl-for-jetty-**based-cxf-services/>
>>>>>>>> <http://**aruld.info/programming-ssl-**for-jetty-based-cxf-services/<http://aruld.info/programming-ssl-for-jetty-based-cxf-services/>
>>>>>>>>   for
>>>>>>>>   my Dynamic Client, I try to do somthing like below :
>>>>>>>>
>>>>>>>>> 1. JaxWsDynamicClientFactory dcf =
>>>>>>>>>
>>>>>>>>>   JaxWsDynamicClientFactory.******newInstance();
>>>>>>>>>
>>>>>>>>   2. Client client = dcf.createClient("
>>>>>>>>
>>>>>>>>>   https://localhost:9001/******ApexCollateral/ing/services/**<https://localhost:9001/****ApexCollateral/ing/services/**>
>>>>>>>>> **<https://localhost:9001/****ApexCollateral/ing/services/**<https://localhost:9001/**ApexCollateral/ing/services/**>
>>>>>>>>> **>
>>>>>>>>>
>>>>>>>>>   wss/agreementDemo/2.0?wsdl<**htt**ps://localhost:9001/**
>>>>>>>> ApexCollateral/ing/services/****wss/agreementDemo/2.0?wsdl<htt**
>>>>>>>> ps://localhost:9001/**ApexCollateral/ing/services/**
>>>>>>>> wss/agreementDemo/2.0?wsdl<https://localhost:9001/ApexCollateral/ing/services/wss/agreementDemo/2.0?wsdl>
>>>>>>>>   ");
>>>>>>>>
>>>>>>>>> 3. configureSSLOnTheClient(******client);
>>>>>>>>> 4. Object[] res = client.invoke("******getAgreementDemoIdentifier",
>>>>>>>>> new
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Integer(1));
>>>>>>>>>
>>>>>>>>> Theoretically it should have worked, but it fails with
an exception
>>>>>>>>> like
>>>>>>>>> "org.apache.cxf.service.******factory.******
>>>>>>>>> ServiceConstructionException:
>>>>>>>>> Could not
>>>>>>>>> resolve URL "https://localhost:9001/******someService/2.0?wsdl<https://localhost:9001/****someService/2.0?wsdl>
>>>>>>>>> <https://**localhost:9001/**someService/**2.0?wsdl<https://localhost:9001/**someService/2.0?wsdl>
>>>>>>>>> <https://**localhost:9001/**someService/2.**0?wsdl<https:/**
>>>>>>>>> /localhost:9001/someService/2.**0?wsdl<https://localhost:9001/someService/2.0?wsdl>
>>>>>>>>>   ".",
>>>>>>>>> while
>>>>>>>>> excetuing *line number 2 (*logs attached*) *that is even
before
>>>>>>>>> line 3
>>>>>>>>> where I could setup the truststore, manually.
>>>>>>>>>
>>>>>>>>> I really want to use the Dynamic Client approach in the
test cases
>>>>>>>>> to
>>>>>>>>>
>>>>>>>>>   test
>>>>>>>>>
>>>>>>>>   my web services. I assume, along with the testing services,
with
>>>>>>>> this
>>>>>>>>
>>>>>>>>> approach I also validate auto code generation for clients,
which
>>>>>>>>> would
>>>>>>>>> be
>>>>>>>>> used eventually by the consumers (by exposed wsdls).
>>>>>>>>>
>>>>>>>>> Please help,
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Himanshu.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Mon, Jun 25, 2012 at 2:51 PM, Glen Mazza<gmazza@talend.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>   Personally, for SSL, I would recommend using a standalone
servlet
>>>>>>>>>
>>>>>>>>>   container like Tomcat to host your web service (
>>>>>>>>>>   http://www.jroller.com/**
>>>>>>>>>>
>>>>>>>>> gmazza/entry/ssl_for_web_********services<
>>>>>>>>> http://www.jroller.com/gmazza/******entry/ssl_for_web_services<http://www.jroller.com/gmazza/****entry/ssl_for_web_services>
>>>>>>>>> **<http://www.jroller.com/**gmazza/**entry/ssl_for_web_**services<http://www.jroller.com/gmazza/**entry/ssl_for_web_services>
>>>>>>>>> <h**ttp://www.jroller.com/**gmazza/**entry/ssl_for_web_**services<http://www.jroller.com/gmazza/**entry/ssl_for_web_services>
>>>>>>>>> <http://www.jroller.**com/gmazza/entry/ssl_for_web_**services<http://www.jroller.com/gmazza/entry/ssl_for_web_services>
>>>>>>>>> ),
>>>>>>>>> I wouldn't rely on Endpoint.publish() for production,
especially if
>>>>>>>>> you're
>>>>>>>>> using SSL.
>>>>>>>>>
>>>>>>>>>   For your dynamic client, as the link above mentions,
the certs will
>>>>>>>>>> need
>>>>>>>>>> to be in the "cacerts" file used by the JRE that
is running the
>>>>>>>>>> dynamic
>>>>>>>>>> client--or another truststore file that you configure--the
browser
>>>>>>>>>> is
>>>>>>>>>> irrelevant as it's not being used there.
>>>>>>>>>>
>>>>>>>>>> HTH,
>>>>>>>>>> Glen
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 06/25/2012 07:46 AM, Himanshu Gupta wrote:
>>>>>>>>>>
>>>>>>>>>>   Hello Experts,
>>>>>>>>>>
>>>>>>>>>>   Quite new to CXF, having a usecase where I need
to expose our
>>>>>>>>>>> existing
>>>>>>>>>>> services as webservices. App is a standalone
server, so am using
>>>>>>>>>>>
>>>>>>>>>>>   embedded
>>>>>>>>>>>
>>>>>>>>>> jetty with https. Everything works fine, except that
when I hit the
>>>>>>>>>   server
>>>>>>>>>>> with the wsdl url through a browser (any browser),
I get
>>>>>>>>>>> "javax.net.ssl.********SSLHandshakeException:
no cipher suites in
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> common".
>>>>>>>>>>>
>>>>>>>>>>> This could be reproduced if you just run the
wsdl_first_https
>>>>>>>>>>> server
>>>>>>>>>>>
>>>>>>>>>>>   and
>>>>>>>>>>>
>>>>>>>>>> hit the url https://localhost:9001/********
>>>>>>>>> SoapContext/SoapPort?wsdl<https://localhost:9001/******SoapContext/SoapPort?wsdl>
>>>>>>>>> <http**s://localhost:9001/******SoapContext/SoapPort?wsdl<https://localhost:9001/****SoapContext/SoapPort?wsdl>
>>>>>>>>> <http**s://localhost:9001/******SoapContext/SoapPort?wsdl<http**
>>>>>>>>> s://localhost:9001/****SoapContext/SoapPort?wsdl<https://localhost:9001/**SoapContext/SoapPort?wsdl>
>>>>>>>>>   <
>>>>>>>>>
>>>>>>>>>>   https://localhost:9001/******SoapContext/SoapPort?wsdl<https://localhost:9001/****SoapContext/SoapPort?wsdl>
>>>>>>>>>>> <http**s://localhost:9001/****SoapContext/SoapPort?wsdl<https://localhost:9001/**SoapContext/SoapPort?wsdl>
>>>>>>>>>> <http**s://localhost:9001/****SoapContext/SoapPort?wsdl<http**
>>>>>>>>>> s://localhost:9001/**SoapContext/SoapPort?wsdl<https://localhost:9001/SoapContext/SoapPort?wsdl>
>>>>>>>>> .
>>>>>>>>> Please help
>>>>>>>>>
>>>>>>>>>   escape this problem.
>>>>>>>>>>> Also the client in the wsdl_first_https works.
But if I try to use
>>>>>>>>>>> the
>>>>>>>>>>> Dynamic Client (thats a requirement), it fails
as well, as it
>>>>>>>>>>> could
>>>>>>>>>>> not
>>>>>>>>>>> find the wsdl. The Dynamic client looks somthing
like below :
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>   JaxWsDynamicClientFactory dcf = JaxWsDynamicClientFactory.**
>>>>>>>>>>> newInstance();
>>>>>>>>>>>          Client client = dcf.createClient("
>>>>>>>>>>> https://localhost:443/********someservice/2.0?wsdl<https://localhost:443/******someservice/2.0?wsdl>
>>>>>>>>>>> <https://**localhost:443/****someservice/**2.0?wsdl<https://localhost:443/****someservice/2.0?wsdl>
>>>>>>>>>>> <https://**localhost:443/****someservice/2.**0?wsdl<https:/**
>>>>>>>>>>> /localhost:443/**someservice/**2.0?wsdl<https://localhost:443/**someservice/2.0?wsdl>
>>>>>>>>>>> <
>>>>>>>>>>>
>>>>>>>>>>>   https://localhost:443/******someservice/2.0?wsdl<https://localhost:443/****someservice/2.0?wsdl>
>>>>>>>>>>> <https://**localhost:443/**someservice/2.**0?wsdl<https://localhost:443/**someservice/2.0?wsdl>
>>>>>>>>>> <https://**localhost:443/**someservice/2.0?**wsdl<https:/**
>>>>>>>>>> /localhost:443/someservice/2.**0?wsdl<https://localhost:443/someservice/2.0?wsdl>
>>>>>>>>> <https://**localhost/******someservice/2.0?wsdl<
>>>>>>>>>
>>>>>>>>>   https://localhost/someservice/******2.0?wsdl<https://localhost/someservice/****2.0?wsdl>
>>>>>>>>>> <https://**localhost/someservice/**2.0?**wsdl<https://localhost/someservice/**2.0?wsdl>
>>>>>>>>>> <https://localhost/****someservice/2.0?wsdl<https://localhost/**someservice/2.0?wsdl>
>>>>>>>>>> <https://**localhost/someservice/2.0?wsdl<https://localhost/someservice/2.0?wsdl>
>>>>>>>>>> **>
>>>>>>>>>>
>>>>>>>>> **>
>>>>>>>>>
>>>>>>>>>   ");
>>>>>>>>>>>          Object[] res = client.invoke(jnew
>>>>>>>>>>> QName("http://someNameSpace/<******h**ttp://somenamespace/<
>>>>>>>>>>>
>>>>>>>>>>>   http://somenamespace/>
>>>>>>>>>>>
>>>>>>>>>> ",
>>>>>>>>>   "getSomeIdentifier"), new Integer(1));
>>>>>>>>>>> PS : I have already tried adding the certs to
the browser.
>>>>>>>>>>>
>>>>>>>>>>> Thanks in Advance,
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>   --
>>>>>>>>>>>
>>>>>>>>>>>   Glen Mazza
>>>>>>>>>> Talend Community Coders
>>>>>>>>>> coders.talend.com
>>>>>>>>>> blog: www.jroller.com/gmazza
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>   --
>>>>>>>>>>
>>>>>>>>> Himanshu Gupta.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>   --
>>>>>>>>>
>>>>>>>> Colm O hEigeartaigh
>>>>>>>>
>>>>>>>> Talend Community Coder
>>>>>>>> http://coders.talend.com
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>    --
>>>>>> Glen Mazza
>>>>>> Talend Community Coders
>>>>>> coders.talend.com
>>>>>> blog: www.jroller.com/gmazza
>>>>>>
>>>>>>
>>>>>>
>>>>>>   --
>>>> Glen Mazza
>>>> Talend Community Coders
>>>> coders.talend.com
>>>> blog: www.jroller.com/gmazza
>>>>
>>>>
>>>>
>> --
>> Glen Mazza
>> Talend Community Coders
>> coders.talend.com
>> blog: www.jroller.com/gmazza
>>
>>
>


-- 
Glen Mazza
Talend Community Coders
coders.talend.com
blog: www.jroller.com/gmazza


Mime
View raw message